diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-adding-hidden-file-attribute-via-attrib.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-adding-hidden-file-attribute-via-attrib.asciidoc new file mode 100644 index 0000000000..688c690e9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-adding-hidden-file-attribute-via-attrib.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-1-adding-hidden-file-attribute-via-attrib]] +=== Adding Hidden File Attribute via Attrib + +Adversaries can add the 'hidden' attribute to files to hide them from the user in an attempt to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Adding Hidden File Attribute via Attrib* + + +The `Hidden` attribute is a file or folder attribute that makes the file or folder invisible to regular directory listings when the attribute is set. + +Attackers can use this attribute to conceal tooling and malware to prevent administrators and users from finding it, even if they are looking specifically for it. + +This rule looks for the execution of the `attrib.exe` utility with a command line that indicates the modification of the `Hidden` attribute. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the command line to identify the target file or folder. + - Examine the file, which process created it, header, etc. + - If suspicious, retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Examine the host for derived artifacts that indicate suspicious activities: + - Observe and collect information about the following activities in the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "attrib.exe" or ?process.pe.original_file_name == "ATTRIB.EXE") and process.args : "+h" and + not (process.parent.name: "cmd.exe" and process.command_line: "attrib +R +H +S +A *.cui") and + + not ( + process.parent.name: "draw.io.exe" and + ( + process.command_line : ("*drawio.bkp*", "*drawio.dtmp*") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Windows File and Directory Permissions Modification +** ID: T1222.001 +** Reference URL: https://attack.mitre.org/techniques/T1222/001/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-ssm-command-document-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-ssm-command-document-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..297f1d5328 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-ssm-command-document-created-by-rare-user.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-1-aws-ssm-command-document-created-by-rare-user]] +=== AWS SSM Command Document Created by Rare User + +Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html +* https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Execution + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Command Document Created by Rare User* + + +This rule identifies when an AWS Systems Manager (SSM) command document is created by a user who does not typically perform this action. Creating SSM command documents can be a legitimate action but may also indicate malicious intent if done by an unusual or compromised user. Adversaries may leverage SSM documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, or data exfiltration. + + +*Possible Investigation Steps* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify who created the SSM document. Verify if this user typically creates such documents and has the appropriate permissions. It may be unexpected for certain types of users, like assumed roles or federated users, to perform this action. +- **Analyze the Document Details**: + - **Document Name**: Check the `aws.cloudtrail.request_parameters.name` field for the document name to understand its intended purpose. + - **Document Content**: If possible, review `aws.cloudtrail.request_parameters.content` for any sensitive or unexpected instructions (e.g., actions for data exfiltration or privilege escalation). If not available via logs, consider reviewing the document in the AWS Management Console. +- **Contextualize the Activity with Related Events**: Look for other CloudTrail events involving the same user ARN or IP address (`source.ip`). Examine actions performed in other AWS services, such as IAM, EC2, or S3, to identify if additional suspicious behavior exists. The `SendCommand` API call may indicate attempts to execute the SSM document on managed instances. +- **Check Document Status and Metadata**: + - **Document Status**: Confirm the document creation status in `aws.cloudtrail.response_elements.documentDescription.status`. A status of `Creating` may indicate that the document is in progress. + - **Execution Permissions**: Review if the document specifies `platformTypes` and `documentVersion` in `aws.cloudtrail.response_elements.documentDescription` to understand which environments may be impacted and if multiple versions exist. + + +*False Positive Analysis* + + +- **Authorized Administrative Actions**: Determine if this document creation aligns with scheduled administrative tasks or actions by authorized personnel. +- **Historical User Actions**: Compare this action against historical activities for the user to determine if they have a history of creating similar documents, which may indicate legitimate usage. + + +*Response and Remediation* + + +- **Immediate Document Review and Deletion**: If the document creation is deemed unauthorized, delete the document immediately and check for other similar documents created recently. +- **Enhance Monitoring and Alerts**: Configure additional monitoring for SSM document creation events, especially when associated with untrusted or rare users. +- **Policy Update**: Consider restricting SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation. +- **Incident Response**: If the document is confirmed as part of malicious activity, treat this as a security incident. Follow incident response protocols, including containment, investigation, and remediation. + + +*Additional Information* + + +For further guidance on managing and securing AWS Systems Manager in your environment, refer to the https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html[AWS SSM documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and event.action: "CreateDocument" + and event.outcome: "success" + and aws.cloudtrail.flattened.response_elements.documentDescription.documentType: "Command" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-ssm-sendcommand-execution-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-ssm-sendcommand-execution-by-rare-user.asciidoc new file mode 100644 index 0000000000..ff62662fd0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-ssm-sendcommand-execution-by-rare-user.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-1-aws-ssm-sendcommand-execution-by-rare-user]] +=== AWS SSM `SendCommand` Execution by Rare User + +Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Use Case: Log Auditing +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM `SendCommand` Execution by Rare User* + + +This rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells. + + +*Possible Investigation Steps* + + +- **Identify the Target Instance**: + - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.instanceIds` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM. + - **Document Used**: Check the `aws.cloudtrail.flattened.request_parameters.documentName` field, which specifies the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access. + - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior. + +- **Analyze Command Parameters**: + - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities. + - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack. + +- **Check User Agent and Source IP**: + - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually. + - **Source IP and Geolocation**: Use `source.ip` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries. + +- **Evaluate for Persistence Indicators**: + - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access. + - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions. + +- **Correlate with Other CloudTrail Events**: + - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation. + - **Monitor Data Access or Modification**: Correlate with S3 access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities. + + +*False Positive Analysis* + + +- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows. +- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances. + + +*Response and Remediation* + + +- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access. +- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration. +- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary. +- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place. + + +*Additional Information* + + +For further details on managing AWS SSM and security best practices for EC2 instances, refer to the https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html[AWS Systems Manager Documentation] and AWS best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and event.action: "SendCommand" + and event.outcome: "success" + and not source.address: ( + "ssm-guiconnect.amazonaws.com" or + "ssm.amazonaws.com" or + "inspector2.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-sts-role-assumption-by-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-sts-role-assumption-by-service.asciidoc new file mode 100644 index 0000000000..a876ec20f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-sts-role-assumption-by-service.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-1-aws-sts-role-assumption-by-service]] +=== AWS STS Role Assumption by Service + +Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Lateral Movement + +*Version*: 213 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS Role Assumption by Service* + + +This rule identifies instances where AWS STS (Security Token Service) is used to assume a role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment. + + +*Possible Investigation Steps* + + +- **Identify the Actor and Assumed Role**: + - **User Identity**: Review the `aws.cloudtrail.user_identity.invoked_by` field to determine which service initiated the `AssumeRole` action. + - **Role Assumed**: Check the `aws.cloudtrail.resources.arn` field to confirm the assumed role and ensure it aligns with expected responsibilities. + - **Session Name**: Observe the `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the session's intended purpose, if available. + - **Expiration Time**: Verify `aws.cloudtrail.flattened.response_elements.credentials.expiration` to determine when the credentials expire or expired. + +- **Inspect the User Agent for Tooling Identification**: + - **User Agent Details**: Review the `user_agent.original` field to identify the tool or SDK used for the role assumption. Indicators include: + - **AWS SDKs (e.g., Boto3)**: Often used in automated workflows or scripts. + - **AWS CLI**: Suggests command-line access, potentially indicating direct user interaction. + - **Custom Tooling**: Unusual user agents may signify custom or suspicious tools. + +- **Contextualize with Related Events**: + - **Review Event Patterns**: Check surrounding CloudTrail events to see if other actions coincide with this `AssumeRole` activity, such as attempts to access sensitive resources. + - **Identify High-Volume Exceptions**: Due to the potential volume of `AssumeRole` events, determine common, legitimate `roleArn` values or `user_agent` patterns, and consider adding these as exceptions to reduce noise. + +- **Evaluate the Privilege Level of the Assumed Role**: + - **Permissions**: Inspect permissions associated with the assumed role to understand its access level. + - **Authorized Usage**: Confirm whether the role is typically used for administrative purposes and if the assuming entity frequently accesses it as part of regular responsibilities. + + +*False Positive Analysis* + + +- **Automated Workflows and Applications**: Many applications or scheduled tasks may assume roles for standard operations. Check user agents and ARNs for consistency with known workflows. +- **Routine AWS Service Actions**: Historical data may reveal if the same service assumes new roles regularly as part of authorized operations. + + +*Response and Remediation* + + +- **Revoke Unauthorized Sessions**: If unauthorized, consider revoking the session by adjusting IAM policies or permissions associated with the assumed role. +- **Enhance Monitoring and Alerts**: Set up enhanced monitoring for high-risk roles, especially those with elevated privileges. +- **Manage Exceptions**: Regularly review and manage high-frequency roles and user agent patterns, adding trusted ARNs and user agents to exception lists to minimize alert fatigue. +- **Incident Response**: If malicious behavior is identified, follow incident response protocols, including containment, investigation, and remediation. + + +*Additional Information* + + +For more information on managing and securing AWS STS, refer to the https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html[AWS STS documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRole" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "AWSService" + and aws.cloudtrail.user_identity.invoked_by: ( + "ec2.amazonaws.com" or + "lambda.amazonaws.com" or + "rds.amazonaws.com" or + "ssm.amazonaws.com" or + "ecs-tasks.amazonaws.com" or + "ecs.amazonaws.com" or + "eks.amazonaws.com" or + "eks-fargate.amazonaws.com" or + "codepipeline.amazonaws.com" or + "codebuild.amazonaws.com" or + "autoscaling.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-sts-role-assumption-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-sts-role-assumption-by-user.asciidoc new file mode 100644 index 0000000000..b847a05b06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-aws-sts-role-assumption-by-user.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-1-aws-sts-role-assumption-by-user]] +=== AWS STS Role Assumption by User + +Identifies when a user or role has assumed a role in AWS Security Token Service (STS). Users can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Lateral Movement + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS Role Assumption by User* + + +This rule detects when a user assumes a role in AWS Security Token Service (STS), receiving temporary credentials to access AWS resources. While often used for legitimate purposes, this action can be leveraged by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment. + + +*Possible Investigation Steps* + + +- **Identify the User and Assumed Role**: + - **User Identity**: Check `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` for details about the initiator of the `AssumeRole` action. + - **Role Assumed**: Review `aws.cloudtrail.resources.arn` to confirm the role assumed and ensure it aligns with the user’s standard permissions. + - **Session Name**: Note `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the purpose of the session. + - **Expiration Time**: Use `aws.cloudtrail.flattened.response_elements.credentials.expiration` to confirm the credential expiration. + +- **Inspect User Agent and Source Information**: + - **User Agent**: Analyze the `user_agent.original` field to identify if specific tooling or SDKs like AWS CLI, Boto3, or custom agents were used. + - **Source IP and Geolocation**: Examine `source.ip` and `source.geo` fields to determine the origin of the request, confirming if it aligns with expected locations. + +- **Correlate with Related Events**: + - **Identify Patterns**: Review related CloudTrail events for unusual access patterns, such as resource access or sensitive actions following this `AssumeRole` action. + - **Filter High-Volume Roles**: If this role or user has a high volume of access, evaluate `roleArn` or `user_agent` values for common patterns and add trusted entities as exceptions. + +- **Review the Privileges of the Assumed Role**: + - **Permissions**: Examine permissions associated with the `roleArn` to assess its access scope. + - **Authorized Usage**: Confirm if the role is used frequently for administrative purposes and if this aligns with the user’s regular responsibilities. + + +*False Positive Analysis* + + +- **Automated Processes and Applications**: Applications or scheduled tasks may assume roles regularly for operational purposes. Validate the consistency of the `user_agent` or `roleArn` with known automated workflows. +- **Standard IAM Policy Usage**: Confirm if the user or application routinely assumes new roles for normal operations by reviewing historical activity. + + +*Response and Remediation* + + +- **Terminate Unauthorized Sessions**: If the role assumption is deemed unauthorized, revoke the session by modifying IAM policies or the permissions associated with the assumed role. +- **Strengthen Monitoring and Alerts**: Implement additional monitoring for specific high-risk roles, especially those with elevated permissions. +- **Regularly Manage Exceptions**: Regularly review high-volume roles and user agent patterns to refine alerts, minimizing noise by adding trusted patterns as exceptions. +- **Incident Response**: If confirmed as malicious, follow incident response protocols for containment, investigation, and remediation. + + +*Additional Information* + + +For more details on managing and securing AWS STS in your environment, refer to the https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html[AWS STS documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRole" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: ("AssumedRole" or "IAMUser") + +---------------------------------- + +*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/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-docker-release-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-docker-release-file-creation.asciidoc new file mode 100644 index 0000000000..de4ce7702f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-docker-release-file-creation.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-1-docker-release-file-creation]] +=== Docker Release File Creation + +This rule detects the creation of files named release_agent or notify_on_release, which are commonly associated with the abuse of Linux cgroup release mechanisms. In Docker or containerized environments, this behavior may indicate an attempt to exploit privilege escalation vulnerabilities such as CVE-2022-0492, where attackers use the release_agent feature to execute code on the host from within a container. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/ + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 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 Docker Release File Creation* + + +In Linux, cgroups manage resources for processes, and the release_agent file can execute scripts when a cgroup is released. In containerized environments like Docker, adversaries may exploit this to escalate privileges, executing code on the host. The detection rule identifies the creation of files like release_agent, signaling potential misuse of cgroup release mechanisms for privilege escalation. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file creation event occurred on a Linux host, as specified by the query field host.os.type == "linux". +- Identify the specific file name created, either release_agent or notify_on_release, to understand the potential method of exploitation. +- Investigate the process that created the file by examining process logs or using process monitoring tools to determine if it was initiated by a legitimate application or a suspicious process. +- Check for any recent container activity on the host, such as new container deployments or changes, to identify potential sources of the file creation. +- Analyze user activity logs to determine if any unauthorized or unusual user actions correlate with the file creation event. +- Look for any additional indicators of compromise or related alerts on the host that might suggest a broader attack or exploitation attempt. +- Assess the system for any signs of privilege escalation or unauthorized access to determine if the release_agent or notify_on_release file creation was part of a successful attack. + + +*False positive analysis* + + +- System administrators or automated scripts may create release_agent or notify_on_release files for legitimate resource management tasks in containerized environments. +- Regularly scheduled maintenance scripts might trigger the rule if they involve creating or modifying cgroup release files as part of their operations. +- Developers testing container features might inadvertently create these files during the development process. +- To handle these false positives, users can create exceptions for known scripts or processes that routinely create these files by whitelisting their specific paths or process names. +- Implement monitoring to differentiate between expected and unexpected file creation events, focusing on unusual patterns or contexts that deviate from normal operations. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further exploitation or lateral movement. This can be done by stopping the container or disconnecting it from the network. +- Investigate the container's logs and processes to identify any unauthorized or suspicious activity that may have occurred as a result of the release_agent or notify_on_release file creation. +- Remove any unauthorized files or scripts that were executed as a result of the cgroup release mechanism exploitation. Ensure that the release_agent and notify_on_release files are deleted if they were created maliciously. +- Patch the host system and all containers to address known vulnerabilities such as CVE-2022-0492. Ensure that all security updates are applied to prevent similar exploits. +- Review and tighten the security configurations of Docker and the host system, including setting appropriate cgroup permissions and limiting container capabilities to the minimum necessary. +- Monitor for any further attempts to exploit cgroup release mechanisms by setting up alerts for the creation of release_agent and notify_on_release files. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may have been affected or if there is a broader security incident underway. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and file.name in ("release_agent", "notify_on_release") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-dynamic-iex-reconstruction-via-method-string-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-dynamic-iex-reconstruction-via-method-string-access.asciidoc new file mode 100644 index 0000000000..77bed3e416 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-dynamic-iex-reconstruction-via-method-string-access.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-1-dynamic-iex-reconstruction-via-method-string-access]] +=== Dynamic IEX Reconstruction via Method String Access + +Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 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 Dynamic IEX Reconstruction via Method String Access* + + +PowerShell's flexibility allows dynamic command execution, which adversaries exploit by obfuscating commands like Invoke-Expression (IEX). They manipulate method strings to reconstruct IEX, evading static detection. The detection rule identifies scripts using this obfuscation by analyzing patterns in method string access, flagging suspicious activity for further investigation. + + +*Possible investigation steps* + + +- Review the powershell.file.script_block_text field to understand the content and intent of the script that triggered the alert. Look for any suspicious patterns or obfuscation techniques. +- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy. +- Check the host.name and user.id fields to identify the machine and user account involved in executing the script, which can help assess whether the activity aligns with expected behavior. +- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other PowerShell activities on the host, providing a broader view of the script's execution context. +- Investigate the agent.id field to verify the endpoint's security posture and ensure that it is up-to-date with the latest security patches and configurations. + + +*False positive analysis* + + +- Scripts with legitimate use of string manipulation methods like IndexOf or SubString may trigger false positives if they are part of complex PowerShell scripts used in administrative tasks. To manage this, review the context of the script and consider adding exceptions for known safe scripts or users. +- Automated scripts from trusted software that perform extensive string operations for configuration or data processing might be flagged. Identify these scripts and exclude them by their script block ID or file path to prevent unnecessary alerts. +- Development environments where PowerShell is used for testing or debugging purposes may generate alerts due to frequent use of string manipulation. Implement exclusions based on host names or user IDs associated with these environments to reduce noise. +- Security tools or monitoring solutions that use PowerShell for log analysis or system checks might inadvertently match the detection pattern. Verify the source of the script and whitelist these tools by agent ID or specific script characteristics. +- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network. +- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity. +- Review the PowerShell script block text and script block ID from the alert to understand the scope and intent of the obfuscation technique used. +- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Restore the affected system from a known good backup if the integrity of the system is compromised and cannot be assured. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Look for scripts with more than 500 chars that contain a related keyword +| EVAL script_len = LENGTH(powershell.file.script_block_text) +| WHERE script_len > 500 + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """(?i)['"]['"].(Insert|Normalize|Chars|SubString|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\[]+\[\d+,\d+,\d+\]""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-entra-id-rt-to-prt-transition-from-same-user-and-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-entra-id-rt-to-prt-transition-from-same-user-and-device.asciidoc new file mode 100644 index 0000000000..fd812ce0c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-entra-id-rt-to-prt-transition-from-same-user-and-device.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-1-entra-id-rt-to-prt-transition-from-same-user-and-device]] +=== Entra ID RT to PRT Transition from Same User and Device + +Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Tactic: Persistence +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID RT to PRT Transition from Same User and Device* + + +This rule identifies a sequence where a Microsoft Entra ID user signs in using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by a sign-in using a Primary Refresh Token (PRT) from the same device. This behavior is uncommon for normal user activity and strongly suggests adversarial behavior, particularly when paired with OAuth phishing and device registration tools like ROADtx. The use of PRT shortly after a refresh token sign-in typically indicates the attacker has obtained device trust and is now using the PRT to impersonate a fully compliant user+device pair. + + +*Possible investigation steps* + +- Identify the user principal and device from `azure.signinlogs.properties.user_principal_name` and `azure.signinlogs.properties.device_detail.device_id`. +- Confirm the first sign-in event came from the Microsoft Auth Broker (`app_id`) with `incoming_token_type: refreshToken`. +- Ensure the device has a `trust_type` of "Azure AD joined" and that the `sign_in_session_status` is "unbound". +- Confirm the second sign-in used `incoming_token_type: primaryRefreshToken` and that the `resource_display_name` is not "Device Registration Service". +- Investigate any Microsoft Graph, Outlook, or SharePoint access occurring shortly after. +- Review conditional access policy outcomes and determine whether MFA or device compliance was bypassed. + + +*False positive analysis* + +- Legitimate device onboarding and sign-ins using hybrid-joined endpoints may trigger this rule. +- Rapid device provisioning in enterprise environments using MAB could generate similar token behavior. +- Use supporting signals, such as IP address changes, geolocation, or user agent anomalies, to reduce noise. + + +*Response and remediation* + +- Investigate other sign-in patterns and assess whether token abuse has occurred. +- Revoke PRT sessions via Microsoft Entra ID or Conditional Access. +- Remove or quarantine the suspicious device registration. +- Require password reset and enforce MFA. +- Audit and tighten device trust and conditional access configurations. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1h + [authentication where + event.dataset == "azure.signinlogs" and + azure.signinlogs.category == "NonInteractiveUserSignInLogs" and + azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.incoming_token_type == "refreshToken" and + azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and + azure.signinlogs.properties.device_detail.device_id != null and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and + azure.signinlogs.properties.user_type == "Member" and + azure.signinlogs.result_signature == "SUCCESS" + ] + [authentication where + event.dataset == "azure.signinlogs" and + azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and + azure.signinlogs.properties.resource_display_name != "Device Registration Service" and + azure.signinlogs.result_signature == "SUCCESS" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-entra-id-user-signed-in-from-unusual-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-entra-id-user-signed-in-from-unusual-device.asciidoc new file mode 100644 index 0000000000..631ec75e61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-entra-id-user-signed-in-from-unusual-device.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-1-entra-id-user-signed-in-from-unusual-device]] +=== Entra ID User Signed In from Unusual Device + +Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Signed In from Unusual Device* + + +This rule detects when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. + + +*Possible investigation steps* + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user associated with the sign-in. +- Check the `azure.signinlogs.properties.device_detail.device_id` field to identify the device used for the sign-in. +- Review `azure.signinlogs.properties.incoming_token_type` to determine what tpe of security token was used for the sign-in, such as a Primary Refresh Token (PRT). +- Examine `azure.signinlogs.category` to determine if these were non-interactive or interactive sign-ins. +- Check the geolocation of the sign-in by reviewing `source.geo.country_name` and `source.geo.city_name` to identify the location of the device used for the sign-in. If these are unusual for the user, it may indicate a potential compromise. +- Review `azure.signinlogs.properties.app_id` to determine which client application was used for the sign-in. If the application is not recognized or expected, it may indicate unauthorized access. Adversaries use first-party client IDs to blend in with legitimate traffic. +- Examine `azure.signinlogs.properties.resource_id` to determine what resource the security token has in scope and/or is requesting access to. If the resource is not recognized or expected, it may indicate unauthorized access. Excessive access to Graph API is common post-compromise behavior. +- Review the identity protection risk status by checking `azure.signinlogs.properties.risk_level` and `azure.signinlogs.properties.risk_detail` to determine if the sign-in was flagged as risky by Entra ID Protection. + + +*False positive analysis* + +- Legitimate users may sign in from new devices, such as when using a new laptop or mobile device. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or device IDs. +- Environments where users frequently change devices, such as in a corporate setting with rotating hardware, may generate false positives. +- Users may use both an endpoint and mobile device for sign-ins, which could trigger this rule. + + +*Response and remediation* + +- If the sign-in is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Identify the registered Entra ID device by reviewing `azure.signinlogs.properties.device_detail.display_name` and confirm it is expected for the user or organization. If it is not expected, consider removing the device registration. +- Consider adding exceptions for verified devices that are known to be used by the user to reduce false-positives. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "azure.signinlogs" and + event.category: "authentication" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and + not azure.signinlogs.properties.device_detail.device_id: "" and + azure.signinlogs.properties.user_principal_name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-excessive-microsoft-365-mailbox-items-accessed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-excessive-microsoft-365-mailbox-items-accessed.asciidoc new file mode 100644 index 0000000000..102f063228 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-excessive-microsoft-365-mailbox-items-accessed.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-1-excessive-microsoft-365-mailbox-items-accessed]] +=== Excessive Microsoft 365 Mailbox Items Accessed + +Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts#use-mailitemsaccessed-audit-records-for-forensic-investigations +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Excessive Microsoft 365 Mailbox Items Accessed* + + +Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. + + +*Possible investigation steps* + +- Review `host.name` to identify the tenant where the mailbox access occurred. +- Review `o365.audit.UserId` or `o365.audit.MailboxOwnerUPN` to identify the user associated with the mailbox access. +- Examine `o365.audit.ExternalAccess` to determine if the mailbox access was performed by an external user or application. +- Check the geolocation data to identify the location from which the mailbox access occurred. Is this an expected location for the user? +- Check `o365.audit.ClientAppId` to identify the application used for mailbox access. Look for any unusual or unexpected applications but be aware that some legitimate applications may also trigger this rule if OAuth phishing was used. +- Review `o365.audit.Folders.Path` and `o365.audit.Folders.FolderItems.Id` to identify the specific folders and items accessed within the mailbox. Look for any sensitive or high-value folders that may indicate targeted access. +- For specific items accessed, examine `o365.audit.Folders.FolderItems.Id` to gather more context on the accessed mailbox items. +- User types can be identified by checking `o365.audit.UserType`. Review if the mailbox of the user is a member, admin or delegate. +- If Entra ID logs are available, checking the risk status via `azure.signinlogs.properties.risk_state` and `azure.signinlogs.properties.risk_level` can provide additional context on the user's risk status during the mailbox access. + + +*False positive analysis* + +- Legitimate users may access a large number of mailbox items in a short period, especially in environments with high email volume or during data migrations. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups. +- Automated processes or scripts that access mailbox items may also trigger this rule. If these processes are legitimate and necessary, consider adding exceptions for the specific applications or users involved. +- Users with high email activity, such as helpdesk or support roles, may trigger this rule due to their job responsibilities. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups. + + +*Response and remediation* + +- Investigate the user account associated with the excessive mailbox access to determine if it has been compromised or if the activity is expected behavior. +- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Examine how the mailbox access was performed. If it was done via a third-party application, review the permissions granted to that application and consider revoking them if they are not necessary. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "o365.audit" and + event.provider: "Exchange" and + event.action: "MailItemsAccessed" and + event.code: "ExchangeItemAggregated" and + ( + ( + o365.audit.OperationProperties.Name: "IsThrottled" and + o365.audit.OperationProperties.Value: "True" + ) or o365.audit.OperationCount >= 100 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-first-time-seen-commonly-abused-remote-access-tool-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-first-time-seen-commonly-abused-remote-access-tool-execution.asciidoc new file mode 100644 index 0000000000..1bfade5971 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-first-time-seen-commonly-abused-remote-access-tool-execution.asciidoc @@ -0,0 +1,315 @@ +[[prebuilt-rule-8-19-1-first-time-seen-commonly-abused-remote-access-tool-execution]] +=== First Time Seen Commonly Abused Remote Access Tool Execution + +Adversaries may install legitimate remote access tools (RAT) to compromised endpoints for further command-and-control (C2). Adversaries can rely on installed RATs for persistence, execution of native commands and more. This rule detects when a process is started whose name or code signature resembles commonly abused RATs. This is a New Terms rule type indicating the host has not seen this RAT process started before within the last 30 days. + +*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://attack.mitre.org/techniques/T1219/ +* https://github.com/redcanaryco/surveyor/blob/master/definitions/remote-admin.json + +*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 + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Commonly Abused Remote Access Tool Execution* + + +Remote access software is a class of tools commonly used by IT departments to provide support by connecting securely to users' computers. Remote access is an ever-growing market where new companies constantly offer new ways of quickly accessing remote systems. + +At the same pace as IT departments adopt these tools, the attackers also adopt them as part of their workflow to connect into an interactive session, maintain access with legitimate software as a persistence mechanism, drop malicious software, etc. + +This rule detects when a remote access tool is seen in the environment for the first time in the last 15 days, enabling analysts to investigate and enforce the correct usage of such tools. + + +*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. +- Check if the execution of the remote access tool is approved by the organization's IT department. +- 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. + - If the tool is not approved for use in the organization, the employee could have been tricked into installing it and providing access to a malicious third party. Investigate whether this third party could be attempting to scam the end-user or gain access to the environment through social engineering. +- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes. + + +*False positive analysis* + + +- If an authorized support person or administrator used the tool to conduct legitimate support or remote access, consider reinforcing that only tooling approved by the IT policy should be used. The analyst can dismiss the alert if no other suspicious behavior is observed involving the host or users. + + +*Response 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 scan using the antimalware tool in place. This scan can 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. +- If an unauthorized third party did the access via social engineering, consider improvements to the security awareness program. +- Enforce that only tooling approved by the IT policy should be used for remote access purposes and only by authorized staff. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type: "windows" and + + event.category: "process" and event.type : "start" and + + ( + process.code_signature.subject_name : ( + "Action1 Corporation" or + "AeroAdmin LLC" or + "Ammyy LLC" or + "Atera Networks Ltd" or + "AWERAY PTE. LTD." or + "BeamYourScreen GmbH" or + "Bomgar Corporation" or + "DUC FABULOUS CO.,LTD" or + "DOMOTZ INC." or + "DWSNET OÜ" or + "FleetDeck Inc" or + "GlavSoft LLC" or + "GlavSoft LLC." or + "Hefei Pingbo Network Technology Co. Ltd" or + "IDrive, Inc." or + "IMPERO SOLUTIONS LIMITED" or + "Instant Housecall" or + "ISL Online Ltd." or + "LogMeIn, Inc." or + "Monitoring Client" or + "MMSOFT Design Ltd." or + "Nanosystems S.r.l." or + "NetSupport Ltd" or + "NetSupport Ltd." or + "NETSUPPORT LTD." or + "NinjaRMM, LLC" or + "Parallels International GmbH" or + "philandro Software GmbH" or + "Pro Softnet Corporation" or + "RealVNC" or + "RealVNC Limited" or + "BreakingSecurity.net" or + "Remote Utilities LLC" or + "Rocket Software, Inc." or + "SAFIB" or + "Servably, Inc." or + "ShowMyPC INC" or + "Splashtop Inc." or + "Superops 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 + + process.name.caseless : ( + AA_v*.exe or + "AeroAdmin.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 + "domotzagent.exe" or + "domotz-windows-x64-10.exe" or + "dwagsvc.exe" or + "DWRCC.exe" or + "ImperoClientSVC.exe" or + "ImperoServerSVC.exe" or + "ISLLight.exe" or + "ISLLightClient.exe" or + fleetdeck_commander*.exe or + "getscreen.exe" or + "LMIIgnition.exe" or + "LogMeIn.exe" or + "ManageEngine_Remote_Access_Plus.exe" or + "Mikogo-Service.exe" or + "NinjaRMMAgent.exe" or + "NinjaRMMAgenPatcher.exe" or + "ninjarmm-cli.exe" or + "r_server.exe" or + "radmin.exe" or + "radmin3.exe" or + "RCClient.exe" or + "RCService.exe" or + "RemoteDesktopManager.exe" or + "RemotePC.exe" or + "RemotePCDesktop.exe" or + "RemotePCService.exe" or + "rfusclient.exe" or + "ROMServer.exe" or + "ROMViewer.exe" or + "RPCSuite.exe" or + "rserver3.exe" or + "rustdesk.exe" or + "rutserv.exe" or + "rutview.exe" or + "saazapsc.exe" or + ScreenConnect*.exe or + "smpcview.exe" or + "spclink.exe" or + "Splashtop-streamer.exe" or + "SRService.exe" or + "strwinclt.exe" or + "Supremo.exe" or + "SupremoService.exe" or + "teamviewer.exe" or + "TiClientCore.exe" or + "TSClient.exe" or + "tvn.exe" or + "tvnserver.exe" or + "tvnviewer.exe" or + UltraVNC*.exe or + UltraViewer*.exe or + "vncserver.exe" or + "vncviewer.exe" or + "winvnc.exe" or + "winwvc.exe" or + "Zaservice.exe" or + "ZohoURS.exe" + ) or + process.name : ( + AA_v*.exe or + "AeroAdmin.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 + "domotzagent.exe" or + "domotz-windows-x64-10.exe" or + "dwagsvc.exe" or + "DWRCC.exe" or + "ImperoClientSVC.exe" or + "ImperoServerSVC.exe" or + "ISLLight.exe" or + "ISLLightClient.exe" or + fleetdeck_commander*.exe or + "getscreen.exe" or + "LMIIgnition.exe" or + "LogMeIn.exe" or + "ManageEngine_Remote_Access_Plus.exe" or + "Mikogo-Service.exe" or + "NinjaRMMAgent.exe" or + "NinjaRMMAgenPatcher.exe" or + "ninjarmm-cli.exe" or + "r_server.exe" or + "radmin.exe" or + "radmin3.exe" or + "RCClient.exe" or + "RCService.exe" or + "RemoteDesktopManager.exe" or + "RemotePC.exe" or + "RemotePCDesktop.exe" or + "RemotePCService.exe" or + "rfusclient.exe" or + "ROMServer.exe" or + "ROMViewer.exe" or + "RPCSuite.exe" or + "rserver3.exe" or + "rustdesk.exe" or + "rutserv.exe" or + "rutview.exe" or + "saazapsc.exe" or + ScreenConnect*.exe or + "smpcview.exe" or + "spclink.exe" or + "Splashtop-streamer.exe" or + "SRService.exe" or + "strwinclt.exe" or + "Supremo.exe" or + "SupremoService.exe" or + "teamviewer.exe" or + "TiClientCore.exe" or + "TSClient.exe" or + "tvn.exe" or + "tvnserver.exe" or + "tvnviewer.exe" or + UltraVNC*.exe or + UltraViewer*.exe or + "vncserver.exe" or + "vncviewer.exe" or + "winvnc.exe" or + "winwvc.exe" or + "Zaservice.exe" or + "ZohoURS.exe" + ) + ) and + + not (process.pe.original_file_name : ("G2M.exe" or "Updater.exe" or "powershell.exe") and process.code_signature.subject_name : "LogMeIn, Inc.") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-first-time-seen-newcredentials-logon-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-first-time-seen-newcredentials-logon-process.asciidoc new file mode 100644 index 0000000000..918465438a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-first-time-seen-newcredentials-logon-process.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-1-first-time-seen-newcredentials-logon-process]] +=== First Time Seen NewCredentials Logon Process + +Identifies a new credentials logon type performed by an unusual process. This may indicate the existence of an access token forging capability that are often abused to bypass access control restrictions. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/pt/blog/how-attackers-abuse-access-token-manipulation + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*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 First Time Seen NewCredentials Logon Process* + + +The NewCredentials logon type in Windows allows processes to impersonate a user without requiring a new logon session, often used for legitimate tasks like network resource access. However, adversaries can exploit this by forging access tokens to escalate privileges and bypass controls. The detection rule identifies unusual processes performing this logon type, excluding known system paths and service accounts, to flag potential misuse indicative of token manipulation attacks. + + +*Possible investigation steps* + + +- Review the process executable path to determine if it is a known or expected application, especially since the query excludes common system paths like Program Files. +- Investigate the SubjectUserName to identify the user account associated with the logon event and determine if it is a legitimate user or a potential compromised account. +- Check the historical activity of the identified process and user account to see if this behavior is consistent with past actions or if it is anomalous. +- Correlate the event with other security logs to identify any preceding or subsequent suspicious activities, such as failed logon attempts or unusual network connections. +- Assess the environment for any recent changes or incidents that might explain the unusual logon process, such as software updates or new application deployments. +- Consult threat intelligence sources to determine if the process or behavior is associated with known malicious activity or threat actors. + + +*False positive analysis* + + +- Legitimate administrative tools or scripts may trigger this rule if they use the NewCredentials logon type for network resource access. To manage this, identify and whitelist these tools by their process executable paths. +- Scheduled tasks or automated processes running under service accounts might be flagged. Review these tasks and exclude them by adding exceptions for known service account names. +- Software updates or installations that require elevated privileges could cause false positives. Monitor these activities and create exceptions for the specific processes involved in regular update cycles. +- Custom in-house applications that use impersonation for legitimate purposes may be detected. Work with development teams to document these applications and exclude their process paths from the rule. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as using the NewCredentials logon type that are not part of known system paths or service accounts. +- Revoke any potentially compromised access tokens and reset credentials for affected user accounts to prevent further misuse. +- Conduct a thorough review of recent logon events and process executions on the affected system to identify any additional unauthorized activities or compromised accounts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring for similar suspicious logon activities across the network to detect and respond to potential future attempts promptly. +- Review and update access control policies and token management practices to mitigate the risk of access token manipulation in the future. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"authentication" and host.os.type:"windows" and winlog.logon.type:"NewCredentials" and + winlog.event_data.LogonProcessName:Advapi* and + not winlog.event_data.SubjectUserName:*$ and + not process.executable: (C\:\\Program*Files*\(x86\)\\*.exe or C\:\\Program*Files\\*.exe) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Token Impersonation/Theft +** ID: T1134.001 +** Reference URL: https://attack.mitre.org/techniques/T1134/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-forbidden-request-from-unusual-user-agent-in-kubernetes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-forbidden-request-from-unusual-user-agent-in-kubernetes.asciidoc new file mode 100644 index 0000000000..40584f5a38 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-forbidden-request-from-unusual-user-agent-in-kubernetes.asciidoc @@ -0,0 +1,106 @@ +[[prebuilt-rule-8-19-1-forbidden-request-from-unusual-user-agent-in-kubernetes]] +=== Forbidden Request from Unusual User Agent in Kubernetes + +This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* 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 Forbidden Request from Unusual User Agent in Kubernetes* + + +Kubernetes, a container orchestration platform, manages applications across clusters. It uses APIs for communication, which can be targeted by adversaries using atypical user agents to mask malicious activities. These agents may attempt unauthorized actions, exploiting vulnerabilities. The detection rule identifies such anomalies by flagging forbidden requests from non-standard user agents, indicating potential threats. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the source IP address and user associated with the forbidden request. This can help determine if the request originated from a known or unknown entity. +- Analyze the user agent string in the audit logs to understand its origin and purpose. Cross-reference it with known legitimate user agents to assess its legitimacy. +- Check for any recent changes or deployments in the Kubernetes environment that might have introduced new user agents or configurations, potentially leading to the forbidden request. +- Investigate the specific resource or API endpoint that was targeted by the forbidden request to understand what the adversary might have been attempting to access or exploit. +- Correlate the event with other security logs and alerts to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort. +- Assess the current security posture and configurations of the Kubernetes cluster to identify any vulnerabilities or misconfigurations that could be exploited by adversaries using unusual user agents. + + +*False positive analysis* + + +- Legitimate internal tools or scripts may use non-standard user agents that are not included in the exclusion list. Review and identify these tools, then update the exclusion list to prevent them from being flagged. +- Automated processes or third-party integrations might use unique user agents that trigger the rule. Verify these processes and consider adding their user agents to the exclusion list if they are deemed safe. +- Development or testing environments often use custom user agents for API interactions. Ensure these environments are accounted for by excluding their user agents to avoid unnecessary alerts. +- Regularly review and update the exclusion list to reflect changes in legitimate user agents used within your organization, ensuring that only truly unusual and potentially malicious agents are flagged. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary. +- Revoke any suspicious or unauthorized credentials or tokens that may have been used in the forbidden request to ensure they cannot be reused. +- Conduct a thorough review of the Kubernetes audit logs to identify any additional unauthorized or suspicious activities that may have occurred around the time of the alert. +- Patch any identified vulnerabilities or misconfigurations in the Kubernetes environment that may have been exploited, ensuring all components are up to date with the latest security patches. +- Implement stricter access controls and user agent validation to prevent non-standard user agents from interacting with the Kubernetes API unless explicitly allowed. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary. +- Enhance monitoring and alerting for similar activities by tuning detection systems to recognize patterns associated with this type of threat, ensuring rapid response to future incidents. + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "linux" and event.dataset == "kubernetes.audit_logs" and +kubernetes.audit.stage == "ResponseComplete" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid" and +not user_agent.original like~ ( + "/", "karpenter", "csi-secrets-store/*", "elastic-agent/*", "agentbeat/*", "insights-operator*", "oc/*", "cloud-defend/*", + "OpenAPI-Generator/*", "local-storage-operator/*", "falcon-client/*", "nginx-ingress-controller/*", "config-translator/*", + "kwatch/*", "PrometheusOperator/*", "kube*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-git-repository-or-file-download-to-suspicious-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-git-repository-or-file-download-to-suspicious-directory.asciidoc new file mode 100644 index 0000000000..50109d67bd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-git-repository-or-file-download-to-suspicious-directory.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-1-git-repository-or-file-download-to-suspicious-directory]] +=== Git Repository or File Download to Suspicious Directory + +This rule detects the use of git to clone a repository or download files from GitHub using wget or curl, followed by the creation of files in suspicious directories such as /tmp, /var/tmp, or /dev/shm. This behavior may indicate an attempt to download a payload, exploit or tool. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 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 Git Repository or File Download to Suspicious Directory* + + +Git, wget, and curl are essential tools for managing and transferring files in Linux environments. Adversaries exploit these tools to download malicious payloads into temporary directories like /tmp, /var/tmp, or /dev/shm, which are often overlooked. The detection rule identifies this behavior by monitoring for git clone commands or GitHub downloads followed by file creation in these directories, signaling potential threats. + + +*Possible investigation steps* + + +- Review the process details, including process.entity_id and process.name, to confirm the execution of git, wget, or curl commands and verify if they align with expected usage patterns. +- Examine the process.command_line field to identify the specific GitHub URL or repository being accessed, and assess whether it is known or potentially malicious. +- Check the file creation event details, focusing on the file.path to determine the exact location and nature of the files created in /tmp, /var/tmp, or /dev/shm directories. +- Investigate the host.id and host.os.type to gather additional context about the affected system, including its role and any recent changes or anomalies. +- Correlate the timing of the process start and file creation events to understand the sequence of actions and identify any potential patterns or anomalies. +- Consult threat intelligence sources to determine if the accessed GitHub repository or downloaded files are associated with known threats or malicious activity. + + +*False positive analysis* + + +- Development activities may trigger this rule when developers clone repositories or download files from GitHub into temporary directories for testing purposes. To manage this, create exceptions for specific user accounts or processes that are known to perform legitimate development tasks. +- Automated scripts or cron jobs that regularly update or download files from GitHub into temporary directories can also cause false positives. Identify these scripts and exclude their process IDs or command patterns from the rule. +- System maintenance tasks that involve downloading updates or patches into temporary directories might be flagged. Coordinate with system administrators to identify these tasks and whitelist the associated processes or directories. +- Security tools or monitoring solutions that download threat intelligence feeds or other data into temporary directories could be mistakenly identified. Verify these tools and exclude their activities from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further potential malicious activity and lateral movement within the network. +- Terminate any suspicious processes related to git, wget, or curl that are actively running and associated with the creation of files in the /tmp, /var/tmp, or /dev/shm directories. +- Conduct a thorough examination of the files created in these directories to identify and remove any malicious payloads or tools. +- Restore any compromised files or systems from clean backups to ensure the integrity of the affected system. +- Implement network monitoring to detect and block any unauthorized outbound connections to suspicious domains, particularly those related to GitHub or other code repositories. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems may be affected. +- Update endpoint protection and intrusion detection systems to enhance detection capabilities for similar threats, focusing on the specific indicators of compromise identified in this alert. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id, host.id with maxspan=10s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.name == "git" and process.args == "clone") or + (process.name in ("wget", "curl") and process.command_line like~ "*github*") + )] + [file where host.os.type == "linux" and event.type == "creation" and file.path like ("/tmp/*", "/var/tmp/*", "/dev/shm/*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubeconfig-file-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubeconfig-file-creation-or-modification.asciidoc new file mode 100644 index 0000000000..e0476aa6cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubeconfig-file-creation-or-modification.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-1-kubeconfig-file-creation-or-modification]] +=== Kubeconfig File Creation or Modification + +The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster. + +*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://kubernetes-threat-matrix.redguard.ch/initial-access/kubeconfig-file/ +* https://kubenomicon.com/Initial_access/Kubeconfig_file.html + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Defense Evasion +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubeconfig File Creation or Modification* + +Kubeconfig files are essential in Kubernetes environments, storing configurations for cluster access and management. Adversaries may target these files to gain unauthorized access or move laterally within clusters. The detection rule identifies suspicious creation or modification of kubeconfig files, excluding legitimate processes like kubeadm and minikube, to flag potential threats and mitigate risks associated with unauthorized access. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path involved in the creation or modification event, focusing on paths like "/root/.kube/config" or "/etc/kubernetes/admin.conf". +- Examine the process responsible for the file creation or modification, ensuring it is not one of the excluded legitimate processes such as "kubeadm", "kubelet", "vcluster", or "minikube". +- Check the user account associated with the process to determine if it has legitimate access to modify kubeconfig files and assess if the activity aligns with typical user behavior. +- Investigate the timing of the event to see if it coincides with any scheduled maintenance or deployment activities that could explain the modification. +- Look for any related alerts or logs that might indicate lateral movement or unauthorized access attempts within the Kubernetes cluster. +- Assess the network activity from the host where the modification occurred to identify any suspicious connections or data transfers that could suggest unauthorized access or exfiltration. + + +*False positive analysis* + + +- Legitimate administrative tools like kubeadm, kubelet, vcluster, and minikube may create or modify kubeconfig files as part of normal operations. Ensure these processes are excluded from triggering alerts by maintaining the exclusion list in the detection rule. +- Automated scripts or configuration management tools that use sed to modify kubeconfig files might be flagged. Consider adding specific script names or paths to the exclusion list if they are verified as non-threatening. +- User-initiated changes to kubeconfig files for legitimate access or configuration updates can trigger alerts. Implement a process to verify and document such changes, allowing for quick exclusion of known user actions. +- Regular updates or maintenance activities that involve kubeconfig file modifications should be documented and excluded from detection. Coordinate with the operations team to identify and whitelist these activities. +- Development environments where frequent kubeconfig changes occur, such as in testing or staging, may generate false positives. Establish a separate monitoring policy for these environments to reduce noise while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the Kubernetes cluster. +- Revoke any potentially compromised credentials associated with the kubeconfig files and issue new credentials to ensure secure access. +- Conduct a thorough review of recent access logs and audit trails to identify any unauthorized access or suspicious activity related to the kubeconfig files. +- Restore the kubeconfig files from a known good backup to ensure the integrity of the configuration and access settings. +- Implement additional monitoring and alerting for any future modifications to kubeconfig files, focusing on processes not typically involved in legitimate changes. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader Kubernetes environment. +- Review and update Kubernetes access policies to ensure they align with best practices for security and least privilege, reducing the risk of unauthorized access. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type != "deletion" and file.path like ( + "/root/.kube/config", + "/home/*/.kube/config", + "/etc/kubernetes/admin.conf", + "/etc/kubernetes/super-admin.conf", + "/etc/kubernetes/kubelet.conf", + "/etc/kubernetes/controller-manager.conf", + "/etc/kubernetes/scheduler.conf", + "/var/lib/*/kubeconfig" +) and not ( + process.name in ("kubeadm", "kubelet", "vcluster", "minikube") or + (process.name == "sed" and file.Ext.original.name like "sed*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubeconfig-file-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubeconfig-file-discovery.asciidoc new file mode 100644 index 0000000000..c1fdbbdcb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubeconfig-file-discovery.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-1-kubeconfig-file-discovery]] +=== Kubeconfig File Discovery + +The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create, or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster. This rule detects process discovery executions that involve kubeconfig files, particularly those executed from common shell environments or world-writeable 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*: 100 + +*References*: + +* https://kubernetes-threat-matrix.redguard.ch/initial-access/kubeconfig-file/ +* https://kubenomicon.com/Initial_access/Kubeconfig_file.html + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubeconfig File Discovery* + + +Kubeconfig files are essential in Kubernetes, storing credentials and configurations for cluster access. Adversaries may target these files to gain unauthorized access or move laterally within clusters. The detection rule identifies suspicious processes interacting with kubeconfig files, especially from common shell environments or risky directories, flagging potential misuse by excluding benign commands like 'stat' or 'md5sum'. + + +*Possible investigation steps* + + +- Review the process details to identify the parent process name and executable path, focusing on those originating from common shell environments or risky directories like /tmp, /var/tmp, or /dev/shm. +- Examine the process arguments to determine if they include references to sensitive kubeconfig files such as admin.conf, kubelet.conf, or any files within /etc/kubernetes or ~/.kube directories. +- Check the working directory of the process to see if it aligns with known Kubernetes configuration paths like /etc/kubernetes or ~/.kube, which may indicate an attempt to access or modify kubeconfig files. +- Investigate the user account associated with the process to assess whether it has legitimate access to Kubernetes configurations or if it might be compromised. +- Correlate the event with other recent activities from the same user or IP address to identify any patterns of suspicious behavior or potential lateral movement within the cluster. +- Review any related alerts or logs for the same host or container to gather additional context on the system's state and any other potential indicators of compromise. + + +*False positive analysis* + + +- Processes like 'stat' and 'md5sum' are excluded from detection as they are commonly used for legitimate file checks. Ensure these exclusions are correctly configured to prevent unnecessary alerts. +- Scripts located in user directories such as '/home/*/.kube' may trigger alerts if they interact with kubeconfig files. Consider adding exceptions for known scripts or users that regularly access these files for legitimate purposes. +- Processes originating from world-writeable directories like '/tmp' or '/var/tmp' can be flagged. Review these alerts to identify routine operations and whitelist specific processes or directories that are part of regular maintenance tasks. +- Alerts triggered by processes with names matching patterns like '*.sh' may include legitimate scripts. Evaluate these scripts and exclude them if they are part of standard operations or administrative tasks. +- Regular administrative tasks involving kubeconfig files in directories like '/etc/kubernetes' may be flagged. Implement exceptions for known administrative processes to reduce false positives while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access to the Kubernetes cluster. +- Revoke any compromised credentials associated with the kubeconfig files and issue new credentials to authorized users. +- Conduct a thorough review of recent access logs and audit trails for the Kubernetes cluster to identify any unauthorized access or lateral movement attempts. +- Restore any modified or deleted kubeconfig files from a secure backup to ensure the integrity of the cluster configuration. +- Implement stricter access controls and permissions for directories containing kubeconfig files, ensuring only authorized personnel have access. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected. +- Enhance monitoring and alerting for suspicious activities related to kubeconfig files, leveraging the MITRE ATT&CK framework to identify potential discovery tactics. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer 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 ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or + ( + process.parent.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") or + process.parent.name like (".*", "*.sh") + ) +) and +( + ( + process.working_directory like ("/etc/kubernetes", "/root/.kube", "/home/*/.kube") and + process.args in ("kubeconfig", "admin.conf", "super-admin.conf", "kubelet.conf", "controller-manager.conf", "scheduler.conf") + ) or + process.args like ( + "/etc/kubernetes/admin.conf", + "/etc/kubernetes/super-admin.conf", + "/etc/kubernetes/kubelet.conf", + "/etc/kubernetes/controller-manager.conf", + "/etc/kubernetes/scheduler.conf", + "/home/*/.kube/config", + "/root/.kube/config", + "/var/lib/*/kubeconfig" + ) +) and not process.name in ("stat", "md5sum", "dirname") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-apply-pod-from-url.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-apply-pod-from-url.asciidoc new file mode 100644 index 0000000000..4c0b22e230 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-apply-pod-from-url.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-1-kubectl-apply-pod-from-url]] +=== Kubectl Apply Pod from URL + +This rule detects the execution of the "kubectl apply" command with a URL argument. This command is often used to apply configurations or deploy resources in a Kubernetes cluster. Attackers may use this command to deploy malicious pods or modify existing ones, potentially leading to unauthorized access or data exfiltration. + +*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 +* Domain: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 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 Kubectl Apply Pod from URL* + + +Kubectl is a command-line tool for managing Kubernetes clusters, allowing users to deploy and manage applications. Adversaries may exploit the 'kubectl apply' command with a URL to deploy malicious configurations or pods, potentially compromising the cluster. The detection rule identifies such activities by monitoring for the execution of 'kubectl apply' with URL arguments, flagging potential unauthorized deployments. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of 'kubectl apply' with a URL argument, ensuring the command matches the query criteria. +- Identify the source IP address or hostname from which the 'kubectl apply' command was executed to determine if it originates from a known or trusted source. +- Check the URL used in the 'kubectl apply' command to assess its legitimacy and whether it points to a trusted or suspicious source. +- Investigate the user account associated with the execution of the command to verify if it has the necessary permissions and if the activity aligns with expected behavior. +- Examine the Kubernetes cluster logs for any recent changes or deployments that correspond with the time of the alert to identify any unauthorized modifications or deployments. +- Cross-reference the alert with other security tools or logs, such as network traffic analysis, to detect any related suspicious activities or data exfiltration attempts. + + +*False positive analysis* + + +- Routine administrative tasks: Regular use of 'kubectl apply' with URLs for legitimate configuration updates or deployments can trigger alerts. To manage this, create exceptions for known and trusted URLs used by administrators. +- Automated deployment scripts: Continuous integration/continuous deployment (CI/CD) pipelines often use 'kubectl apply' with URLs to automate deployments. Identify and exclude these scripts by their specific process arguments or originating IP addresses. +- Monitoring and logging tools: Some monitoring solutions may use 'kubectl apply' with URLs as part of their normal operations. Review and whitelist these tools by verifying their source and purpose. +- Internal development environments: Developers may frequently use 'kubectl apply' with URLs in test environments. Establish a separate rule set or exceptions for these environments to reduce noise while maintaining security in production clusters. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized deployments or access. This can be done by restricting network access or disabling external API access temporarily. +- Review the specific pod or configuration deployed using the 'kubectl apply' command with a URL. Identify any malicious or unauthorized changes and remove them from the cluster. +- Conduct a thorough audit of the cluster's current state to identify any other unauthorized deployments or configurations that may have been applied. +- Revoke any compromised credentials or access tokens that may have been used to execute the unauthorized 'kubectl apply' command. Ensure that all access keys and tokens are rotated. +- Escalate the incident to the security operations team for further investigation and to determine the root cause of the breach. This may involve analyzing logs and network traffic to trace the source of the attack. +- Implement network policies and role-based access controls (RBAC) to limit the ability to apply configurations from external URLs, ensuring only trusted sources are allowed. +- Enhance monitoring and alerting for similar activities by integrating with security information and event management (SIEM) systems to detect and respond to future threats 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 == "kubectl" and process.args == "apply" and process.args like "http*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-network-configuration-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-network-configuration-modification.asciidoc new file mode 100644 index 0000000000..4bb608c1d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-network-configuration-modification.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-1-kubectl-network-configuration-modification]] +=== Kubectl Network Configuration Modification + +This rule detects potential kubectl network configuration modification activity by monitoring for process events where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in Kubernetes. This could indicate an adversary trying to manipulate network settings for malicious purposes, such as establishing unauthorized access or exfiltrating data. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 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 Kubectl Network Configuration Modification* + + +Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and network settings. Adversaries may exploit kubectl to alter network configurations, potentially establishing unauthorized access or data exfiltration channels. The detection rule identifies suspicious kubectl usage patterns, such as port-forwarding or proxy commands, especially when executed from atypical parent processes or directories, indicating possible malicious intent. + + +*Possible investigation steps* + + +- Review the process command line to confirm the specific kubectl command and arguments used, focusing on "port-forward", "proxy", or "expose" to understand the intended network configuration change. +- Examine the parent process details, including the name and executable path, to determine if the kubectl command was initiated from an unusual or suspicious location, such as "/tmp/*" or "/var/tmp/*". +- Investigate the user account associated with the kubectl process to verify if the activity aligns with their typical behavior or if it indicates potential compromise. +- Check for any recent changes or anomalies in the Kubernetes cluster's network settings or configurations that could correlate with the detected kubectl activity. +- Look for additional related alerts or logs that might indicate a broader pattern of suspicious activity, such as other command and control tactics or protocol tunneling attempts. + + +*False positive analysis* + + +- Legitimate administrative tasks using kubectl port-forward or proxy commands can trigger the rule. To manage this, create exceptions for known administrative scripts or users who frequently perform these tasks. +- Automated scripts or cron jobs that use kubectl for network configuration changes may cause false positives. Identify these scripts and exclude their specific command patterns or parent processes from the rule. +- Development environments where developers frequently use kubectl for testing purposes might generate alerts. Consider excluding specific user accounts or directories associated with development activities. +- Continuous integration/continuous deployment (CI/CD) pipelines that utilize kubectl for deployment processes can be a source of false positives. Exclude the CI/CD tool's process names or execution paths from the rule. +- Temporary directories like /tmp or /var/tmp used by legitimate applications for kubectl operations can trigger alerts. Review and whitelist these specific applications or their execution contexts. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further unauthorized access or data exfiltration. This can be done by removing the host from the network or applying network segmentation rules. +- Terminate any suspicious kubectl processes identified by the detection rule to halt any ongoing malicious activity. +- Review and revoke any unauthorized access credentials or tokens that may have been compromised or used in the attack. +- Conduct a thorough audit of Kubernetes network configurations and access controls to identify and rectify any unauthorized changes or vulnerabilities. +- Restore any altered network configurations to their original state using backups or configuration management tools. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Implement enhanced monitoring and logging for kubectl activities and network configuration changes to detect and respond to similar threats more effectively in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name == "kubectl" and ( + process.args == "port-forward" and process.command_line like "*:*" or + process.args in ("proxy", "expose") +) and ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or + ( + process.parent.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") or + process.parent.name like (".*", "*.sh") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-permission-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-permission-discovery.asciidoc new file mode 100644 index 0000000000..75f367dbaa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubectl-permission-discovery.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-1-kubectl-permission-discovery]] +=== Kubectl Permission Discovery + +This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/ + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubectl Permission Discovery* + + +Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit the "kubectl auth can-i" command to probe for permission misconfigurations, potentially leading to unauthorized access or privilege escalation. The detection rule identifies this activity by monitoring specific command executions on Linux systems, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the "kubectl auth can-i" command, focusing on the process name "kubectl" and arguments "auth" and "can-i". +- Identify the user account associated with the execution of the command to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access. +- Check the timing and frequency of the command execution to assess whether it corresponds with routine operations or suggests suspicious behavior. +- Investigate the source IP address or hostname from which the command was executed to verify if it originates from a known and trusted environment. +- Examine related logs and events around the time of the alert to identify any subsequent actions that might indicate privilege escalation or unauthorized access attempts. +- Cross-reference the alert with any recent changes or incidents in the Kubernetes cluster to determine if the command execution is part of a broader security concern. + + +*False positive analysis* + + +- Routine administrative checks by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or roles that regularly perform these checks as part of their job duties. +- Automated scripts or monitoring tools that verify permissions as part of their normal operation may cause false positives. Identify these scripts and whitelist their execution paths or associated service accounts. +- Development and testing environments where developers frequently check permissions might lead to alerts. Consider excluding these environments from the rule or adjusting the risk score for these specific contexts. +- Scheduled audits or compliance checks that involve permission verification can be mistaken for malicious activity. Document these activities and set up time-based exceptions to prevent unnecessary alerts during known audit periods. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation. +- Revoke any suspicious or unauthorized credentials or tokens identified during the investigation to prevent further misuse. +- Conduct a thorough review of the Kubernetes Role-Based Access Control (RBAC) configurations to identify and rectify any permission misconfigurations. +- Implement stricter access controls and least privilege principles for Kubernetes users and service accounts to minimize the risk of unauthorized access. +- Monitor for any additional suspicious activity or anomalies in the cluster, focusing on access patterns and command executions. +- Escalate the incident to the security operations team for further analysis and to determine if additional clusters or systems are affected. +- Update detection and monitoring systems to enhance visibility and alerting for similar permission discovery attempts in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.name == "kubectl" and process.args == "auth" and process.args == "can-i" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-anonymous-request-authorized.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-anonymous-request-authorized.asciidoc new file mode 100644 index 0000000000..674ee2bd80 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-anonymous-request-authorized.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-1-kubernetes-anonymous-request-authorized]] +=== Kubernetes Anonymous Request Authorized + +This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Anonymous Request Authorized* + + +Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request. +- Examine the kubernetes.audit.user.username field to confirm if the request was made by "system:anonymous" or "system:unauthenticated" and assess the potential risk associated with these accounts. +- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity. +- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns. +- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster. + + +*False positive analysis* + + +- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives. +- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts. +- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe. +- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise. +- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary. +- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized. +- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster. +- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access. +- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected. +- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:kubernetes.audit_logs + and kubernetes.audit.annotations.authorization_k8s_io/decision:allow + and kubernetes.audit.user.username:("system:anonymous" or "system:unauthenticated" or not *) + and not kubernetes.audit.requestURI:(/healthz* or /livez* or /readyz*) + +---------------------------------- + +*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-1/prebuilt-rule-8-19-1-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc new file mode 100644 index 0000000000..90536903e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-1-kubernetes-container-created-with-excessive-linux-capabilities]] +=== Kubernetes Container Created with Excessive Linux Capabilities + +This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container +* https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities +* https://man7.org/linux/man-pages/man7/capabilities.7.html +* https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Container Created with Excessive Linux Capabilities* + + +Linux capabilities were designed to divide root privileges into smaller units. Each capability grants a thread just enough power to perform specific privileged tasks. In Kubernetes, containers are given a set of default capabilities that can be dropped or added to at the time of creation. Added capabilities entitle containers in a pod with additional privileges that can be used to change +core processes, change network settings of a cluster, or directly access the underlying host. The following have been used in container escape techniques: + +BPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more. +DAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks. +NET_ADMIN - Perform various network-related operations. +SYS_ADMIN - Perform a range of system administration operations. +SYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution. +SYS_MODULE - Load and unload kernel modules. +SYS_PTRACE - Trace arbitrary processes using ptrace(2). +SYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)). +SYSLOG - Perform privileged syslog(2) operations. + + +*False positive analysis* + + +- While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: kubernetes.audit_logs + and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + and kubernetes.audit.verb: create + and kubernetes.audit.objectRef.resource: pods + and kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add: ("BPF" or "DAC_READ_SEARCH" or "NET_ADMIN" or "SYS_ADMIN" or "SYS_BOOT" or "SYS_MODULE" or "SYS_PTRACE" or "SYS_RAWIO" or "SYSLOG") + and not kubernetes.audit.requestObject.spec.containers.image : ("docker.elastic.co/beats/elastic-agent:8.4.0" or "rancher/klipper-lb:v0.3.5" or "") + +---------------------------------- + +*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-1/prebuilt-rule-8-19-1-kubernetes-denied-service-account-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-denied-service-account-request.asciidoc new file mode 100644 index 0000000000..9cef1f1cb0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-denied-service-account-request.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-1-kubernetes-denied-service-account-request]] +=== Kubernetes Denied Service Account Request + +This rule detects when a service account makes an unauthorized request for resources from the API server. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster. + +*Rule type*: 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/reference/access-authn-authz/authentication/#service-account-tokens + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Denied Service Account Request* + + +Kubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow strict access patterns. Adversaries may exploit compromised service account credentials to probe or manipulate cluster resources, potentially leading to unauthorized access or lateral movement. The detection rule identifies anomalies by flagging unauthorized API requests from service accounts, signaling possible security breaches or misconfigurations. + + +*Possible investigation steps* + + +- Review the specific service account involved in the unauthorized request by examining the kubernetes.audit.user.username field to determine which service account was used. +- Analyze the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm the request was indeed forbidden and identify the nature of the denied request. +- Investigate the source of the request by checking the originating pod or node to understand where the unauthorized request was initiated. +- Examine recent activity logs for the service account to identify any unusual patterns or deviations from its typical behavior. +- Check for any recent changes or deployments in the cluster that might have affected service account permissions or configurations. +- Assess whether there have been any recent security incidents or alerts related to the cluster that could be connected to this unauthorized request. + + +*False positive analysis* + + +- Service accounts used for testing or development may generate unauthorized requests if they are not properly configured. Regularly review and update permissions for these accounts to ensure they align with their intended use. +- Automated scripts or tools that interact with the Kubernetes API might trigger false positives if they use service accounts with insufficient permissions. Ensure these tools have the necessary permissions or adjust the detection rule to exclude known benign activities. +- Misconfigured role-based access control (RBAC) settings can lead to legitimate service accounts being denied access. Conduct periodic audits of RBAC policies to verify that service accounts have appropriate permissions. +- Temporary service accounts created for specific tasks might not have the correct permissions, leading to denied requests. Consider excluding these accounts from the rule if they are known to perform non-threatening activities. +- Service accounts from third-party integrations or plugins may not have the required permissions, resulting in false positives. Validate the permissions needed for these integrations and adjust the rule to exclude their expected behavior. + + +*Response and remediation* + + +- Immediately isolate the affected service account by revoking its access tokens and credentials to prevent further unauthorized API requests. +- Conduct a thorough review of the audit logs to identify any other suspicious activities or unauthorized access attempts associated with the compromised service account. +- Rotate credentials for the affected service account and any other potentially impacted accounts to mitigate the risk of further exploitation. +- Assess and remediate any misconfigurations in role-based access control (RBAC) policies that may have allowed the unauthorized request, ensuring that service accounts have the minimum necessary permissions. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are required. +- Implement enhanced monitoring and alerting for similar unauthorized access attempts to improve detection and response times for future incidents. +- Review and update incident response plans to incorporate lessons learned from this event, ensuring readiness for similar threats in the future. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "kubernetes.audit_logs" + and kubernetes.audit.user.username: system\:serviceaccount\:* + and kubernetes.audit.annotations.authorization_k8s_io/decision: "forbid" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-direct-api-request-via-curl-or-wget.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-direct-api-request-via-curl-or-wget.asciidoc new file mode 100644 index 0000000000..84998568f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-direct-api-request-via-curl-or-wget.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-1-kubernetes-direct-api-request-via-curl-or-wget]] +=== Kubernetes Direct API Request via Curl or Wget + +This rule monitors for the execution of curl or wget commands that directly access Kubernetes API endpoints, which may indicate an attempt to interact with Kubernetes resources in a potentially unauthorized manner. This technique is often used by adversaries to gather information about the Kubernetes environment, such as secrets, config maps, and other sensitive data, without using the official Kubernetes client tools such as "kubectl". + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Direct API Request via Curl or Wget* + + +Kubernetes API endpoints are crucial for managing cluster resources. Adversaries may exploit tools like curl or wget to directly query these endpoints, bypassing standard clients like kubectl, to extract sensitive data such as secrets or config maps. The detection rule identifies such unauthorized access attempts by monitoring command executions that target specific API paths, flagging potential security threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of curl or wget, focusing on the process.name and process.args fields to understand the exact command used and the specific Kubernetes API endpoint targeted. +- Check the user context under which the curl or wget command was executed, including user ID and group ID, to determine if the action was performed by a legitimate user or an unauthorized entity. +- Investigate the source IP address and host information to identify the origin of the request and assess whether it aligns with expected network activity within the Kubernetes environment. +- Examine recent authentication and authorization logs for any anomalies or failed attempts that might indicate unauthorized access attempts to the Kubernetes API. +- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities, such as unusual network traffic or access patterns. +- Assess the potential impact by reviewing the specific Kubernetes resources targeted, such as secrets or config maps, to determine if sensitive data might have been exposed or compromised. + + +*False positive analysis* + + +- Routine monitoring scripts or health checks that use curl or wget to verify the availability of Kubernetes API endpoints may trigger this rule. To manage this, identify and whitelist the specific scripts or IP addresses that are known to perform these checks regularly. +- Automated backup processes that access Kubernetes secrets or config maps using curl or wget could be flagged. Exclude these processes by specifying their unique command patterns or execution contexts in the detection rule. +- Developers or administrators using curl or wget for legitimate troubleshooting or testing purposes might inadvertently trigger the rule. Implement user-based exceptions for known and trusted personnel who require such access for their roles. +- Integration tools or CI/CD pipelines that interact with Kubernetes APIs using curl or wget for deployment or configuration tasks may cause false positives. Create exceptions for these tools by identifying their process names or execution environments. +- Security scanners or vulnerability assessment tools that probe Kubernetes API endpoints as part of their scanning routines can be mistaken for unauthorized access attempts. Whitelist these tools by their known signatures or execution patterns to prevent false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access to Kubernetes API endpoints. +- Revoke any potentially compromised credentials or tokens that may have been used in the unauthorized API requests. +- Conduct a thorough review of Kubernetes audit logs to identify the scope of the unauthorized access and determine if any sensitive data was exfiltrated. +- Reset and rotate all secrets and config maps that may have been accessed during the incident to ensure they are no longer valid. +- Implement network segmentation and access controls to restrict direct access to Kubernetes API endpoints, ensuring only authorized clients can communicate with the API. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions. +- Enhance monitoring and alerting for similar unauthorized access attempts by integrating additional threat intelligence and refining detection capabilities. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started") and +process.name in ("curl", "wget") and process.args like~ ( + "*http*//*/apis/authorization.k8s.io/*", + "*http*//*/apis/rbac.authorization.k8s.io/*", + "*http*//*/api/v1/secrets*", + "*http*//*/api/v1/namespaces/*/secrets*", + "*http*//*/api/v1/configmaps*", + "*http*//*/api/v1/pods*", + "*http*//*/apis/apps/v1/deployments*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-events-deleted.asciidoc new file mode 100644 index 0000000000..82e13d1f7c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-events-deleted.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-1-kubernetes-events-deleted]] +=== Kubernetes Events Deleted + +This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 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 Kubernetes Events Deleted* + +Kubernetes, a container orchestration platform, logs events to track activities within the cluster. These events are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impeding incident response. The detection rule identifies deletions of Kubernetes events, signaling potential defense evasion attempts by matching specific audit log attributes, thus alerting security teams to investigate further. + + +*Possible investigation steps* + + +- Review the audit logs to identify the source of the deletion request by examining the `kubernetes.audit.user.username` field to determine which user or service account initiated the delete action. +- Check the `kubernetes.audit.sourceIPs` field to trace the IP address from which the deletion request originated, which can help identify potential unauthorized access. +- Investigate the `kubernetes.audit.objectRef.namespace` field to understand which namespace the deleted events belonged to, as this can provide context on the affected applications or services. +- Analyze the timeline of events leading up to the deletion by reviewing other audit logs with similar `kubernetes.audit.verb` values to identify any suspicious activities or patterns. +- Assess the role and permissions of the user or service account involved in the deletion to determine if they had legitimate access or if there was a potential privilege escalation. +- Cross-reference the deletion event with other security alerts or logs to identify any correlated activities that might indicate a broader attack or misconfiguration. + + +*False positive analysis* + + +- Routine maintenance activities may involve the deletion of Kubernetes events, such as during cluster upgrades or cleanup tasks. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools that manage Kubernetes resources might delete events as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their service accounts or IP addresses. +- Misconfigured applications or services might inadvertently delete events. Regularly review and update configurations to ensure they align with best practices, and consider excluding specific applications if they are known to cause benign deletions. +- Development and testing environments often have more frequent event deletions as part of iterative testing processes. Implement separate monitoring rules or thresholds for these environments to reduce noise in alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or tampering with event logs. +- Review and restore any deleted Kubernetes events from backup logs or snapshots to ensure a complete audit trail is available for further investigation. +- Conduct a thorough review of access controls and permissions within the Kubernetes environment to identify and revoke any unauthorized access that may have led to the deletion of events. +- Implement stricter logging and monitoring policies to ensure that any future deletions of Kubernetes events are detected and alerted in real-time. +- Escalate the incident to the security operations center (SOC) for a comprehensive analysis of potential breaches and to determine if additional systems or data were affected. +- Coordinate with the incident response team to conduct a root cause analysis and identify any vulnerabilities or misconfigurations that allowed the event deletion to occur. +- Update and reinforce security policies and procedures to prevent similar incidents, including enhancing detection capabilities for defense evasion tactics as outlined in MITRE ATT&CK. + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "linux" and event.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "delete" and +kubernetes.audit.objectRef.resource == "events" and kubernetes.audit.stage == "ResponseComplete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-exposed-service-created-with-type-nodeport.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-exposed-service-created-with-type-nodeport.asciidoc new file mode 100644 index 0000000000..4dcc133ebe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-exposed-service-created-with-type-nodeport.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-1-kubernetes-exposed-service-created-with-type-nodeport]] +=== Kubernetes Exposed Service Created With Type NodePort + +This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types +* https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport +* https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/ + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 207 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Exposed Service Created With Type NodePort* + + +Kubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is "services" and kubernetes.audit.verb is "create", "update", or "patch". +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized. +- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name. +- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally. +- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception. +- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent. + + +*False positive analysis* + + +- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly. +- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters. +- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts. +- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms. +- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period. + + +*Response and remediation* + + +- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception. +- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service. +- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service. +- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed. +- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture. +- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited. +- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset : "kubernetes.audit_logs" + and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + and kubernetes.audit.objectRef.resource:"services" + and kubernetes.audit.verb:("create" or "update" or "patch") + and kubernetes.audit.requestObject.spec.type:"NodePort" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-forbidden-creation-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-forbidden-creation-request.asciidoc new file mode 100644 index 0000000000..1c97f601bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-forbidden-creation-request.asciidoc @@ -0,0 +1,105 @@ +[[prebuilt-rule-8-19-1-kubernetes-forbidden-creation-request]] +=== Kubernetes Forbidden Creation Request + +This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 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 Kubernetes Forbidden Creation Request* + + +Kubernetes, a container orchestration platform, manages applications across clusters. It uses authorization policies to control resource creation. Adversaries may exploit misconfigurations or attempt unauthorized resource creation to gain access or escalate privileges. The detection rule identifies denied creation requests, signaling potential unauthorized attempts, by analyzing audit logs for forbidden decisions, aiding in threat detection and response. + + +*Possible investigation steps* + + +- Review the audit logs to identify the user or service account associated with the forbidden creation request by examining the `kubernetes.audit.user.username` field. +- Check the `kubernetes.audit.objectRef.resource` field to determine which specific resource type the unauthorized creation attempt was targeting. +- Investigate the `kubernetes.audit.sourceIPs` field to trace the source IP address of the request, which may help identify the origin of the unauthorized attempt. +- Analyze the `kubernetes.audit.annotations.authorization_k8s_io/reason` field, if available, to understand why the request was forbidden, providing insights into potential misconfigurations or policy violations. +- Cross-reference the user or service account with existing role bindings and cluster role bindings to verify if there are any misconfigurations or missing permissions that could have led to the forbidden request. +- Review recent changes in the cluster's authorization policies or role assignments that might have inadvertently affected permissions, leading to the denied request. +- Consider correlating this event with other security alerts or logs to identify patterns or repeated unauthorized attempts, which could indicate a broader attack strategy. + + +*False positive analysis* + + +- Service accounts with limited permissions may trigger false positives when attempting to create resources they are not authorized for. Review service account roles and permissions to ensure they align with intended access levels. +- Automated processes or scripts that attempt resource creation without proper permissions can result in false positives. Identify and adjust these processes to ensure they operate within their designated permissions. +- Developers testing new configurations or deployments might inadvertently cause forbidden creation requests. Implement a separate testing environment with appropriate permissions to minimize false positives in production. +- Changes in authorization policies can lead to temporary false positives as users adjust to new permissions. Communicate policy changes effectively and provide guidance on necessary adjustments to avoid unnecessary alerts. +- Regularly scheduled tasks or cron jobs that attempt resource creation without updated permissions can trigger false positives. Review and update these tasks to ensure they have the necessary access rights. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or resource manipulation. This can be done by restricting network access or applying stricter firewall rules temporarily. +- Identify and revoke any unauthorized or suspicious service accounts or user credentials that attempted the forbidden creation request. Ensure that these accounts are disabled or have their permissions reduced to prevent further misuse. +- Review and update the Kubernetes Role-Based Access Control (RBAC) policies to ensure that only authorized users and service accounts have the necessary permissions to create resources. This includes verifying that least privilege principles are applied. +- Conduct a thorough audit of recent Kubernetes audit logs to identify any other unauthorized access attempts or suspicious activities that may have occurred around the same time as the detected alert. +- Escalate the incident to the security operations team for further investigation and to determine if there is a broader security incident or breach. Provide them with all relevant logs and findings. +- Implement additional monitoring and alerting for similar unauthorized creation attempts in the future. This can include setting up alerts for any "forbid" decisions in the audit logs to ensure rapid detection and response. +- Consider deploying additional security tools or services, such as intrusion detection systems or anomaly detection solutions, to enhance the security posture of the Kubernetes environment and prevent similar threats. + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "linux" and event.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "create" and +kubernetes.audit.stage == "ResponseComplete" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc new file mode 100644 index 0000000000..aabe8d061f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-1-kubernetes-pod-created-with-a-sensitive-hostpath-volume]] +=== Kubernetes Pod created with a Sensitive hostPath Volume + +This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216 +* https://kubernetes.io/docs/concepts/storage/volumes/#hostpath + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 208 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Pod created with a Sensitive hostPath Volume* + + +Kubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs". +- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path. +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision. +- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories. +- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment. +- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data. + + +*False positive analysis* + + +- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads. +- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image. +- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening. +- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods. +- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources. +- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise. +- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image. +- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod. +- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset : "kubernetes.audit_logs" + and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + and kubernetes.audit.objectRef.resource:"pods" + and kubernetes.audit.verb:("create" or "update" or "patch") + and kubernetes.audit.requestObject.spec.volumes.hostPath.path: + ("/" or + "/proc" or + "/root" or + "/var" or + "/var/run" or + "/var/run/docker.sock" or + "/var/run/crio/crio.sock" or + "/var/run/cri-dockerd.sock" or + "/var/lib/kubelet" or + "/var/lib/kubelet/pki" or + "/var/lib/docker/overlay2" or + "/etc" or + "/etc/kubernetes" or + "/etc/kubernetes/manifests" or + "/etc/kubernetes/pki" or + "/home/admin") + and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostipc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostipc.asciidoc new file mode 100644 index 0000000000..6e935783e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostipc.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostipc]] +=== Kubernetes Pod Created With HostIPC + +This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 208 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes 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] +---------------------------------- +event.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:8.4.0") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostnetwork.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostnetwork.asciidoc new file mode 100644 index 0000000000..d8599d7d16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostnetwork.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostnetwork]] +=== Kubernetes Pod Created With HostNetwork + +This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 208 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes 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] +---------------------------------- +event.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.hostNetwork:true + and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostpid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostpid.asciidoc new file mode 100644 index 0000000000..2a6e821466 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostpid.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostpid]] +=== Kubernetes Pod Created With HostPID + +This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 208 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes 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] +---------------------------------- +event.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: ("docker.elastic.co/beats/elastic-agent:8.4.0") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-privileged-pod-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-privileged-pod-created.asciidoc new file mode 100644 index 0000000000..dbd3df0239 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-privileged-pod-created.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-1-kubernetes-privileged-pod-created]] +=== Kubernetes Privileged Pod Created + +This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 208 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Privileged Pod Created* + + +Kubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields. +- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious. +- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation. +- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments. +- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod. + + +*False positive analysis* + + +- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts. +- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production. +- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list. +- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods. +- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis. +- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges. +- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources. +- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod. +- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement. +- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset : "kubernetes.audit_logs" + and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + and kubernetes.audit.objectRef.resource:pods + and kubernetes.audit.verb:create + and kubernetes.audit.requestObject.spec.containers.securityContext.privileged:true + and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-sensitive-configuration-file-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-sensitive-configuration-file-activity.asciidoc new file mode 100644 index 0000000000..0b3e1a14fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-sensitive-configuration-file-activity.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-1-kubernetes-sensitive-configuration-file-activity]] +=== Kubernetes Sensitive Configuration File Activity + +This rule detects the creation or modification of sensitive Kubernetes configuration files on Linux systems. These files include Kubernetes manifests, PKI files, and configuration files that are critical for the operation of Kubernetes clusters. Monitoring these files helps identify potential unauthorized changes or misconfigurations that could lead to security vulnerabilities in Kubernetes environments. Attackers may attempt to modify these files to gain persistence or to deploy malicious containers within the Kubernetes cluster. + +*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 +* Domain: Kubernetes +* Domain: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* 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 Kubernetes Sensitive Configuration File Activity* + + +Kubernetes relies on configuration files to manage cluster operations, including manifests and PKI files. These files are crucial for defining the desired state and security of the cluster. Adversaries may exploit these files to gain persistence or deploy unauthorized containers. The detection rule monitors for unauthorized changes to these files, excluding legitimate processes, to identify potential security threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path that triggered the alert, focusing on paths like "/etc/kubernetes/manifests/*", "/etc/kubernetes/pki/*", or "/etc/kubernetes/*.conf". +- Check the process that attempted to modify the file by examining the process name and compare it against the list of excluded legitimate processes ("kubeadm", "kubelet", "dpkg", "sed") to determine if it is suspicious. +- Investigate the user account associated with the process that made the change to assess if the account has the necessary permissions and if it has been compromised. +- Analyze recent activity on the host to identify any other unusual or unauthorized actions that might correlate with the file modification, such as unexpected network connections or process executions. +- Review the history of changes to the affected file to determine if there have been other unauthorized modifications or if this is an isolated incident. +- Consult Kubernetes audit logs, if available, to gather additional context on the actions performed around the time of the alert, focusing on any anomalies or unauthorized access attempts. + + +*False positive analysis* + + +- Routine updates or maintenance activities by system administrators can trigger alerts. To manage this, consider excluding processes or users known to perform regular maintenance from the rule. +- Automated scripts or configuration management tools like Ansible or Puppet may modify configuration files as part of their normal operation. Identify these tools and add them to the exclusion list to prevent unnecessary alerts. +- Scheduled backups or system snapshots might access or modify configuration files. Ensure that these processes are recognized and excluded if they are part of a regular, non-threatening operation. +- Legitimate software updates or patches may alter configuration files. Monitor update schedules and exclude these processes during known update windows to reduce false positives. +- Custom scripts developed in-house for cluster management might not be recognized by default. Review these scripts and add them to the exclusion list if they are verified as safe and necessary for operations. + + +*Response and remediation* + + +- Immediately isolate the affected node or container to prevent further unauthorized access or changes to the Kubernetes configuration files. +- Review the modified configuration files to identify unauthorized changes and revert them to their last known good state using backups or version control systems. +- Conduct a thorough investigation to identify the source of the unauthorized changes, focusing on process names and user accounts involved in the modification. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or nodes have been compromised. +- Implement additional access controls and monitoring on the affected systems to prevent recurrence, such as restricting write permissions to sensitive directories and files. +- Update and patch the Kubernetes environment and related components to address any vulnerabilities that may have been exploited. +- Enhance detection capabilities by ensuring that alerts are configured to notify the security team of any future unauthorized changes to critical Kubernetes configuration files. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type != "deletion" and file.path like ( + "/etc/kubernetes/manifests/*", + "/etc/kubernetes/pki/*", + "/etc/kubernetes/*.conf" +) and not process.name in ("kubeadm", "kubelet", "dpkg", "sed") + +---------------------------------- + +*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: Container Service +** ID: T1543.005 +** Reference URL: https://attack.mitre.org/techniques/T1543/005/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Container Orchestration Job +** ID: T1053.007 +** Reference URL: https://attack.mitre.org/techniques/T1053/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-service-account-secret-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-service-account-secret-access.asciidoc new file mode 100644 index 0000000000..f19447d77a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-service-account-secret-access.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-1-kubernetes-service-account-secret-access]] +=== Kubernetes Service Account Secret Access + +This rule detects when a process accesses Kubernetes service account secrets. Kubernetes service account secrets are files that contain sensitive information used by applications running in Kubernetes clusters to authenticate and authorize access to the cluster. These secrets are typically mounted into pods at runtime, allowing applications to access them securely. Unauthorized access to these secrets can lead to privilege escalation, lateral movement and unauthorized actions within the cluster. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Service Account Secret Access* + + +Kubernetes service account secrets are crucial for authenticating applications within clusters, providing access to necessary resources. Adversaries may exploit these secrets to escalate privileges or move laterally within the cluster. The detection rule identifies unauthorized access by monitoring processes that interact with secret file paths or specific secret files, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process command line and working directory to confirm if the access to the service account secrets was expected or authorized. Check for any known applications or scripts that should have access to these paths. +- Investigate the user or service account under which the process was executed to determine if it has legitimate reasons to access the Kubernetes service account secrets. +- Examine the process arguments, specifically looking for access to files like "ca.crt", "token", and "namespace", to understand the nature of the access and whether it aligns with normal operations. +- Check the history of the process and any associated processes to identify if there are any patterns of unauthorized access or if this is an isolated incident. +- Correlate the event with other logs or alerts from the same host or cluster to identify any signs of privilege escalation or lateral movement attempts. +- Assess the risk score and severity in the context of the environment to prioritize the investigation and response actions accordingly. + + +*False positive analysis* + + +- Routine access by system processes or monitoring tools can trigger false positives. Identify these processes and create exceptions to prevent unnecessary alerts. +- Automated scripts or applications that regularly access service account secrets for legitimate purposes may be flagged. Review these scripts and whitelist them if they are verified as non-threatening. +- Development and testing environments often have processes accessing service account secrets as part of normal operations. Exclude these environments from the rule or adjust the rule's scope to focus on production environments. +- Frequent access by container orchestration tools or agents that manage Kubernetes clusters can be mistaken for unauthorized access. Ensure these tools are recognized and excluded from triggering alerts. +- Scheduled jobs or cron tasks that interact with service account secrets for maintenance or updates might be flagged. Validate these tasks and add them to an exception list if they are part of regular operations. + + +*Response and remediation* + + +- Immediately isolate the affected pod or container to prevent further unauthorized access or lateral movement within the cluster. +- Revoke and rotate the compromised service account credentials to prevent further misuse. Ensure that new credentials are securely distributed and stored. +- Conduct a thorough review of access logs to identify any unauthorized actions or data access that occurred using the compromised credentials. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the cluster and associated resources. +- Implement network segmentation and access controls to limit the exposure of sensitive secrets and reduce the risk of unauthorized access in the future. +- Enhance monitoring and alerting for unusual access patterns to Kubernetes service account secrets to detect similar threats promptly. +- Review and update Kubernetes security policies to enforce least privilege access and ensure that service accounts have only the necessary permissions for their intended functions. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.command_line like ( + "*/run/secrets/kubernetes.io/serviceaccount*", + "*/var/run/secrets/kubernetes.io/serviceaccount*", + "*/secrets/kubernetes.io/serviceaccount*" + ) or ( + process.working_directory like ( + "/run/secrets/kubernetes.io/serviceaccount", + "/var/run/secrets/kubernetes.io/serviceaccount", + "/secrets/kubernetes.io/serviceaccount" + ) and + process.args in ("ca.crt", "token", "namespace") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc new file mode 100644 index 0000000000..1e4f979920 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-1-kubernetes-suspicious-assignment-of-controller-service-account]] +=== Kubernetes Suspicious Assignment of Controller Service Account + +This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Suspicious Assignment of Controller Service Account* + + +Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the audit logs to confirm the presence of a "create" event for a pod in the "kube-system" namespace with a service account name containing "controller". +- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs. +- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts. +- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster. +- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod. +- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies. + + +*False positive analysis* + + +- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates. +- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts. +- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments. +- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening. +- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged. + + +*Response and remediation* + + +- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing. +- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials. +- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts. +- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless. +- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected. +- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset : "kubernetes.audit_logs" + and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + and kubernetes.audit.verb : "create" + and kubernetes.audit.objectRef.resource : "pods" + and kubernetes.audit.objectRef.namespace : "kube-system" + and kubernetes.audit.requestObject.spec.serviceAccountName:*controller + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-suspicious-self-subject-review.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-suspicious-self-subject-review.asciidoc new file mode 100644 index 0000000000..70a11ce328 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-suspicious-self-subject-review.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-1-kubernetes-suspicious-self-subject-review]] +=== Kubernetes Suspicious Self-Subject Review + +This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms +* https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access +* https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/detecting-identity-attacks-in-kubernetes/ba-p/3232340 + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 207 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Suspicious Self-Subject Review* + + +Kubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields. +- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews. +- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source. +- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior. +- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered. +- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise. + + +*False positive analysis* + + +- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls. +- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule. +- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts. +- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors. + + +*Response and remediation* + + +- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster. +- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts. +- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely. +- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts. +- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset : "kubernetes.audit_logs" + and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + and kubernetes.audit.verb:"create" + and kubernetes.audit.objectRef.resource:("selfsubjectaccessreviews" or "selfsubjectrulesreviews") + and (kubernetes.audit.user.username:(system\:serviceaccount\:* or system\:node\:*) + or kubernetes.audit.impersonatedUser.username:(system\:serviceaccount\:* or system\:node\:*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-user-exec-into-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-user-exec-into-pod.asciidoc new file mode 100644 index 0000000000..3e1e5d5da2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-kubernetes-user-exec-into-pod.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-1-kubernetes-user-exec-into-pod]] +=== Kubernetes User Exec into Pod + +This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/ +* https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/ + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 208 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes User Exec into Pod* + + +Kubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for "kubernetes.audit_logs". +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access. +- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource. +- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access. +- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address. +- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment. + + +*False positive analysis* + + +- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly. +- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses. +- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows. +- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod. +- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized. +- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege. +- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod. +- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised. +- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "linux" and event.dataset == "kubernetes.audit_logs" and +kubernetes.audit.verb in ("get", "create") and kubernetes.audit.objectRef.subresource == "exec" and +kubernetes.audit.stage == "ResponseComplete" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-linux-telegram-api-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-linux-telegram-api-request.asciidoc new file mode 100644 index 0000000000..84dbe5f87d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-linux-telegram-api-request.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-1-linux-telegram-api-request]] +=== Linux Telegram API Request + +This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux Telegram API Request* + + +Telegram's API allows applications to interact with its messaging platform, often used for legitimate automation and communication tasks. However, adversaries may exploit this by using commands like `curl` or `wget` to communicate with Telegram's API for command and control purposes. The detection rule identifies such suspicious activity by monitoring for these commands accessing the Telegram API, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the curl or wget command with the api.telegram.org domain in the command line, as indicated by the process.command_line field. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if the account may be compromised. +- Check the network activity logs to identify any additional connections to api.telegram.org or other suspicious domains, which may indicate further command and control communication. +- Analyze the parent process of the detected curl or wget command to understand how the process was initiated and if it was triggered by another suspicious activity. +- Examine the system for any other indicators of compromise, such as unusual file modifications or additional unauthorized processes, to assess the scope of potential malicious activity. + + +*False positive analysis* + + +- Legitimate automation scripts or applications may use curl or wget to interact with Telegram's API for non-malicious purposes. Review the context and purpose of these scripts to determine if they are authorized. +- System administrators or developers might use curl or wget for testing or maintenance tasks involving Telegram's API. Verify if these activities are part of routine operations and consider excluding them if they are deemed safe. +- Monitoring tools or integrations that rely on Telegram for notifications could trigger this rule. Identify these tools and add exceptions for their known processes to prevent unnecessary alerts. +- If a specific user or service account frequently triggers this rule due to legitimate use, consider creating an exception for that account to reduce noise while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further communication with the Telegram API and potential data exfiltration. +- Terminate any suspicious processes identified as using curl or wget to interact with api.telegram.org to halt ongoing malicious activities. +- Conduct a thorough review of the affected system's process logs and network connections to identify any additional indicators of compromise or related malicious activity. +- Remove any unauthorized scripts or binaries that may have been used to automate the interaction with the Telegram API. +- Reset credentials and review access permissions for any accounts that were active on the affected system to prevent unauthorized access. +- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that could be exploited in similar attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.name in ("curl", "wget") and process.command_line like "*api.telegram.org*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-local-account-tokenfilter-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-local-account-tokenfilter-policy-disabled.asciidoc new file mode 100644 index 0000000000..93ab55385c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-local-account-tokenfilter-policy-disabled.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-1-local-account-tokenfilter-policy-disabled]] +=== Local Account TokenFilter Policy Disabled + +Identifies registry modification to the LocalAccountTokenFilterPolicy policy. If this value exists (which doesn't by default) and is set to 1, then remote connections from all local members of Administrators are granted full high-integrity tokens during negotiation. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.stigviewer.com/stig/windows_server_2008_r2_member_server/2014-04-02/finding/V-36439 +* https://posts.specterops.io/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy-506c25a7c167 +* https://www.welivesecurity.com/wp-content/uploads/2018/01/ESET_Turla_Mosquito.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender for Endpoint +* Resources: Investigation Guide + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Local Account TokenFilter Policy Disabled* + + +The LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled, allows remote connections from local administrators to use full high-integrity tokens. Adversaries may exploit this to bypass User Account Control (UAC) and gain elevated privileges remotely. The detection rule monitors changes to this registry setting, identifying potential unauthorized modifications that could indicate an attempt to facilitate lateral movement or evade defenses. + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the change to the LocalAccountTokenFilterPolicy setting, specifically looking for entries where the registry.value is "LocalAccountTokenFilterPolicy" and registry.data.strings is "1" or "0x00000001". +- Identify the user account and process responsible for the registry modification by examining the associated event logs for user and process information. +- Check for any recent remote connections to the affected system, focusing on connections initiated by local administrator accounts, to determine if the change was exploited for lateral movement. +- Investigate any other recent registry changes on the host to identify potential patterns of unauthorized modifications that could indicate broader malicious activity. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and assess the scope of the potential threat. +- Assess the system for signs of compromise or malicious activity, such as unusual processes, network connections, or file modifications, that may have occurred around the time of the registry change. + + +*False positive analysis* + + +- Administrative tools or scripts that modify the LocalAccountTokenFilterPolicy for legitimate configuration purposes may trigger alerts. To manage this, identify and document these tools, then create exceptions for their known registry changes. +- System updates or patches that adjust registry settings as part of their installation process can cause false positives. Monitor update schedules and correlate alerts with these activities to determine if they are benign. +- Security software or management solutions that enforce policy changes across endpoints might modify this registry setting. Verify these actions with your IT or security team and consider excluding these processes from triggering alerts. +- Custom scripts or automation tasks used for system hardening or configuration management may alter this setting. Review these scripts and whitelist their expected changes to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revert the registry setting for LocalAccountTokenFilterPolicy to its default state if it was modified without authorization. +- Conduct a thorough review of recent administrative activities and access logs on the affected system to identify any unauthorized access or changes. +- Reset passwords for all local administrator accounts on the affected system to prevent potential misuse of compromised credentials. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify registry settings. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional network segmentation and access controls to limit administrative access to critical systems and reduce the risk of similar threats. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "LocalAccountTokenFilterPolicy" and + registry.path : ( + "HKLM\\*\\LocalAccountTokenFilterPolicy", + "\\REGISTRY\\MACHINE\\*\\LocalAccountTokenFilterPolicy", + "MACHINE\\*\\LocalAccountTokenFilterPolicy" + ) and registry.data.strings : ("1", "0x00000001") and + not process.executable : ( + /* Intune */ + "C:\\Windows\\system32\\deviceenroller.exe", + "C:\\Windows\\system32\\omadmclient.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Hash +** ID: T1550.002 +** Reference URL: https://attack.mitre.org/techniques/T1550/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-manual-memory-dumping-via-proc-filesystem.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-manual-memory-dumping-via-proc-filesystem.asciidoc new file mode 100644 index 0000000000..d1ae7ae492 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-manual-memory-dumping-via-proc-filesystem.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-1-manual-memory-dumping-via-proc-filesystem]] +=== Manual Memory Dumping via Proc Filesystem + +This rule monitors for manual memory dumping via the proc filesystem. The proc filesystem in Linux provides a virtual filesystem that contains information about system processes and their memory mappings. Attackers may use this technique to dump the memory of a process, potentially extracting sensitive information such as credentials or encryption keys. + +*Rule type*: eql + +*Rule indices*: + +* 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: Credential Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Manual Memory Dumping via Proc Filesystem* + + +The proc filesystem in Linux is a virtual interface providing detailed insights into system processes and their memory. Adversaries exploit this by manually dumping memory from processes to extract sensitive data like credentials. The detection rule identifies suspicious activities by monitoring process executions that access memory files within the proc directory, flagging potential credential access attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name and command line that triggered the rule, focusing on processes like "cat", "grep", "tail", "less", "more", "egrep", or "fgrep" accessing "/proc/*/mem". +- Examine the process execution context, including the parent process and user account associated with the suspicious activity, to determine if the activity is expected or potentially malicious. +- Check the system logs and historical data for any previous occurrences of similar activities involving the same process names and command lines to assess if this is part of a pattern or anomaly. +- Investigate the user account's recent activities and permissions to determine if there are any signs of compromise or unauthorized access that could explain the memory dumping attempt. +- Analyze network traffic and connections from the host to identify any potential data exfiltration attempts or communications with known malicious IP addresses or domains. +- If necessary, isolate the affected system to prevent further potential data leakage and conduct a deeper forensic analysis to uncover any additional indicators of compromise. + + +*False positive analysis* + + +- System administrators or automated scripts may legitimately access the proc filesystem for monitoring or debugging purposes. To handle this, identify and whitelist known scripts or administrative tools that frequently access memory files. +- Security tools or monitoring solutions might access the proc filesystem as part of their regular operations. Review and exclude these processes from the rule to prevent unnecessary alerts. +- Developers or testers might use commands like cat or grep on proc files during application debugging. Establish a list of approved users or groups who are allowed to perform these actions and exclude their activities from triggering alerts. +- Backup or system maintenance processes could involve accessing proc files. Document these processes and create exceptions for them to avoid false positives. +- Regular system health checks might involve accessing memory files. Identify these checks and configure the rule to ignore them by specifying the associated process names or command patterns. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access or data exfiltration. Disconnect the network connection and disable remote access capabilities. +- Terminate any suspicious processes identified by the detection rule, specifically those accessing memory files within the proc directory using commands like "cat", "grep", "tail", "less", "more", "egrep", or "fgrep". +- Conduct a memory analysis on the isolated system to identify any extracted sensitive data, such as credentials or encryption keys, and assess the extent of the compromise. +- Change all potentially compromised credentials and encryption keys immediately, prioritizing those associated with critical systems and services. +- Review and enhance system logging and monitoring configurations to ensure comprehensive visibility into process activities, particularly those involving the proc filesystem. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional security controls, such as restricting access to the proc filesystem and employing application whitelisting, to prevent unauthorized memory dumping activities in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.command_line like "/proc/*/mem" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Proc Filesystem +** ID: T1003.007 +** Reference URL: https://attack.mitre.org/techniques/T1003/007/ +* Technique: +** Name: Exploitation for Credential Access +** ID: T1212 +** Reference URL: https://attack.mitre.org/techniques/T1212/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc new file mode 100644 index 0000000000..59e263c156 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-1-manual-mount-discovery-via-etc-exports-or-etc-fstab]] +=== Manual Mount Discovery via /etc/exports or /etc/fstab + +This rule detects manual mount discovery via the /etc/exports or /etc/fstab file on Linux systems. These files are used by NFS (Network File System) to define which directories are shared with remote hosts. Attackers may access this file to gather information about shared directories and potential targets for further exploitation. + +*Rule type*: eql + +*Rule indices*: + +* 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: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Manual Mount Discovery via /etc/exports or /etc/fstab* + + +In Linux environments, the `/etc/exports` and `/etc/fstab` files are crucial for managing shared directories and mounting filesystems, respectively. Adversaries may exploit these files to identify shared resources and potential targets for lateral movement. The detection rule identifies suspicious processes accessing these files, using common command-line utilities, to flag potential reconnaissance activities by attackers. + + +*Possible investigation steps* + + +- Review the process details to identify the user account associated with the suspicious activity, focusing on the process.name and process.command_line fields. +- Examine the command line arguments in the process.command_line field to determine the specific actions taken and whether they align with legitimate administrative tasks. +- Check the process start time and correlate it with other system activities to identify any unusual patterns or sequences of events. +- Investigate the source IP address or hostname if the process was initiated remotely, to assess whether it is a known or trusted entity. +- Look for any other related alerts or logs around the same timeframe to identify potential lateral movement or further reconnaissance activities. +- Verify if the accessed directories in /etc/exports or /etc/fstab are critical or sensitive, and assess the potential impact of unauthorized access. + + +*False positive analysis* + + +- Routine system administration tasks may trigger alerts when administrators use command-line utilities to view or edit /etc/exports or /etc/fstab. To mitigate this, consider excluding processes executed by known administrator accounts or during scheduled maintenance windows. +- Automated scripts for system monitoring or configuration management might access these files regularly. Identify and whitelist these scripts by their process names or command-line patterns to reduce false positives. +- Backup operations often involve reading configuration files like /etc/exports or /etc/fstab. Exclude processes associated with backup software or services to prevent unnecessary alerts. +- Security tools or compliance checks may scan these files as part of their regular operations. Review and whitelist these tools based on their process names or command-line arguments to avoid false positives. +- Developers or testers might access these files in development environments for testing purposes. Consider excluding processes from development servers or specific user accounts associated with testing activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Conduct a thorough review of the `/etc/exports` and `/etc/fstab` files on the affected system to identify any unauthorized changes or suspicious entries. +- Revoke any unauthorized access to shared directories identified in the `/etc/exports` file and ensure that only trusted hosts have access. +- Reset credentials and review access permissions for users and services that have access to the affected system to prevent further unauthorized access. +- Monitor network traffic for any unusual activity originating from the affected system, focusing on connections to external IPs or unexpected internal hosts. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement enhanced monitoring and logging for access to critical configuration files like `/etc/exports` and `/etc/fstab` to detect similar threats in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.command_line like ("/etc/exports", "/etc/fstab") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-365-brute-force-via-entra-id-sign-ins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-365-brute-force-via-entra-id-sign-ins.asciidoc new file mode 100644 index 0000000000..4758e95107 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-365-brute-force-via-entra-id-sign-ins.asciidoc @@ -0,0 +1,252 @@ +[[prebuilt-rule-8-19-1-microsoft-365-brute-force-via-entra-id-sign-ins]] +=== Microsoft 365 Brute Force via Entra ID Sign-Ins + +Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft 365 Brute Force via Entra ID Sign-Ins* + + +Identifies brute-force authentication activity against Microsoft 365 services using Entra ID sign-in logs. This detection groups and classifies failed sign-in attempts based on behavior indicative of password spraying, credential stuffing, or password guessing. The classification (`bf_type`) is included for immediate triage. + + +*Possible investigation steps* + + +- Review `bf_type`: Classifies the brute-force behavior (`password_spraying`, `credential_stuffing`, `password_guessing`). +- Examine `user_id_list`: Review the identities targeted. Are they admins, service accounts, or external identities? +- Review `login_errors`: Multiple identical errors (e.g., `"Invalid grant..."`) suggest automated abuse or tooling. +- Check `ip_list` and `source_orgs`: Determine if requests came from known VPNs, hosting providers, or anonymized infrastructure. +- Validate `unique_ips` and `countries`: Multiple countries or IPs in a short window may indicate credential stuffing or distributed spray attempts. +- Compare `total_attempts` vs `duration_seconds`: High volume over a short duration supports non-human interaction. +- Inspect `user_agent.original` via `device_detail_browser`: Clients like `Python Requests` or `curl` are highly suspicious. +- Investigate `client_app_display_name` and `incoming_token_type`: Identify non-browser-based logins, token abuse or commonly mimicked clients like VSCode. +- Review `target_resource_display_name`: Confirm the service being targeted (e.g., SharePoint, Exchange). This may be what authorization is being attempted against. +- Pivot using `session_id` and `device_detail_device_id`: Determine if a single device is spraying multiple accounts. +- Check `conditional_access_status`: If "notApplied", determine whether conditional access is properly scoped. +- Correlate `user_principal_name` with successful sign-ins: Investigate surrounding logs for lateral movement or privilege abuse. + + +*False positive analysis* + + +- Developer automation (e.g., CI/CD logins) or mobile sync errors may create noisy but benign login failures. +- Red team exercises or pentesting can resemble brute-force patterns. +- Legacy protocols or misconfigured service principals may trigger repeated login failures from the same IP or session. + + +*Response and remediation* + + +- Notify identity or security operations teams to investigate further. +- Lock or reset affected user accounts if compromise is suspected. +- Block the source IP(s) or ASN temporarily using conditional access or firewall rules. +- Review tenant-wide MFA and conditional access enforcement. +- Audit targeted accounts for password reuse across systems or tenants. +- Enable lockout or throttling policies for repeated failed login attempts. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.signinlogs* + +| EVAL + time_window = DATE_TRUNC(15 minutes, @timestamp), + user_id = TO_LOWER(azure.signinlogs.properties.user_principal_name), + ip = source.ip, + login_error = azure.signinlogs.result_description, + error_code = azure.signinlogs.properties.status.error_code, + request_type = TO_LOWER(azure.signinlogs.properties.incoming_token_type), + app_name = TO_LOWER(azure.signinlogs.properties.app_display_name), + asn_org = source.`as`.organization.name, + country = source.geo.country_name, + user_agent = user_agent.original, + event_time = @timestamp + +| WHERE event.dataset == "azure.signinlogs" + AND event.category == "authentication" + AND azure.signinlogs.category IN ("NonInteractiveUserSignInLogs", "SignInLogs") + AND azure.signinlogs.properties.resource_display_name RLIKE "(.*)365|SharePoint|Exchange|Teams|Office(.*)" + AND event.outcome == "failure" + AND error_code != 50053 + AND azure.signinlogs.properties.status.error_code IN ( + 50034, // UserAccountNotFound + 50126, // InvalidUsernameOrPassword + 50055, // PasswordExpired + 50056, // InvalidPassword + 50057, // UserDisabled + 50064, // CredentialValidationFailure + 50076, // MFARequiredButNotPassed + 50079, // MFARegistrationRequired + 50105, // EntitlementGrantsNotFound + 70000, // InvalidGrant + 70008, // ExpiredOrRevokedRefreshToken + 70043, // BadTokenDueToSignInFrequency + 80002, // OnPremisePasswordValidatorRequestTimedOut + 80005, // OnPremisePasswordValidatorUnpredictableWebException + 50144, // InvalidPasswordExpiredOnPremPassword + 50135, // PasswordChangeCompromisedPassword + 50142, // PasswordChangeRequiredConditionalAccess + 120000, // PasswordChangeIncorrectCurrentPassword + 120002, // PasswordChangeInvalidNewPasswordWeak + 120020 // PasswordChangeFailure + ) + AND user_id IS NOT NULL AND user_id != "" + AND user_agent != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0" + +| STATS + authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement), + client_app_id = VALUES(azure.signinlogs.properties.app_id), + client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name), + target_resource_id = VALUES(azure.signinlogs.properties.resource_id), + target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name), + conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status), + device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser), + device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id), + device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system), + incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type), + risk_state = VALUES(azure.signinlogs.properties.risk_state), + session_id = VALUES(azure.signinlogs.properties.session_id), + user_id = VALUES(azure.signinlogs.properties.user_id), + user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name), + result_description = VALUES(azure.signinlogs.result_description), + result_signature = VALUES(azure.signinlogs.result_signature), + result_type = VALUES(azure.signinlogs.result_type), + + unique_users = COUNT_DISTINCT(user_id), + user_id_list = VALUES(user_id), + login_errors = VALUES(login_error), + unique_login_errors = COUNT_DISTINCT(login_error), + error_codes = VALUES(error_code), + unique_error_codes = COUNT_DISTINCT(error_code), + request_types = VALUES(request_type), + app_names = VALUES(app_name), + ip_list = VALUES(ip), + unique_ips = COUNT_DISTINCT(ip), + source_orgs = VALUES(asn_org), + countries = VALUES(country), + unique_country_count = COUNT_DISTINCT(country), + unique_asn_orgs = COUNT_DISTINCT(asn_org), + first_seen = MIN(event_time), + last_seen = MAX(event_time), + total_attempts = COUNT() +BY time_window + +| EVAL + duration_seconds = DATE_DIFF("seconds", first_seen, last_seen), + bf_type = CASE( + // Many users, relatively few distinct login errors, distributed over multiple IPs (but not too many), + // and happens quickly. Often bots using leaked credentials. + unique_users >= 10 AND total_attempts >= 30 AND unique_login_errors <= 3 + AND unique_ips >= 5 + AND duration_seconds <= 600 + AND unique_users > unique_ips, + "credential_stuffing", + + // One password against many users. Single error (e.g., "InvalidPassword"), not necessarily fast. + unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 15 AND duration_seconds <= 1800, + "password_spraying", + + // One user targeted repeatedly (same error), OR extremely noisy pattern from many IPs. + (unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 30 AND duration_seconds <= 300) + OR (unique_users <= 3 AND unique_ips > 30 AND total_attempts >= 100), + "password_guessing", + + // everything else + "other" + ) + +| KEEP + time_window, bf_type, duration_seconds, total_attempts, first_seen, last_seen, + unique_users, user_id_list, login_errors, unique_login_errors, + unique_error_codes, error_codes, request_types, app_names, + ip_list, unique_ips, source_orgs, countries, + unique_country_count, unique_asn_orgs, + authentication_requirement, client_app_id, client_app_display_name, + target_resource_id, target_resource_display_name, conditional_access_status, + device_detail_browser, device_detail_device_id, device_detail_operating_system, + incoming_token_type, risk_state, session_id, user_id, + user_principal_name, result_description, result_signature, result_type + +| WHERE bf_type != "other" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-entra-id-sign-in-brute-force-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-entra-id-sign-in-brute-force-activity.asciidoc new file mode 100644 index 0000000000..7f4787d73d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-entra-id-sign-in-brute-force-activity.asciidoc @@ -0,0 +1,249 @@ +[[prebuilt-rule-8-19-1-microsoft-entra-id-sign-in-brute-force-activity]] +=== Microsoft Entra ID Sign-In Brute Force Activity + +Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Entra ID Sign-In Brute Force Activity* + + +This rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response. + + +*Possible investigation steps* + + +- Review `bf_type`: Determines the brute-force technique being used (`password_spraying`, `credential_stuffing`, or `password_guessing`). +- Examine `user_id_list`: Identify if high-value accounts (e.g., administrators, service principals, federated identities) are being targeted. +- Review `login_errors`: Repetitive error types like `"Invalid Grant"` or `"User Not Found"` suggest automated attacks. +- Check `ip_list` and `source_orgs`: Investigate if the activity originates from suspicious infrastructure (VPNs, hosting providers, etc.). +- Validate `unique_ips` and `countries`: Geographic diversity and IP volume may indicate distributed or botnet-based attacks. +- Compare `total_attempts` vs `duration_seconds`: High rate of failures in a short time period implies automation. +- Analyze `user_agent.original` and `device_detail_browser`: User agents like `curl`, `Python`, or generic libraries may indicate scripting tools. +- Investigate `client_app_display_name` and `incoming_token_type`: Detect potential abuse of legacy or unattended login mechanisms. +- Inspect `target_resource_display_name`: Understand what application or resource the attacker is trying to access. +- Pivot using `session_id` and `device_detail_device_id`: Determine if a device is targeting multiple accounts. +- Review `conditional_access_status`: If not enforced, ensure Conditional Access policies are scoped correctly. + + +*False positive analysis* + + +- Legitimate automation (e.g., misconfigured scripts, sync processes) can trigger repeated failures. +- Internal red team activity or penetration tests may mimic brute-force behaviors. +- Certain service accounts or mobile clients may generate repetitive sign-in noise if not properly configured. + + +*Response and remediation* + + +- Notify your identity security team for further analysis. +- Investigate and lock or reset impacted accounts if compromise is suspected. +- Block offending IPs or ASNs at the firewall, proxy, or using Conditional Access. +- Confirm MFA and Conditional Access are enforced for all user types. +- Audit targeted accounts for credential reuse across services. +- Implement account lockout or throttling for failed sign-in attempts where possible. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.signinlogs* + +// Define a time window for grouping and maintain the original event timestamp +| EVAL + time_window = DATE_TRUNC(15 minutes, @timestamp), + event_time = @timestamp + +// Filter relevant failed authentication events with specific error codes +| WHERE event.dataset == "azure.signinlogs" + AND event.category == "authentication" + AND azure.signinlogs.category IN ("NonInteractiveUserSignInLogs", "SignInLogs") + AND event.outcome == "failure" + AND azure.signinlogs.properties.authentication_requirement == "singleFactorAuthentication" + AND azure.signinlogs.properties.status.error_code IN ( + 50034, // UserAccountNotFound + 50126, // InvalidUsernameOrPassword + 50055, // PasswordExpired + 50056, // InvalidPassword + 50057, // UserDisabled + 50064, // CredentialValidationFailure + 50076, // MFARequiredButNotPassed + 50079, // MFARegistrationRequired + 50105, // EntitlementGrantsNotFound + 70000, // InvalidGrant + 70008, // ExpiredOrRevokedRefreshToken + 70043, // BadTokenDueToSignInFrequency + 80002, // OnPremisePasswordValidatorRequestTimedOut + 80005, // OnPremisePasswordValidatorUnpredictableWebException + 50144, // InvalidPasswordExpiredOnPremPassword + 50135, // PasswordChangeCompromisedPassword + 50142, // PasswordChangeRequiredConditionalAccess + 120000, // PasswordChangeIncorrectCurrentPassword + 120002, // PasswordChangeInvalidNewPasswordWeak + 120020 // PasswordChangeFailure + ) + AND azure.signinlogs.properties.user_principal_name IS NOT NULL AND azure.signinlogs.properties.user_principal_name != "" + AND user_agent.original != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0" + AND source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + +// Aggregate statistics for behavioral pattern analysis +| STATS + authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement), + client_app_id = VALUES(azure.signinlogs.properties.app_id), + client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name), + target_resource_id = VALUES(azure.signinlogs.properties.resource_id), + target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name), + conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status), + device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser), + device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id), + device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system), + incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type), + risk_state = VALUES(azure.signinlogs.properties.risk_state), + session_id = VALUES(azure.signinlogs.properties.session_id), + user_id = VALUES(azure.signinlogs.properties.user_id), + user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name), + result_description = VALUES(azure.signinlogs.result_description), + result_signature = VALUES(azure.signinlogs.result_signature), + result_type = VALUES(azure.signinlogs.result_type), + + unique_users = COUNT_DISTINCT(azure.signinlogs.properties.user_id), + user_id_list = VALUES(azure.signinlogs.properties.user_id), + login_errors = VALUES(azure.signinlogs.result_description), + unique_login_errors = COUNT_DISTINCT(azure.signinlogs.result_description), + error_codes = VALUES(azure.signinlogs.properties.status.error_code), + unique_error_codes = COUNT_DISTINCT(azure.signinlogs.properties.status.error_code), + request_types = VALUES(azure.signinlogs.properties.incoming_token_type), + app_names = VALUES(azure.signinlogs.properties.app_display_name), + ip_list = VALUES(source.ip), + unique_ips = COUNT_DISTINCT(source.ip), + source_orgs = VALUES(source.`as`.organization.name), + countries = VALUES(source.geo.country_name), + unique_country_count = COUNT_DISTINCT(source.geo.country_name), + unique_asn_orgs = COUNT_DISTINCT(source.`as`.organization.name), + first_seen = MIN(@timestamp), + last_seen = MAX(@timestamp), + total_attempts = COUNT() +BY time_window + +// Determine brute force behavior type based on statistical thresholds +| EVAL + duration_seconds = DATE_DIFF("seconds", first_seen, last_seen), + bf_type = CASE( + // Many users, relatively few distinct login errors, distributed over multiple IPs (but not too many), + // and happens quickly. Often bots using leaked credentials. + unique_users >= 10 AND total_attempts >= 30 AND unique_login_errors <= 3 + AND unique_ips >= 5 + AND duration_seconds <= 600 + AND unique_users > unique_ips, + "credential_stuffing", + + // One password against many users. Single error (e.g., "InvalidPassword"), not necessarily fast. + unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 15 AND duration_seconds <= 1800, + "password_spraying", + + // One user targeted repeatedly (same error), OR extremely noisy pattern from many IPs. + (unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 30 AND duration_seconds <= 300) + OR (unique_users <= 3 AND unique_ips > 30 AND total_attempts >= 100), + "password_guessing", + + // everything else + "other" + ) + +// Only keep columns necessary for detection output/reporting +| KEEP + time_window, bf_type, duration_seconds, total_attempts, first_seen, last_seen, + unique_users, user_id_list, login_errors, unique_login_errors, + unique_error_codes, error_codes, request_types, app_names, + ip_list, unique_ips, source_orgs, countries, + unique_country_count, unique_asn_orgs, + authentication_requirement, client_app_id, client_app_display_name, + target_resource_id, target_resource_display_name, conditional_access_status, + device_detail_browser, device_detail_device_id, device_detail_operating_system, + incoming_token_type, risk_state, session_id, user_id, + user_principal_name, result_description, result_signature, result_type + +// Remove anything not classified as credential attack activity +| WHERE bf_type != "other" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-entra-id-suspicious-cloud-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-entra-id-suspicious-cloud-device-registration.asciidoc new file mode 100644 index 0000000000..17b603a726 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-microsoft-entra-id-suspicious-cloud-device-registration.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-1-microsoft-entra-id-suspicious-cloud-device-registration]] +=== Microsoft Entra ID Suspicious Cloud Device Registration + +Detects a sequence of events in Microsoft Entra ID indicative of a suspicious cloud-based device registration, potentially using ROADtools. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools, a popular red team toolkit, often leaves distinct telemetry signatures such as the `Microsoft.OData.Client` user agent and specific OS version values. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Entra ID Suspicious Cloud Device Registration* + + +This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation. The activity includes three correlated events: + +1. Add device operation from the Device Registration Service using a `Microsoft.OData.Client/*` user-agent and a known Windows OS version. +2. Addition of a registered user with an `enterprise registration` URN. +3. Assignment of a registered owner to the device. + +This pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access. + + +*Possible investigation steps* + + +- Identify the user principal associated with the device registration. +- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request. +- Check for the presence of the `Microsoft.OData.Client/*` user-agent in `azure.auditlogs.properties.additional_details.value`, as this is common in ROADtools usage. +- Confirm the OS version seen in the modified properties is expected (e.g., `10.0.19041.928`), or investigate unexpected versions. +- Examine the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) to verify it's not being misused. +- Use `azure.correlation_id` to pivot across all three steps of the registration flow. +- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens. +- Look for signs of persistence or lateral movement enabled by the newly registered device. +- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization. +- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration. +- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`. + + +*False positive analysis* + + +- Some MDM or autopilot provisioning flows may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory. +- Investigate whether the device name, OS version, and registration details align with normal IT workflows. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID. +- Revoke refresh tokens and primary refresh tokens associated with the user and device. +- Disable the user account and initiate password reset and identity verification procedures. +- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device. +- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by azure.correlation_id with maxspan=1m +[any where event.dataset == "azure.auditlogs" and + azure.auditlogs.identity == "Device Registration Service" and + azure.auditlogs.operation_name == "Add device" and + azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" and ( + `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "CloudAccountEnabled" and + `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == "[true]" + ) and + `azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value` like "*10.0.19041.928*"] +[any where event.dataset == "azure.auditlogs" and + azure.auditlogs.operation_name == "Add registered users to device" and + `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like "*urn:ms-drs:enterpriseregistration.windows.net*"] +[any where event.dataset == "azure.auditlogs" and + azure.auditlogs.operation_name == "Add registered owner to device"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc new file mode 100644 index 0000000000..4ec7c1dc4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc @@ -0,0 +1,95 @@ +[[prebuilt-rule-8-19-1-multiple-alerts-in-different-att-ck-tactics-on-a-single-host]] +=== Multiple Alerts in Different ATT&CK Tactics on a Single Host + +This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: threshold + +*Rule indices*: + +* .alerts-security.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Alerts in Different ATT&CK Tactics on a Single Host* + + +The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +signal.rule.name:* and kibana.alert.rule.threat.tactic.id:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-okta-user-sessions-started-from-different-geolocations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-okta-user-sessions-started-from-different-geolocations.asciidoc new file mode 100644 index 0000000000..4850530b7b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-okta-user-sessions-started-from-different-geolocations.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-1-okta-user-sessions-started-from-different-geolocations]] +=== Okta User Sessions Started from Different Geolocations + +Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 305 + +*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 ES|QL 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 + event.dataset == "okta.system" + AND (event.action RLIKE "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, event.outcome, client.geo.country_name, okta.actor.alternate_id +| STATS + geo_auth_counts = COUNT_DISTINCT(client.geo.country_name) + BY okta.actor.id, okta.actor.alternate_id +| WHERE + geo_auth_counts >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-backdoor-execution-through-pam-exec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-backdoor-execution-through-pam-exec.asciidoc new file mode 100644 index 0000000000..4b892c514c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-backdoor-execution-through-pam-exec.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-1-potential-backdoor-execution-through-pam-exec]] +=== Potential Backdoor Execution Through PAM_EXEC + +This rule detects SSH session ID change followed by a suspicious SSHD child process, this may indicate the successful execution of a potentially malicious process through the Pluggable Authentication Module (PAM) utility. PAM is a framework used by Linux systems to authenticate users. Adversaries may create malicious PAM modules that grant them persistence onto the target every time a user logs in by executing a backdoor script or command. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/approaching-the-summit-on-persistence +* https://www.group-ib.com/blog/pluggable-authentication-module/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Backdoor Execution Through PAM_EXEC* + + +PAM (Pluggable Authentication Module) is a critical framework in Linux systems for user authentication. Adversaries may exploit PAM by inserting malicious modules that execute backdoor scripts during user logins, ensuring persistent access. The detection rule identifies this threat by monitoring SSH session changes followed by unusual child processes, often indicative of backdoor execution, especially when these processes originate from suspicious directories or use scripting languages. + + +*Possible investigation steps* + + +- Review the process entity ID associated with the alert to identify the specific SSH session and its related activities. +- Examine the parent process details, specifically focusing on the SSH or SSHD process, to determine the source and legitimacy of the login attempt. +- Investigate the child process that was started, paying close attention to its name and executable path, especially if it matches patterns like scripting languages (e.g., perl, python) or suspicious directories (e.g., /tmp, /var/tmp). +- Check the process arguments count and content to understand the command or script being executed, which may provide insights into the potential backdoor's functionality. +- Correlate the event timestamp with user login records and system logs to identify any unusual login patterns or unauthorized access attempts. +- Assess the risk and impact by determining if the process has made any unauthorized changes to the system or if it has established any persistent mechanisms. +- If a backdoor is confirmed, initiate containment measures such as terminating the malicious process, removing the unauthorized PAM module, and conducting a full system audit to prevent further exploitation. + + +*False positive analysis* + + +- Legitimate administrative scripts executed via SSH may trigger the rule if they use scripting languages like Perl, Python, or PHP. To handle this, identify and whitelist known administrative scripts and their execution paths. +- Automated backup or maintenance processes that run from directories like /var/backups or /var/log can be mistaken for malicious activity. Exclude these processes by specifying their exact paths and names in the exception list. +- Development or testing environments where scripts are frequently executed from temporary directories such as /tmp or /dev/shm may cause false positives. Implement exceptions for these environments by defining specific user accounts or process names that are known to be safe. +- Custom monitoring or logging tools that spawn child processes from SSH sessions might be flagged. Review these tools and add them to the exclusion list if they are verified as non-threatening. +- Regular user activities involving the use of scripting languages for legitimate purposes can be misinterpreted. Educate users on best practices and adjust the rule to exclude common benign scripts used in daily operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or using scripting languages. +- Conduct a thorough review of PAM configuration files and modules to identify and remove any unauthorized or malicious entries. +- Reset credentials for all users on the affected system, prioritizing those with elevated privileges, to mitigate potential credential compromise. +- Restore the system from a known good backup if malicious modifications are confirmed, ensuring that the backup is free from tampering. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of the threat, focusing on SSH session changes and unusual child processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "change" and event.action == "session_id_change" and process.name in ("ssh", "sshd")] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name in ("ssh", "sshd") and + process.args_count == 2 and ( + process.name like ("perl*", "python*", "php*", "ruby*", "lua*") or + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/boot/*", "/sys/*", "/lost+found/*", "/media/*", "/proc/*", + "/var/backups/*", "/var/log/*", "/var/mail/*", "/var/spool/*") or + process.name like ".*" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* 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-1/prebuilt-rule-8-19-1-potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-data-exfiltration-through-curl.asciidoc new file mode 100644 index 0000000000..b6be4ef20c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-data-exfiltration-through-curl.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-1-potential-data-exfiltration-through-curl]] +=== Potential Data Exfiltration Through Curl + +Detects the use of curl to upload an archived file to an internet server. Threat actors often will collect data on a system and compress it in an archive file before exfiltrating the file back to their C2 server for review. Many threat actors have been seen utilizing curl to upload this archive file with the collected data to do this. Use of curl in this way while not inherently malicious should be considered highly abnormal and suspicious activity. + +*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://everything.curl.dev/usingcurl/uploads + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating 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]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "curl" and +process.parent.executable != null and (process.args in ("-F", "-T", "-d") or process.args like "--data*") and +process.command_line like~ ("*@/*.zip*", "*@/*.gz*", "*@/*.tgz*", "*b64=@*", "*=<*") and +process.command_line like~ "*http*" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc new file mode 100644 index 0000000000..1a947e7029 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-1-potential-dynamic-iex-reconstruction-via-environment-variables]] +=== Potential Dynamic IEX Reconstruction via Environment Variables + +Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Dynamic IEX Reconstruction via Environment Variables* + + +PowerShell's Invoke-Expression (IEX) command is a powerful tool for executing strings as code, often exploited by attackers to run obfuscated scripts. Adversaries may dynamically reconstruct IEX using environment variables to evade static detection. The detection rule identifies scripts that manipulate environment variables to form IEX commands, focusing on patterns of character slicing and joining, which are indicative of obfuscation techniques. By analyzing script length and specific patterns, the rule effectively flags potential misuse, aiding in defense against such evasion tactics. + + +*Possible investigation steps* + + +- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on how environment variables are manipulated to reconstruct the IEX command. +- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context on whether the activity is expected or suspicious. +- Analyze the user.id and agent.id fields to identify the user and agent responsible for executing the script, checking for any anomalies or unauthorized access. +- Investigate the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related PowerShell activities on the host. +- Assess the count field to understand the extent of obfuscation patterns detected, which can indicate the complexity and potential maliciousness of the script. + + +*False positive analysis* + + +- Scripts with legitimate use of environment variables for configuration management may trigger the rule. Users can create exceptions for specific scripts or processes known to use environment variables in a non-threatening manner. +- Automated scripts that dynamically construct commands for legitimate administrative tasks might be flagged. Review the script's purpose and source, and whitelist trusted scripts or processes. +- Development environments where scripts are frequently tested and modified may produce false positives. Implement monitoring exclusions for development machines or specific user accounts involved in script testing. +- Scripts using environment variables for localization or language settings can be mistakenly identified. Identify and exclude scripts that are part of standard localization processes. +- PowerShell scripts from trusted vendors or software packages that use environment variables for legitimate functionality should be reviewed and excluded from detection if verified as safe. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit lateral movement. +- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity. +- Review the PowerShell script block text and associated file paths to understand the scope and intent of the script, focusing on any obfuscated commands or environment variable manipulations. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation patterns in PowerShell scripts. +- 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 for unusual PowerShell activity and environment variable manipulations to enhance detection of similar threats in the future. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Look for scripts with more than 500 chars that contain a related keyword +| EVAL script_len = LENGTH(powershell.file.script_block_text) +| WHERE script_len > 500 + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """(?i)(\$(?:\w+|\w+\:\w+)\[\d++\]\+\$(?:\w+|\w+\:\w+)\[\d++\]\+['"]x['"]|\$(?:\w+\:\w+)\[\d++,\d++,\d++\]|\.name\[\d++,\d++,\d++\])""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-potential-hex-payload-execution-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-hex-payload-execution-via-command-line.asciidoc new file mode 100644 index 0000000000..3c256f5213 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-hex-payload-execution-via-command-line.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-1-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*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential 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 == "exec" and +process.parent.executable != null and +process.command_line : "*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*" and +length(process.command_line) > 50 + +---------------------------------- + +*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/ +* 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-1/prebuilt-rule-8-19-1-potential-kubectl-masquerading-via-unexpected-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-kubectl-masquerading-via-unexpected-process.asciidoc new file mode 100644 index 0000000000..637003d199 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-kubectl-masquerading-via-unexpected-process.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-1-potential-kubectl-masquerading-via-unexpected-process]] +=== Potential Kubectl Masquerading via Unexpected Process + +This rule detects potential kubectl masquerading activity by monitoring for process events where the process name is not "kubectl" but the command line arguments include kubectl-related commands. This could indicate an adversary attempting to masquerade as legitimate kubectl activity to evade detection. This rule covers evasion gaps introduced by renaming the kubectl binary, or placing it in an unusual directory. + +*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://kubernetes.io/docs/reference/kubectl/ + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 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 Potential Kubectl Masquerading via Unexpected Process* + + +Kubectl is a command-line tool for interacting with Kubernetes clusters, crucial for managing containerized applications. Adversaries may exploit this by renaming the kubectl binary or placing it in unusual directories to mimic legitimate activity and evade detection. The detection rule identifies such masquerading by monitoring for non-standard process names executing kubectl-related commands, thus highlighting potential evasion attempts. + + +*Possible investigation steps* + + +- Review the process executable path to determine if it is located in a non-standard directory such as /tmp, /var/tmp, /dev/shm, or other specified paths in the query. +- Examine the process name to check if it deviates from the expected "kubectl" name, which could indicate an attempt to masquerade the process. +- Analyze the command line arguments used in the process to identify any kubectl-related commands, such as "get", "describe", "exec", "port-forward", or authentication commands, which may suggest unauthorized access or activity. +- Investigate the user account associated with the process to determine if it has legitimate access to execute kubectl commands or if it might be compromised. +- Check for any recent changes or anomalies in the Kubernetes cluster that could correlate with the suspicious process activity, such as unauthorized deployments or configuration changes. +- Review system logs and other security alerts around the time of the event to identify any additional indicators of compromise or related suspicious activities. +- If possible, capture and analyze network traffic associated with the process to detect any unusual or unauthorized communication with the Kubernetes API server or other cluster components. + + +*False positive analysis* + + +- Processes running in development or testing environments may trigger alerts if kubectl is executed from non-standard directories. To manage this, create exceptions for known development paths where kubectl is legitimately used. +- Automated scripts or CI/CD pipelines that use kubectl from custom directories might be flagged. Identify these scripts and exclude their specific paths or process names from the rule. +- Some legitimate applications might wrap kubectl commands for functionality, leading to unexpected process names. Review these applications and add their process names to the exclusion list if they are verified as non-threatening. +- Users with custom kubectl installations in home directories could cause false positives. Verify these installations and exclude the specific user paths if they are deemed safe. +- Temporary or experimental setups where kubectl is renamed for testing purposes might be mistakenly flagged. Document these setups and apply temporary exclusions during the testing phase. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes identified by the detection rule that are masquerading as kubectl to halt potential malicious activity. +- Conduct a thorough review of the affected system's logs and command history to identify any unauthorized kubectl commands executed and assess the scope of the compromise. +- Revoke any potentially compromised credentials or access tokens associated with the Kubernetes cluster to prevent further unauthorized access. +- Restore any altered or deleted Kubernetes resources from backups, ensuring the integrity and availability of the cluster's services. +- Implement stricter access controls and monitoring on the Kubernetes cluster, such as enforcing the principle of least privilege and enabling audit logging for kubectl commands. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started") and +( + process.executable like~ ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/var/www/*", "./kubectl", "/home/*/kubectl") or + process.name like ".*" +) and +process.command_line like~ ( + + // get and describe commands + "*get po*", "*get deploy*", "*get node*", "*get svc*", "*get service*", "*get secret*", "*get clusterrole*", "*get ingress*", + "*get configmap*", "*describe po*", "*describe deploy*", "*describe node*", "*describe svc*", "*describe service*", + "*describe secret*", "*describe configmap*", "*describe clusterrole*", "*describe ingress*", + + // exec commands + "*exec -it*", "*exec --stdin*", "*exec --tty*", + + // networking commands + "*port-forward* ", "*proxy --port*", "*run --image=*", "*expose*", + + // authentication/impersonation commands + "*auth can-i*", "*--kubeconfig*", "*--as *", "*--as=*", "*--as-group*", "*--as-uid*" +) and not ( + process.executable like "/tmp/newroot/*" or + process.name == ".flatpak-wrapped" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc new file mode 100644 index 0000000000..30aaff4ce4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option]] +=== Potential Linux Tunneling and/or Port Forwarding via SSH Option + +This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform +* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Linux Tunneling and/or Port Forwarding via SSH Option* + + +SSH is a secure protocol used for encrypted communication over networks, often employed for remote administration. Adversaries exploit SSH options like port forwarding to create tunnels, facilitating covert data exfiltration or unauthorized access. The detection rule identifies suspicious SSH commands indicative of tunneling by monitoring specific SSH options, helping to flag potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process command line details to identify the specific SSH options used, such as ProxyCommand, LocalForward, RemoteForward, DynamicForward, Tunnel, GatewayPorts, ExitOnForwardFailure, or ProxyJump, to understand the nature of the potential tunneling or port forwarding. +- Examine the user account associated with the SSH process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the source and destination IP addresses involved in the SSH connection to identify any unusual or unauthorized endpoints that may indicate malicious activity. +- Investigate the timing and frequency of the SSH connections to assess whether they coincide with known business operations or if they suggest unauthorized access patterns. +- Correlate the event with other security logs or alerts from the same host or network segment to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Legitimate administrative tasks using SSH options like ProxyCommand or LocalForward can trigger the rule. To manage this, create exceptions for known administrative scripts or users frequently using these options for valid purposes. +- Automated backup or synchronization processes that use SSH tunneling for secure data transfer may be flagged. Identify these processes and exclude them by specifying the associated process names or user accounts. +- Development or testing environments where developers use SSH tunneling for accessing remote services might cause alerts. Implement exceptions for specific IP addresses or user groups associated with these environments. +- Monitoring or logging tools that utilize SSH for secure data collection can be mistaken for malicious activity. Whitelist these tools by their process names or command-line patterns to prevent false positives. +- Internal network services that rely on SSH port forwarding for legitimate communication should be reviewed and excluded based on their known behavior and usage patterns. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SSH sessions identified by the detection rule to halt potential tunneling or port forwarding activities. +- Conduct a thorough review of SSH configuration files and logs on the affected system to identify unauthorized changes or access patterns. +- Reset credentials for any accounts that were used in the suspicious SSH activity to prevent further unauthorized access. +- Implement network segmentation to limit SSH access to only necessary systems and services, reducing the risk of lateral movement. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Enhance monitoring and logging of SSH activities across the network to detect similar threats in the future, ensuring alerts are promptly reviewed and acted upon. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("ssh", "sshd") and process.args == "-o" and +process.command_line like~ ( + "*ProxyCommand*", "*LocalForward*", "*RemoteForward*", "*DynamicForward*", "*Tunnel*", "*GatewayPorts*", + "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding.asciidoc new file mode 100644 index 0000000000..71bed70176 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding]] +=== Potential Linux Tunneling and/or Port Forwarding + +This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform +* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Linux Tunneling and/or Port Forwarding* + + +Attackers can leverage many utilities to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems. + +This rule looks for several utilities that are capable of setting up tunnel network communications by analyzing process names or command line arguments. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd +- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f +- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769 +- Suspicious Utility Launched via ProxyChains - 6ace94ba-f02c-4d55-9f53-87d99b6f9af4 +- ProxyChains Activity - 4b868f1f-15ff-4ba3-8c11-d5a7a6356d37 + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( + ( + // gost & pivotnacci - spawned without process.parent.name + (process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or (process.name == "pivotnacci")) or ( + // ssh + (process.name == "ssh" and (process.args in ("-R", "-L", "-D", "-w") and process.args_count >= 4 and + not process.args : "chmod")) or + // sshuttle + (process.name == "sshuttle" and process.args in ("-r", "--remote", "-l", "--listen") and process.args_count >= 4) or + // socat + (process.name == "socat" and process.args : ("TCP4-LISTEN:*", "SOCKS*") and process.args_count >= 3) or + // chisel + (process.name : "chisel*" and process.args in ("client", "server")) or + // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok + (process.name in ("iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng", "ssf", "3proxy", "ngrok")) + ) and process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc new file mode 100644 index 0000000000..bf56278463 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion]] +=== Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion + +Identifies PowerShell scripts that use backtick-escaped characters inside ${} variable expansion as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion* + + +PowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like backtick-escaped variable expansion to evade detection. This method involves disguising malicious scripts to bypass security measures. The detection rule identifies scripts with excessive length and specific obfuscation patterns, flagging potential threats for further analysis. + + +*Possible investigation steps* + + +- Review the `powershell.file.script_block_text` field to understand the content of the script and identify any suspicious or malicious commands. +- Examine the `file.path` and `file.name` fields to determine the origin and context of the script execution, which may provide insights into whether the script is part of a legitimate process or potentially malicious activity. +- Check the `host.name` and `agent.id` fields to identify the affected system and correlate with other security events or logs from the same host for additional context. +- Analyze the `user.id` field to determine which user account executed the script, and assess whether this activity aligns with the user's typical behavior or role. +- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution flow of the script and identify any related script blocks that may have been executed in sequence. +- Consider the `count` field to evaluate the extent of obfuscation used in the script, which may indicate the level of sophistication or intent behind the script. + + +*False positive analysis* + + +- Scripts with legitimate administrative functions may use backtick-escaped variable expansion for complex string manipulations. Review the script's context and purpose to determine if it aligns with expected administrative tasks. +- Automated scripts generated by trusted software might include obfuscation patterns as part of their normal operation. Verify the source and integrity of the software to ensure it is from a reputable vendor. +- Developers and IT professionals may use obfuscation techniques during testing or development phases. Establish a process to whitelist known development environments or user accounts to reduce unnecessary alerts. +- PowerShell scripts that are part of legitimate security tools or monitoring solutions may trigger the rule. Identify and exclude these tools by their file path or script block ID to prevent false positives. +- Regularly update the list of known false positives based on historical data and feedback from users to refine the detection rule and improve its accuracy. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further spread of the potentially malicious script across the network. +- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated scripts. +- Conduct a thorough review of the script block text and associated file paths to identify and remove any malicious scripts or files from the system. +- Reset credentials for any user accounts involved in the alert to mitigate the risk of compromised credentials being used for further attacks. +- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or additional compromised systems. +- Implement enhanced monitoring on the affected host and similar systems to detect any recurrence of obfuscation techniques or related suspicious activities. +- Update endpoint protection and intrusion detection systems with indicators of compromise (IOCs) derived from the analysis to improve detection capabilities for similar threats in the future. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Look for scripts with more than 500 chars that contain a related keyword +| EVAL script_len = LENGTH(powershell.file.script_block_text) +| WHERE script_len > 500 + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """\$\{(\w++`){2,}\w++\}""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, file.name, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc new file mode 100644 index 0000000000..0503fe85e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-character-array-reconstruction]] +=== Potential PowerShell Obfuscation via Character Array Reconstruction + +Identifies PowerShell scripts that use character arrays and runtime string reconstruction as a form of obfuscation. This technique breaks strings into individual characters, often using constructs like char[] with index-based access or joining logic. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential PowerShell Obfuscation via Character Array Reconstruction* + + +PowerShell, a powerful scripting language, is often targeted by adversaries for obfuscation to bypass security measures. By reconstructing strings from character arrays, attackers evade static analysis and detection. The detection rule identifies scripts using such obfuscation by searching for patterns indicative of character array manipulation, thus flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on the obfuscated parts indicated by the presence of the "char" keyword and the 🔥 character. +- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context about the environment and potential risk. +- Check the user.id and agent.id fields to identify the user and agent responsible for executing the script, which can help assess whether the activity is expected or suspicious. +- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related script blocks, providing a broader view of the script's behavior. +- Investigate the count field to assess the extent of obfuscation, as a higher count may indicate more complex or extensive obfuscation techniques being used. + + +*False positive analysis* + + +- Scripts used for legitimate administrative tasks may use character arrays for performance optimization or to handle special characters. Review the script's purpose and context to determine if it aligns with known administrative functions. +- PowerShell scripts from trusted sources or vendors might use character arrays for legitimate obfuscation to protect intellectual property. Verify the script's origin and check for digital signatures or hashes to confirm authenticity. +- Automated scripts generated by development tools or frameworks could include character array manipulation as part of their standard output. Identify and whitelist these tools if they are commonly used in your environment. +- Security tools or monitoring solutions might use character arrays in their scripts for legitimate purposes. Cross-reference with known security software and consider excluding these from the detection rule if they are verified as safe. +- Regularly update the exclusion list to include new trusted scripts or tools as they are introduced into the environment, ensuring that legitimate activities are not flagged as false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access. +- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities. +- Conduct a thorough review of the script block text and associated logs to identify any malicious payloads or commands executed. +- Remove any identified malicious scripts or files from the affected system to prevent re-execution. +- Reset credentials for any user accounts involved in the alert to mitigate potential credential compromise. +- Update endpoint protection and ensure that AMSI and other security features are fully enabled and configured to detect similar threats. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Filter for scripts that contain the "char" keyword using MATCH, boosts the query performance +| WHERE powershell.file.script_block_text : "char" + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """(char\[\]\]\(\d+,\d+[^)]+|(\s?\(\[char\]\d+\s?\)\+){2,})""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc new file mode 100644 index 0000000000..a69359c679 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation]] +=== Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation + +Identifies PowerShell scripts that use concatenated strings within dynamic command invocation (&() or .()) as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation* + + +PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities by obfuscating commands to evade detection, often using concatenated strings in dynamic invocations. This detection rule identifies such obfuscation by analyzing script patterns, specifically looking for concatenated strings within dynamic command invocations, which are indicative of attempts to bypass security measures like AMSI. By counting these patterns, the rule effectively flags suspicious scripts, aiding in the identification of potential threats. + + +*Possible investigation steps* + + +- Review the `powershell.file.script_block_text` field to understand the content and purpose of the script, focusing on the concatenated strings and dynamic command invocations. +- Check the `host.name` and `user.id` fields to identify the machine and user account associated with the execution of the suspicious script, which can help determine if the activity is expected or anomalous. +- Analyze the `file.path` field to locate the script's source or storage location, which may provide additional context or indicate if the script is part of a known application or process. +- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related PowerShell activities, which might reveal a broader pattern of behavior. +- Assess the `agent.id` field to determine the specific endpoint agent involved, which can assist in further endpoint-specific investigations or actions. + + +*False positive analysis* + + +- Scripts with legitimate concatenated strings for dynamic command execution may trigger the rule. Review the script context to determine if the concatenation serves a valid administrative purpose. +- Automated scripts from trusted sources that use concatenation for modularity or readability might be flagged. Consider adding these scripts to an allowlist if they are verified as safe. +- Development or testing environments where PowerShell scripts are frequently modified and tested could generate false positives. Implement exceptions for known development hosts or user accounts. +- Security tools or monitoring solutions that use PowerShell for legitimate operations may inadvertently match the pattern. Identify these tools and exclude their operations from the rule. +- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network. +- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated commands. +- Conduct a thorough review of the script block text and associated script block ID to understand the intent and potential impact of the obfuscated commands. +- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and signed. +- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that all data integrity checks are performed. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems have been compromised. +- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques, leveraging insights from the MITRE ATT&CK framework. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" and powershell.file.script_block_text LIKE "*+*" + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """[.&]\(\s*(['"][A-Za-z0-9.-]+['"]\s*\+\s*)+['"][A-Za-z0-9.-]+['"]\s*\)""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc new file mode 100644 index 0000000000..c47a98516d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-high-numeric-character-proportion]] +=== Potential PowerShell Obfuscation via High Numeric Character Proportion + +Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 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 PowerShell Obfuscation via High Numeric Character Proportion* + + +PowerShell is a powerful scripting language used for system administration, but adversaries exploit its capabilities to obfuscate malicious scripts. Obfuscation often involves encoding payloads using numeric characters, making detection challenging. The detection rule identifies scripts with a high proportion of numeric characters, signaling potential obfuscation. By analyzing script length and numeric density, it flags suspicious activity, aiding in defense evasion detection. + + +*Possible investigation steps* + + +- Review the script block text from the alert to understand the context and identify any obvious signs of obfuscation or malicious intent. +- Examine the file path and host name fields to determine the origin and location of the script execution, which can help assess the potential impact and scope. +- Check the user ID and agent ID fields to identify the user and system involved, which may provide insights into whether the activity is expected or suspicious. +- Analyze the powershell.sequence and powershell.total fields to understand the sequence of script execution and the total number of scripts executed, which can indicate whether this is part of a larger pattern of behavior. +- Investigate any related logs or alerts from the same host or user to identify patterns or correlations that might suggest broader malicious activity. + + +*False positive analysis* + + +- Scripts with legitimate numeric-heavy content such as data processing or mathematical calculations may trigger the rule. To handle this, identify and whitelist specific scripts or script patterns that are known to be safe. +- Automated scripts that generate or manipulate large datasets often contain high numeric content. Consider creating exceptions for scripts executed by trusted users or from known safe directories. +- PowerShell scripts used for legitimate software installations or updates might include encoded data blocks. Review and exclude these scripts by verifying their source and purpose. +- Scripts containing large hexadecimal strings for legitimate purposes, such as cryptographic operations, may be flagged. Use the exclusion pattern to filter out these known safe operations. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate scripts that may be introduced. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further execution of potentially malicious scripts and limit lateral movement within the network. +- Review the PowerShell script block text and script block ID to identify any malicious payloads or encoded strings. If confirmed malicious, remove or quarantine the script. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to detect and remove any additional threats or remnants of the obfuscated script. +- Analyze the file path and user ID associated with the script execution to determine if unauthorized access or privilege escalation occurred. Revoke any suspicious user access and reset credentials if necessary. +- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other alerts to assess the scope and impact of the threat across the network. +- Implement enhanced monitoring and logging for PowerShell activities on all endpoints to detect similar obfuscation attempts in the future, focusing on scripts with high numeric character proportions. +- Review and update endpoint protection policies to restrict the execution of scripts with high numeric density, ensuring compliance with security best practices and reducing the risk of obfuscation-based attacks. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Look for scripts with more than 1000 chars that contain a related keyword +| EVAL script_len = LENGTH(powershell.file.script_block_text) +| WHERE script_len > 1000 + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """[0-9]""", "🔥") + +// Count the occurrence of numbers and their proportion to the total chars in the script +| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) +| EVAL proportion = special_count::double / script_len::double + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP special_count, script_len, proportion, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id + +// Filter for scripts with a 30%+ proportion of numbers +| WHERE proportion > 0.30 + +// Exclude noisy patterns +| WHERE + NOT powershell.file.script_block_text RLIKE """.*\"[a-fA-F0-9]{64}\"\,.*""" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc new file mode 100644 index 0000000000..6579e2014b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-invalid-escape-sequences]] +=== Potential PowerShell Obfuscation via Invalid Escape Sequences + +Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 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 PowerShell Obfuscation via Invalid Escape Sequences* + + +PowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques to evade detection. By inserting invalid escape sequences, attackers can obscure malicious scripts, bypassing static analysis and security tools like AMSI. The detection rule identifies such obfuscation by analyzing script patterns, specifically targeting unusual backtick usage, to flag potential threats. + + +*Possible investigation steps* + + +- Review the `powershell.file.script_block_text` field to understand the context and content of the script block that triggered the alert. Look for patterns of invalid escape sequences and assess whether they appear intentionally obfuscated. +- Examine the `file.name` and `file.path` fields to determine the origin and location of the script. This can help identify whether the script is part of a legitimate application or potentially malicious. +- Check the `host.name` and `agent.id` fields to identify the affected system and the agent responsible for logging the event. This information is crucial for understanding the scope of the potential threat. +- Analyze the `user.id` field to ascertain which user executed the script. This can provide insights into whether the user has a history of executing suspicious scripts or if their account may be compromised. +- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related script blocks, which may reveal additional obfuscation or malicious activity. +- Assess the `count` field to evaluate the extent of obfuscation detected. A higher count may indicate more aggressive obfuscation techniques, warranting further scrutiny. + + +*False positive analysis* + + +- Scripts from Visual Studio Code's PowerShell extension may trigger false positives due to its shell integration. To handle this, exclude scripts containing the pattern "$([char]0x1b)]633" from detection. +- PowerShell modules with names starting with "TSS_" may be flagged incorrectly. Exclude these by adding a condition to ignore files matching the pattern "TSS_*.psm1". +- Legitimate scripts that use backticks for formatting or other non-obfuscation purposes might be detected. Review such scripts and, if verified as safe, add them to an exception list based on their script block ID or file path. +- Regularly update the exclusion list to reflect changes in legitimate script usage patterns, ensuring that new false positives are addressed promptly. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts. Disconnect the host from the network and disable remote access. + +- Analyze the script block text and file path to identify the source and nature of the obfuscated script. Determine if the script is part of a larger attack or if other systems are affected. + +- Remove or quarantine the identified malicious script and any associated files from the host. Ensure that all remnants of the obfuscated code are eliminated to prevent re-execution. + +- Conduct a thorough scan of the host using updated antivirus and antimalware tools to detect and remove any additional threats or indicators of compromise. + +- Review and update PowerShell execution policies and security settings to restrict the execution of scripts with invalid escape sequences. Implement stricter controls to prevent similar obfuscation techniques. + +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and monitoring. Provide detailed logs and findings to assist in understanding the scope and impact of the threat. + +- Implement enhanced logging and monitoring for PowerShell activities across the network to detect and respond to similar obfuscation attempts promptly. Use the identified patterns to refine detection capabilities. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" and powershell.file.script_block_text LIKE "*`*" + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """[A-Za-z0-9_-]`(?![rntb]|\r|\n|\d)[A-Za-z0-9_-]""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.name, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count >= 10 + +// Filter FPs, and due to the behavior of the LIKE operator, allow null values +| WHERE (file.name NOT LIKE "TSS_*.psm1" or file.name IS NULL) + +| WHERE + // VSCode Shell integration + NOT powershell.file.script_block_text LIKE "*$([char]0x1b)]633*" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-reverse-keywords.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-reverse-keywords.asciidoc new file mode 100644 index 0000000000..e300b9d4a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-reverse-keywords.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-reverse-keywords]] +=== Potential PowerShell Obfuscation via Reverse Keywords + +Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential PowerShell Obfuscation via Reverse Keywords* + + +PowerShell, a powerful scripting language in Windows environments, is often targeted by adversaries for obfuscation to bypass security measures like AMSI. Attackers reverse keywords in scripts to evade static analysis. The detection rule identifies such obfuscation by searching for reversed keywords, replacing them with a unique marker, and counting occurrences. This helps in flagging scripts with multiple obfuscated elements, indicating potential malicious activity. + + +*Possible investigation steps* + + +- Review the `powershell.file.script_block_text` field to understand the context and content of the script that triggered the alert. Look for any suspicious or unexpected behavior in the script logic. +- Examine the `file.path` field to determine the location of the script on the system. This can provide insights into whether the script is part of a legitimate application or potentially malicious. +- Check the `powershell.file.script_block_id` and `powershell.sequence` fields to identify if the script is part of a larger sequence of commands. This can help in understanding the full scope of the script's execution. +- Investigate the `agent.id` field to identify the specific endpoint where the script was executed. This can help in correlating with other alerts or logs from the same machine. +- Assess the `count` field to determine the extent of obfuscation. A higher count may indicate a more heavily obfuscated script, suggesting a higher likelihood of malicious intent. + + +*False positive analysis* + + +- Scripts with legitimate administrative functions may use reversed keywords for benign purposes, such as custom logging or debugging. Review the context of the script to determine if the usage is intentional and non-malicious. +- Automated scripts generated by legitimate software tools might include reversed keywords as part of their normal operation. Identify these tools and create exceptions for their known script patterns to prevent unnecessary alerts. +- Developers or IT personnel might use reversed keywords in test environments to simulate obfuscation techniques. Ensure these environments are well-documented and excluded from production monitoring to avoid false positives. +- PowerShell scripts used in educational or training settings may intentionally include obfuscation techniques for learning purposes. Exclude these scripts by identifying their unique characteristics or file paths. +- Regularly update the list of excluded scripts or patterns as new legitimate use cases are identified, ensuring the detection rule remains effective without generating excessive false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potentially malicious scripts. +- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity. +- Conduct a thorough review of the script block text and associated files to understand the scope and intent of the obfuscation. +- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution. +- Restore affected systems from a known good backup if malicious activity has altered system integrity. +- Update endpoint protection and security tools to recognize and block similar obfuscation techniques in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and monitoring of potential lateral movement or additional threats. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Filter for scripts that contains these keywords using MATCH, boosts the query performance, match will ignore the | and look for the individual words +| WHERE powershell.file.script_block_text : "rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod" + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\.|:vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, agent.id +| WHERE count >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-special-character-overuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-special-character-overuse.asciidoc new file mode 100644 index 0000000000..c51a48d744 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-special-character-overuse.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-special-character-overuse]] +=== Potential PowerShell Obfuscation via Special Character Overuse + +Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 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 PowerShell Obfuscation via Special Character Overuse* + + +PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's flexibility to obfuscate scripts, using excessive special characters to evade detection. The detection rule identifies scripts with high special character density, indicating potential obfuscation, by analyzing script length and character patterns, thus aiding in uncovering malicious activities. + + +*Possible investigation steps* + + +- Review the dedup_space_script_block field to understand the script's structure and identify any suspicious patterns or keywords that might indicate obfuscation techniques. +- Analyze the replaced_with_fire field to assess the density and distribution of special characters, which can provide insights into the obfuscation methods used. +- Examine the file.path and host.name fields to determine the origin and context of the script execution, which can help identify if the script was run on a critical system or by a privileged user. +- Check the user.id and agent.id fields to verify the identity of the user or agent executing the script, which can help assess if the activity aligns with expected behavior or if it might be unauthorized. +- Correlate the powershell.file.script_block_id with other logs or alerts to identify if similar scripts have been executed elsewhere in the environment, indicating a broader attack pattern. + + +*False positive analysis* + + +- Scripts with legitimate use of special characters for formatting or encoding may trigger false positives. Review the script's purpose and context to determine if the use of special characters is justified. +- Automated scripts that heavily rely on string manipulation or dynamic content generation might be flagged. Consider adding exceptions for known scripts or trusted sources to reduce unnecessary alerts. +- PowerShell scripts used in development or testing environments often contain high special character density. Implement environment-based exclusions to prevent these from being flagged in non-production settings. +- Scripts utilizing SecureString or other security-related encoding methods may appear obfuscated. Verify the script's origin and purpose, and whitelist these methods if they are part of standard security practices. +- Regularly update the detection rule to refine the pattern matching and reduce false positives by incorporating feedback from security analysts and system administrators. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts. +- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity. +- Conduct a thorough review of the script block text and associated metadata to understand the intent and potential impact of the obfuscated script. +- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution. +- Restore the system from a known good backup if the script has caused significant changes or damage to the system. +- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation techniques in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Replace repeated spaces used for formatting after a new line with a single space to reduce FPs +| EVAL dedup_space_script_block = REPLACE(powershell.file.script_block_text, """\n\s+""", "\n ") + +// Look for scripts with more than 1000 chars that contain a related keyword +| EVAL script_len = LENGTH(dedup_space_script_block) +| WHERE script_len > 1000 + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(dedup_space_script_block, """[\s\$\{\}\+\@\=\(\)\^\\\"~\[\]\?\.]""", "🔥") + +// Count the occurrence of numbers and their proportion to the total chars in the script +| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) +| EVAL proportion = special_count::double / script_len::double + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP special_count, script_len, proportion, dedup_space_script_block, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id + +// Filter for scripts with a 75%+ proportion of numbers +| WHERE proportion > 0.75 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-concatenation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-concatenation.asciidoc new file mode 100644 index 0000000000..4ce31f686a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-concatenation.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-concatenation]] +=== Potential PowerShell Obfuscation via String Concatenation + +Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 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 PowerShell Obfuscation via String Concatenation* + + +PowerShell is a powerful scripting language used for task automation and configuration management. Adversaries exploit its flexibility to obfuscate malicious scripts, often using string concatenation to evade detection. The detection rule identifies scripts with excessive concatenation patterns, flagging potential obfuscation by analyzing script length and pattern frequency, thus aiding in uncovering hidden threats. + + +*Possible investigation steps* + + +- Review the powershell.file.script_block_text field to understand the content and purpose of the script, focusing on the sections identified by the string concatenation patterns. +- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy. +- Check the host.name and agent.id fields to identify the affected system and correlate with other security events or alerts from the same host for broader context. +- Investigate the user.id field to determine which user executed the script, assessing their role and whether they have a legitimate reason to run such scripts. +- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution flow and sequence of the script blocks, which may reveal additional obfuscation or malicious behavior. +- Cross-reference the _id and _index fields with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign. + + +*False positive analysis* + + +- Scripts with legitimate string concatenation for logging or configuration purposes may trigger the rule. Review the script context to determine if the concatenation is part of a benign operation. +- Automated scripts generated by development tools might use string concatenation extensively. Identify these tools and consider excluding their output directories or specific script patterns from the rule. +- PowerShell scripts used in complex data processing tasks may naturally contain high levels of string concatenation. Analyze the script's purpose and, if deemed safe, add exceptions for specific script block IDs or paths. +- Frequent administrative scripts that concatenate strings for dynamic command execution could be flagged. Verify the script's source and function, then whitelist known safe scripts by user ID or host name. +- Consider adjusting the threshold for pattern detection if legitimate scripts frequently exceed the current limit, ensuring that the rule remains effective without generating excessive false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further spread of potentially malicious scripts across the network. Disconnect it from the network and any shared resources. +- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of potentially obfuscated scripts. +- Conduct a thorough examination of the script block text and associated files to identify and remove any malicious code or artifacts. Use a secure, isolated environment for analysis. +- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be easily remediated. +- Update and run a full antivirus and antimalware scan on the affected system to ensure no additional threats are present. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for PowerShell activities across the network to detect similar obfuscation attempts in the future, ensuring that alerts are configured to notify the appropriate personnel promptly. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Look for scripts with more than 500 chars that contain a related keyword +| EVAL script_len = LENGTH(powershell.file.script_block_text) +| WHERE script_len > 500 + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """['"][A-Za-z0-9.]+['"](\s?\+\s?['"][A-Za-z0-9.,\-\s]+['"]){2,}""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-reordering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-reordering.asciidoc new file mode 100644 index 0000000000..b59f330b14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-reordering.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-reordering]] +=== Potential PowerShell Obfuscation via String Reordering + +Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential PowerShell Obfuscation via String Reordering* + + +PowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like string reordering to evade detection. This involves rearranging strings and reconstructing them at runtime, bypassing static analysis and security measures. The detection rule identifies scripts with excessive length and specific patterns, flagging those with multiple occurrences of string format expressions, which are indicative of obfuscation attempts. By filtering out known benign patterns, it reduces false positives, focusing on genuine threats. + + +*Possible investigation steps* + + +- Review the script block text by examining the powershell.file.script_block_text field to understand the nature of the obfuscation and identify any potentially malicious commands or patterns. +- Check the file.path and file.name fields to determine the origin and context of the script, which can provide insights into whether the script is part of a legitimate application or a potential threat. +- Investigate the host.name and user.id fields to identify the affected system and user, which can help in assessing the potential impact and scope of the incident. +- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and history of the script, which may reveal additional suspicious activities or related scripts. +- Correlate the alert with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign. + + +*False positive analysis* + + +- Scripts related to the Icinga Framework may trigger false positives due to their use of string formatting. To handle this, ensure that the file name "framework_cache.psm1" is excluded from the detection rule. +- PowerShell scripts that include specific sentinel patterns, such as "sentinelbreakpoints" or paths like ":::::\windows\sentinel", combined with variables like "$local:Bypassed" or "origPSExecutionPolicyPreference", are known to be benign. These should be excluded to reduce noise. +- Regularly review and update the exclusion list to include any new benign patterns that are identified over time, ensuring the rule remains effective without generating unnecessary alerts. +- Consider implementing a whitelist of known safe scripts or script authors to further minimize false positives, especially in environments with frequent legitimate use of complex PowerShell scripts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potentially malicious scripts. +- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity. +- Conduct a thorough review of the PowerShell script block text flagged by the alert to understand the intent and potential impact of the obfuscated script. +- Remove any malicious scripts or files identified during the investigation from the affected system to prevent re-execution. +- Restore the system from a known good backup if the script has caused significant changes or damage to the system. +- Update and strengthen endpoint protection measures, ensuring that AMSI and other security tools are fully operational and configured to detect similar obfuscation techniques. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Look for scripts with more than 500 chars that contain a related keyword +| EVAL script_len = LENGTH(powershell.file.script_block_text) +| WHERE script_len > 500 +| WHERE powershell.file.script_block_text LIKE "*{0}*" + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """((\{\d+\}){2,}["']\s?-f|::Format[^\{]+(\{\d+\}){2,})""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count > 3 + +// Exclude Noisy Patterns + +// Icinga Framework +| WHERE (file.name NOT LIKE "framework_cache.psm1" or file.name IS NULL) +| WHERE NOT + // https://wtfbins.wtf/17 + ( + (powershell.file.script_block_text LIKE "*sentinelbreakpoints*" OR + powershell.file.script_block_text LIKE "*:::::\\\\windows\\\\sentinel*") + AND + (powershell.file.script_block_text LIKE "*$local:Bypassed*" OR + powershell.file.script_block_text LIKE "*origPSExecutionPolicyPreference*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* 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-1/prebuilt-rule-8-19-1-potential-process-injection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-process-injection-via-powershell.asciidoc new file mode 100644 index 0000000000..e7a482f96b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-potential-process-injection-via-powershell.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-1-potential-process-injection-via-powershell]] +=== Potential Process Injection via PowerShell + +Detects the use of Windows API functions that are commonly abused by malware and security tools to load malicious code or inject it into remote processes. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-PSInject.ps1 +* https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-ReflectivePEInjection.ps1 +* https://github.com/BC-SECURITY/Empire/blob/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1 +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: PowerShell Logs + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Process Injection via PowerShell* + + +PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code. + +PowerShell also has solid capabilities to make the interaction with the Win32 API in an uncomplicated and reliable way, like the execution of inline C# code, PSReflect, Get-ProcAddress, etc. + +Red Team tooling and malware developers take advantage of these capabilities to develop stagers and loaders that inject payloads directly into the memory without touching the disk to circumvent file-based security protections. + + +*Possible investigation steps* + + +- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics. +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Examine file or network events from the involved PowerShell process for suspicious behavior. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Evaluate whether the user needs to use PowerShell to complete tasks. +- Check if the imported function was executed and which process it targeted. +- Check if the injected code can be retrieved (hardcoded in the script or on command line logs). + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Related rules* + + +- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + (VirtualAlloc or VirtualAllocEx or VirtualProtect or LdrLoadDll or LoadLibrary or LoadLibraryA or + LoadLibraryEx or GetProcAddress or OpenProcess or OpenProcessToken or AdjustTokenPrivileges) and + (WriteProcessMemory or CreateRemoteThread or NtCreateThreadEx or CreateThread or QueueUserAPC or + SuspendThread or ResumeThread or GetDelegateForFunctionPointer) + ) and not + file.directory: ( + "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\SenseCM" or + "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Dynamic-link Library Injection +** ID: T1055.001 +** Reference URL: https://attack.mitre.org/techniques/T1055/001/ +* Sub-technique: +** Name: Portable Executable Injection +** ID: T1055.002 +** Reference URL: https://attack.mitre.org/techniques/T1055/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-powershell-obfuscation-via-negative-index-string-reversal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-powershell-obfuscation-via-negative-index-string-reversal.asciidoc new file mode 100644 index 0000000000..c27ff09fa0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-powershell-obfuscation-via-negative-index-string-reversal.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-1-powershell-obfuscation-via-negative-index-string-reversal]] +=== PowerShell Obfuscation via Negative Index String Reversal + +Identifies PowerShell scripts that use negative index ranges to reverse the contents of a string or array at runtime as a form of obfuscation. This technique avoids direct use of reversal functions by iterating through array elements in reverse order. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 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 PowerShell Obfuscation via Negative Index String Reversal* + + +PowerShell, a powerful scripting language, can be exploited by adversaries using obfuscation techniques like negative index string reversal to evade detection. This method manipulates strings or arrays by iterating in reverse, bypassing static analysis tools. The detection rule identifies scripts with obfuscation patterns by analyzing script length and specific indexing patterns, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the `powershell.file.script_block_text` to understand the script's intent and identify any suspicious or malicious behavior. +- Check the `host.name` and `user.id` fields to determine the affected system and user, assessing if they are high-value targets or have a history of similar alerts. +- Analyze the `file.path` to identify the location of the script and assess if it is in a common or suspicious directory. +- Investigate the `powershell.file.script_block_id` and `powershell.sequence` to trace the execution flow and determine if this script is part of a larger, potentially malicious sequence. +- Correlate the `agent.id` with other logs to see if there are additional related activities or alerts from the same endpoint. +- Examine the `count` of detected patterns to assess the level of obfuscation and potential threat severity. + + +*False positive analysis* + + +- Scripts containing the keyword "GENESIS-5654" are known false positives and are automatically excluded from triggering alerts. Ensure that any legitimate scripts using this keyword are documented to prevent unnecessary investigations. +- Legitimate administrative scripts that use negative indexing for valid purposes may trigger false positives. Review these scripts and consider adding them to an exception list if they are frequently flagged but verified as non-malicious. +- Automated scripts generated by trusted software that use similar obfuscation patterns for performance or compatibility reasons can be excluded by identifying unique identifiers or patterns within these scripts and updating the exclusion criteria accordingly. +- Regularly update the exclusion list to include new patterns or identifiers from trusted sources as they are identified, ensuring that legitimate activities are not hindered by the detection rule. +- Collaborate with IT and security teams to maintain a list of known safe scripts and their characteristics, which can be referenced when analyzing potential false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access. +- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities. +- Conduct a thorough review of the PowerShell script block text and related logs to identify any malicious payloads or commands executed. +- Remove any identified malicious scripts or files from the affected system to prevent re-execution. +- Reset credentials for any user accounts involved in the alert to mitigate potential unauthorized access. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised. +- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques in the future. + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-windows.powershell_operational* metadata _id, _version, _index +| WHERE event.code == "4104" + +// Look for scripts with more than 500 chars that contain a related keyword +| EVAL script_len = LENGTH(powershell.file.script_block_text) +| WHERE script_len > 500 + +// Replace string format expressions with 🔥 to enable counting the occurrence of the patterns we are looking for +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, """\$\w+\[\-\s?1\.\.""", "🔥") + +// Count how many patterns were detected by calculating the number of 🔥 characters inserted +| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, "🔥", "")) + +// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id +| WHERE count >= 1 + +// FP Patterns +| WHERE NOT powershell.file.script_block_text LIKE "*GENESIS-5654*" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-service-creation-via-local-kerberos-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-service-creation-via-local-kerberos-authentication.asciidoc new file mode 100644 index 0000000000..48ccad8d54 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-service-creation-via-local-kerberos-authentication.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-1-service-creation-via-local-kerberos-authentication]] +=== Service Creation via Local Kerberos Authentication + +Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Dec0ne/KrbRelayUp +* https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html +* https://github.com/cube0x0/KrbRelay +* https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Credential Access +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Service Creation via Local Kerberos Authentication* + + +Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event. +- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system. +- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious. +- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity. +- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance. +- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule. +- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening. +- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Terminate any suspicious services created during the incident to halt potential malicious activities. +- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise. +- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets. +- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks. +- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name with maxspan=5m + [authentication where + + /* event 4624 need to be logged */ + event.action == "logged-in" and event.outcome == "success" and winlog.event_data.ElevatedToken == "%%1843" and process.pid == 0 and + + /* authenticate locally using relayed kerberos Ticket */ + winlog.event_data.AuthenticationPackageName :"Kerberos" and winlog.logon.type == "Network" and cidrmatch(source.ip, "127.0.0.0/8", "::1")] by winlog.event_data.TargetLogonId + + [any where + /* event 4697 need to be logged */ + event.action : "service-installed"] by winlog.event_data.SubjectLogonId + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-application-assignment-change-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-application-assignment-change-events.asciidoc new file mode 100644 index 0000000000..a985c30019 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-application-assignment-change-events.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-1-spike-in-group-application-assignment-change-events]] +=== Spike in Group Application Assignment Change Events + +A machine learning job has identified an unusual spike in Okta group application assignment change events, indicating potential privileged access activity. Threat actors might be assigning applications to groups to escalate access, maintain persistence, or facilitate lateral movement within an organization’s environment. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Spike in Group Application Assignment Change Events* + + +In modern environments, identity and access management systems like Okta manage user access to applications. Adversaries may exploit these systems by altering group application assignments to gain unauthorized access or escalate privileges. The detection rule leverages machine learning to identify unusual spikes in these changes, signaling potential misuse and enabling timely investigation of privilege escalation activities. + + +*Possible investigation steps* + + +- Review the specific group application assignment change events that triggered the alert to identify which groups and applications were involved. +- Analyze the timeline of the changes to determine if there is a pattern or specific time frame when the spike occurred. +- Investigate the user accounts associated with the changes to assess if they have a history of suspicious activity or if they belong to high-risk roles. +- Check for any recent changes in group membership or application access policies that could explain the spike in assignment changes. +- Correlate the events with other security alerts or logs to identify any concurrent suspicious activities, such as failed login attempts or unusual access patterns. +- Consult with the IT or security team to verify if there were any legitimate administrative activities or changes that could have caused the spike. + + +*False positive analysis* + + +- Routine administrative changes in group application assignments can trigger false positives. Regularly review and document these changes to differentiate them from suspicious activities. +- Automated processes or scripts that frequently update group assignments may cause spikes. Identify and whitelist these processes to prevent unnecessary alerts. +- Organizational restructuring or onboarding/offboarding activities can lead to increased group assignment changes. Temporarily adjust the detection thresholds or exclude these events during known periods of high activity. +- Changes related to application updates or migrations might be flagged. Coordinate with IT teams to schedule these changes and exclude them from monitoring during the update window. +- Frequent changes by trusted users or administrators can be excluded by creating exceptions for specific user accounts or roles, ensuring that only unexpected changes trigger alerts. + + +*Response and remediation* + + +- Immediately isolate affected user accounts and groups to prevent further unauthorized access or privilege escalation. +- Revert any unauthorized group application assignments to their previous state to mitigate potential misuse. +- Conduct a thorough review of recent changes in group application assignments to identify any additional unauthorized modifications. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or accounts have been compromised. +- Implement additional monitoring on the affected accounts and groups to detect any further suspicious activity. +- Review and update access controls and group assignment policies to prevent similar unauthorized changes in the future. +- Coordinate with the IT and security teams to ensure that all affected systems and applications are patched and secured against known vulnerabilities. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-management-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-management-events.asciidoc new file mode 100644 index 0000000000..5c71d658b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-management-events.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-1-spike-in-group-management-events]] +=== Spike in Group Management Events + +A machine learning job has identified a spike in group management events for a user, indicating potential privileged access activity. The machine learning has flagged an abnormal rise in group management actions (such as adding or removing users from privileged groups), which could point to an attempt to escalate privileges or unauthorized modifications to group memberships. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Spike in Group Management Events* + + +The detection of spikes in group management events leverages machine learning to monitor and identify unusual patterns in user activities related to group memberships. Adversaries may exploit this by adding or removing users from privileged groups to escalate privileges or alter access controls. The detection rule identifies these anomalies, flagging potential unauthorized modifications indicative of privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the specific user account associated with the spike in group management events to determine if the activity aligns with their typical behavior or role. +- Check the timeline of the group management events to identify any patterns or sequences that might suggest unauthorized access or privilege escalation attempts. +- Investigate the source IP addresses and devices used during the group management events to verify if they are consistent with the user's usual access points or if they indicate potential compromise. +- Examine recent changes to privileged groups, focusing on additions or removals of users, to assess if these modifications were authorized and necessary. +- Cross-reference the flagged events with any recent support tickets or change requests to confirm if the actions were legitimate and documented. +- Look for any other related alerts or anomalies in the same timeframe that might indicate a broader security incident or coordinated attack. + + +*False positive analysis* + + +- Routine administrative tasks can trigger spikes in group management events, such as scheduled user onboarding or offboarding. To manage this, create exceptions for known periods of increased activity. +- Automated scripts or tools that manage group memberships might cause false positives. Identify these scripts and exclude their activities from the rule's monitoring. +- Changes in organizational structure, like department mergers, can lead to legitimate spikes. Document these changes and adjust the rule's sensitivity temporarily. +- Regular audits or compliance checks that involve group membership reviews may appear as anomalies. Schedule these activities and inform the monitoring team to prevent false alerts. +- High turnover rates in certain departments can result in frequent group changes. Monitor these departments separately and adjust thresholds accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized group management activities. +- Review and audit recent changes to group memberships, focusing on privileged groups, to identify any unauthorized additions or removals. +- Revert any unauthorized changes to group memberships to restore the intended access controls. +- Conduct a thorough investigation to determine the source of the anomaly, including checking for compromised credentials or insider threats. +- Reset the password for the affected user account and enforce multi-factor authentication to enhance security. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and related privileged groups to detect any further suspicious activities. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] and https://docs.elastic.co/en/integrations/windows[Windows] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Windows integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-privilege-change-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-privilege-change-events.asciidoc new file mode 100644 index 0000000000..631698ca60 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-group-privilege-change-events.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-1-spike-in-group-privilege-change-events]] +=== Spike in Group Privilege Change Events + +A machine learning job has identified an unusual spike in Okta group privilege change events, indicating potential privileged access activity. Attackers might be elevating privileges by adding themselves or compromised accounts to high-privilege groups, enabling further access or persistence. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Spike in Group Privilege Change Events* + + +In environments using Okta, group privilege changes are crucial for managing access. Adversaries may exploit this by adding themselves to privileged groups, gaining unauthorized access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential privilege escalation attempts, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the specific group privilege change events identified by the machine learning job to determine which accounts were added to privileged groups. +- Cross-reference the accounts involved in the privilege changes with recent login activity to identify any unusual or suspicious access patterns. +- Check the history of privilege changes for the affected groups to see if there is a pattern of unauthorized access or if this is an isolated incident. +- Investigate the source IP addresses and locations associated with the privilege change events to identify any anomalies or unexpected geolocations. +- Examine any recent changes to the accounts involved, such as password resets or multi-factor authentication (MFA) modifications, to assess if they have been compromised. +- Collaborate with the affected users or their managers to verify if the privilege changes were authorized and legitimate. + + +*False positive analysis* + + +- Routine administrative tasks may trigger spikes in group privilege changes. Regularly scheduled audits or updates to group memberships should be documented and excluded from alerts. +- Automated scripts or tools that manage user access can cause frequent changes. Identify these scripts and create exceptions for their activity to prevent false positives. +- Organizational restructuring or mergers often lead to bulk updates in group privileges. During these periods, temporarily adjust the sensitivity of the detection rule or whitelist specific activities. +- Onboarding or offboarding processes can result in a high volume of legitimate group changes. Coordinate with HR and IT to anticipate these events and adjust monitoring accordingly. +- Changes in security policies or compliance requirements might necessitate widespread privilege adjustments. Ensure these policy-driven changes are communicated to the security team to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected accounts by removing them from any high-privilege groups to prevent further unauthorized access. +- Conduct a thorough review of recent group membership changes in Okta to identify any other unauthorized privilege escalations. +- Reset passwords and enforce multi-factor authentication for the affected accounts to secure them against further compromise. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further suspicious activity is detected. +- Implement additional monitoring on the affected accounts and privileged groups to detect any further unauthorized changes or access attempts. +- Review and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future privilege escalation. +- Document the incident, including all actions taken, to improve response strategies and inform future security measures. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-user-lifecycle-management-change-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-user-lifecycle-management-change-events.asciidoc new file mode 100644 index 0000000000..0cc9502642 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-spike-in-user-lifecycle-management-change-events.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-1-spike-in-user-lifecycle-management-change-events]] +=== Spike in User Lifecycle Management Change Events + +A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating potential privileged access activity. Threat actors may manipulate user accounts to gain higher access rights or persist within the environment. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-3h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/pad + +*Tags*: + +* Use Case: Privileged Access Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Spike in User Lifecycle Management Change Events* + + +User lifecycle management in environments like Okta involves creating, modifying, and deleting user accounts. Adversaries may exploit this by manipulating accounts to escalate privileges or maintain access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse. By focusing on anomalies, it aids in early detection of privilege escalation tactics. + + +*Possible investigation steps* + + +- Review the specific user accounts involved in the lifecycle management change events to identify any patterns or anomalies, such as multiple changes in a short period or changes made by unusual sources. +- Check the timestamps of the change events to determine if they align with normal business hours or if they occurred during unusual times, which might indicate suspicious activity. +- Investigate the source IP addresses and locations associated with the change events to identify any unusual or unauthorized access points. +- Examine the types of changes made to the user accounts, such as privilege escalations or role modifications, to assess if they align with legitimate business needs. +- Cross-reference the user accounts involved with recent security alerts or incidents to determine if they have been previously flagged for suspicious activity. +- Consult with the account owners or relevant department heads to verify if the changes were authorized and necessary for business operations. + + +*False positive analysis* + + +- Routine administrative tasks such as bulk user account updates or scheduled maintenance can trigger spikes in user lifecycle management events. To manage this, create exceptions for known maintenance windows or bulk operations. +- Automated processes or scripts that regularly modify user accounts may cause false positives. Identify these processes and exclude them from the detection rule to prevent unnecessary alerts. +- Onboarding or offboarding periods with high user account activity can lead to spikes. Adjust the detection thresholds temporarily during these periods or exclude specific user groups involved in these activities. +- Integration with third-party applications that frequently update user attributes might result in false positives. Review and whitelist these applications to reduce noise in the detection system. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts to prevent further unauthorized access or privilege escalation. This can be done by disabling the accounts or changing their passwords. +- Review and revoke any unauthorized permissions or roles that were assigned during the spike in user lifecycle management change events. Ensure that only legitimate access rights are restored. +- Conduct a thorough audit of recent user account changes to identify any additional accounts that may have been manipulated. Pay special attention to accounts with elevated privileges. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response. +- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activity or attempts to regain unauthorized access. +- Escalate the incident to higher-level security management if the scope of the breach is extensive or if sensitive data may have been compromised. +- Review and update access management policies and procedures to prevent similar incidents in the future, ensuring that changes to user accounts are logged and regularly reviewed. + +==== Setup + + + +*Setup* + + +The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. + + +*Privileged Access Detection Setup* + +The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. + + +*Prerequisite Requirements:* + +- Fleet is required for Privileged Access Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Okta events collected by https://docs.elastic.co/en/integrations/okta[Okta] integration. +- To add the Okta integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. + + +*The following steps should be executed to install assets associated with the Privileged Access Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-adrs-token-request-by-microsoft-auth-broker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-adrs-token-request-by-microsoft-auth-broker.asciidoc new file mode 100644 index 0000000000..132bfa8321 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-adrs-token-request-by-microsoft-auth-broker.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-1-suspicious-adrs-token-request-by-microsoft-auth-broker]] +=== Suspicious ADRS Token Request by Microsoft Auth Broker + +Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious ADRS Token Request by Microsoft Auth Broker* + + +Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. + + +*Possible investigation steps* + +- Identify the user principal associated with the request by checking `azure.signinlogs.properties.user_principal_name` or `azure.signinlogs.properties.user_id`. +- Review the `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.resource_id` to confirm the request is made by the Microsoft Authentication Broker and targeting the Device Registration Service. +- Examine the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` for the presence of `adrs_access`, indicating an attempt to access ADRS. +- Check the `azure.signinlogs.properties.incoming_token_type` to confirm the request is made using a refresh token, which is typical for persistent access scenarios. +- Review the `azure.signinlogs.properties.user_type` to ensure it is a "Member" user, as this behavior is unusual for standard user accounts. +- Review the `source.address` and `source.geo.country_name` to identify the origin of the request. Look for any anomalies or unexpected locations. +- Check the `azure.signinlogs.properties.device_detail.operating_system` and `azure.signinlogs.properties.device_detail.browser` to identify the device and browser used for the request. Look for any unusual or unexpected devices for this user. +- Use the `azure.signinlogs.properties.session_id` to correlate this request with other sign-in events for the same user. Look for any patterns of suspicious activity or multiple requests in a short time frame. +- Correlate with Entra ID audit logs to identify any recent device registrations or changes to the user's device registration status. +- Pivot to primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse or unauthorized access attempts. + + +*False positive analysis* + +- Legitimate applications or services that require access to the Device Registration Service may trigger this rule. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user accounts. +- Users being onboarded or enrolled in new devices may also trigger this rule, especially if they are using the Microsoft Authentication Broker for the first time. + + +*Response and remediation* + +- If the request is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Consider deactivating any newly registered devices associated with the user account until further investigation is complete. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "azure.signinlogs" and + azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and + azure.signinlogs.category: "NonInteractiveUserSignInLogs" and + azure.signinlogs.properties.authentication_processing_details: *adrs_access* and + azure.signinlogs.properties.incoming_token_type: "refreshToken" and + azure.signinlogs.properties.user_type: "Member" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-endpoint-security-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-endpoint-security-parent-process.asciidoc new file mode 100644 index 0000000000..462eb10a6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-endpoint-security-parent-process.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-1-suspicious-endpoint-security-parent-process]] +=== Suspicious Endpoint Security Parent Process + +A suspicious Endpoint Security parent process was detected. This may indicate a process hollowing or other form of code injection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Endpoint Security Parent Process* + + +Endpoint security solutions, like Elastic and Microsoft Defender, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes to evade detection. The detection rule identifies anomalies by flagging unexpected parent processes of security executables, excluding known benign paths and arguments, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details for the flagged executable (e.g., esensor.exe or elastic-endpoint.exe) to understand its expected behavior and any recent changes in its configuration or deployment. +- Examine the parent process executable path and name to determine if it is a known legitimate process or potentially malicious. Pay special attention to paths not listed in the known benign paths, such as those outside "?:\Program Files\Elastic\*" or "?:\Windows\System32\*". +- Investigate the command-line arguments used by the parent process to identify any unusual or suspicious patterns that could indicate malicious activity, especially if they do not match the benign arguments like "test", "version", or "status". +- Check the historical activity of the parent process to see if it has been involved in other suspicious activities or if it has a history of spawning security-related processes. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender for Endpoint, or Sysmon to gather additional context and identify any related suspicious activities. +- Assess the risk and impact of the alert by considering the environment, the criticality of the affected systems, and any potential data exposure or operational disruption. + + +*False positive analysis* + + +- Security tools or scripts that automate tasks may trigger false positives if they launch endpoint security processes with unexpected parent processes. To manage this, identify and document these tools, then add their parent executable paths to the exclusion list. +- System administrators or IT personnel may use command-line tools like PowerShell or cmd.exe for legitimate maintenance tasks. If these tasks frequently trigger alerts, consider adding specific command-line arguments used in these tasks to the exclusion list. +- Software updates or installations might temporarily cause unexpected parent processes for security executables. Monitor these activities and, if they are routine and verified, add the associated parent executable paths to the exclusion list. +- Custom scripts or third-party applications that interact with security processes can also lead to false positives. Review these scripts or applications, and if they are deemed safe, include their parent executable paths in the exclusion list. +- Regularly review and update the exclusion list to ensure it reflects the current environment and operational practices, minimizing the risk of overlooking new legitimate processes. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity and prevent further code execution. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized changes or additional malicious files. +- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised. +- Update endpoint security solutions and apply any available patches to address vulnerabilities that may have been exploited by the adversary. +- Monitor the network and systems for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting based on the identified threat indicators. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("esensor.exe", "elastic-endpoint.exe") and + process.parent.executable != null and + process.args != null and + /* add FPs here */ + not process.parent.executable : ( + "?:\\Program Files\\Elastic\\*", + "?:\\Windows\\System32\\services.exe", + "?:\\Windows\\System32\\WerFault*.exe", + "?:\\Windows\\System32\\wermgr.exe", + "?:\\Windows\\explorer.exe" + ) and + not ( + process.parent.executable : ( + "?:\\Windows\\System32\\cmd.exe", + "?:\\Windows\\System32\\SecurityHealthHost.exe", + "?:\\Windows\\System32\\SecurityHealth\\*\\SecurityHealthHost.exe", + "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" + ) and + process.args : ( + "test", "version", + "top", "run", + "*help", "status", + "upgrade", "/launch", + "/enable", "/av" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-entra-id-oauth-user-impersonation-scope-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-entra-id-oauth-user-impersonation-scope-detected.asciidoc new file mode 100644 index 0000000000..b6dea73c30 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-entra-id-oauth-user-impersonation-scope-detected.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-1-suspicious-entra-id-oauth-user-impersonation-scope-detected]] +=== Suspicious Entra ID OAuth User Impersonation Scope Detected + +Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Flangvik/TeamFiltration +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Tactic: Defense Evasion +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Suspicious Entra ID OAuth User Impersonation Scope Detected* + + +Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious +OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where +the sign-in session status is `unbound`, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or +unauthorized access attempts, especially when the user type is `Member` and the sign-in outcome is `success`. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. + + +*Possible investigation steps* + + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the OAuth workflow. +- Check the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` field for the presence of `user_impersonation`. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user. +- Confirm that the `azure.signinlogs.properties.authentication_requirement` is set to `singleFactorAuthentication`, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.signinlogs.properties.client_ip` to determine the source of the sign-in attempt. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Examine the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id` to identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities. +- Use the `azure.signinlogs.properties.session_id` or `azure.signinlogs.properties.correlation_id` to correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise. + + +*False positive analysis* + + +- Some legitimate applications may use the `user_impersonation` scope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may use the `user_impersonation` scope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + + +- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor. +- If the OAuth workflow is confirmed to be malicious: + - Block the user account and reset the password to prevent further unauthorized access. + - Revoke active sessions and refresh tokens associated with the user principal. + - Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant. + - Investigate the source of the sign-in attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity. + - Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified. +- Educate users about the risks associated with OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.signinlogs and + azure.signinlogs.properties.authentication_processing_details: *user_impersonation* and + azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and + azure.signinlogs.properties.token_issuer_type: "AzureAD" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and + azure.signinlogs.properties.user_type: "Member" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-kernel-feature-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-kernel-feature-activity.asciidoc new file mode 100644 index 0000000000..f49c8bd8e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-kernel-feature-activity.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-1-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* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-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 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious 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 == "exec" and +process.command_line : ( + "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*", + "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*", + "*/proc/sys/kernel/randomize_va_space*", "*/proc/sys/vm/drop_caches*", + "*/proc/sys/kernel/sysrq*", "*grsecurity*", "*exec-shield*", + "*kernel.randomize_va_space*", "*kernel.yama.ptrace_scope*", + "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*", + "*kernel.sysrq*" +) and +process.parent.executable != null and +( + (process.name == "tee" and process.args like "-*a*") or // also detects --append + (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "grep" and process.args_count == 3 and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.args : "*echo *") +) + +---------------------------------- + +*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: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* 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-1/prebuilt-rule-8-19-1-suspicious-microsoft-365-mail-access-by-unusual-clientappid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-microsoft-365-mail-access-by-unusual-clientappid.asciidoc new file mode 100644 index 0000000000..51d3fe4fb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-microsoft-365-mail-access-by-unusual-clientappid.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-1-suspicious-microsoft-365-mail-access-by-unusual-clientappid]] +=== Suspicious Microsoft 365 Mail Access by Unusual ClientAppId + +Identifies suspicious Microsoft 365 mail access by ClientAppId. This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a +* https://trustedsec.com/blog/mailitemsaccessed-woes-m365-investigation-challenges +* https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Suspicious Microsoft 365 Mail Access by Unusual ClientAppId* + + +This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. + + +*Possible investigation steps* + +- Review the `o365.audit.UserId` field to identify the user associated with the mailbox access. +- Check the `o365.audit.ClientAppId` field to determine which client application was used for the mailbox access. Look for unusual or unexpected applications or determine which first-party Microsoft applications are being abused. +- Review `o365.audit.ClientInfoString` to gather additional information about the client application used for the mailbox access. +- Examine `o365.audit.Folders.Path` to identify the specific mailbox folders accessed by the client application. This can help determine if sensitive information was accessed or if the access was legitimate. +- Ensure that `o365.audit.MailboxOwnerUPN` matches the `o365.audit.UserId` to confirm that the mailbox accessed belongs to the user identified in the `o365.audit.UserId` field. +- Review geolocation information to identify the location from which the mailbox access occurred. Look for any anomalies or unexpected locations that may indicate suspicious activity. +- Examine `o365.audit.Folders.FolderItems.Id` to identify the specific items accessed within the mailbox folders. This can help determine if sensitive information was accessed or if the access was legitimate. + + +*False positive analysis* + +- Legitimate users may access their mailboxes using new or different client applications, such as when switching to a new email client or using a mobile application. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or client applications. +- Users may access their mailboxes using custom or third-party applications that are authorized by the organization, such as CRM or ERP systems. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications. + + +*Response and remediation* + +- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Examine the sensitivity of the mailbox data accessed and determine if any sensitive information was compromised. +- Rotate the user's credentials and enforce multi-factor authentication (MFA) to prevent further unauthorized access. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "o365.audit" and + event.provider: "Exchange" and + event.category: "web" and + event.action: "MailItemsAccessed" and + event.outcome: "success" and + o365.audit.LogonType: ("0" or "1" or "6") and + o365.audit.UserType: ("0" or "2" or "3" or "10") and + o365.audit.OperationProperties.Value: "Bind" and + not o365.audit.ClientAppId : ( + "00000002-0000-0000-c000-000000000000" or "00000002-0000-0ff1-ce00-000000000000" or + "00000003-0000-0ff1-ce00-000000000000" or "00000004-0000-0ff1-ce00-000000000000" or + "00000005-0000-0ff1-ce00-000000000000" or "00000006-0000-0ff1-ce00-000000000000" or + "00000007-0000-0000-c000-000000000000" or "00000007-0000-0ff1-ce00-000000000000" or + "00000009-0000-0000-c000-000000000000" or "0000000c-0000-0000-c000-000000000000" or + "00000012-0000-0000-c000-000000000000" or "00000015-0000-0000-c000-000000000000" or + "0000001a-0000-0000-c000-000000000000" or "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "022907d3-0f1b-48f7-badc-1ba6abab6d66" or "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "08543e9e-5b1f-4af5-8228-cb5a5c9d4e24" or "08e18876-6177-487e-b8b5-cf950c1e598c" or + "0cb7b9ec-5336-483b-bc31-b15b5788de71" or "0cd196ee-71bf-4fd6-a57c-b491ffd4fb1e" or + "0f698dd4-f011-4d23-a33e-b36416dcb1e6" or "1150aefc-07de-4228-b2b2-042a536703c0" or + "11ba4a52-3159-44e1-93cd-d18e9443e3ef" or "13937bba-652e-4c46-b222-3003f4d1ff97" or + "13937bba-652e-4c46-b222-3003f4d1ff97" or "13937bba-652e-4c46-b222-3003f4d1ff97" or + "14d82eec-204b-4c2f-b7e8-296a70dab67e" or "157cdfbf-7398-4a56-96c3-e93e9ab309b5" or + "16aeb910-ce68-41d1-9ac3-9e1673ac9575" or "1786c5ed-9644-47b2-8aa0-7201292175b6" or + "17d5e35f-655b-4fb0-8ae6-86356e9a49f5" or "18fbca16-2224-45f6-85b0-f7bf2b39b3f3" or + "1950a258-227b-4e31-a9cf-717495945fc2" or "1b3c667f-cde3-4090-b60b-3d2abd0117f0" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "20a11fe0-faa8-4df5-baf2-f965f8f9972e" or "23523755-3a2b-41ca-9315-f81f3f566a95" or + "243c63a3-247d-41c5-9d83-7788c43f1c43" or "268761a2-03f3-40df-8a8b-c3db24145b6b" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "26abc9a8-24f0-4b11-8234-e86ede698878" or "27922004-5251-4030-b22d-91ecd9a37ea4" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or "27b9c0f2-3d8e-4a1c-8b6f-5d7a0c6e1f2b" or + "28b567f6-162c-4f54-99a0-6887f387bbcc" or "29d9ed98-a469-4536-ade2-f981bc1d605e" or + "2abdc806-e091-4495-9b10-b04d93c3f040" or "2cee05de-2b8f-45a2-8289-2a06ca32c4c8" or + "2d4d3d8e-2be3-4bef-9f87-7875a61c29de" or "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "2fd64745-b008-3e7d-4903-15d43e60f62a" or "3090ab82-f1c1-4cdf-af2c-5d7a6f3e2cc7" or + "35d54a08-36c9-4847-9018-93934c62740c" or "37182072-3c9c-4f6a-a4b3-b3f91cacffce" or + "38049638-cc2c-4cde-abe4-4479d721ed44" or "3c896ded-22c5-450f-91f6-3d1ef0848f6e" or + "43375d74-c6a5-4d4e-a0a3-de139860ea75" or "4345a7b9-9a63-4910-a426-35363201d503" or + "45a330b1-b1ec-4cc1-9161-9f03992aa49f" or "464e0e4d-676a-4c3b-9f81-2ed9b2a9acd2" or + "4765445b-32c6-49b0-83e6-1d93765276ca" or "497effe9-df71-4043-a8bb-14cf78c4b63b" or + "4b233688-031c-404b-9a80-a4f3f2351f90" or "4d5c2d63-cf83-4365-853c-925fd1a64357" or + "51be292c-a17e-4f17-9a7e-4b661fb16dd2" or "5572c4c0-d078-44ce-b81c-6cbf8d3ed39e" or + "5d661950-3475-41cd-a2c3-d671a3162bc1" or "5e3ce6c0-2b1f-4285-8d4b-75ee78787346" or + "60c8bde5-3167-4f92-8fdb-059f6176dc0f" or "61109738-7d2b-4a0b-9fe3-660b1ff83505" or + "62256cef-54c0-4cb4-bcac-4c67989bdc40" or "6253bca8-faf2-4587-8f2f-b056d80998a7" or + "6326e366-9d6d-4c70-b22a-34c7ea72d73d" or "65d91a3d-ab74-42e6-8a2f-0add61688c74" or + "66a88757-258c-4c72-893c-3e8bed4d6899" or "67e3df25-268a-4324-a550-0de1c7f97287" or + "69893ee3-dd10-4b1c-832d-4870354be3d8" or "74658136-14ec-4630-ad9b-26e160ff0fc6" or + "74bcdadc-2fdc-4bb3-8459-76d06952a0e9" or "75efb5bc-18a1-4e7b-8a66-2ad2503d79c6" or + "75f31797-37c9-498e-8dc9-53c16a36afca" or "797f4846-ba00-4fd7-ba43-dac1f8f63013" or + "7ab7862c-4c57-491e-8a45-d52a7e023983" or "7ae974c5-1af7-4923-af3a-fb1fd14dcb7e" or + "7b7531ad-5926-4f2d-8a1d-38495ad33e17" or "7fba38f4-ec1f-458d-906c-f4e3c4f41335" or + "80ccca67-54bd-44ab-8625-4b79c4dc7775" or "82d8ab62-be52-a567-14ea-1616c4ee06c4" or + "835b2a73-6e10-4aa5-a979-21dfda45231c" or "871c010f-5e61-4fb1-83ac-98610a7e9110" or + "89bee1f7-5e6e-4d8a-9f3d-ecd601259da7" or "8acd33ea-7197-4a96-bc33-d7cc7101262f" or + "8edd93e1-2103-40b4-bd70-6e34e586362d" or "905fcf26-4eb7-48a0-9ff0-8dcc7194b5ba" or + "9199bf20-a13f-4107-85dc-02114787ef48" or "9199bf20-a13f-4107-85dc-02114787ef48" or + "91ca2ca5-3b3e-41dd-ab65-809fa3dffffa" or "93625bc8-bfe2-437a-97e0-3d0060024faa" or + "93d53678-613d-4013-afc1-62e9e444a0a5" or "944f0bd1-117b-4b1c-af26-804ed95e767e" or + "94c63fef-13a3-47bc-8074-75af8c65887a" or "95de633a-083e-42f5-b444-a4295d8e9314" or + "97cb1f73-50df-47d1-8fb0-0271f2728514" or "98db8bd6-0cc0-4e67-9de5-f187f1cd1b41" or + "99b904fd-a1fe-455c-b86c-2f9fb1da7687" or "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7" or + "9fd38622-d9b4-4401-b1b9-1ce14c5e435a" or "a3475900-ccec-4a69-98f5-a65cd5dc5306" or + "a3883eba-fbe9-48bd-9ed3-dca3e0e84250" or "a3883eba-fbe9-48bd-9ed3-dca3e0e84250" or + "a3b79187-70b2-4139-83f9-6016c58cd27b" or "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a57aca87-cbc0-4f3c-8b9e-dc095fdc8978" or "a970bac6-63fe-4ec5-8884-8536862c42d4" or + "a9b49b65-0a12-430b-9540-c80b3332c127" or "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "ae8e128e-080f-4086-b0e3-4c19301ada69" or "b23dd4db-9142-4734-867f-3577f640ad0c" or + "b4bddae8-ab25-483e-8670-df09b9f1d0ea" or "b669c6ea-1adf-453f-b8bc-6d526592b419" or + "b6e69c34-5f1f-4c34-8cdf-7fea120b8670" or "bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4" or + "bdd48c81-3a58-4ea9-849c-ebea7f6b6360" or "c1c74fed-04c9-4704-80dc-9f79a2e515cb" or + "c35cb2ba-f88b-4d15-aa9d-37bd443522e1" or "c44b4083-3bb0-49c1-b47d-974e53cbdf3c" or + "c9a559d2-7aab-4f13-a6ed-e7e9c52aec87" or "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or "cf53fce8-def6-4aeb-8d30-b158e7b1cf83" or + "d176f6e7-38e5-40c9-8a78-3998aab820e7" or "d34dcd43-8519-44e4-827c-de79b767da47" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or "d396de1f-10d4-4023-aae2-5bb3d724ba9a" or + "d71dfe16-1070-48f3-bd3a-c3ec919d34e7" or "d73f4b35-55c9-48c7-8b10-651f6f2acb2e" or + "d9b8ec3a-1e4e-4e08-b3c2-5baf00c0fcb0" or "de8bc8b5-d9f9-48b1-a8ad-b748da725064" or + "dfe74da8-9279-44ec-8fb2-2aed9e1c73d0" or "e1ef36fd-b883-4dbf-97f0-9ece4b576fc6" or + "e64aa8bc-8eb4-40e2-898b-cf261a25954f" or "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" or + "e9f49c6b-5ce5-44c8-925d-015017e9f7ad" or "ee272b19-4411-433f-8f28-5c13cb6fd407" or + "eed83176-464d-48c7-a887-cc5cc534c7b8" or "f5eaa862-7f08-448c-9c4e-f4047d4d4521" or + "f8d98a96-0999-43f5-8af3-69971c7bb423" or "fb78d390-0c51-40cd-8e17-fdbfab77341b" or + "fc0f3af4-6835-4174-b806-f7db311fd2f3" or "fdf9885b-dd37-42bf-82e5-c3129ef5a302" or + "ffcb16e8-f789-467c-8ce9-f826a080d987" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-microsoft-365-userloggedin-via-oauth-code.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-microsoft-365-userloggedin-via-oauth-code.asciidoc new file mode 100644 index 0000000000..f8f2b722bd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-microsoft-365-userloggedin-via-oauth-code.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-1-suspicious-microsoft-365-userloggedin-via-oauth-code]] +=== Suspicious Microsoft 365 UserLoggedIn via OAuth Code + +Identifies sign-ins on behalf of a principal user to the Microsoft Graph API from multiple IPs using the Microsoft Authentication Broker or Visual Studio Code application. This behavior may indicate an adversary using a phished OAuth refresh token. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 59m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Microsoft 365 UserLoggedIn via OAuth Code* + + + +*Possible Investigation Steps:* + + +- `o365.audit.UserId`: The identity value the application is acting on behalf of principal user. +- `unique_ips`: Analyze the list of unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers, or anonymizing infrastructure (e.g., Tor or VPNs). +- `target_time_window`: Use the truncated time window to pivot into raw events to reconstruct the full sequence of resource access events, including exact timestamps and service targets. +- `azure.auditlogs` to check for device join or registration events around the same timeframe. +- `azure.identityprotection` to identify correlated risk detections, such as anonymized IP access or token replay. +- Any additional sign-ins from the `ips` involved, even outside the broker, to determine if tokens have been reused elsewhere. + + +*False Positive Analysis* + + +- Developers or IT administrators working across environments may also produce similar behavior. + + +*Response and Remediation* + + +- If confirmed unauthorized, revoke all refresh tokens for the affected user and remove any devices registered during this session. +- Notify the user and determine whether the device join or authentication activity was expected. +- Audit Conditional Access and broker permissions (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure policies enforce strict access controls. +- Consider blocking token-based reauthentication to Microsoft Graph and DRS from suspicious locations or user agents. +- Continue monitoring for follow-on activity like lateral movement or privilege escalation. + + +==== Setup + + + +*Setup* + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| WHERE event.dataset == "o365.audit" and event.action == "UserLoggedIn" and + + // ensure source, application and user are not null + source.ip is not null and + o365.audit.UserId is not null and + o365.audit.ApplicationId is not null and + + // filter for user principals that are not service accounts + o365.audit.UserType in ("0", "2", "3", "10") and + + // filter for successful logon to Microsoft Graph and from the Microsoft Authentication Broker or Visual Studio Code + o365.audit.ApplicationId in ("aebc6443-996d-45c2-90f0-388ff96faa56", "29d9ed98-a469-4536-ade2-f981bc1d605e") and + o365.audit.ObjectId in ("00000003-0000-0000-c000-000000000000") + +// keep relevant fields only +| keep @timestamp, o365.audit.UserId, source.ip, o365.audit.ApplicationId, o365.audit.ObjectId, o365.audit.ExtendedProperties.RequestType, source.as.organization.name, o365.audit.ExtendedProperties.ResultStatusDetail + +// case statements to track which are OAuth2 authorization request via redirect and which are related to OAuth2 code to token conversion +| eval + oauth_authorize = case(o365.audit.ExtendedProperties.RequestType == "OAuth2:Authorize" and o365.audit.ExtendedProperties.ResultStatusDetail == "Redirect", o365.audit.UserId, null), + oauth_token = case(o365.audit.ExtendedProperties.RequestType == "OAuth2:Token", o365.audit.UserId, null) + +// split time to 30 minutes intervals +| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp) + +// aggregate by principal, applicationId, objectId and time window +| stats + unique_ips = COUNT_DISTINCT(source.ip), + source_ips = VALUES(source.ip), + appIds = VALUES(o365.audit.ApplicationId), + asn = values(`source.as.organization.name`), + is_oauth_token = COUNT_DISTINCT(oauth_token), + is_oauth_authorize = COUNT_DISTINCT(oauth_authorize) +by o365.audit.UserId, target_time_window, o365.audit.ApplicationId, o365.audit.ObjectId + +// filter for cases where the same appId is used by the same principal user to access the same object and from multiple addresses via OAuth2 token +| where unique_ips >= 2 and is_oauth_authorize > 0 and is_oauth_token > 0 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-named-pipe-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-named-pipe-creation.asciidoc new file mode 100644 index 0000000000..f6ac6fd740 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-named-pipe-creation.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-1-suspicious-named-pipe-creation]] +=== Suspicious Named Pipe Creation + +This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Named Pipe Creation* + + +Named pipes, or FIFOs, are a form of inter-process communication in Linux environments, allowing data transfer between processes. Adversaries exploit this by creating named pipes in common directories like /tmp to stealthily execute commands or maintain persistence. The detection rule identifies unusual named pipe creation by monitoring the `mkfifo` command, especially when initiated by common shell processes, to flag potential malicious activity. + + +*Possible investigation steps* + + +- Review the process command line arguments to identify the exact named pipe path and any associated commands or scripts that might have been executed using the named pipe. +- Investigate the parent process (bash, csh, dash, fish, ksh, sh, tcsh, or zsh) to determine the origin of the mkfifo command, checking for any unusual or unexpected scripts or commands that might have initiated it. +- Examine the user account associated with the mkfifo process to determine if it is a legitimate user or if the account might have been compromised. +- Check for any other suspicious activities or processes running under the same user account or originating from the same parent process to identify potential lateral movement or further malicious actions. +- Analyze the system logs around the time of the named pipe creation for any other indicators of compromise, such as unauthorized access attempts or unusual network connections. +- If possible, capture and review the contents of the named pipe to understand the data being transferred and assess whether it is part of a malicious operation. + + +*False positive analysis* + + +- Named pipes created by legitimate applications for inter-process communication can trigger this rule. Users should identify and whitelist these applications by adding exceptions for specific process command lines that are known to be safe. +- System maintenance scripts or backup processes that use named pipes in directories like /tmp or /var/tmp may cause false positives. Review these scripts and exclude them from the rule if they are verified as non-malicious. +- Development environments or testing frameworks that frequently create and delete named pipes during their operations might be flagged. Users can mitigate this by excluding these environments from monitoring or by specifying exceptions for known development tools. +- Automated deployment tools that use named pipes for configuration management or orchestration tasks can also be a source of false positives. Ensure these tools are recognized and excluded from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes associated with the mkfifo command, especially those originating from common shell processes like bash or sh. +- Delete any named pipes created in directories such as /tmp, /dev/shm, or /var/tmp that do not follow expected naming conventions or are not part of legitimate applications. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation. +- Restore the system from a known good backup if any unauthorized changes or persistence mechanisms are detected. +- Implement additional monitoring on the affected system and network to detect any further attempts to create suspicious named pipes or execute unauthorized commands. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:mkfifo and +process.parent.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and +process.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not /*fifo*) + +---------------------------------- + +*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-1/prebuilt-rule-8-19-1-suspicious-net-reflection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-net-reflection-via-powershell.asciidoc new file mode 100644 index 0000000000..f4ed24ec29 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-net-reflection-via-powershell.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-1-suspicious-net-reflection-via-powershell]] +=== Suspicious .NET Reflection via PowerShell + +Detects the use of Reflection.Assembly to load PEs and DLLs in memory in PowerShell scripts. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: PowerShell Logs + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious .NET Reflection via PowerShell* + + +PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code. + +Attackers can use .NET reflection to load PEs and DLLs in memory. These payloads are commonly embedded in the script, which can circumvent file-based security protections. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics. +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Examine file or network events from the involved PowerShell process for suspicious behavior. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Evaluate whether the user needs to use PowerShell to complete tasks. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the script using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately outside engineering or IT business units. As long as the analyst did not identify malware or suspicious activity related to the user or host, this alert can be dismissed. + + +*Related rules* + + +- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe +- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d +- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + "[System.Reflection.Assembly]::Load" or + "[Reflection.Assembly]::Load" or + "Assembly.Load(" + ) and + not powershell.file.script_block_text : ( + ("CommonWorkflowParameters" or "RelatedLinksHelpInfo") and + "HelpDisplayStrings" + ) and + not (powershell.file.script_block_text : + ("Get-SolutionFiles" or "Get-VisualStudio" or "Select-MSBuildPath") and + file.name : "PathFunctions.ps1" + ) and + not powershell.file.script_block_text : ( + "Microsoft.PowerShell.Workflow.ServiceCore" and "ExtractPluginProperties([string]$pluginDir" + ) and + + not powershell.file.script_block_text : ("reflection.assembly]::Load('System." or "LoadWithPartialName('Microsoft." or "::Load(\"Microsoft." or "Microsoft.Build.Utilities.Core.dll") and + + not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Dynamic-link Library Injection +** ID: T1055.001 +** Reference URL: https://attack.mitre.org/techniques/T1055/001/ +* Sub-technique: +** Name: Portable Executable Injection +** ID: T1055.002 +** Reference URL: https://attack.mitre.org/techniques/T1055/002/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-path-mounted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-path-mounted.asciidoc new file mode 100644 index 0000000000..a08ddc25b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-suspicious-path-mounted.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-1-suspicious-path-mounted]] +=== Suspicious Path Mounted + +This rule detects suspicious paths mounted on Linux systems. The mount command is used to attach filesystems to the system, and attackers may use it to mount malicious filesystems or directories for data exfiltration or persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Path Mounted* + + +In Linux environments, the mount command integrates filesystems, enabling access to storage devices. Adversaries exploit this by mounting malicious filesystems in sensitive directories like /tmp or /dev/shm to exfiltrate data or maintain persistence. The detection rule identifies such activities by monitoring the execution of the mount command in unusual paths, excluding legitimate parent processes, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the mount command, focusing on the process.name and process.args fields to identify the specific path being mounted. +- Examine the process.parent.executable field to determine the parent process that initiated the mount command, ensuring it is not a known legitimate process. +- Investigate the user account associated with the process to determine if it is a privileged account or if there are any signs of compromise. +- Check for any recent changes or anomalies in the mounted directories, such as unexpected files or modifications, to assess potential data exfiltration or persistence activities. +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack. + + +*False positive analysis* + + +- System maintenance scripts may trigger the rule if they mount filesystems in monitored paths. Review and whitelist these scripts by adding their parent executable paths to the exclusion list. +- Backup processes that temporarily mount directories for data transfer can be mistaken for suspicious activity. Identify these processes and exclude their parent executables to prevent false alerts. +- Software installations or updates that require mounting filesystems in user directories might be flagged. Verify these activities and add the responsible parent executables to the exclusion criteria. +- Development tools that use temporary mounts for testing purposes can generate false positives. Recognize these tools and exclude their parent executables to reduce noise. +- Custom administrative scripts that perform legitimate mounting operations should be reviewed and, if deemed safe, their parent executables should be added to the exclusion list. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further data exfiltration or persistence by disconnecting it from the network. +- Terminate any suspicious mount processes identified in the alert to halt potential malicious activity. +- Conduct a thorough review of mounted filesystems and directories to identify and unmount any unauthorized or suspicious mounts. +- Restore any compromised files or directories from backups, ensuring they are clean and free from malicious modifications. +- Implement stricter access controls and permissions on sensitive directories like /tmp, /var/tmp, /dev/shm, /home, and /root to prevent unauthorized mounting. +- Escalate the incident to the security operations team for further investigation and to assess the scope of the threat, including potential lateral movement or additional compromised systems. +- Enhance monitoring and detection capabilities by configuring alerts for unusual mount activities and integrating threat intelligence feeds to identify similar tactics used by adversaries. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "mount" and +process.args like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*", "/root/*", "/mount") and process.parent.executable != null and +not ( + process.parent.executable like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", "/usr/libexec/*") or + process.parent.name == "snapd" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-svchost-spawning-cmd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-svchost-spawning-cmd.asciidoc new file mode 100644 index 0000000000..b1f9aae4c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-svchost-spawning-cmd.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-1-svchost-spawning-cmd]] +=== Svchost spawning Cmd + +Identifies a suspicious parent child process relationship with cmd.exe descending from svchost.exe + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-system.security* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nasbench.medium.com/demystifying-the-svchost-exe-process-and-its-command-line-options-508e9114e747 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender for Endpoint +* Data Source: Sysmon +* Data Source: SentinelOne + +*Version*: 423 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Svchost spawning Cmd* + + +The Service Host process (SvcHost) is a system process that can host one, or multiple, Windows services in the Windows NT family of operating systems. Note that `Svchost.exe` is reserved for use by the operating system and should not be used by non-Windows services. + +This rule looks for the creation of the `cmd.exe` process with `svchost.exe` as its parent process. This is an unusual behavior that can indicate the masquerading of a malicious process as `svchost.exe` or exploitation for privilege escalation. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and process.parent.name:"svchost.exe" and +process.name:("cmd.exe" or "Cmd.exe" or "CMD.EXE") and + + not process.command_line : "\"cmd.exe\" /C sc control hptpsmarthealthservice 211" + +---------------------------------- + +*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-1/prebuilt-rule-8-19-1-system-binary-symlink-to-suspicious-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-system-binary-symlink-to-suspicious-location.asciidoc new file mode 100644 index 0000000000..75590069c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-system-binary-symlink-to-suspicious-location.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-1-system-binary-symlink-to-suspicious-location]] +=== System Binary Symlink to Suspicious Location + +This rule detects the creation of a symbolic link from a system binary to a suspicious and writable location. This activity may indicate an attacker's attempt to evade detection by behavioral rules that depend on predefined process parent/child relationships. By executing the symlinked variant of a binary instead of the original, the attacker aims to bypass these rules. Through the new_terms rule type, this rule can identify uncommon parent processes that may indicate the presence of a malicious symlink. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating System Binary Symlink to Suspicious Location* + + +Symbolic links in Linux create shortcuts to files or directories, allowing flexible file management. Adversaries exploit this by linking system binaries to writable, suspicious locations, aiming to bypass security measures that monitor standard execution paths. The detection rule identifies unusual parent processes and symbolic link creation to these locations, flagging potential evasion attempts. + + +*Possible investigation steps* + + +- Review the parent process executable (process.parent.executable) to determine if it is a known and legitimate process that should be creating symbolic links. +- Examine the specific system binary involved (process.args) to verify if it is commonly used in the environment and assess if its redirection to a suspicious location is justified. +- Investigate the destination path of the symbolic link (process.args) to determine if it is a writable and potentially malicious location such as /tmp, /dev/shm, or /var/tmp. +- Check for any recent or concurrent alerts or logs related to the same parent process or destination path to identify potential patterns or repeated attempts. +- Assess the user account associated with the process (if available) to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Correlate with other security tools or logs to identify any additional suspicious activities or anomalies around the time of the alert. + + +*False positive analysis* + + +- Routine system maintenance tasks may create symbolic links in monitored directories. Exclude known maintenance scripts or processes like mkinitcpio and dracut from triggering alerts by adding them to the exception list. +- Software installations or updates often involve creating symbolic links in writable directories. Identify and whitelist trusted installation processes or package managers to prevent unnecessary alerts. +- Development environments may frequently use symbolic links for testing purposes. Consider excluding specific user directories or development tools that are known to create such links regularly. +- Backup or synchronization tools might create symbolic links as part of their operation. Verify and exclude these tools if they are part of a legitimate and routine process. +- Custom scripts or automation tools used within the organization might trigger this rule. Review and whitelist these scripts if they are verified to be safe and necessary for business operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as creating symbolic links to writable locations, especially those with uncommon parent processes. +- Remove any unauthorized symbolic links from system binaries to suspicious locations, ensuring the integrity of the original binaries. +- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts or unnecessary elevated privileges. +- Restore affected binaries and system files from a known good backup to ensure no tampered files remain. +- Monitor the system for any further attempts to create unauthorized symbolic links, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.parent.executable:* and +(process.name:ln or process.name:busybox and process.args:ln or process.name:cp and process.args:--symbolic-link) and +process.args:( + ( + /bin/* or /lib/* or /lib64/* or /sbin/* or /usr/bin/* or /usr/lib/* or /usr/lib64/* or /usr/local/bin/* or + /usr/local/lib/* or /usr/local/lib64/* or /usr/local/sbin/* or /usr/sbin/* + ) and ( + /*/.* or /dev/shm/* or /home/* or /root/* or /tmp/* or /var/tmp/* + ) and + not (/usr/bin/coreutils or /tmp/mkinitcpio* or /var/tmp/dracut* or /var/tmp/mkinitramfs*) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc new file mode 100644 index 0000000000..6f481b6c43 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-1-unusual-execution-from-kernel-thread-kthreadd-parent]] +=== Unusual Execution from Kernel Thread (kthreadd) Parent + +This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Execution from Kernel Thread (kthreadd) Parent* + + +The kernel thread (kthreadd) is a fundamental component in Linux systems responsible for managing kernel-level processes. Adversaries may exploit kthreadd to execute payloads from kernel space, thereby evading detection due to its trusted status. The detection rule identifies suspicious child processes initiated by kthreadd, focusing on unusual executable paths and command lines indicative of malicious activity, while filtering out known benign processes. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific child process name and executable path that triggered the rule. Focus on paths like /dev/shm, /tmp, /var/tmp, and /var/www, which are commonly used for storing temporary or potentially malicious files. +- Examine the command line arguments associated with the suspicious process. Look for indicators of compromise such as references to sensitive files or directories like /etc/shadow, /etc/sudoers, or ~/.ssh, as well as suspicious commands like base64 or cron. +- Check the parent process details to confirm it is indeed kthreadd. Investigate any unusual behavior or anomalies in the parent process that might suggest exploitation or manipulation. +- Investigate the network activity of the host to identify any connections to suspicious IP addresses or domains, especially if the command line includes references to /dev/tcp or other network-related paths. +- Analyze the system logs and historical data to determine if similar alerts have been triggered in the past, which might indicate a persistent threat or repeated exploitation attempts. +- Assess the risk and impact of the detected activity by correlating it with other security events or alerts on the host, considering the medium severity and risk score of 47 associated with this rule. + + +*False positive analysis* + + +- Legitimate system maintenance tasks may trigger this rule, such as automated scripts running from temporary directories. Users can create exceptions for specific scripts or processes that are verified as safe. +- Development or testing environments often use temporary directories for executing scripts. Exclude known development tools or scripts from these environments to reduce noise. +- Some monitoring or backup tools might use command lines or executables that match the rule's criteria. Identify these tools and add them to the exclusion list to prevent false alerts. +- Custom administrative scripts that perform routine checks or updates might inadvertently match the rule. Review these scripts and exclude them if they are part of regular operations. +- If certain processes are consistently flagged but are known to be benign, consider adjusting the rule to exclude these specific processes or command lines to improve detection accuracy. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. +- Terminate any suspicious processes identified as child processes of kthreadd that match the alert criteria, ensuring to log the process details for further analysis. +- Conduct a thorough review of the file paths and command lines flagged in the alert to identify any unauthorized or malicious files or scripts. Remove or quarantine these files as necessary. +- Check for unauthorized modifications in critical system files and directories such as /etc/init.d, /etc/ssh, and /root/.ssh. Restore any altered files from a known good backup. +- Escalate the incident to the security operations team for a deeper forensic investigation to determine the root cause and entry point of the threat. +- Implement additional monitoring on the affected host and similar systems to detect any recurrence of the threat, focusing on the specific indicators identified in the alert. +- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that may have been exploited by the adversary. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.parent.name:kthreadd and ( + process.executable:(/dev/shm/* or /tmp/* or /var/tmp/* or /var/www/*) or + process.name:(bash or csh or curl or dash or fish or id or ksh or nohup or setsid or sh or tcsh or wget or whoami or zsh) +) and +process.command_line:( + */dev/shm/* or */dev/tcp/* or */etc/init.d* or */etc/ld.so* or */etc/profile* or */etc/rc.local* or */etc/shadow* or */etc/ssh* or + */etc/sudoers* or */home/*/.ssh/* or */root/.ssh* or */tmp/* or */var/log/* or */var/run/* or */var/tmp/* or */var/www/* or + *base64* or *cron* or *xxd* or *~/.ssh/* +) and not ( + process.name:(true or cifs.upcall or dpkg or flock or gdbus or getopt or grep or mount or touch or umount or uname) or + process.command_line:( + "sh -c /bin/true" or */bin/ps* or */usr/bin/find* or */usr/bin/grep* or *ds_agent* or *gitlabrunner* or *nagios* or + *omsagent* or *pgrep* + ) or + process.executable:( + /lib/systemd/systemd-cgroups-agent or /proc/self/exe or /usr/local/axs-haproxy-monitoring/haproxy_stats.sh or /tmp/newroot/* or + /var/lib/docker/overlay2/* or /vz/root/* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-exim4-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-exim4-child-process.asciidoc new file mode 100644 index 0000000000..0b296606a9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-exim4-child-process.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-1-unusual-exim4-child-process]] +=== Unusual Exim4 Child Process + +This rule detects the execution of unusual commands via a descendant process of exim4. Attackers may use descendant processes of exim4 to evade detection and establish persistence or execute post-exploitation commands on a target system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.qualys.com/2021/05/04/21nails/21nails.txt +* https://blog.qualys.com/vulnerabilities-threat-research/2021/05/04/21nails-multiple-vulnerabilities-in-exim-mail-server + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Exim4 Child Process* + + +Exim4 is a widely used mail transfer agent on Linux systems, responsible for routing and delivering email. Adversaries may exploit Exim4 by spawning unexpected child processes to execute malicious commands, thereby evading detection and maintaining persistence. The detection rule identifies suspicious child processes initiated by Exim4, excluding known legitimate processes, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific unusual child process name and command line arguments that were executed under the parent process exim4. +- Examine the process tree to understand the hierarchy and context of the spawned process, including any sibling or child processes that may indicate further malicious activity. +- Check the user account associated with the exim4 process to determine if it aligns with expected usage patterns or if it might be compromised. +- Investigate the source and destination of any network connections initiated by the unusual child process to identify potential data exfiltration or command and control activity. +- Analyze system logs around the time of the alert to identify any related events or anomalies that could provide additional context or evidence of compromise. +- Correlate the findings with other alerts or incidents in the environment to determine if this activity is part of a broader attack campaign. + + +*False positive analysis* + + +- Development tools like cmake, gcc, and cppcheck may trigger false positives if they are used in environments where Exim4 is installed. To mitigate this, ensure these tools are included in the exclusion list if they are part of regular development activities. +- System maintenance scripts that utilize commands such as readlink, grep, and stat might be flagged. Review these scripts and add them to the exclusion list if they are verified as part of routine system operations. +- Automated deployment or configuration management tools that invoke systemctl or update-exim4.conf can be mistaken for suspicious activity. Confirm these processes are legitimate and add them to the exclusion list to prevent unnecessary alerts. +- If Exim4 is used in conjunction with SSH services, processes like sshd may appear as child processes. Verify the legitimacy of these connections and exclude them if they are part of expected behavior. +- Regularly review and update the exclusion list to reflect changes in system operations or new legitimate processes that may arise, ensuring the rule remains effective without generating excessive false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious child processes of Exim4 that are not recognized as legitimate, using process management tools like `kill` or `pkill`. +- Conduct a thorough review of the Exim4 configuration files and scripts to identify unauthorized modifications or additions, and restore them from a known good backup if necessary. +- Scan the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any malicious artifacts found. +- Apply security patches and updates to Exim4 and the operating system to mitigate known vulnerabilities that could be exploited by attackers. +- Monitor the system for any recurrence of unusual Exim4 child processes and adjust logging and alerting to capture detailed information for further analysis. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems in the network may be affected. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.type:start and event.action:exec and process.parent.name:exim4 and +not process.name:( + exim4 or start-stop-daemon or run-parts or systemctl or update-exim4.conf or install or plymouth or + readlink or grep or stat or cmake or gcc or cppcheck or sort or sshd +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-file-creation-alternate-data-stream.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-file-creation-alternate-data-stream.asciidoc new file mode 100644 index 0000000000..9950408381 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-file-creation-alternate-data-stream.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-1-unusual-file-creation-alternate-data-stream]] +=== Unusual File Creation - Alternate Data Stream + +Identifies suspicious creation of Alternate Data Streams on highly targeted files. This is uncommon for legitimate files and sometimes done by adversaries to hide malware. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Data Source: Elastic Endgame + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual File Creation - Alternate Data Stream* + + +Alternate Data Streams (ADS) are file attributes only found on the NTFS file system. In this file system, files are built up from a couple of attributes; one of them is $Data, also known as the data attribute. + +The regular data stream, also referred to as the unnamed data stream since the name string of this attribute is empty, contains the data inside the file. So any data stream that has a name is considered an alternate data stream. + +Attackers can abuse these alternate data streams to hide malicious files, string payloads, etc. This rule detects the creation of alternate data streams on highly targeted file types. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Retrieve the contents of the alternate data stream, and analyze it for potential maliciousness. Analysts can use the following PowerShell cmdlet to accomplish this: + - `Get-Content C:\Path\To\file.exe -stream SampleAlternateDataStreamName` +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of process executable and file conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and + + file.path : "C:\\*:*" and file.extension in~ ( + "pdf", "dll", "exe", "dat", "com", "bat", "cmd", "sys", "vbs", "ps1", "hta", "txt", "vbe", "js", + "wsh", "docx", "doc", "xlsx", "xls", "pptx", "ppt", "rtf", "gif", "jpg", "png", "bmp", "img", "iso" + ) and + + not file.path : + ("C:\\*:zone.identifier*", + "C:\\users\\*\\appdata\\roaming\\microsoft\\teams\\old_weblogs_*:$DATA", + "C:\\Windows\\CSC\\*:CscBitmapStream") and + + not process.executable : ( + "?:\\Program Files (x86)\\Dropbox\\Client\\Dropbox.exe", + "?:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Program Files (x86)\\Microsoft Office\\root\\*\\EXCEL.EXE", + "?:\\Program Files (x86)\\Microsoft Office\\root\\*\\OUTLOOK.EXE", + "?:\\Program Files (x86)\\Microsoft Office\\root\\*\\POWERPNT.EXE", + "?:\\Program Files (x86)\\Microsoft Office\\root\\*\\WINWORD.EXE", + "?:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe", + "?:\\Program Files\\ExpressConnect\\ExpressConnectNetworkService.exe", + "?:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Program Files\\Microsoft Office\\root\\*\\EXCEL.EXE", + "?:\\Program Files\\Microsoft Office\\root\\*\\OUTLOOK.EXE", + "?:\\Program Files\\Microsoft Office\\root\\*\\POWERPNT.EXE", + "?:\\Program Files\\Microsoft Office\\root\\*\\WINWORD.EXE", + "?:\\Program Files\\Mozilla Firefox\\firefox.exe", + "?:\\Program Files\\Windows Defender Advanced Threat Protection\\MsSense.exe", + "?:\\Program Files\\Rivet Networks\\SmartByte\\SmartByteNetworkService.exe", + "?:\\Windows\\explorer.exe", + "?:\\Windows\\System32\\DataExchangeHost.exe", + "?:\\Windows\\System32\\drivers\\Intel\\ICPS\\IntelConnectivityNetworkService.exe", + "?:\\Windows\\System32\\drivers\\RivetNetworks\\Killer\\KillerNetworkService.exe", + "?:\\Windows\\System32\\inetsrv\\w3wp.exe", + "?:\\Windows\\System32\\PickerHost.exe", + "?:\\Windows\\System32\\RuntimeBroker.exe", + "?:\\Windows\\System32\\SearchProtocolHost.exe", + "?:\\Windows\\System32\\sihost.exe", + "?:\\windows\\System32\\svchost.exe", + "?:\\Windows\\System32\\WFS.exe" + ) and + + not ( + ?process.code_signature.trusted == true and + file.name : "*:sec.endpointdlp:$DATA" + ) + + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: NTFS File Attributes +** ID: T1564.004 +** Reference URL: https://attack.mitre.org/techniques/T1564/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc new file mode 100644 index 0000000000..f8b93b01f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-1-unusual-ld-preload-ld-library-path-command-line-arguments]] +=== Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments + +This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments* + + +LD_PRELOAD and LD_LIBRARY_PATH are environment variables in Linux that influence dynamic linking by specifying libraries to load before others. Adversaries exploit these to hijack execution flow, evade defenses, or escalate privileges. The detection rule identifies suspicious use of these variables in shell commands, excluding benign processes, signaling potential misuse for persistence or defense evasion. + + +*Possible investigation steps* + + +- Review the process command line to identify the specific libraries being loaded via LD_PRELOAD or LD_LIBRARY_PATH and assess their legitimacy. +- Examine the parent process name to determine if the process is expected to use these environment variables, considering the exclusion list provided in the query. +- Investigate the user account associated with the process to check for any signs of compromise or unusual activity. +- Analyze the process execution context, including the timestamp and host details, to identify any patterns or correlations with other suspicious activities. +- Check system logs and other security tools for related alerts or events that might indicate broader malicious activity or attempts to evade defenses. + + +*False positive analysis* + + +- Development and testing environments often use LD_PRELOAD and LD_LIBRARY_PATH for legitimate purposes such as testing new libraries or debugging. Consider excluding processes associated with these environments if they are known and trusted. +- Some software installations or updates may temporarily use these environment variables to ensure compatibility or to load specific libraries. Monitor installation logs and exclude these processes if they are verified as part of legitimate software management. +- System administration scripts or automation tools might use these variables to manage library paths dynamically. Review and whitelist these scripts if they are part of routine maintenance and have been vetted for security. +- Certain applications, like custom-built software or legacy systems, may rely on these variables for normal operation. Document these applications and exclude them from the rule if they are essential and secure. +- Security tools or monitoring agents might use these variables to hook into processes for legitimate monitoring purposes. Verify the behavior of these tools and exclude them if they are part of your security infrastructure. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified with unusual LD_PRELOAD or LD_LIBRARY_PATH usage to halt potential exploitation. +- Conduct a thorough review of the affected system's environment variables and remove any unauthorized or suspicious entries. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement stricter access controls and monitoring on the affected system to prevent unauthorized changes to environment variables. +- Update and enhance detection rules to include additional indicators of compromise related to LD_PRELOAD and LD_LIBRARY_PATH misuse, ensuring future attempts are identified promptly. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:exec and +process.parent.name:(* and not ( + awk or bwrap or cylancesvc or dbus-run-session or java or julia or make or matlab_helper or ninja or noproc_sandbox or + nxrunner or nxserver or perl or rear or sapcontrol or setsid or spoold or sshd or steam or su or sudo or titanagent or + vls_agent or zabbix_agentd +)) and +process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and +process.args:-c and process.command_line:(*LD_LIBRARY_PATH=* or *LD_PRELOAD=*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-ropc-login-attempt-by-user-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-ropc-login-attempt-by-user-principal.asciidoc new file mode 100644 index 0000000000..3171a92f95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-ropc-login-attempt-by-user-principal.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-1-unusual-ropc-login-attempt-by-user-principal]] +=== Unusual ROPC Login Attempt by User Principal + +Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://dirkjanm.io/assets/raw/Finding%20Entra%20ID%20CA%20Bypasses%20-%20the%20structured%20way.pdf +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual ROPC Login Attempt by User Principal* + + +This rule detects unusual login attempts using the Resource Owner Password Credentials (ROPC) flow in Microsoft Entra ID. ROPC allows applications to obtain tokens by directly providing user credentials, bypassing multi-factor authentication (MFA). This method is less secure and can be exploited by adversaries to gain access to user accounts, especially during enumeration or password spraying. + + +*Possible investigation steps* + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the ROPC login attempt. Check if this user is expected to use ROPC or if it is an unusual account for this type of authentication. +- Analyze the `azure.signinlogs.properties.authentication_protocol` field to confirm that the authentication protocol is indeed ROPC. This protocol is typically used in legacy applications or scripts that do not support modern authentication methods. +- Check the `user_agent.original` field to identify potentially abused open-source tools or scripts that may be using ROPC for unauthorized access such as TeamFiltration or other enumeration tools. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to determine which application is attempting the ROPC login. FOCI applications are commonly used for enumeration and password spraying. +- Investigate the `azure.signinlogs.properties.client_ip` to identify the source of the login attempt. Check if the IP address is associated with known malicious activity or if it is a legitimate user location. +- Review the `azure.signinlogs.properties.authentication_details` field for any additional context on the authentication attempt, such as whether it was successful or if there were any errors. +- Examine the `azure.signinlogs.properties.applied_conditional_access_policies` to see if any conditional access policies were applied during the login attempt. If no policies were applied, this could indicate a potential bypass of security controls. +- Identify the resource requested access to by checking the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id`. This can help determine if the login attempt was targeting sensitive resources or applications such as Exchange Online, SharePoint, or Teams. + + +*False positive analysis* + +- Legitimate applications or scripts that use ROPC for automation purposes may trigger this rule. +- Some legacy applications may still rely on ROPC for authentication, especially in environments where modern authentication methods are not fully implemented. +- Internal security tools or scripts that perform automated tasks using ROPC may generate false positives if they are not properly whitelisted or excluded from the rule. + + +*Response and remediation* + +- If the ROPC login attempt is confirmed to be malicious, immediately block the user account and reset the password to prevent further unauthorized access. +- Consider enforcing multi-factor authentication (MFA) for the user account to enhance security and prevent future unauthorized access attempts. +- Review and update conditional access policies to restrict the use of ROPC for sensitive accounts or applications, ensuring that MFA is required for all login attempts. +- Investigate the source of the ROPC login attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity. +- Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified. +- Educate users about the risks associated with ROPC and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "azure.signinlogs" and + azure.signinlogs.properties.authentication_protocol: "ropc" and + azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and + azure.signinlogs.properties.user_type: "Member" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-scheduled-task-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-scheduled-task-update.asciidoc new file mode 100644 index 0000000000..dc12ec9f8d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-unusual-scheduled-task-update.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-1-unusual-scheduled-task-update]] +=== Unusual Scheduled Task Update + +Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*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 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. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: "iam" 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-1/prebuilt-rule-8-19-1-windows-registry-file-creation-in-smb-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-windows-registry-file-creation-in-smb-share.asciidoc new file mode 100644 index 0000000000..6de4fe6849 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-windows-registry-file-creation-in-smb-share.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-1-windows-registry-file-creation-in-smb-share]] +=== Windows Registry File Creation in SMB Share + +Identifies the creation or modification of a medium-size registry hive file on a Server Message Block (SMB) share, which may indicate an exfiltration attempt of a previously dumped Security Account Manager (SAM) registry hive for credential extraction on an attacker-controlled system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Registry File Creation in SMB Share* + + +Dumping registry hives is a common way to access credential information. Some hives store credential material, as is the case for the SAM hive, which stores locally cached credentials (SAM secrets), and the SECURITY hive, which stores domain cached credentials (LSA secrets). Dumping these hives in combination with the SYSTEM hive enables the attacker to decrypt these secrets. + +Attackers can try to evade detection on the host by transferring this data to a system that is not monitored to be parsed and decrypted. This rule identifies the creation or modification of a medium-size registry hive file on an SMB share, which may indicate this kind of exfiltration attempt. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user/source host during the past 48 hours. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Inspect the source host for suspicious or abnormal behaviors in the alert timeframe. +- Capture the registry file(s) to determine the extent of the credential compromise in an eventual incident response. + + +*False positive analysis* + + +- Administrators can export registry hives for backup purposes. Check whether the user should be performing this kind of activity and is aware of it. + + +*Related rules* + + +- Credential Acquisition via Registry Hive Dumping - a7e7bfa3-088e-4f13-b29e-3986e0e756b8 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Reimage the host operating system and restore compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and + /* regf file header */ + file.Ext.header_bytes : "72656766*" and file.size >= 30000 and + process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-1-*") and + not file.path : ( + "?:\\*\\UPM_Profile\\NTUSER.DAT", + "?:\\*\\UPM_Profile\\NTUSER.DAT.LASTGOODLOAD", + "?:\\*\\UPM_Profile\\AppData\\Local\\Microsoft\\Windows\\UsrClass.dat*", + "?:\\Windows\\Netwrix\\Temp\\????????.???.offreg", + "?:\\*\\AppData\\Local\\Packages\\Microsoft.*\\Settings\\settings.dat*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-windows-sandbox-with-sensitive-configuration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-windows-sandbox-with-sensitive-configuration.asciidoc new file mode 100644 index 0000000000..6a69f803d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-windows-sandbox-with-sensitive-configuration.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-1-windows-sandbox-with-sensitive-configuration]] +=== Windows Sandbox with Sensitive Configuration + +Identifies Windows sanfbox processes indicating the start of a new container with sensitive configurations like write access to the host file system, network connection and automatic execution via logon command. Malware may abuse the sandbox feature to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog-en.itochuci.co.jp/entry/2025/03/12/140000 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Windows Sandbox with Sensitive Configuration* + + +Windows Sandbox is a lightweight virtual environment designed to safely run untrusted applications. It isolates processes from the host system, preventing permanent changes. However, adversaries can exploit this by configuring the sandbox to access host resources, enabling network connections, or executing commands at startup. The detection rule identifies such misuse by monitoring specific process activities and configurations indicative of potential abuse, such as unauthorized file system access or network enablement, helping analysts spot and mitigate threats effectively. + + +*Possible investigation steps* + + +- Review the process details for "wsb.exe" or "WindowsSandboxClient.exe" to confirm the start of a new container and check for any unusual command-line arguments that match the query criteria, such as "Enable" or "true>". +- Investigate any file system access attempts by the sandbox, particularly focusing on write access to the host file system indicated by "C:\false". Determine if any unauthorized or suspicious files have been modified or created. +- Examine network activity associated with the sandbox process to identify any unexpected or unauthorized connections, especially if "true>" is present in the command line. +- Check for any logon commands executed by the sandbox process using "" in the command line to identify potential persistence mechanisms or automated tasks that could indicate malicious intent. +- Correlate the sandbox activity with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context and identify any related suspicious activities. + + +*False positive analysis* + + +- Legitimate software installations or updates may configure the Windows Sandbox to enable network connections or access host resources. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- Developers and IT administrators might use Windows Sandbox for testing purposes, which could involve enabling network connections or accessing host files. Establishing a list of approved users or processes that frequently perform these actions can help reduce false positives. +- Automated scripts or tools that configure the sandbox for legitimate purposes, such as testing or development, may trigger the rule. Identifying and excluding these scripts from monitoring can minimize false alerts. +- Security tools or system management software might use sandbox features for legitimate operations. Users should verify and whitelist these tools to avoid misidentification as threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those related to Windows Sandbox misuse, such as "wsb.exe" or "WindowsSandboxClient.exe". +- Conduct a thorough review of the system's file system and network logs to identify any unauthorized access or data transfers that may have occurred. +- Remove any unauthorized configurations or scripts found within the Windows Sandbox environment that enable network connections or host file system access. +- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process creation and command-line parameters related to Windows Sandbox configurations. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("wsb.exe", "WindowsSandboxClient.exe") and + process.command_line : ("*Enable*", + "*C:\\*false*", + "**", + "*true*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Run Virtual Instance +** ID: T1564.006 +** Reference URL: https://attack.mitre.org/techniques/T1564/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-windows-service-installed-via-an-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-windows-service-installed-via-an-unusual-client.asciidoc new file mode 100644 index 0000000000..5571bde97b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rule-8-19-1-windows-service-installed-via-an-unusual-client.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-1-windows-service-installed-via-an-unusual-client]] +=== Windows Service Installed via an Unusual Client + +Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.x86matthew.com/view_post?id=create_svc_rpc +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697 +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0100_windows_audit_security_system_extension.md +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Windows Service Installed via an Unusual Client* + + +Windows services are crucial for running background processes with elevated privileges. Adversaries exploit this by creating services to escalate privileges from administrator to SYSTEM. The detection rule identifies anomalies by flagging service installations initiated by atypical processes, excluding known legitimate services. This helps in spotting potential privilege escalation attempts by monitoring unusual client activity. + + +*Possible investigation steps* + + +- Review the event logs to identify the specific client process that initiated the service installation by examining the winlog.event_data.ClientProcessId and winlog.event_data.ParentProcessId fields. +- Investigate the parent process associated with the unusual client process to determine if it is a known legitimate application or potentially malicious. +- Check the winlog.event_data.ServiceFileName to verify the path and name of the service file, ensuring it is not a known legitimate service excluded in the query. +- Analyze the timeline of events around the service installation to identify any preceding suspicious activities or related alerts that might indicate a broader attack. +- Conduct a reputation check on the client process and service file using threat intelligence sources to assess if they are associated with known malicious activities. +- Examine the system for any additional indicators of compromise, such as unexpected network connections or changes to critical system files, that may suggest privilege escalation or lateral movement attempts. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they create services using unusual client processes. To manage this, identify and whitelist these processes in the detection rule to prevent unnecessary alerts. +- System management tools like Veeam and PDQ Inventory are already excluded, but other similar tools might not be. Regularly review and update the exclusion list to include any additional legitimate tools used in your environment. +- Custom scripts or administrative tools that create services for maintenance or monitoring purposes can also cause false positives. Document these scripts and consider adding them to the exclusion list if they are verified as safe. +- Temporary or one-time service installations for troubleshooting or testing can be mistaken for threats. Ensure that such activities are logged and communicated to the security team to avoid confusion and unnecessary alerts. +- Changes in system configurations or updates to existing software might alter the behavior of legitimate processes, causing them to be flagged. Regularly review and adjust the detection rule to accommodate these changes while maintaining security integrity. + + +*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 service and any associated processes identified by the alert to stop potential privilege escalation or malicious activity. +- Conduct a thorough review of the service's configuration and associated files to identify any unauthorized changes or malicious code. +- Restore any altered or compromised system files from a known good backup to ensure system integrity. +- Change all administrator and SYSTEM account passwords on the affected system and any connected systems to prevent further unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring and logging on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities. + +==== Setup + + + +*Setup* + + +The 'Audit Security System Extension' logging policy must be configured for (Success) +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +System > +Audit Security System Extension (Success) +``` + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where host.os.type == "windows" and + event.action == "service-installed" and + (winlog.event_data.ClientProcessId == "0" or winlog.event_data.ParentProcessId == "0") and + startswith~(user.domain, winlog.computer_name) and winlog.event_data.ServiceAccount == "LocalSystem" and + not winlog.event_data.ServiceFileName : ( + "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe", + "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe", + "%SystemRoot%\\system32\\Drivers\\Crowdstrike\\*-CsInstallerService.exe", + "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" " + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rules-8-19-1-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rules-8-19-1-appendix.asciidoc new file mode 100644 index 0000000000..01fdee12cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rules-8-19-1-appendix.asciidoc @@ -0,0 +1,94 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-1-prebuilt-rules-8-19-1-appendix"] += Downloadable rule update v8.19.1 + +This section lists all updates associated with version 8.19.1 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-1-suspicious-entra-id-oauth-user-impersonation-scope-detected.asciidoc[] +include::prebuilt-rule-8-19-1-unusual-ropc-login-attempt-by-user-principal.asciidoc[] +include::prebuilt-rule-8-19-1-entra-id-rt-to-prt-transition-from-same-user-and-device.asciidoc[] +include::prebuilt-rule-8-19-1-suspicious-adrs-token-request-by-microsoft-auth-broker.asciidoc[] +include::prebuilt-rule-8-19-1-microsoft-entra-id-suspicious-cloud-device-registration.asciidoc[] +include::prebuilt-rule-8-19-1-entra-id-user-signed-in-from-unusual-device.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-events-deleted.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-forbidden-creation-request.asciidoc[] +include::prebuilt-rule-8-19-1-forbidden-request-from-unusual-user-agent-in-kubernetes.asciidoc[] +include::prebuilt-rule-8-19-1-excessive-microsoft-365-mailbox-items-accessed.asciidoc[] +include::prebuilt-rule-8-19-1-kubectl-network-configuration-modification.asciidoc[] +include::prebuilt-rule-8-19-1-potential-kubectl-masquerading-via-unexpected-process.asciidoc[] +include::prebuilt-rule-8-19-1-kubectl-apply-pod-from-url.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-direct-api-request-via-curl-or-wget.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-sensitive-configuration-file-activity.asciidoc[] +include::prebuilt-rule-8-19-1-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc[] +include::prebuilt-rule-8-19-1-aws-ssm-command-document-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-1-aws-ssm-sendcommand-execution-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-1-aws-sts-role-assumption-by-service.asciidoc[] +include::prebuilt-rule-8-19-1-aws-sts-role-assumption-by-user.asciidoc[] +include::prebuilt-rule-8-19-1-microsoft-entra-id-sign-in-brute-force-activity.asciidoc[] +include::prebuilt-rule-8-19-1-microsoft-365-brute-force-via-entra-id-sign-ins.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-denied-service-account-request.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-suspicious-self-subject-review.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-user-exec-into-pod.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-anonymous-request-authorized.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-exposed-service-created-with-type-nodeport.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostipc.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostnetwork.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-pod-created-with-hostpid.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-privileged-pod-created.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc[] +include::prebuilt-rule-8-19-1-suspicious-microsoft-365-mail-access-by-unusual-clientappid.asciidoc[] +include::prebuilt-rule-8-19-1-suspicious-microsoft-365-userloggedin-via-oauth-code.asciidoc[] +include::prebuilt-rule-8-19-1-okta-user-sessions-started-from-different-geolocations.asciidoc[] +include::prebuilt-rule-8-19-1-spike-in-group-application-assignment-change-events.asciidoc[] +include::prebuilt-rule-8-19-1-spike-in-group-privilege-change-events.asciidoc[] +include::prebuilt-rule-8-19-1-spike-in-user-lifecycle-management-change-events.asciidoc[] +include::prebuilt-rule-8-19-1-spike-in-group-management-events.asciidoc[] +include::prebuilt-rule-8-19-1-git-repository-or-file-download-to-suspicious-directory.asciidoc[] +include::prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding.asciidoc[] +include::prebuilt-rule-8-19-1-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc[] +include::prebuilt-rule-8-19-1-linux-telegram-api-request.asciidoc[] +include::prebuilt-rule-8-19-1-kubernetes-service-account-secret-access.asciidoc[] +include::prebuilt-rule-8-19-1-manual-memory-dumping-via-proc-filesystem.asciidoc[] +include::prebuilt-rule-8-19-1-potential-hex-payload-execution-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-1-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc[] +include::prebuilt-rule-8-19-1-suspicious-path-mounted.asciidoc[] +include::prebuilt-rule-8-19-1-system-binary-symlink-to-suspicious-location.asciidoc[] +include::prebuilt-rule-8-19-1-suspicious-kernel-feature-activity.asciidoc[] +include::prebuilt-rule-8-19-1-kubeconfig-file-discovery.asciidoc[] +include::prebuilt-rule-8-19-1-kubectl-permission-discovery.asciidoc[] +include::prebuilt-rule-8-19-1-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc[] +include::prebuilt-rule-8-19-1-suspicious-named-pipe-creation.asciidoc[] +include::prebuilt-rule-8-19-1-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc[] +include::prebuilt-rule-8-19-1-potential-data-exfiltration-through-curl.asciidoc[] +include::prebuilt-rule-8-19-1-kubeconfig-file-creation-or-modification.asciidoc[] +include::prebuilt-rule-8-19-1-potential-backdoor-execution-through-pam-exec.asciidoc[] +include::prebuilt-rule-8-19-1-unusual-exim4-child-process.asciidoc[] +include::prebuilt-rule-8-19-1-docker-release-file-creation.asciidoc[] +include::prebuilt-rule-8-19-1-first-time-seen-commonly-abused-remote-access-tool-execution.asciidoc[] +include::prebuilt-rule-8-19-1-windows-registry-file-creation-in-smb-share.asciidoc[] +include::prebuilt-rule-8-19-1-adding-hidden-file-attribute-via-attrib.asciidoc[] +include::prebuilt-rule-8-19-1-suspicious-endpoint-security-parent-process.asciidoc[] +include::prebuilt-rule-8-19-1-local-account-tokenfilter-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-1-suspicious-net-reflection-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc[] +include::prebuilt-rule-8-19-1-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc[] +include::prebuilt-rule-8-19-1-dynamic-iex-reconstruction-via-method-string-access.asciidoc[] +include::prebuilt-rule-8-19-1-powershell-obfuscation-via-negative-index-string-reversal.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-reverse-keywords.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-concatenation.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-string-reordering.asciidoc[] +include::prebuilt-rule-8-19-1-potential-powershell-obfuscation-via-special-character-overuse.asciidoc[] +include::prebuilt-rule-8-19-1-potential-process-injection-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-1-windows-sandbox-with-sensitive-configuration.asciidoc[] +include::prebuilt-rule-8-19-1-unusual-file-creation-alternate-data-stream.asciidoc[] +include::prebuilt-rule-8-19-1-svchost-spawning-cmd.asciidoc[] +include::prebuilt-rule-8-19-1-unusual-scheduled-task-update.asciidoc[] +include::prebuilt-rule-8-19-1-service-creation-via-local-kerberos-authentication.asciidoc[] +include::prebuilt-rule-8-19-1-first-time-seen-newcredentials-logon-process.asciidoc[] +include::prebuilt-rule-8-19-1-windows-service-installed-via-an-unusual-client.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rules-8-19-1-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rules-8-19-1-summary.asciidoc new file mode 100644 index 0000000000..629709eb65 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-1/prebuilt-rules-8-19-1-summary.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-1-prebuilt-rules-8-19-1-summary]] +[role="xpack"] +== Update v8.19.1 + +This section lists all updates associated with version 8.19.1 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. | new | 1 + +|<> | Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. | new | 1 + +|<> | Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint. | new | 1 + +|<> | Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. | new | 1 + +|<> | Detects a sequence of events in Microsoft Entra ID indicative of a suspicious cloud-based device registration, potentially using ROADtools. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools, a popular red team toolkit, often leaves distinct telemetry signatures such as the `Microsoft.OData.Client` user agent and specific OS version values. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. | new | 1 + +|<> | Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. | new | 1 + +|<> | This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents. | new | 1 + +|<> | This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation. | new | 1 + +|<> | This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster. | new | 1 + +|<> | Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. | new | 1 + +|<> | This rule detects potential kubectl network configuration modification activity by monitoring for process events where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in Kubernetes. This could indicate an adversary trying to manipulate network settings for malicious purposes, such as establishing unauthorized access or exfiltrating data. | new | 1 + +|<> | This rule detects potential kubectl masquerading activity by monitoring for process events where the process name is not "kubectl" but the command line arguments include kubectl-related commands. This could indicate an adversary attempting to masquerade as legitimate kubectl activity to evade detection. This rule covers evasion gaps introduced by renaming the kubectl binary, or placing it in an unusual directory. | new | 1 + +|<> | This rule detects the execution of the "kubectl apply" command with a URL argument. This command is often used to apply configurations or deploy resources in a Kubernetes cluster. Attackers may use this command to deploy malicious pods or modify existing ones, potentially leading to unauthorized access or data exfiltration. | new | 1 + +|<> | This rule monitors for the execution of curl or wget commands that directly access Kubernetes API endpoints, which may indicate an attempt to interact with Kubernetes resources in a potentially unauthorized manner. This technique is often used by adversaries to gather information about the Kubernetes environment, such as secrets, config maps, and other sensitive data, without using the official Kubernetes client tools such as "kubectl". | new | 1 + +|<> | This rule detects the creation or modification of sensitive Kubernetes configuration files on Linux systems. These files include Kubernetes manifests, PKI files, and configuration files that are critical for the operation of Kubernetes clusters. Monitoring these files helps identify potential unauthorized changes or misconfigurations that could lead to security vulnerabilities in Kubernetes environments. Attackers may attempt to modify these files to gain persistence or to deploy malicious containers within the Kubernetes cluster. | new | 1 + +|<> | This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 6 + +|<> | Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. | update | 5 + +|<> | Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. | update | 214 + +|<> | Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. | update | 213 + +|<> | Identifies when a user or role has assumed a role in AWS Security Token Service (STS). Users can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. | update | 5 + +|<> | Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. | update | 2 + +|<> | Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams. | update | 105 + +|<> | This rule detects when a service account makes an unauthorized request for resources from the API server. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster. | update | 9 + +|<> | This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster. | update | 207 + +|<> | This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. | update | 208 + +|<> | This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously. | update | 10 + +|<> | This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster. | update | 207 + +|<> | This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine. | update | 9 + +|<> | This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used. | update | 208 + +|<> | This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace. | update | 208 + +|<> | This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root. | update | 208 + +|<> | This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods. | update | 208 + +|<> | This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host. | update | 208 + +|<> | This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control. | update | 10 + +|<> | Identifies suspicious Microsoft 365 mail access by ClientAppId. This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. | update | 111 + +|<> | Identifies sign-ins on behalf of a principal user to the Microsoft Graph API from multiple IPs using the Microsoft Authentication Broker or Visual Studio Code application. This behavior may indicate an adversary using a phished OAuth refresh token. | update | 2 + +|<> | Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. | update | 305 + +|<> | A machine learning job has identified an unusual spike in Okta group application assignment change events, indicating potential privileged access activity. Threat actors might be assigning applications to groups to escalate access, maintain persistence, or facilitate lateral movement within an organization’s environment. | update | 4 + +|<> | A machine learning job has identified an unusual spike in Okta group privilege change events, indicating potential privileged access activity. Attackers might be elevating privileges by adding themselves or compromised accounts to high-privilege groups, enabling further access or persistence. | update | 4 + +|<> | A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating potential privileged access activity. Threat actors may manipulate user accounts to gain higher access rights or persist within the environment. | update | 4 + +|<> | A machine learning job has identified a spike in group management events for a user, indicating potential privileged access activity. The machine learning has flagged an abnormal rise in group management actions (such as adding or removing users from privileged groups), which could point to an attempt to escalate privileges or unauthorized modifications to group memberships. | update | 4 + +|<> | This rule detects the use of git to clone a repository or download files from GitHub using wget or curl, followed by the creation of files in suspicious directories such as /tmp, /var/tmp, or /dev/shm. This behavior may indicate an attempt to download a payload, exploit or tool. | update | 2 + +|<> | This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control. | update | 112 + +|<> | This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data. | update | 2 + +|<> | This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior. | update | 2 + +|<> | This rule detects when a process accesses Kubernetes service account secrets. Kubernetes service account secrets are files that contain sensitive information used by applications running in Kubernetes clusters to authenticate and authorize access to the cluster. These secrets are typically mounted into pods at runtime, allowing applications to access them securely. Unauthorized access to these secrets can lead to privilege escalation, lateral movement and unauthorized actions within the cluster. | update | 2 + +|<> | This rule monitors for manual memory dumping via the proc filesystem. The proc filesystem in Linux provides a virtual filesystem that contains information about system processes and their memory mappings. Attackers may use this technique to dump the memory of a process, potentially extracting sensitive information such as credentials or encryption keys. | update | 2 + +|<> | This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection. | update | 2 + +|<> | This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system. | update | 2 + +|<> | This rule detects suspicious paths mounted on Linux systems. The mount command is used to attach filesystems to the system, and attackers may use it to mount malicious filesystems or directories for data exfiltration or persistence. | update | 2 + +|<> | This rule detects the creation of a symbolic link from a system binary to a suspicious and writable location. This activity may indicate an attacker's attempt to evade detection by behavioral rules that depend on predefined process parent/child relationships. By executing the symlinked variant of a binary instead of the original, the attacker aims to bypass these rules. Through the new_terms rule type, this rule can identify uncommon parent processes that may indicate the presence of a malicious symlink. | update | 2 + +|<> | 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. | update | 2 + +|<> | The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create, or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster. This rule detects process discovery executions that involve kubeconfig files, particularly those executed from common shell environments or world-writeable directories. | update | 2 + +|<> | This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges. | update | 2 + +|<> | This rule detects manual mount discovery via the /etc/exports or /etc/fstab file on Linux systems. These files are used by NFS (Network File System) to define which directories are shared with remote hosts. Attackers may access this file to gather information about shared directories and potential targets for further exploitation. | update | 2 + +|<> | This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe. | update | 2 + +|<> | This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process. | update | 2 + +|<> | Detects the use of curl to upload an archived file to an internet server. Threat actors often will collect data on a system and compress it in an archive file before exfiltrating the file back to their C2 server for review. Many threat actors have been seen utilizing curl to upload this archive file with the collected data to do this. Use of curl in this way while not inherently malicious should be considered highly abnormal and suspicious activity. | update | 2 + +|<> | The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster. | update | 2 + +|<> | This rule detects SSH session ID change followed by a suspicious SSHD child process, this may indicate the successful execution of a potentially malicious process through the Pluggable Authentication Module (PAM) utility. PAM is a framework used by Linux systems to authenticate users. Adversaries may create malicious PAM modules that grant them persistence onto the target every time a user logs in by executing a backdoor script or command. | update | 2 + +|<> | This rule detects the execution of unusual commands via a descendant process of exim4. Attackers may use descendant processes of exim4 to evade detection and establish persistence or execute post-exploitation commands on a target system. | update | 2 + +|<> | This rule detects the creation of files named release_agent or notify_on_release, which are commonly associated with the abuse of Linux cgroup release mechanisms. In Docker or containerized environments, this behavior may indicate an attempt to exploit privilege escalation vulnerabilities such as CVE-2022-0492, where attackers use the release_agent feature to execute code on the host from within a container. | update | 2 + +|<> | Adversaries may install legitimate remote access tools (RAT) to compromised endpoints for further command-and-control (C2). Adversaries can rely on installed RATs for persistence, execution of native commands and more. This rule detects when a process is started whose name or code signature resembles commonly abused RATs. This is a New Terms rule type indicating the host has not seen this RAT process started before within the last 30 days. | update | 113 + +|<> | Identifies the creation or modification of a medium-size registry hive file on a Server Message Block (SMB) share, which may indicate an exfiltration attempt of a previously dumped Security Account Manager (SAM) registry hive for credential extraction on an attacker-controlled system. | update | 112 + +|<