Attack Chain

1. An attacker gains initial access to a system (e.g., via phishing or exploit).
2. The attacker leverages PowerShell, a built-in Windows scripting language, to execute malicious commands.
3. The attacker uses obfuscation techniques (encoding, encryption, compression) to disguise the PowerShell script’s true intent.
4. The obfuscated script is executed, bypassing basic signature-based detections.
5. The script may download and execute additional payloads or establish persistence.
6. The script performs malicious actions such as data exfiltration, lateral movement, or system compromise.

Impact

A successful attack using obfuscated PowerShell can lead to various negative impacts, including data breaches, system compromise, and disruption of services. The low severity reflects the need for further analysis to confirm malicious intent, given potential false positives from legitimate encoded scripts. While the exact number of affected systems and sectors is unknown, the widespread use of PowerShell makes this a potentially significant threat across many organizations.

Recommendation

• Enable PowerShell Script Block Logging to generate the necessary events (4104) as outlined in the setup instructions: https://ela.st/powershell-logging-setup.
• Deploy the provided Sigma rule to your SIEM and tune the thresholds (powershell.file.script_block_length, powershell.file.script_block_entropy_bits, powershell.file.script_block_surprisal_stdev) based on your environment’s baseline.
• Investigate alerts generated by the Sigma rule, focusing on execution context (user.name, host.name), script provenance (file.path), and reconstructed script content (powershell.file.script_block_text).
• Review the investigation guide within the rule’s note section for detailed triage and analysis steps.

Attack Chain

1. The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
2. The attacker escalates privileges to gain the necessary permissions to delete files.
3. The attacker deploys or utilizes an existing copy of the SDelete utility.
4. The attacker executes SDelete against targeted files or directories.
5. SDelete overwrites the targeted file(s) multiple times with random data.
6. SDelete renames the file(s) multiple times, often with patterns such as “*AAA.AAA”.
7. SDelete deletes the file(s) making recovery difficult.
8. The attacker removes SDelete or any associated tools to further cover their tracks.

Impact

Successful exploitation of this technique can result in the permanent deletion of crucial forensic artifacts, log files, or even critical data. This can severely hinder incident response efforts, making it challenging to identify the scope of the attack, the attacker’s methods, and the compromised assets. The number of victims and affected sectors depends on the scale of the initial breach and the attacker’s objectives.

Recommendation

• Deploy the “Potential Secure File Deletion via SDelete Utility” detection rule to your SIEM and tune for your environment.
• Investigate any alerts generated by the detection rule, focusing on the process execution chain and identifying the user account involved.
• Review the privileges assigned to the user account to ensure the least privilege principle is followed.
• Enable Sysmon Event ID 11 (File Create) logging to enhance visibility into file creation events.

Attack Chain

1. An attacker gains initial access via phishing (T1566) or other means to execute commands on the target system.
2. The attacker uses msiexec.exe with the /V parameter to initiate the installation of a remote MSI package. This allows the attacker to bypass typical execution restrictions.
3. Msiexec.exe attempts a network connection (T1105) to retrieve the remote MSI package from a malicious server.
4. Msiexec.exe spawns a child process to handle the installation of the downloaded MSI package.
5. The spawned child process executes malicious code embedded within the MSI package.
6. The malicious code performs actions such as installing malware, modifying system settings, or establishing persistence.
7. The attacker leverages the compromised system for further lateral movement or data exfiltration.

Impact

Successful exploitation can lead to the installation of malware, unauthorized access to sensitive data, and further compromise of the affected system and network. While this specific rule has a low risk score, it can be an early indicator of more serious attacks. It is crucial to investigate any alerts generated by this rule to determine the full scope and impact of the potential compromise.

Recommendation

• Deploy the Sigma rule provided below to your SIEM to detect suspicious usage of msiexec.exe to install remote packages. Tune the rule for your environment by adding exceptions for legitimate software installation processes.
• Enable process monitoring and network connection logging on Windows endpoints to provide the necessary data for the Sigma rule to function effectively (Data Source: Elastic Defend).
• Review the “Possible investigation steps” section in the Elastic rule’s documentation to investigate potential false positives and legitimate uses of msiexec.exe.
• Implement application control policies to restrict the execution of unauthorized applications, including potentially malicious MSI packages.

Attack Chain

1. An attacker gains initial access to a compromised host within the target environment.
2. The attacker executes dsquery.exe with the argument objectClass=trustedDomain to enumerate domain trusts.
3. The command execution is logged by endpoint detection and response (EDR) solutions or Windows Security Event Logs.
4. The attacker parses the output of the dsquery.exe command to identify trusted domains and their attributes.
5. The attacker uses the discovered trust information to plan lateral movement strategies.
6. The attacker attempts to authenticate to other systems within the trusted domains using stolen credentials or other exploits.

Impact

Successful enumeration of domain trusts enables attackers to map out the Active Directory environment and identify potential pathways for lateral movement. While the enumeration itself is low impact, it facilitates subsequent actions like credential theft, privilege escalation, and data exfiltration. This can lead to widespread compromise across the organization, impacting numerous systems and sensitive data.

Recommendation

• Deploy the Sigma rule “Detect Enumerating Domain Trusts via DSQUERY.EXE” to your SIEM and tune for your environment.
• Investigate any execution of dsquery.exe with the argument objectClass=trustedDomain to identify potentially malicious activity.
• Monitor process execution events for dsquery.exe to detect suspicious command-line arguments and execution patterns.

Attack Chain

1. The attacker gains initial access to the system through an exploit or social engineering.
2. The attacker uses RunDLL32.exe to execute a malicious DLL.
3. RunDLL32.exe loads the specified DLL into memory.
4. The malicious DLL contains code to execute a command shell (cmd.exe or powershell.exe).
5. RunDLL32.exe spawns a command shell process.
6. The attacker uses the command shell to execute commands for reconnaissance.
7. The attacker may use the command shell to download additional payloads.
8. The attacker leverages the command shell to perform lateral movement.

Impact

Successful exploitation allows attackers to execute arbitrary commands on the compromised system. While the rule is rated “low” severity, this initial access can lead to credential access (T1552) and further lateral movement within the network. Attackers can potentially gain full control of the system, leading to data theft, system disruption, or other malicious activities.

Recommendation

• Deploy the Sigma rule “Command Shell Activity Started via RunDLL32” to your SIEM and tune for your environment.
• Enable Sysmon process creation logging (Event ID 1) to provide the necessary data for this detection.
• Review the process details of RunDLL32.exe to confirm the parent-child relationship with the command shell, helping to reduce false positives.
• Implement enhanced monitoring for rundll32.exe and related processes to detect similar activities in the future and improve response times.

Attack Chain

Due to the lack of details regarding CVE-2026-30656, a specific attack chain cannot be outlined at this time. The steps below represent a generic exploitation scenario:

1. Initial Access: Attacker identifies a vulnerable system exposed to the network.
2. Exploitation: Attacker leverages CVE-2026-30656 to execute arbitrary code.
3. Privilege Escalation: Attacker escalates privileges to gain higher-level access.
4. Lateral Movement: Attacker moves laterally to other systems on the network.
5. Persistence: Attacker establishes persistent access to the compromised systems.
6. Data Exfiltration: Attacker exfiltrates sensitive data from the compromised network.
7. Impact: Attacker achieves their objective, such as data theft or system disruption.

Impact

The impact of CVE-2026-30656 is currently unknown. Depending on the affected product and the nature of the vulnerability, successful exploitation could lead to a range of outcomes, including remote code execution, denial of service, or information disclosure. Without further details, the potential damage is difficult to assess, but defenders should prioritize monitoring for updates from Microsoft and promptly apply any released patches.

Recommendation

• Monitor the Microsoft Security Response Center (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-30656) for updates and technical details regarding CVE-2026-30656.
• When details are released, prioritize patching affected systems based on their criticality and exposure.
• Review existing security controls and incident response plans to ensure they are adequate for addressing potential exploitation attempts targeting Microsoft products.

Attack Chain

1. An attacker gains initial access to an AWS environment using compromised credentials or through an exposed IAM role. (T1530)
2. The attacker authenticates to AWS using the obtained credentials, creating a programmatic session.
3. The attacker issues a series of GetBucketAcl, GetBucketPublicAccessBlock, GetBucketPolicy, GetBucketPolicyStatus, and GetBucketVersioning API calls to S3.
4. These API calls are directed towards multiple distinct S3 buckets within a short timeframe (10 seconds).
5. The attacker collects information about the bucket’s access control lists (ACLs), public access blocks, policies, versioning status, and other metadata. (T1526, T1580, T1619)
6. The collected information is analyzed to identify publicly accessible buckets, misconfigurations, or sensitive data storage locations.
7. The attacker uses identified vulnerabilities to exfiltrate data.
8. The attacker attempts lateral movement within the AWS environment, leveraging the discovered information to compromise other resources.

Impact

Successful enumeration of S3 buckets can lead to the discovery of sensitive data, misconfigurations, and publicly accessible resources. This can result in data breaches, unauthorized access, and further compromise of the AWS environment. The enumeration allows an attacker to map out the S3 storage landscape, identifying targets for data exfiltration or privilege escalation. The rapid nature of the enumeration suggests automated scanning or reconnaissance, potentially indicating a larger attack campaign.

Recommendation

• Deploy the following Sigma rule to detect rapid S3 bucket enumeration activity based on AWS CloudTrail logs, adjusting the threshold of 15 distinct buckets to suit your environment.
• Investigate any alerts generated by the Sigma rule, focusing on the source IP address (source.ip), AWS principal ARN (aws.cloudtrail.user_identity.arn), and the list of accessed buckets (aws.cloudtrail.resources.arn).
• Review IAM policies associated with the identified principal to ensure least privilege for S3 read APIs.
• Monitor CloudTrail logs for related events, such as ListBuckets, GetObject, PutBucketPolicy, AssumeRole, or IAM changes, occurring within ±30 minutes of the detected enumeration activity.
• Implement network-level restrictions on the source IP address if it is not authorized to perform S3 enumeration.
• Document approved scanning accounts and add user agent filters to the provided Sigma rule to reduce noise from those identities.

Attack Chain

1. Initial Access: An attacker gains access to an AWS environment, potentially through compromised credentials or by compromising an EC2 instance.
2. Credential Usage: The attacker leverages the AWS CLI to interact with the AWS environment using the compromised credentials.
3. Reconnaissance: The attacker initiates a series of discovery API calls to gather information about the AWS infrastructure. This includes using Describe*, List*, Get*, and Generate* commands.
4. Resource Enumeration: The attacker enumerates various AWS resources, including EC2 instances, IAM roles, S3 buckets, and KMS keys, by querying their respective APIs.
5. Target Identification: The attacker analyzes the gathered information to identify potential targets for further exploitation, such as vulnerable EC2 instances or misconfigured S3 buckets.
6. Privilege Escalation (Optional): If the compromised credentials have limited permissions, the attacker might attempt to escalate privileges to gain broader access to the AWS environment.
7. Lateral Movement (Optional): The attacker might attempt to move laterally to other AWS accounts or services to expand their reach and impact.
8. Data Exfiltration/Impact: Based on the attacker’s goals, they may attempt to exfiltrate sensitive data or cause disruption by modifying or deleting resources.

Impact

Successful exploitation could lead to unauthorized access to sensitive data, such as customer information, intellectual property, or financial records. The attacker could also disrupt business operations by modifying or deleting critical resources. Identifying and responding to such activity in a timely manner can help prevent significant damage and maintain the security and integrity of the AWS environment.

Recommendation

• Deploy the following Sigma rule to your SIEM and tune for your environment to detect the described reconnaissance activity.
• Enable AWS CloudTrail logging for all AWS regions and accounts in your organization to ensure the required logs are available for detection.
• Investigate any alerts generated by the Sigma rule, focusing on identifying the affected AWS identity, the source IP address, and the specific API calls made (as captured by the Sigma rule).
• If suspicious activity is confirmed, follow AWS’s incident-handling guidance, including disabling or rotating the access key used and restricting outbound connectivity from the source (reference the AWS Security Incident Response Guide).

Attack Chain

1. Initial Disclosure: Microsoft publishes the CVE ID CVE-2026-35236 without any details.
2. Information Gathering (Attacker): Attackers monitor Microsoft’s channels and other sources for further information on CVE-2026-35236.
3. Vulnerability Analysis (Attacker): Once details are released (hypothetically), attackers analyze the vulnerability to develop an exploit.
4. Exploit Development (Attacker): An exploit is created, potentially leveraging publicly available tools or custom-developed code.
5. Target Selection (Attacker): Attackers identify vulnerable systems based on the (currently unknown) affected product.
6. Exploitation Attempt (Attacker): The exploit is deployed against the target system.
7. Privilege Escalation (Attacker): (Hypothetical) If the initial exploit doesn’t provide sufficient privileges, further steps are taken to escalate privileges.
8. Impact (Attacker): (Hypothetical) Depending on the vulnerability, the impact could range from remote code execution to denial of service.

Impact

The current impact is unknown due to the lack of information about the vulnerability associated with CVE-2026-35236. If the vulnerability is severe and widely exploitable, successful attacks could lead to data breaches, system compromise, or denial of service. The number of potential victims and affected sectors will depend on the affected product and its deployment scope.

Recommendation

• Continuously monitor the Microsoft Security Response Center for updates regarding CVE-2026-35236 (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-35236).
• Once Microsoft releases details on CVE-2026-35236, prioritize patching or implementing recommended mitigations.
• Deploy generic detection rules to identify exploitation attempts based on unusual network activity or suspicious process creation.
• Review existing security controls and ensure they are up-to-date to protect against potential exploitation attempts.

Attack Chain

1. An attacker gains access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.
2. The attacker uses the acquired credentials to authenticate to the AWS environment.
3. The attacker executes a script or tool that calls multiple S3 APIs (e.g., GetBucketAcl, GetBucketPolicy) to gather information about S3 buckets.
4. The tool iterates through a list of buckets, querying the configuration of each.
5. The attacker collects the responses from the S3 API calls, mapping out bucket names, permissions, and access control lists.
6. The attacker analyzes the collected data to identify potentially sensitive data or misconfigured buckets.
7. Based on the findings, the attacker may proceed to exfiltrate data from accessible buckets (T1530).
8. The attacker may also attempt to modify bucket policies or access controls to gain further access or persistence.

Impact

Successful reconnaissance of S3 bucket configurations allows attackers to identify vulnerable buckets, potentially leading to data breaches or unauthorized access to sensitive information. The source material does not provide specific victim counts or sectors. However, the impact can range from exposure of confidential data to full compromise of the AWS environment, depending on the level of access gained and the sensitivity of the data stored in the targeted buckets. Identifying the activity early can prevent further exploitation.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect rapid S3 bucket posture API calls (see: “AWS S3 Rapid Bucket Enumeration”).
• Review IAM policies and enforce least privilege on S3 read APIs to limit the scope of potential reconnaissance activities.
• Monitor CloudTrail logs for the same aws.cloudtrail.user_identity.arn and source.ip within approximately ±30 minutes for follow-on patterns such as ListBuckets, GetObject, PutBucketPolicy, or AssumeRole activities (see Overview).
• Rotate or disable keys for the affected identity, revoke active role sessions where possible, and restrict the source IP at the network layer if it is not authorized (see Overview).
• Whitelist approved scanning accounts and tune the Sigma rule to reduce noise from those identities (see Overview).

Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials or an exposed IAM role.
2. The attacker attempts to create a new SSM Command document using the CreateDocument API call.
3. The CreateDocument API call is logged by AWS CloudTrail with details about the user identity, request parameters, and document description.
4. The detection rule analyzes CloudTrail logs, specifically looking for the CreateDocument event with a document type of Command.
5. The rule identifies the user or role associated with the CreateDocument API call by inspecting the aws.cloudtrail.user_identity.arn field.
6. If the user or role is considered rare or unusual for creating SSM Command documents within the organization, the rule triggers an alert.
7. The attacker could then use the created document to execute arbitrary commands on managed instances.
8. Successful execution of these commands leads to various impacts, including unauthorized access, command and control, data exfiltration, or disruption of services.

Impact

The successful exploitation of this technique can lead to unauthorized access to AWS resources, potentially affecting all systems managed by AWS SSM in the targeted environment. The creation of malicious SSM command documents can lead to data exfiltration, system compromise, or denial of service. If successful, this can impact hundreds or thousands of systems depending on the scope of AWS SSM usage in the organization.

Recommendation

• Deploy the Sigma rule “AWS SSM Command Document Created by Rare User” to your SIEM, ensuring proper indexing of CloudTrail logs (index = [“filebeat-*”, “logs-aws.cloudtrail-*”]).
• Review the aws.cloudtrail.request_parameters.content field in the CloudTrail logs for any suspicious commands within the created SSM document.
• Restrict SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation as mentioned in the overview.
• Monitor the SendCommand API call related to the created SSM document to see if it is used to execute commands on managed instances, as described in the triage section.

Attack Chain

1. Initial Compromise: An attacker gains initial access to the Kubernetes cluster, potentially by exploiting a vulnerability in a pod or by stealing a kubeconfig file.
2. Discovery: The attacker enumerates available resources within the cluster to identify potential targets, including secrets. This might involve using kubectl get secrets --all-namespaces.
3. Credential Theft: The attacker attempts to access Kubernetes secrets using an unusual user agent, source IP, or user name. For example, using curl from a compromised pod to access the Kubernetes API.
4. Data Exfiltration: The attacker retrieves the contents of the secrets. Secrets might contain service account tokens, registry credentials, cloud IAM keys, database passwords, etc.
5. Lateral Movement: With stolen credentials, the attacker attempts to move laterally within the cluster or the connected cloud environment. They might use the credentials to access other pods, services, or cloud resources.
6. Privilege Escalation: The attacker uses the stolen credentials to escalate their privileges within the Kubernetes cluster or the cloud environment. For example, creating new roles or role bindings.
7. Persistence: The attacker establishes persistence by creating backdoors or modifying existing deployments. This might involve creating new pods or modifying existing deployments.
8. Impact: The attacker achieves their objective, such as data theft, denial of service, or infrastructure compromise.

Impact

Successful exploitation can lead to the compromise of sensitive data stored within Kubernetes secrets. This could include database credentials, API keys, and service account tokens. The impact can range from unauthorized access to sensitive data, to complete compromise of the Kubernetes cluster and the connected cloud environment. This can affect any organization using Kubernetes to manage their applications, potentially leading to data breaches, service disruptions, and financial losses. The severity depends on the sensitivity of the data stored in the compromised secrets and the level of access the attacker gains.

Recommendation

• Deploy the Sigma rule Kubernetes Secret Access via Unusual User Agent to your SIEM and tune for your environment to detect unusual access patterns to Kubernetes secrets.
• Investigate and validate any alerts generated by the deployed Sigma rule, focusing on the requesting identity, source IP, and user agent to confirm whether they align with approved access records.
• Implement RBAC least privilege to limit access to secrets to only the required service accounts and users to minimize the potential impact of credential theft.
• Monitor Kubernetes audit logs (logs-kubernetes.audit_logs-*) for suspicious activity, including unusual API calls and access patterns to sensitive resources.
• Regularly rotate secrets and credentials to minimize the window of opportunity for attackers to use stolen credentials.

Attack Chain

1. Credential Compromise: An attacker obtains valid Azure credentials (username/password or service principal keys) through phishing, credential stuffing, or other means.
2. Initial Access: The attacker uses the compromised credentials to log in to the Azure environment from an unusual geographic location (city).
3. Activity Log Generation: The login and subsequent actions generate Azure Activity Logs entries.
4. Resource Access/Modification: The attacker performs actions such as adding privileged role assignments, creating virtual machines, modifying network configurations, or accessing Key Vault secrets.
5. Lateral Movement (Potential): The attacker may use the initially compromised account to discover and access other resources or accounts within the Azure environment.
6. Data Exfiltration/Resource Exploitation (Potential): The attacker exfiltrates sensitive data or uses compromised resources for malicious purposes like cryptocurrency mining.

Impact

A successful attack can lead to unauthorized access to sensitive data, modification of critical infrastructure, and deployment of malicious resources within the Azure environment. The impact can range from data breaches and financial losses to disruption of services. While the risk score of this detection is low, further investigation is required to determine the extent and nature of the malicious activity.

Recommendation

• Enable the associated Machine Learning job (azure_activitylogs_rare_event_action_for_a_city_ea) and ensure that the Azure Activity Logs integration is properly configured to provide the necessary data.
• Review the investigation guide within the rule’s note field to understand possible investigation steps, including validating user presence in the region and enriching the source IP.
• Implement response and remediation steps outlined in the rule note field such as revoking active sessions, resetting passwords, and reverting changes executed from the unusual city.
• Configure Conditional Access policies with country allowlists and named egress IP ranges, as recommended in the rule’s note field, to prevent logins from unexpected locations.

Attack Chain

1. Initial Access: An attacker gains initial access to a network or system (not explicitly described in source).
2. Credential Harvesting: The attacker attempts to gather valid credentials through password spraying or brute-force attacks (T1110, T1110.003).
3. Account Discovery: The attacker enumerates user accounts to identify potential targets, often performed in conjunction with password attacks.
4. Successful Authentication: Using compromised credentials, the attacker successfully authenticates to a system or service (T1078, T1078.002, T1078.003).
5. Lateral Movement: After successful authentication, the attacker potentially moves laterally within the network using valid accounts (not explicitly described in source).
6. Privilege Escalation: The attacker may attempt to escalate privileges to gain higher-level access (not explicitly described in source).
7. Data Exfiltration/Impact: After gaining sufficient access, the attacker may exfiltrate sensitive data or cause damage to the system or network (not explicitly described in source).

Impact

Successful exploitation can lead to unauthorized access to sensitive data, systems, and services. The number of affected users and the extent of the damage depend on the scope of the compromised credentials and the attacker’s objectives. This can impact any sector, as credential compromise is a common attack vector across various industries.

Recommendation

• Enable and configure the Elastic Defend, Auditd Manager, or System integrations to provide the necessary data for the machine learning job (see Setup section).
• Install the associated Machine Learning job “auth_high_count_logon_events_for_a_source_ip_ea” to enable the detection (see Setup section).
• Tune the anomaly threshold of the machine learning job based on your environment to reduce false positives (anomaly_threshold metadata).
• Investigate alerts triggered by this rule, focusing on identifying the involved assets, users, and source IP addresses (see Note section).

Attack Chain

1. The attacker gains initial access to a system via compromised credentials or other means.
2. The attacker enumerates sensitive data on the compromised system.
3. The attacker stages the data for exfiltration, possibly compressing or archiving it.
4. The attacker connects an external device (e.g., USB drive) to the system.
5. The attacker initiates a large data transfer to the external device.
6. The Data Exfiltration Detection machine learning job detects a significant increase in bytes written to the external device, triggering an alert.
7. The attacker removes the external device containing the exfiltrated data.
8. The attacker uses the external device to access the stolen data.

Impact

A successful data exfiltration event can result in the loss of sensitive information, potentially leading to financial losses, reputational damage, legal repercussions, and competitive disadvantage. Although the specific number of victims and targeted sectors are not specified, the potential impact is broad, affecting any organization that stores sensitive data on systems accessible to malicious actors. The severity depends on the nature and volume of the exfiltrated data.

Recommendation

• Review and tune the Data Exfiltration Detection integration’s configuration, specifically the “ded_high_bytes_written_to_external_device” machine learning job, to reduce false positives related to legitimate data transfer activities.
• Implement and enforce data transfer policies to restrict the unauthorized use of external devices and ensure compliance with organizational security standards.
• Deploy endpoint detection and response (EDR) solutions to enhance visibility and control over data movements to external devices, as recommended in the rule’s response and remediation guidance.
• Investigate any alerts generated by the “Spike in Bytes Sent to an External Device” rule (rule_id: “35a3b253-eea8-46f0-abd3-68bdd47e6e3d”) to determine the legitimacy of the data transfer and take appropriate action.
• Consult the investigation guide provided in the rule’s notes section to aid in the triage and analysis of potential data exfiltration incidents.

Attack Chain

1. An attacker gains initial access to a system with kubectl installed and configured to interact with a Kubernetes cluster.
2. The attacker executes the kubectl command with arguments like port-forward to create a local port that forwards traffic to a service or pod within the cluster.
3. The attacker uses kubectl proxy to create a proxy server that allows them to access the Kubernetes API server from their local machine.
4. The attacker employs kubectl expose to create a new service that exposes a deployment, replication controller, or pod as a new Kubernetes service, potentially opening up unintended access points.
5. The attacker may execute these commands from a shell like bash, or from a script located in a temporary directory like /tmp/ or /var/tmp/, to evade detection.
6. The attacker leverages the modified network configurations to establish unauthorized access to sensitive services or data within the Kubernetes cluster.
7. The attacker may use the proxied or forwarded connections to exfiltrate data from the cluster to an external location.

Impact

Successful exploitation via kubectl network configuration modification can lead to unauthorized access to sensitive data and services within a Kubernetes cluster. This can result in data breaches, service disruptions, and lateral movement within the cluster. The low severity score suggests that while the risk exists, the impact might be limited if proper Kubernetes security best practices are followed. The rule aims to detect these actions early, preventing potential damage to the cluster.

Recommendation

• Enable Elastic Defend integration or equivalent EDR solutions to monitor process execution and network connections (Data Source: Elastic Defend, Data Source: Crowdstrike, Data Source: SentinelOne).
• Deploy the provided Sigma rule to detect suspicious kubectl commands with network-related arguments (rules section). Tune the rule based on your environment to minimize false positives.
• Investigate any alerts generated by the Sigma rule, focusing on the parent process and the command-line arguments of the kubectl command (rules section, Resources: Investigation Guide).
• Implement enhanced monitoring and logging for kubectl activities and network configuration changes within the Kubernetes cluster to proactively detect and respond to similar threats in the future (Resources: Investigation Guide).

Attack Chain

This brief describes a service offering that enables rapid incident response, rather than a specific attack chain. Therefore, the typical attack chain steps do not apply. However, the service is designed to improve resilience against attacks, which can be described as follows:

1. Initial Access: An attacker gains initial access to the target environment through various means such as phishing, vulnerability exploitation, or stolen credentials (not directly mentioned in the source).
2. Lateral Movement: The attacker attempts to move laterally within the network, escalating privileges to gain control over critical systems (not directly mentioned in the source).
3. Data Exfiltration: The attacker identifies and exfiltrates sensitive data from the compromised systems (not directly mentioned in the source).
4. Impact: The attacker deploys ransomware or causes other damage to disrupt business operations (not directly mentioned in the source).
5. Detection: The organization detects the intrusion, potentially through existing security tools or alerts (not directly mentioned in the source).
6. Activation of CrowdStrike Services: The organization leverages CrowdStrike Flex for Services to engage incident response experts.
7. Incident Response: CrowdStrike experts rapidly assess the scope of the breach, contain the attacker’s activities, and begin remediation efforts.
8. Remediation and Recovery: CrowdStrike assists in recovering compromised systems, patching vulnerabilities, and implementing security enhancements to prevent future incidents.

Impact

The successful utilization of CrowdStrike Flex for Services can significantly reduce the impact of a cyberattack by enabling rapid incident response and minimizing downtime. Organizations can pre-arrange incident response coverage, providing access to elite expertise and a more adaptable approach to consuming cybersecurity services over time. The Zero Dollar Flex Fund provides a direct path to CrowdStrike expertise for first-time services customers, offering a standalone 12-month agreement with flexibility in applying proactive services to readiness and consulting priorities. This results in improved preparedness, faster containment of threats, and more effective recovery from incidents, minimizing potential financial losses, reputational damage, and operational disruptions.

Recommendation

• Evaluate the CrowdStrike Falcon Flex for Services model to determine its suitability for your organization’s incident response and cybersecurity service needs (Reference: CrowdStrike Flex for Services).
• For qualifying new services customers, explore the Zero Dollar Flex Fund to gain initial access to CrowdStrike Services for incident response and proactive security measures (Reference: Zero Dollar Flex Fund).
• Integrate CrowdStrike’s incident response capabilities with existing security tools and processes to streamline incident handling and improve overall security posture (Reference: CrowdStrike Services).

Attack Chain

This toolkit is designed to aid in the detection of the following attack chains:

1. Initial Access: (Phishing, Malware) An attacker gains initial access through methods such as phishing emails or malware-infected attachments.
2. Credential Access: (Kerberoasting, Pass-the-Hash) After gaining initial access, the attacker attempts to harvest credentials using techniques like Kerberoasting to target service accounts or Pass-the-Hash to reuse existing credentials.
3. Lateral Movement: (Pass-the-Hash) Using compromised credentials, the attacker moves laterally within the network, accessing additional systems and resources.
4. Execution: (LOLBAS) The attacker utilizes Living-Off-The-Land Binaries and Scripts (LOLBAS) to execute malicious commands and evade detection.
5. Persistence: (Scheduled Task Persistence) The attacker establishes persistence by creating scheduled tasks that execute malicious code at regular intervals.
6. Command and Control: (C2 on non-standard ports) The attacker establishes a command and control channel, communicating with compromised systems over non-standard ports to evade detection.
7. Exfiltration: (Data Exfil) The attacker exfiltrates sensitive data from the compromised systems.
8. Impact: (Data Exfil) The attacker achieves their final objective of data exfiltration, resulting in data loss or exposure.

Impact

The toolkit helps defenders to mitigate the impact of attacks by providing resources for incident response, alert triage, and threat hunting. Successful implementation of the toolkit’s recommendations can lead to faster detection and containment of security incidents, reducing the potential for data breaches, financial losses, and reputational damage.

Recommendation

• Review the threat hunting guides within the toolkit and adapt the provided Splunk and Elastic queries for Kerberoasting, Pass-the-Hash, LOLBAS, scheduled task persistence, and C2 on non-standard ports to your environment.
• Utilize the provided IR Checklists (Phishing, Malware, Brute Force, Data Exfil, Suspicious PowerShell) to standardize and improve incident response procedures.
• Customize and integrate the Alert Triage Playbooks into your existing security operations workflows to assist with the analysis of alerts related to impossible travel, lateral movement, and DNS beaconing.

Attack Chain

This threat brief focuses on the analysis of Rust binaries, not a specific attack chain. However, understanding the structure of these binaries is crucial for analyzing attacks leveraging them. The following steps outline a general reverse engineering process applicable to any binary, with considerations specific to Rust:

1. Initial Reconnaissance: Obtain the Rust binary and gather basic information such as file type, size, and compilation timestamp using tools like file and strings.
2. Metadata Analysis: Examine the binary’s metadata section to identify Rust version, crate dependencies, and potentially debug symbols. This can be done using tools like objdump or specialized Rust metadata parsers.
3. String Extraction: Extract embedded strings from the binary. Note that Rust often uses UTF-8 encoding for strings, so ensure your tools support this encoding.
4. Function Identification: Identify key functions such as main, and any other functions related to suspicious behavior. Tools like IDA Pro or Ghidra can be used for disassembly and function analysis.
5. Control Flow Analysis: Analyze the control flow of the program, paying attention to function calls and branching logic. Rust’s ownership and borrowing system can make control flow more complex than in C/C++.
6. Dependency Analysis: Identify and analyze any external crates (libraries) used by the binary. These crates may contain known vulnerabilities or malicious code.
7. Behavioral Analysis: Execute the binary in a controlled environment (sandbox) to observe its behavior, including file system access, network connections, and registry modifications.
8. Detection Rule Creation: Based on the reverse engineering and behavioral analysis, create detection rules for identifying similar malicious Rust binaries.

Impact

The increasing use of Rust in malware development poses a challenge for security analysts. Successful reverse engineering and understanding of Rust binaries are crucial for detecting and mitigating threats. Failure to adapt to this trend could lead to a decreased ability to identify and respond to novel malware strains.

Recommendation

• Familiarize detection engineers with the structure and characteristics of Rust binaries as described in the JPCERT/CC study to improve reverse engineering capabilities.
• Implement the Sigma rules provided below to detect suspicious behaviors commonly associated with potentially malicious binaries, adjusting thresholds and whitelists as needed for your environment.
• Utilize tools capable of parsing Rust metadata to extract crate dependencies and other useful information from Rust binaries during analysis, as described in the “Metadata Analysis” step above.

Attack Chain

1. An attacker gains initial access to an AWS account as an IAM user, potentially through compromised credentials or an exposed access key.
2. The attacker enumerates available IAM roles within the AWS environment to identify roles with elevated privileges or access to sensitive resources.
3. The attacker calls the AssumeRole API in AWS STS, requesting temporary credentials for the target role, using a roleSessionName for context.
4. The STS service validates the request and, if authorized, issues temporary credentials consisting of an accessKeyId, secretAccessKey, and sessionToken.
5. The attacker configures their AWS CLI or SDK with the temporary credentials obtained from the STS service.
6. The attacker uses the temporary credentials to access AWS resources and perform actions permitted by the assumed role, such as modifying security groups, accessing S3 buckets, or launching EC2 instances.
7. The attacker may attempt to further escalate privileges by assuming additional roles or creating new IAM users with administrative privileges.

Impact

A successful role assumption can grant an attacker access to sensitive data, allow them to disrupt critical services, or provide a foothold for further attacks within the AWS environment. While this rule has a low severity, a high volume of alerts should be reviewed as it could indicate ongoing lateral movement and privilege escalation. The impact of a successful attack can range from data breaches and service disruptions to complete compromise of the AWS environment.

Recommendation

• Deploy the Sigma rule provided below to your SIEM and tune for your environment to detect suspicious role assumptions.
• Investigate any alerts generated by the rule by reviewing the associated CloudTrail logs, specifically the aws.cloudtrail.user_identity.arn and aws.cloudtrail.resources.arn fields.
• Implement additional monitoring for high-risk roles with elevated permissions, and create exceptions for trusted patterns.
• Regularly review IAM policies and roles to minimize the risk of privilege escalation.
• Refer to the AWS STS documentation for more details on managing and securing AWS STS in your environment.

Attack Chain

1. An attacker gains initial access to an Okta account, possibly through compromised credentials or other means. (T1078)
2. The attacker begins enumerating user accounts and their associated roles and permissions within the Okta environment.
3. The attacker identifies a target user account with elevated privileges or a role that would grant them desired access.
4. The attacker modifies the target user account’s attributes, such as adding the attacker’s account to a privileged group or changing the user’s role. (T1098)
5. The attacker leverages the newly acquired privileges to access sensitive resources or perform unauthorized actions.
6. The attacker may create new user accounts with elevated privileges to maintain persistent access to the environment. (T1098)
7. The attacker covers their tracks by deleting logs or modifying audit trails to conceal their activity.
8. The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

A successful attack can result in privilege escalation, allowing unauthorized access to sensitive data and systems. Depending on the level of access gained, attackers may be able to compromise critical infrastructure, steal confidential information, or disrupt business operations. The impact can range from minor data breaches to significant financial losses and reputational damage. Early detection of anomalous user lifecycle changes is crucial to mitigating these risks.

Recommendation

• Ensure the Privileged Access Detection integration is installed and properly configured, including the preconfigured anomaly detection job “pad_okta_spike_in_user_lifecycle_management_changes_ea”.
• Investigate any alerts generated by this rule by following the investigation steps outlined in the rule’s note section within the Kibana UI.
• 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 as described in the rule’s documentation.
• Monitor Okta logs for any unusual or unauthorized activity, focusing on user account changes, as described in the setup documentation.
• Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activity or attempts to regain unauthorized access as mentioned in the response and remediation guidelines.

Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
2. The attacker identifies the existing Network ACLs within the target Virtual Private Cloud (VPC).
3. The attacker uses the AWS Management Console, CLI, or API to create a new Network ACL entry. The CreateNetworkAclEntry event is logged in CloudTrail.
4. The new ACL entry may be configured to allow specific inbound or outbound traffic that was previously blocked, effectively opening a new attack vector.
5. Alternatively, the new ACL entry may be configured to deny legitimate traffic, causing a denial-of-service condition for specific services or resources.
6. The attacker leverages the newly created ACL entry to move laterally within the AWS environment, accessing previously inaccessible resources.
7. The attacker performs malicious actions, such as data exfiltration or resource compromise, using the newly opened network pathways.

Impact

The creation of unauthorized Network ACL entries can have significant consequences. It can lead to the opening of new attack vectors, allowing unauthorized access to sensitive data and critical resources. In some scenarios, it can result in a denial-of-service condition, disrupting legitimate business operations. Depending on the scope of the compromised resources and data, the impact can range from minor inconvenience to significant financial loss and reputational damage. Early detection of this activity is crucial to mitigating potential risks.

Recommendation

• Deploy the Sigma rule “New Network ACL Entry Added” to your SIEM to detect suspicious ACL modifications (logsource: aws, service: cloudtrail).
• Investigate any CreateNetworkAclEntry events that deviate from established baseline configurations or involve unexpected source/destination IP ranges.
• Review and audit existing Network ACL configurations regularly to identify and remediate any overly permissive or restrictive rules.
• Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise and unauthorized access.
• Monitor CloudTrail logs for other related events, such as DeleteNetworkAclEntry or ReplaceNetworkAclEntry, which may indicate further tampering with network security configurations.

Attack Chain

1. The attacker gains initial access to a domain-joined system, possibly through compromised credentials or phishing.
2. The attacker passively monitors LLMNR/NBT-NS broadcast traffic to identify systems being requested on the network.
3. Upon observing a request for a target system (e.g., WPAD), the attacker creates a DNS-named record in ADIDNS that resolves the target system’s name to an attacker-controlled IP address. This leverages the default permissions in ADIDNS that allow authenticated users to create DNS records.
4. When a legitimate user attempts to access the target system, the DNS query resolves to the attacker’s IP address.
5. The user’s traffic is redirected to the attacker’s system.
6. The attacker intercepts the user’s credentials or other sensitive information.
7. The attacker may relay captured credentials to other systems on the network.
8. The attacker achieves credential access and lateral movement within the network.

Impact

Successful exploitation allows attackers to intercept network traffic, steal credentials, and potentially gain unauthorized access to sensitive systems and data within the Active Directory domain. While the severity is low, it can be a stepping stone to further, more damaging attacks.

Recommendation

• Enable “Audit Directory Service Changes” to generate the necessary Windows Security Event Logs (event code 5137) for detection.
• Deploy the Sigma rule Creation of a DNS-Named Record to detect suspicious DNS record creation events.
• Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.

Attack Chain

1. Initial Access: An attacker gains initial access to a system within the network through various means, such as exploiting a vulnerability or using compromised credentials.
2. Command and Control: The attacker establishes a command and control (C2) channel to communicate with the compromised system.
3. Data Collection: The attacker identifies and collects sensitive data from various sources within the network.
4. Staging: The collected data is staged in a temporary location, compressed, and potentially encrypted for exfiltration.
5. Exfiltration: The attacker uses the C2 channel to transfer the staged data to an external location in an unusual geographic region.
6. Evasion: The attacker may attempt to obfuscate the data transfer by using techniques such as tunneling or encryption to avoid detection.
7. Cleanup: The attacker may attempt to remove traces of their activity, such as deleting logs or files, to hinder investigation.

Impact

A successful data exfiltration attack can result in the loss of sensitive information, including intellectual property, customer data, and financial records. The risk score for this rule is 21, which indicates a moderate level of risk. Detection of this activity allows security teams to quickly respond and mitigate the potential damage. Early detection helps prevent large-scale data breaches and minimizes the impact on the organization.

Recommendation

• Ensure that the Data Exfiltration Detection integration assets are installed and properly configured, including Elastic Defend and Network Packet Capture (see Setup instructions in content).
• Review the geo-location details flagged by the alert to determine if the region is indeed unusual for the organization’s typical network traffic patterns (see Triage and Analysis in content).
• Analyze the network traffic logs associated with the alert to identify the volume and type of data being transferred to the unusual region (see Triage and Analysis in content).
• Implement geo-blocking measures to restrict data transfers to the identified unusual region, ensuring that only approved regions can communicate with the network (see Response and Remediation in content).
• Deploy the Sigma rule below to detect processes initiating network connections to unusual regions based on the DestinationGeoRegion field.

Attack Chain

1. Initial Access: An attacker gains access to a host within the network, potentially through compromised credentials or exploitation of a vulnerability.
2. Discovery: The attacker performs reconnaissance to identify valuable data stores, network shares, and potential exfiltration targets.
3. Collection: The attacker gathers sensitive data from various sources within the compromised network. This data could include documents, databases, or other confidential information.
4. Data Consolidation: To avoid detection, the attacker bundles the collected data into a single, large file. This could involve archiving, compression, or other methods of aggregation.
5. Lateral Tool Transfer: The attacker uses remote services or tools to transfer the large file to a remote host within the network (T1570).
6. Exfiltration Preparation: The attacker stages the large file on the remote host, preparing it for exfiltration outside the network.
7. Exfiltration: The attacker initiates the transfer of the large file from the compromised network to an external destination, potentially using protocols like RDP.
8. Cleanup: The attacker attempts to remove traces of the activity, such as deleting temporary files or logs, to avoid detection.

Impact

A successful attack can lead to the exfiltration of sensitive data, potentially resulting in financial loss, reputational damage, and legal liabilities. The detection of unusual remote file sizes can help organizations identify and prevent data exfiltration attempts before they cause significant harm. Depending on the sensitivity of the exfiltrated data, the impact could range from minor inconvenience to a major security breach affecting thousands of individuals or customers.

Recommendation

• Ensure the host.ip field is populated as required by the rule. For Elastic Defend versions 8.18 and above, verify that host IP collection is enabled following the provided helper guide.
• Install the Lateral Movement Detection integration assets, including the lmd_high_file_size_remote_file_transfer_ea machine learning job. Follow the setup instructions detailed in the documentation.
• Review and tune the anomaly threshold (anomaly_threshold = 70) of the machine learning job based on your environment’s baseline to reduce false positives.
• Implement network segmentation to limit lateral movement, as suggested in the “Response and remediation” section of the rule documentation.
• Enhance monitoring and logging for unusual file transfer activities and remote access attempts as stated in the rule documentation.

Attack Chain

1. Developer attempts to commit code containing a secret to a GitHub repository.
2. GitHub’s push protection mechanism detects the secret and blocks the push.
3. The developer intentionally bypasses the push protection, potentially using allowed administrative activities to circumvent the block.
4. The code, including the secret, is successfully pushed to the repository.
5. The secret becomes exposed within the repository’s history.
6. Unauthorized actors may discover the exposed secret by scanning the repository.
7. Unauthorized actors may use the exposed secret to gain unauthorized access to systems or data.

Impact

A successful bypass of GitHub push protection can lead to secrets being exposed in a repository. This exposure can lead to unauthorized access to sensitive systems or data. The severity of the impact depends on the scope of access granted by the exposed secret, and the visibility of the repository.

Recommendation

• Enable audit log streaming in GitHub to ensure relevant events are captured.
• Deploy the Sigma rule “Github Push Protection Bypass Detected” to your SIEM and tune for your environment using GitHub audit logs.
• Investigate any detected bypass events to determine the context and impact of the bypassed secret.

Attack Chain

1. The attacker gains unauthorized access to a Bitbucket account with sufficient privileges to modify project settings.
2. The attacker navigates to the project settings within Bitbucket.
3. The attacker accesses the secret scanning configuration for the project.
4. The attacker adds a new allowlist rule, specifying a pattern or file to be excluded from secret scanning.
5. The attacker commits code containing secrets that match the allowlist rule, effectively bypassing the secret scanning tool.
6. The changes are pushed to the Bitbucket repository.
7. The secrets remain undetected due to the allowlist rule.
8. The attacker leverages the exposed secrets for further malicious activities, such as gaining access to other systems or data.

Impact

Successful exploitation could lead to the exposure of sensitive information such as API keys, passwords, or other credentials. This can result in unauthorized access to internal systems, data breaches, and reputational damage. The number of affected projects depends on the scope of the attacker’s access and the configuration of the allowlist rule. The addition of the allowlist rule itself does not directly cause damage but creates a window of opportunity for the introduction and persistence of secrets within the codebase.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect the addition of secret scanning allowlist rules (logsource: bitbucket, service: audit).
• Investigate any detected instances of allowlist rule additions to verify their legitimacy and business justification.
• Review and enforce strict access controls for Bitbucket projects to minimize the risk of unauthorized modifications.
• Enable “Basic” log level in Bitbucket to ensure that the audit events required for detection are captured, as indicated in the rule definition.

Attack Chain

1. Initial Compromise: An attacker gains initial access to a host within the network through methods such as phishing, exploiting a vulnerability, or credential theft.
2. Establish Foothold: The attacker establishes a foothold on the compromised system, potentially installing tools for reconnaissance and lateral movement.
3. Internal Reconnaissance: The attacker performs internal reconnaissance to identify potential target systems accessible via RDP.
4. RDP Connection Attempts: The attacker initiates RDP connections to a large number of internal IP addresses from the compromised host.
5. Credential Harvesting: The attacker attempts to harvest credentials from the targeted systems to gain further access.
6. Lateral Movement: The attacker successfully connects to additional systems using RDP, leveraging harvested or stolen credentials.
7. Privilege Escalation: On newly accessed systems, the attacker attempts to escalate privileges to gain administrative control.
8. Objective Completion: With broader access and elevated privileges, the attacker achieves their objective, which may include data exfiltration, ransomware deployment, or disruption of services.

Impact

If successful, this lateral movement can result in widespread compromise across the targeted network. A single compromised host can serve as a launching point to access sensitive data, critical systems, and ultimately, inflict significant damage. The “Spike in Number of Connections Made from a Source IP” rule aims to detect these lateral movement attempts early, minimizing potential damage. The impact of a successful attack could range from data breaches and financial losses to operational disruption and reputational damage, affecting organizations across various sectors.

Recommendation

• Enable host IP collection if using Elastic Defend (versions 8.18 and above), by following the configuration steps outlined in the Elastic documentation to ensure the host.ip field is populated.
• Install the Lateral Movement Detection integration assets as described in the official Elastic documentation.
• Review and tune the false positive analysis steps within the detection rule’s documentation. Whitelist known administrative IPs or legitimate RDP usage patterns to minimize noise.
• Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface as recommended in the rule’s response and remediation guidance.

Attack Chain

1. Attacker gains initial access to the target system through unspecified means.
2. Attacker creates a malicious DLL to be used as a Netsh Helper DLL.
3. Attacker modifies the Windows Registry to add the malicious DLL as a Netsh Helper DLL under HKLM\Software\Microsoft\netsh\.
4. The system administrator or a scheduled task executes netsh.exe.
5. netsh.exe loads and executes the malicious DLL, granting the attacker code execution.
6. The malicious DLL performs its intended actions, such as establishing a reverse shell or deploying additional malware.
7. The attacker maintains persistence on the system through the malicious Netsh Helper DLL.

Impact

Successful exploitation allows attackers to establish persistent access to a compromised system. This can lead to data theft, system compromise, and further malicious activities. While the risk score is low, the persistence mechanism can allow attackers to maintain a foothold for extended periods, increasing the potential for significant damage.

Recommendation

• Monitor registry modifications under the HKLM\Software\Microsoft\netsh\ path for suspicious DLL additions using the “Netsh Helper DLL Registry Modification” Sigma rule.
• Enable Sysmon registry event logging to collect the necessary data for the Sigma rule.
• Investigate any alerts generated by the Sigma rule by reviewing the DLL file properties, timestamps, and related processes.

Attack Chain

1. An attacker gains initial access to a GitHub account, potentially through compromised credentials or phishing (T1078.004).
2. The attacker authenticates to the GitHub organization or repository.
3. The attacker navigates to the settings for the organization, environment, codespaces, or repository.
4. The attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.
5. The secret is stored within GitHub’s infrastructure, accessible to GitHub Actions workflows.
6. The attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.
7. The workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.
8. The attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, code injection, and supply chain compromise. The impact ranges from low, in cases where the secret is used for benign purposes, to critical if the secret is used to deploy malicious code into production environments. While the number of affected organizations is unknown, the potential for widespread impact across the software supply chain makes this a critical area for monitoring.

Recommendation

• Enable GitHub audit log streaming to capture the events necessary for this detection (see logsource definition).
• Deploy the Sigma rule Github New Secret Created to your SIEM and tune for your environment.
• Investigate any alerts generated by the Sigma rule, focusing on the “actor” involved in creating the secret.

Attack Chain

1. An attacker gains initial access to a Windows system through unspecified means.
2. The attacker leverages msxsl.exe to execute a malicious script.
3. Msxsl.exe initiates a network connection to an external IP address.
4. The script downloads a malicious payload from the external server.
5. The downloaded payload is executed on the compromised system.
6. The attacker establishes a command and control channel through the network connection.
7. The attacker performs data exfiltration via the established C2 channel.

Impact

Compromised systems can be used for further malicious activities, including data theft, lateral movement, and deployment of additional malware. Successful exploitation can lead to sensitive data exfiltration, disruption of services, or complete system compromise. The low risk score does not represent impact, but instead reflects that the behavior is not always malicious, and may be a feature of normal software operation.

Recommendation

• Enable Sysmon network connection logging to monitor msxsl.exe network activity.
• Deploy the Sigma rule “Network Connection via MsXsl” to your SIEM and tune for your environment to detect suspicious network connections originating from msxsl.exe.
• Investigate any alerts generated by the Sigma rule, focusing on the destination IP address and the parent process of msxsl.exe.
• Whitelist legitimate uses of msxsl.exe in your environment based on known good processes or applications to reduce false positives.

Attack Chain

1. An attacker identifies a service running with an unquoted path, such as “C:\Program Files\Unquoted Path Service\Common\Service.exe”.
2. The attacker places a malicious executable named “Program.exe” in “C:"
3. The operating system attempts to start the service “C:\Program Files\Unquoted Path Service\Common\Service.exe”.
4. Due to the unquoted path, the OS incorrectly parses the path and first attempts to execute “C:\Program.exe”.
5. The malicious “Program.exe” executes with the privileges of the service account.
6. The malicious executable performs actions to escalate privileges, such as adding a user to the local administrators group.
7. The attacker gains elevated access to the system.

Impact

Successful exploitation of an unquoted service path vulnerability can lead to complete system compromise, as the attacker gains the privileges of the service account. This can allow the attacker to install programs, view, change, or delete data, or create new accounts with full user rights. The impact is high, potentially leading to a loss of confidentiality, integrity, and availability of the affected system.

Recommendation

• Review process executable paths to confirm if they match the patterns specified in the rule query, such as “?:\Program.exe” or executables within “C:\Program Files (x86)\” or “C:\Program Files\”.
• Deploy the Sigma rule “Potential Exploitation of an Unquoted Service Path Vulnerability” to your SIEM and tune for your environment.
• Enable Sysmon process-creation logging with Event ID 1 to activate the Sigma rules above.
• Conduct a thorough review of service configurations to identify and correct any unquoted service paths as part of remediation steps.

Attack Chain

1. An attacker gains initial access to a system, often through phishing or exploiting a vulnerability.
2. The attacker establishes a foothold and escalates privileges to make necessary registry modifications.
3. The attacker modifies the HKCU\Software\Microsoft\Office Test\Special\Perf registry key, adding a new entry or modifying an existing one to point to a malicious DLL.
4. The attacker ensures the malicious DLL is present on the system, either by dropping it directly or using existing system tools to download it.
5. A user launches a Microsoft Office application (e.g., Word, Excel, PowerPoint).
6. The Office application loads the DLL specified in the “Office Test” registry key during startup.
7. The malicious DLL executes its payload, which could include establishing a reverse shell, installing malware, or exfiltrating data.
8. The attacker maintains persistence, allowing them to regain access to the system each time an Office application is started.

Impact

Successful exploitation allows attackers to maintain persistent access to a compromised system. The injected DLL can be used to execute arbitrary code, potentially leading to data theft, malware installation, or further compromise of the network. The relatively low risk score suggests a common technique, but the potential for persistent access makes it a significant threat.

Recommendation

• Deploy the provided Sigma rule to your SIEM and tune for your environment to detect unauthorized modifications to the “Office Test” registry key (HKCU\Software\Microsoft\Office Test\Special\Perf\*).
• Enable Sysmon Registry event logging to capture registry modifications and activate the Sigma rule above.
• Monitor process execution logs for Office applications to detect if a suspicious DLL has been loaded or executed, as described in the investigation guide.
• Implement enhanced monitoring and alerting for similar registry modifications across the network, as described in the remediation steps.

Attack Chain

1. The attacker gains initial access to a Windows system through methods such as phishing, exploiting vulnerabilities, or using stolen credentials.
2. The attacker executes gpresult.exe from the command line or through a script.
3. The attacker uses command-line arguments such as /z, /v, /r, or /x to request detailed information about Group Policy settings.
4. gpresult.exe queries the Active Directory domain to retrieve GPO information applicable to the user or computer.
5. The attacker parses the output of gpresult.exe to identify security policies, user rights assignments, and other relevant configurations.
6. The attacker identifies potential weaknesses in the GPO configuration, such as overly permissive user rights or insecure password policies.
7. The attacker uses the gathered information to exploit identified weaknesses and escalate privileges or move laterally to other systems within the network.
8. The attacker achieves their objective, such as data exfiltration, system compromise, or deployment of ransomware.

Impact

Successful exploitation can lead to a comprehensive understanding of the target environment’s security posture, enabling attackers to identify and exploit weaknesses for privilege escalation and lateral movement. While the source does not specify a number of victims or sectors targeted, the impact of a successful attack can range from data breaches and financial losses to reputational damage and disruption of operations. The discovery of misconfigured group policies can open doors for attackers to compromise critical systems and data within the network.

Recommendation

• Deploy the Sigma rule “Group Policy Discovery via GPResult” to your SIEM to detect the execution of gpresult.exe with suspicious parameters.
• Enable Windows process creation logging to capture command-line arguments used with gpresult.exe and other executables.
• Review and harden Group Policy configurations to minimize the risk of exploitation by attackers.
• Investigate any alerts generated by the Sigma rule “Group Policy Discovery via GPResult” to determine the context and intent of the activity.

Attack Chain

1. The user’s system is compromised, potentially through social engineering or existing malware.
2. The attacker gains access to the system and attempts to install a malicious browser extension.
3. The attacker drops the extension file (.xpi for Firefox, .crx for Chromium) into the appropriate browser extension directory (e.g., C:\\Users\\*\\AppData\\Roaming\\*\\Profiles\\*\\Extensions\\ for Firefox or C:\\Users\\*\\AppData\\Local\\*\\*\\User Data\\Webstore Downloads\\ for Chromium).
4. A file creation event is triggered as the extension file is created in the target directory.
5. The detection rule identifies this file creation event based on the file name and path, filtering out known safe processes like firefox.exe.
6. The malicious extension installs itself into the browser.
7. The extension gains persistence by loading every time the browser starts.
8. The attacker can now perform malicious actions such as monitoring browsing activity, stealing credentials, or injecting malicious content into web pages.

Impact

A successful attack using malicious browser extensions can lead to persistent access to the compromised system, allowing attackers to steal sensitive information such as credentials, financial data, or personal information. This can result in financial loss, identity theft, and reputational damage. The installation of malicious extensions can also lead to the injection of malicious content into web pages, redirecting users to phishing sites or distributing malware. The scope of the impact can range from individual users to entire organizations, depending on the extent of the compromise.

Recommendation

• Enable Sysmon Event ID 11 (File Create) logging to capture the necessary file creation events for this detection.
• Deploy the provided Sigma rule Browser Extension Install via File Creation to your SIEM and tune the exclusions for your specific environment.
• Review and update the list of known safe processes and extensions in the Sigma rule Browser Extension Install via File Creation to minimize false positives.
• Implement application whitelisting policies to restrict the installation of unauthorized browser extensions.
• Educate users on the risks associated with installing browser extensions from untrusted sources and encourage them to only install extensions from official browser stores.
• Implement policies to regularly review installed browser extensions across the organization.

Attack Chain

1. An attacker gains initial access to a system within the network, possibly through phishing or exploiting a public-facing application.
2. The attacker leverages valid credentials or exploits a vulnerability to establish an RDP connection to a target system.
3. The RDP session is maintained for an extended period, significantly longer than typical RDP sessions within the environment.
4. During the prolonged RDP session, the attacker performs reconnaissance, gathering information about the network and target systems.
5. The attacker moves laterally to other systems within the network, using the established RDP session as a persistent access point.
6. The attacker executes malicious commands or transfers files, potentially installing malware or exfiltrating sensitive data.
7. The unusually long RDP session duration helps the attacker to remain undetected and evade security measures.
8. The attacker achieves their final objective, such as data theft, system compromise, or ransomware deployment.

Impact

Successful exploitation and undetected lateral movement via prolonged RDP sessions can lead to significant data breaches, system compromise, and financial loss. The impact includes potential theft of sensitive information, disruption of business operations, and reputational damage. If an adversary establishes a persistent foothold via RDP, they can maintain long-term access to the compromised environment.

Recommendation

• Ensure host.ip field is populated by enabling host IP collection if using Elastic Defend versions 8.18 and above, as described in the helper guide.
• Install and configure the Lateral Movement Detection integration in Kibana as described in the setup guide.
• Tune the machine learning job lmd_high_mean_rdp_session_duration_ea by adjusting the anomaly_threshold based on your environment and RDP usage patterns.
• Investigate triggered alerts from the “High Mean of RDP Session Duration” rule following the triage and analysis guide.
• Monitor Windows RDP process events collected by the Elastic Defend integration for suspicious activity.

Attack Chain

1. Initial Access (T1078): An attacker gains initial access using valid accounts, potentially through compromised credentials or other means.
2. Discovery (T1069): The attacker performs permission group discovery to identify potential target groups for privilege escalation.
3. Account Manipulation (T1098): The attacker attempts to add the compromised account to a privileged group.
4. Registry Modification: The attacker modifies the registry settings to enable the newly acquired privileges.
5. Privilege Escalation (T1068): The attacker exploits vulnerabilities or misconfigurations to escalate their privileges further.
6. Persistence (T1098): The attacker attempts to maintain elevated privileges by adding the compromised account to additional local or domain groups (T1098.007).
7. Lateral Movement: With elevated privileges, the attacker moves laterally within the network, accessing sensitive resources.
8. Data Exfiltration or System Damage: The attacker achieves their final objective, which may include data exfiltration, ransomware deployment, or other forms of system damage.

Impact

Compromise resulting from this type of attack can lead to unauthorized access to sensitive data, system instability, and potentially significant financial losses. While the source does not specify the number of victims or specific sectors targeted, privilege escalation is a common tactic used in a wide range of attacks, making this a broadly applicable threat. A successful privilege escalation could allow the attacker to gain complete control over the targeted system and potentially the entire network.

Recommendation

• Ensure that the Privileged Access Detection integration is installed and configured correctly in Elastic Security, including the pad_windows_rare_group_name_by_user_ea machine learning job, as referenced in the machine_learning_job_id field.
• Enable Windows event collection via Elastic Defend or the Windows integration within Fleet, as detailed in the Setup section.
• Deploy the Sigma rule provided below to detect attempts to add accounts to privileged groups and tune the rule based on your environment.
• Review and update access control policies to ensure that only authorized users have access to sensitive group names and privileged operations, as mentioned in the Response and Remediation section.
• Implement multi-factor authentication (MFA) for accessing sensitive group names to prevent unauthorized access, as recommended in the Response and Remediation section.

Attack Chain

1. An attacker gains initial access to a system within the network.
2. The attacker leverages valid credentials or exploits an RDP vulnerability to establish a remote session (T1021.001).
3. Once connected via RDP, the attacker begins to execute a series of commands to enumerate the system and network.
4. The attacker attempts to install malware or other malicious tools, triggering the creation of multiple processes.
5. The machine learning job detects a significant increase in the number of processes started within the RDP session.
6. The detection rule triggers, alerting analysts to the anomalous activity.
7. The attacker uses the newly installed tools to move laterally to other systems on the network.
8. The attacker achieves their objective, such as data exfiltration or ransomware deployment.

Impact

A successful lateral movement attack can lead to significant damage, including data breaches, system compromise, and financial loss. While the severity is low, a spike in RDP processes can be an early indicator of compromise. Attackers often use RDP to propagate through a network after gaining initial access, making this detection critical for preventing widespread damage.

Recommendation

• Enable host IP collection by following the configuration steps in the Elastic Defend documentation to ensure the host.ip field is populated.
• Install the Lateral Movement Detection integration assets as described in the rule’s setup instructions to enable the machine learning job lmd_high_sum_rdp_number_of_processes_ea.
• Review and tune the anomaly threshold to reduce false positives based on your organization’s typical RDP usage.
• Investigate RDP sessions flagged by this rule to identify the source of the process spike and potential malicious activity as described in the rule’s “Triage and Analysis” notes.

Attack Chain

1. An attacker gains initial access to the target system, potentially through phishing or exploiting a software vulnerability.
2. The attacker elevates privileges to obtain the necessary permissions to modify the registry.
3. The attacker modifies the HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware registry key to disable Windows Defender, setting its value to “1” or “0x00000001”.
4. Alternatively, the attacker modifies the HKLM\\System\\*ControlSet*\\Services\\WinDefend\\Start registry key to prevent the Windows Defender service from starting automatically. The attacker sets the value to “3” or “4” (or their hexadecimal equivalents “0x00000003”, “0x00000004”).
5. The attacker verifies that Windows Defender is disabled by checking the Security Center or attempting to run a scan.
6. With Windows Defender disabled, the attacker proceeds to deploy malware or execute malicious commands without interference from the antivirus software.
7. The attacker may further disable security settings and block security-related indicators.

Impact

If successful, this attack can lead to a complete compromise of the affected system. With Windows Defender disabled, the system becomes vulnerable to malware infections, data exfiltration, and other malicious activities. This can result in financial losses, data breaches, and reputational damage for the targeted organization. The lack of immediate detection allows attackers to establish persistence and expand their foothold within the network.

Recommendation

• Deploy the Sigma rule “Registry Modification to Disable Windows Defender” to your SIEM and tune for your environment to detect unauthorized changes to Windows Defender registry settings.
• Monitor registry events for changes to the HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware and HKLM\\System\\*ControlSet*\\Services\\WinDefend\\Start registry keys using the provided log sources.
• Investigate any alerts generated by the Sigma rule, focusing on identifying the process and user account responsible for the registry modifications.
• Enable Sysmon registry event logging to capture the necessary data for the Sigma rule to function effectively.

Attack Chain

1. Attacker gains initial access via unspecified means (e.g., phishing, compromised credentials).
2. Attacker leverages a legitimate system binary (LOLbin) such as powershell.exe or cmd.exe.
3. The LOLbin is used to execute a malicious payload or script.
4. The malicious process is spawned as a child process of the LOLbin.
5. Elastic’s machine learning model identifies the child process as rare and potentially malicious based on its parent-child relationship and other features.
6. The rare process executes malicious commands, possibly downloading further payloads.
7. The attacker achieves their objective, such as data exfiltration or lateral movement.

Impact

A successful attack utilizing LOLbins can lead to significant compromise, including data theft, system disruption, and further propagation within the network. The reliance on trusted system binaries makes these attacks difficult to detect with traditional methods, potentially allowing attackers to operate undetected for extended periods. The impact is directly correlated to the privileges of the initial compromised account and the effectiveness of lateral movement techniques employed by the attacker.

Recommendation

• Ensure that the Living off the Land (LotL) Attack Detection integration is installed and configured correctly, along with either Elastic Defend or Winlogbeat, as described in the rule’s setup section.
• Review the parent and child process names identified in the alert to determine if they are legitimate applications or associated with LOLbins, as detailed in the investigation guide within the rule’s note section.
• Investigate the command-line arguments used by the suspicious process for potentially malicious commands or scripts as described in the rule note section.
• Tune the anomaly_threshold setting in the machine learning job configuration based on your environment’s baseline activity to reduce false positives, as described in the rule documentation.
• Implement exceptions for legitimate administrative tools and software updates to reduce false positives, as mentioned in the rule’s note section.

Attack Chain

1. An attacker gains initial access to an Okta administrator account, potentially through phishing, credential stuffing, or exploiting a vulnerability.
2. The attacker authenticates to the Okta admin portal.
3. The attacker navigates to the user management section within the Okta admin console.
4. The attacker creates a new user account, potentially mimicking an existing user or using a generic naming convention.
5. The attacker assigns the new user account specific roles and permissions, potentially granting elevated privileges.
6. The attacker may use the newly created account to access sensitive applications and data within the Okta-protected environment.
7. The attacker uses the compromised or newly created account to maintain persistence within the Okta environment.

Impact

A successful attack leading to unauthorized user creation can result in significant data breaches, privilege escalation, and unauthorized access to sensitive applications and resources. This could lead to financial loss, reputational damage, and compliance violations. The impact depends on the permissions granted to the created user and the applications they can access.

Recommendation

• Deploy the Sigma rule “New Okta User Created” to your SIEM to detect user creation events and tune for your environment.
• Investigate any detected user creation events for legitimacy, focusing on the source IP address and the administrator account used.
• Implement multi-factor authentication (MFA) for all Okta administrator accounts to mitigate the risk of credential compromise.
• Review Okta event logs regularly for suspicious activity, including user creation, permission changes, and application access.
• Establish baseline user creation patterns to identify anomalous behavior, such as accounts created outside of normal business hours.

Attack Chain

1. The attacker gains initial access to a system within the network (e.g., via phishing or exploitation of a vulnerability).
2. The attacker identifies a target host for lateral movement.
3. The attacker uses a remote service (e.g., RDP, SMB) to connect to the target host.
4. The attacker attempts to transfer malicious files to the target host.
5. Instead of using common directories like “C:\Windows\Temp” or “C:\ProgramData”, the attacker chooses a less monitored directory to evade detection.
6. The remote service is leveraged to perform the file transfer to the atypical directory.
7. The transferred file is then executed, potentially leading to command execution or privilege escalation.
8. The attacker achieves their objective (e.g., data exfiltration, ransomware deployment) on the target host.

Impact

A successful attack can lead to unauthorized access to sensitive data, compromise of critical systems, and potential disruption of business operations. Although this detection is rated as low severity, successful lateral movement can lead to significant damage. The number of affected hosts and the severity of the impact depends on the attacker’s objectives and the organization’s security posture. Lateral movement allows attackers to gain a deeper foothold within the network and increase the scope of their malicious activities.

Recommendation

• Ensure the host.ip field is populated in Elastic Defend events by following the configuration steps in the Elastic documentation.
• Install the Lateral Movement Detection integration assets as described in the setup instructions.
• Tune the anomaly_threshold in the machine learning job configuration based on your environment’s baseline activity to minimize false positives, as mentioned in the rule’s configuration.
• Investigate any alerts generated by this rule, paying close attention to the source and destination IP addresses, the user account involved, and the specific directory used for the file transfer as outlined in the triage and analysis section.

Attack Chain

1. An attacker gains initial access to a compromised host within the target environment.
2. The attacker executes nltest.exe with specific arguments such as /DOMAIN_TRUSTS, /DCLIST:*, /DCNAME:*, /DSGET*, /LSAQUERYFTI:*, /PARENTDOMAIN, or /BDC_QUERY:* to enumerate domain trusts.
3. The nltest.exe utility queries the Active Directory to gather information about domain trusts, domain controllers, and other domain-related information.
4. The attacker parses the output of nltest.exe to identify trust relationships, domain controllers, and other relevant information about the domain infrastructure.
5. The attacker uses the gathered information to map out potential lateral movement paths within the environment.
6. The attacker leverages discovered trust relationships to authenticate to other domains or resources.
7. The attacker moves laterally to other systems or domains, leveraging the discovered trust relationships and compromised credentials.
8. The attacker establishes persistence and continues to perform malicious activities, such as data exfiltration or ransomware deployment.

Impact

Successful enumeration of domain trusts via nltest.exe can provide attackers with valuable information to facilitate lateral movement and escalate privileges within a Windows NT Domain. This can lead to the compromise of sensitive data, disruption of critical services, and ultimately, a complete takeover of the affected environment. While the specific number of victims and sectors targeted are unknown, the impact can be significant for organizations relying on Active Directory for authentication and authorization.

Recommendation

• Monitor process execution for nltest.exe with command-line arguments indicative of domain trust discovery, using the provided Sigma rule.
• Investigate any instances of nltest.exe execution, especially when initiated by non-administrative users or from unusual locations, as identified by the Sigma rule.
• Enable Sysmon process creation logging to capture the necessary process execution data for the provided Sigma rule.
• Review and restrict the use of nltest.exe to authorized personnel only.

Attack Chain

1. Initial access is gained via exploitation of a vulnerability in a web application or web server component running on a Linux system (e.g., through SQL injection or remote code execution).
2. A web shell is uploaded to the compromised web server, often disguised as a legitimate file or hidden within existing directories.
3. The attacker interacts with the web shell through HTTP requests, using it as a command and control interface.
4. The web shell executes commands on the server, initiating outbound network connections to non-standard ports.
5. These connections may be used to communicate with external C2 servers, download additional payloads, or exfiltrate sensitive data.
6. The attacker uses the web shell to move laterally within the network, targeting other systems and services.
7. The attacker attempts to establish persistence on the compromised server, ensuring continued access even after system reboots.
8. The final objective is data theft, system compromise, or disruption of services.

Impact

Compromised web servers can lead to significant data breaches, system downtime, and reputational damage. While this rule triggers on low-severity behavior, successful exploitation can lead to complete system compromise. The number of affected systems depends on the scope of the initial vulnerability and the attacker’s ability to move laterally. Organizations in all sectors that rely on web-based applications are potentially at risk.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect web server processes initiating connections to unusual destination ports and tune for your environment.
• Enable Elastic Defend integration to collect the necessary network event data from Linux endpoints to activate the rule.
• Review and customize the list of excluded destination ports and internal IP ranges in the Sigma rule to match your organization’s specific network configuration and legitimate traffic patterns.
• Investigate any alerts generated by the rule to determine if the activity is malicious or benign, focusing on the process name, user, destination IP, and destination port.

Attack Chain

1. The attacker compromises a host within the network, potentially through unpatched vulnerabilities or social engineering.
2. Malware is deployed on the compromised host. This malware contains a DGA.
3. The malware uses the DGA to generate a list of potential domain names.
4. The compromised host initiates DNS requests to resolve the generated domain names.
5. The DNS requests are sent to internal or external DNS servers.
6. The machine learning job dga_high_sum_probability_ea analyzes the DNS requests, specifically looking for source IPs with a high aggregate probability of generating DGA domains.
7. If the anomaly score exceeds the threshold (70), an alert is triggered.
8. The malware successfully establishes a C2 channel with a dynamically generated domain, enabling further malicious activities such as data exfiltration or lateral movement.

Impact

The successful exploitation of DGA-based command and control can lead to persistent malware infections, data exfiltration, and further compromise of systems within the network. While the severity is rated low, the potential impact can escalate quickly if the C2 channel is used for more damaging activities. This detection focuses on identifying potential DGA activity, enabling security teams to investigate and prevent further damage.

Recommendation

• Ensure the DGA Detection integration is installed and properly configured, including the machine learning job dga_high_sum_probability_ea (references: Elastic DGA Detection documentation, prebuilt ML jobs).
• Verify that DNS events are being collected by Elastic Defend, Network Packet Capture, or Packetbeat and that the data view used by the machine learning job includes these events (references: Elastic Defend, Network Packet Capture, Packetbeat).
• Tune the anomaly threshold (currently 70) in the machine learning job based on your environment to reduce false positives and ensure timely detection of DGA activity.
• Review and implement the triage and analysis steps outlined in the rule’s note section, focusing on identifying the source IP, analyzing DNS request patterns, and cross-referencing domains with threat intelligence feeds.

Attack Chain

1. An attacker gains initial access to a system, potentially through exploiting a vulnerability in a web application or through phishing.
2. The attacker escalates privileges to the SYSTEM account, possibly by exploiting a local privilege escalation vulnerability.
3. The attacker executes whoami.exe or net1.exe via the SYSTEM account to enumerate user accounts and gather system information.
4. The whoami.exe or net1.exe process is spawned by a parent process such as a web server process (e.g., w3wp.exe) or a service process.
5. The attacker uses the discovered account information to plan further actions, such as lateral movement or credential theft.
6. The attacker may use net1.exe to query domain information.
7. The attacker leverages the gained information to identify valuable targets within the network.
8. The final objective is often data exfiltration, deployment of ransomware, or further compromise of the network.

Impact

A successful attack can lead to unauthorized access to sensitive data, lateral movement within the network, and potential data exfiltration or ransomware deployment. Although this rule has low severity, the execution of discovery commands by the SYSTEM account can be a critical indicator of compromise. Early detection of such activity can prevent more severe damage.

Recommendation

• Deploy the provided Sigma rules to detect account discovery commands executed via the SYSTEM account and tune for your environment.
• Enable Sysmon process creation logging (Event ID 1) to ensure the necessary data is available for detection.
• Investigate any alerts generated by these rules, focusing on the process execution chain to identify the source of the SYSTEM account usage.
• If the process tree includes a web-application server process, investigate suspicious file creation or modification to assess for webshell backdoors.
• Review and harden web application security to prevent initial access and privilege escalation.

Attack Chain

1. Initial Compromise: An attacker gains initial access to a user account, possibly through credential theft or phishing (not directly observed, but a common precursor).
2. Account Enumeration: The attacker enumerates existing groups and their memberships within the Okta environment.
3. Group Manipulation: The attacker initiates unauthorized group lifecycle changes, such as adding or removing members, to escalate privileges.
4. Privilege Escalation: By adding their compromised account to a privileged group (e.g., Okta administrators, application owners), the attacker gains elevated access.
5. Lateral Movement: The attacker leverages their newly acquired privileges to access other systems or applications within the organization’s network.
6. Persistence: The attacker modifies group memberships to maintain persistent access even if their initial access is revoked (T1098.007).
7. Data Access/Exfiltration: The attacker accesses sensitive data or resources that were previously inaccessible due to insufficient privileges.

Impact

A successful attack can lead to unauthorized access to sensitive data, compromise of critical systems, and disruption of business operations. The number of victims and the scope of the impact depend on the level of access achieved by the attacker and the sensitivity of the compromised data. While the alert is low severity, the potential consequences of privilege escalation are significant, requiring prompt investigation and remediation.

Recommendation

• Investigate triggered alerts by reviewing the specific group lifecycle change events that triggered the alert in Okta logs to identify which groups were altered and the nature of the changes.
• Examine the user accounts associated with the changes to determine if they have a history of suspicious activity or if they have recently been granted elevated privileges using the provided investigation steps.
• Tune the machine learning job anomaly threshold anomaly_threshold in the rule configuration to reduce false positives based on your environment’s baseline.

Attack Chain

1. Adversary gains initial access to a valid user account through phishing, credential stuffing, or other means (T1078, T1078.004).
2. The adversary leverages the compromised account to authenticate to Okta, potentially bypassing or circumventing MFA.
3. The adversary attempts to perform privileged operations within Okta, such as modifying user permissions, accessing sensitive applications, or changing security settings.
4. Okta logs record the privileged operation attempt, including the source IP address of the request.
5. The machine learning job analyzes the source IP address and compares it to the user’s historical access patterns.
6. If the source IP address is determined to be unusual or rare for the user, the machine learning job generates an anomaly.
7. The “Unusual Source IP for Okta Privileged Operations Detected” rule triggers based on the anomaly score exceeding a predefined threshold (anomaly_threshold = 75).
8. The alert triggers, potentially leading to account takeover, data exfiltration, or further privilege escalation.

Impact

A successful attack can lead to unauthorized access to sensitive applications and data managed by Okta. This can result in data breaches, financial loss, reputational damage, and legal liabilities. Since Okta is a widely used identity management service, a compromise can impact numerous downstream applications and services that rely on Okta for authentication and authorization. The number of affected users and systems can vary depending on the scope of the privileged access and the attacker’s objectives.

Recommendation

• Install the Privileged Access Detection integration assets, as well as Okta logs collected by integrations such as Okta, as described in the “Setup” section of the rule to enable the machine learning job.
• Review the source IP address flagged by the alert to determine its geolocation and assess if it aligns with the user’s typical access patterns or known locations, as described in the rule’s “Triage and analysis” section.
• Tune the anomaly_threshold parameter in the machine learning job based on your environment to reduce false positives.
• Correlate the flagged IP address with any known threat intelligence feeds to check for any history of malicious activity associated with it, as described in the rule’s “Triage and analysis” section.

Attack Chain

1. A user receives a malicious PDF document via phishing or other means.
2. The user opens the PDF document using a vulnerable PDF reader application (e.g., Adobe Acrobat, Foxit Reader).
3. The PDF document exploits a vulnerability or uses a malicious script to execute an arbitrary command.
4. The PDF reader application spawns a command-line interpreter (e.g., cmd.exe, powershell.exe) or a system administration tool (e.g., reg.exe, net.exe).
5. The spawned process executes commands to gather system information (e.g., ipconfig.exe, systeminfo.exe, whoami.exe).
6. The attacker may attempt to discover network configuration, user accounts, or running processes.
7. The attacker could leverage the spawned process to download and execute further payloads.
8. The attacker gains a foothold on the system and can proceed with lateral movement, data exfiltration, or other malicious activities.

Impact

Successful exploitation of PDF reader applications can lead to initial access, privilege escalation, and further compromise of the affected system. While individual incidents may have a low risk score, widespread exploitation can lead to significant data breaches, system downtime, and reputational damage. The use of legitimate system utilities for malicious purposes can make detection challenging, allowing attackers to operate undetected for extended periods.

Recommendation

• Enable process creation logging with command line arguments to capture the execution of suspicious child processes (Sysmon Event ID 1, Windows Security Event Logs).
• Deploy the Sigma rule “Suspicious PDF Reader Child Process” to your SIEM and tune for your environment to detect the execution of suspicious processes spawned by PDF reader applications.
• Monitor for network connections originating from PDF reader applications to unusual or external IP addresses.
• Implement application control policies to restrict the execution of unauthorized or unknown executables.

Attack Chain

1. An attacker gains unauthorized access to a GitHub account with repository administration privileges.
2. The attacker authenticates to the GitHub platform using the compromised credentials or a stolen session token.
3. The attacker navigates to the settings page of a target repository.
4. The attacker modifies the repository’s archive status, either archiving or unarchiving it depending on their objective.
5. GitHub logs the ‘repo.archived’ or ‘repo.unarchived’ action in the organization’s audit logs.
6. (If archiving) Legitimate users may lose access to the repository and its code, causing disruption.
7. (If unarchiving) The attacker might reintroduce vulnerable code or malicious content into an active repository.
8. The attacker may then attempt to exploit the unarchived repository for further malicious activities.

Impact

The impact of unauthorized repository archiving or unarchiving can range from temporary disruption of services to the reintroduction of vulnerable code. A successful attack could lead to data breaches, code compromise, or supply chain attacks. The number of affected repositories depends on the scope of the attacker’s access and objectives.

Recommendation

• Deploy the Sigma rule “GitHub Repository Archive Status Changed” to your SIEM and tune for your environment. This rule detects the repo.archived and repo.unarchived actions in GitHub audit logs (logsource: github, service: audit).
• Review GitHub audit logs regularly for unexpected repository archiving or unarchiving events.
• Investigate any detected events to determine if the actions were authorized.

Attack Chain

1. An attacker gains initial access to a system, possibly through compromised credentials or a software vulnerability (not described in source).
2. The attacker leverages RDP to attempt lateral movement to other systems within the network.
3. The RDP session is initiated at an unusual time or day, deviating from typical user behavior.
4. The machine learning job detects this anomaly based on the unusual RDP session start time.
5. An alert is triggered, flagging the potentially suspicious activity.
6. The attacker may attempt to access sensitive data or resources on the target system.
7. The attacker could install malware or establish persistence mechanisms (not described in source).

Impact

A successful lateral movement attack can allow an attacker to gain access to sensitive data, compromise critical systems, and ultimately disrupt business operations. While the detection of an unusual RDP session is an early warning sign, it is critical to investigate these alerts promptly to prevent further escalation. If the suspicious RDP session is part of a broader attack, the impact could range from data theft to ransomware deployment. The lack of immediate action could lead to significant financial and reputational damage.

Recommendation

• Enable host IP collection within Elastic Defend if using versions 8.18 and above, following the configuration steps in the helper guide.
• Ensure the Lateral Movement Detection integration assets are installed, as well as file and Windows RDP process events collected by the Elastic Defend integration, as mentioned in the setup instructions.
• Investigate all alerts generated by the “Unusual Time or Day for an RDP Session” rule, correlating the RDP session with other security events.
• Tune the anomaly threshold (currently 70) to reduce false positives while maintaining effective detection capabilities.

Attack Chain

1. Initial Access: The attacker gains initial access to the Windows host through various methods, such as exploiting vulnerabilities or using compromised credentials (not detailed in source).
2. Execution: The attacker executes a LOLBin (e.g., PowerShell, cmd.exe, mshta.exe) on the compromised host.
3. Masquerading: The attacker attempts to masquerade the malicious activity by naming or placing the LOLBin within a legitimate system folder.
4. Defense Evasion: The attacker utilizes the LOLBin with specific command-line arguments designed to evade detection by traditional signature-based security solutions.
5. Privilege Escalation (Optional): The attacker may attempt to escalate privileges using further LOLBINS or other techniques.
6. Lateral Movement (Optional): The attacker may use the compromised host to move laterally to other systems within the network.
7. Command and Control (Optional): The attacker may establish command and control (C2) communication with an external server to receive further instructions.
8. Impact: The attacker achieves their objective, such as data exfiltration, ransomware deployment, or system disruption.

Impact

A successful attack can lead to various negative impacts, including data breaches, financial loss, and reputational damage. The rule is assigned a low severity, due to it likely being a supplemental detection to other rules. Lateral movement and exfiltration can also be accomplished. There is no information available on the number of victims and specific sectors targeted.

Recommendation

• Ensure the Living off the Land (LotL) Attack Detection integration is installed and configured correctly, along with either Elastic Defend or Winlogbeat, to collect Windows process events as outlined in the setup instructions.
• Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts as suggested in the investigation guide.
• Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading, per the investigation guide.
• Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future, as advised in the remediation steps.
• Tune the anomaly threshold of the machine learning job (problem_child_high_sum_by_host_ea) to reduce false positives based on your environment’s specific characteristics and activity patterns.

Attack Chain

1. The attacker gains initial access to a Windows system.
2. The attacker executes net.exe with arguments to list users and groups.
3. The attacker filters the output for administrator-related keywords like “admin”, “Domain Admins”, “Enterprise Admins”, “Remote Desktop Users”, or “Organization Management”.
4. Alternatively, the attacker executes wmic.exe to query user accounts.
5. The attacker parses the output from wmic.exe to identify administrator accounts.
6. The attacker identifies privileged accounts to target for credential theft or privilege escalation.
7. The attacker uses the identified accounts to perform lateral movement or access sensitive data.

Impact

Successful enumeration of administrator accounts allows an attacker to identify high-value targets within the environment. This can lead to credential theft, privilege escalation, lateral movement, and ultimately, unauthorized access to sensitive data or systems. While the risk score is low, this activity serves as a precursor to more serious compromises.

Recommendation

• Monitor process creation events for net.exe and wmic.exe commands with arguments related to user and group enumeration using the Sigma rules provided.
• Investigate any instances of lower-privileged accounts executing these commands and filter out authorized administrative accounts performing the same actions.
• Enable Windows process creation logging to capture the necessary events.
• Deploy the Sigma rules in this brief to your SIEM and tune for your environment.

Attack Chain

1. Attacker gains initial access to a macOS system within the target network.
2. Attacker identifies sensitive data stored on the compromised system.
3. Attacker uses Airdrop to initiate a transfer of the identified data to a nearby device.
4. The receiving device is controlled by the attacker and configured to accept Airdrop transfers.
5. A large volume of data is transferred via Airdrop, triggering the machine learning detection.
6. The data is received by the attacker, completing the exfiltration process.
7. The attacker may attempt to cover their tracks by deleting files or logs related to the Airdrop transfer.

Impact

Successful exploitation can lead to the unauthorized disclosure of sensitive data. The impact depends on the nature of the exfiltrated data, potentially leading to financial loss, reputational damage, or legal repercussions. The severity is relatively low as it depends on the data being transferred.

Recommendation

• Install the Data Exfiltration Detection integration in Elastic, including the preconfigured anomaly detection jobs, as required by the rule setup instructions to enable the machine learning detection (Data Exfiltration Detection integration).
• Investigate alerts generated by the “Spike in Bytes Sent to an External Device via Airdrop” rule, focusing on identifying the involved device, user, and the nature of the transferred data (Spike in Bytes Sent to an External Device via Airdrop).
• Implement additional monitoring on the affected device and similar devices to detect any further anomalous Airdrop activities, as mentioned in the response and remediation steps (Spike in Bytes Sent to an External Device via Airdrop).

Attack Chain

1. An attacker gains initial access to a Linux system, potentially through a compromised account or vulnerability exploitation.
2. The attacker identifies privileged commands they need to execute to achieve their objectives, such as gaining root access or modifying sensitive files.
3. To evade detection, the attacker obfuscates their commands using techniques like encoding, compression, or complex string manipulation.
4. The attacker executes the obfuscated privileged commands via the command line.
5. Elastic Defend or Sysmon Linux captures the command-line activity and logs it to Elasticsearch.
6. The Privileged Access Detection ML job analyzes the command lines and calculates their entropy.
7. If the entropy exceeds a predefined threshold, the ML job flags the activity as anomalous and generates an alert.
8. Security analysts investigate the alert to determine the nature of the suspicious activity and take appropriate action.

Impact

A successful privilege escalation can grant an attacker complete control over a Linux system, allowing them to steal sensitive data, install malware, or disrupt critical services. While this rule itself triggers on unusual command line activity, the underlying behavior could lead to a full system compromise. The number of potential victims is directly related to the scope of the Linux environment being monitored. Sectors commonly targeted by privilege escalation attacks include technology, finance, and government.

Recommendation

• Deploy the Privileged Access Detection integration and ensure that Linux logs from Elastic Defend or Sysmon Linux are being ingested (Setup section).
• Review and tune the machine learning job pad_linux_high_median_process_command_line_entropy_by_user_ea to minimize false positives based on your environment (False positive analysis section in rule).
• Create a case management workflow triggered by the “High Command Line Entropy Detected for Privileged Commands” rule to ensure alerts are promptly investigated.
• Implement the remediation steps outlined in the investigation guide to contain and eradicate any confirmed malicious activity (Response and remediation section).

Attack Chain

1. An attacker gains initial access to a system within the network.
2. The attacker attempts to move laterally to other systems using remote services like RDP or SMB.
3. As part of the lateral movement, the attacker transfers tools or files to the remote system.
4. The attacker uses a rare or uncommon file extension for the transferred files, potentially to evade detection based on known file types.
5. The file transfer occurs over the network, triggering file event logs on the source and destination systems.
6. Elastic Defend, with host IP collection enabled, monitors these file events and forwards the data to the Elastic Security platform.
7. The “Unusual Remote File Extension” machine learning job identifies the transfer of a file with a rare extension, comparing it against historical data.
8. If the file extension is deemed anomalous based on its rarity, the rule triggers, indicating potential lateral movement.

Impact

A successful lateral movement attack can allow an adversary to gain access to sensitive data, critical systems, or privileged accounts. By using uncommon file extensions, attackers attempt to bypass security measures that rely on identifying known file types. This can lead to undetected malware deployment, data exfiltration, or further compromise of the network. Though this rule is of low severity, it can provide an early warning signal to stop an attack before greater damage occurs.

Recommendation

• Enable the host.ip field within Elastic Defend configurations (versions 8.18 and above) to ensure proper data collection for the machine learning job.
• Install the Lateral Movement Detection integration assets within Kibana as per the provided setup instructions to activate the “Unusual Remote File Extension” rule.
• Tune the anomaly threshold of the machine learning job to reduce false positives, considering your organization’s typical file transfer patterns.
• Deploy the “Detect Remote File Extension Transfer” Sigma rule to identify file transfers with rare extensions using process creation logs.
• Review the triage and analysis steps in the rule’s documentation to effectively investigate and respond to triggered alerts.

Attack Chain

1. An attacker gains initial access to a Windows system, possibly through valid accounts (T1078).
2. The attacker attempts to escalate privileges to gain higher-level access within the system (TA0004).
3. This privilege escalation involves performing privileged operations or service calls.
4. The attacker may use access token manipulation (T1134) to impersonate legitimate users or processes with elevated privileges.
5. The system records these privileged operations as special privilege use events.
6. The machine learning model detects a significant spike in these events compared to the user’s baseline behavior.
7. The detection triggers an alert, indicating a potential security incident.
8. The attacker leverages elevated privileges to execute unauthorized tasks or maintain persistence (TA0005).

Impact

A successful privilege escalation attack can grant an attacker complete control over a compromised system. The attacker can then access sensitive data, install malware, or move laterally to other systems within the network. While this specific detection has a low severity, a successful attack could lead to significant data breaches, system downtime, and reputational damage.

Recommendation

• Install the Privileged Access Detection integration assets, including the preconfigured anomaly detection jobs, as outlined in the setup guide.
• Enable Windows event collection using Elastic Defend or the Windows integration to provide the necessary data for the machine learning job.
• Review user accounts associated with spikes in special privilege use events, investigating whether the activity aligns with their normal behavior, as described in the investigation guide.
• Escalate incidents with potential privilege escalation techniques to the security operations team for deeper investigation, referencing MITRE ATT&CK technique T1068.

Attack Chain

1. An attacker gains initial access to a system via compromised credentials or exploiting a vulnerability.
2. The attacker uses their access to locate and stage sensitive data for exfiltration.
3. The attacker connects an external storage device, such as a USB drive, to the compromised system.
4. The attacker initiates a large data transfer operation, copying the staged data to the external device.
5. Elastic Defend monitors file events and detects a significant increase in bytes written to the external device.
6. The ded_high_bytes_written_to_external_device_ea machine learning job identifies the unusual data transfer volume.
7. An alert is triggered based on the anomaly threshold defined in the Data Exfiltration Detection rule.
8. The attacker removes the external device, completing the exfiltration of the sensitive data.

Impact

Successful exfiltration of data to external devices can lead to significant data breaches. The impact varies depending on the sensitivity and volume of the data stolen. This activity can result in financial losses, reputational damage, legal repercussions, and compromise of intellectual property. While the specific number of affected organizations is unknown, any organization that allows the use of external storage devices is potentially vulnerable. This issue poses a risk across various sectors, particularly those handling sensitive data, such as finance, healthcare, and technology.

Recommendation

• Install the Data Exfiltration Detection integration and configure the preconfigured anomaly detection jobs as described in the rule’s setup instructions.
• Review and tune the anomaly_threshold (currently set to 75) based on your environment’s baseline data transfer patterns to reduce false positives.
• Deploy endpoint detection and response (EDR) solutions to enhance visibility and control over data movements to external devices as mentioned in the “Response and remediation” section of the rule’s note.
• Create exceptions for known backup operations, software updates, and data archiving processes that may trigger false positives, referencing the “False positive analysis” section of the rule’s note.
• Implement additional monitoring on similar devices and network segments to detect any further anomalous data transfer activities, based on the rule’s description and “Response and remediation” section of the note.

Attack Chain

1. A user on a Windows host unknowingly executes a malicious file (e.g., via phishing or drive-by download).
2. The malicious file executes a process outside of typical program directories (e.g., C:\Windows\Temp).
3. This process initiates a DNS query to a domain associated with a commonly abused web service (e.g., pastebin.com, githubusercontent.com).
4. The DNS query resolves to an IP address, and a network connection is established to the web service.
5. The malicious process uploads or downloads data from the web service, potentially containing commands for the compromised host or exfiltrated data.
6. The web service acts as an intermediary, relaying commands from the attacker to the compromised host or exfiltrated data from the compromised host to the attacker.
7. The attacker uses the C2 channel to perform further actions on the compromised host, such as lateral movement or data theft.

Impact

A successful attack using common web services for C2 can lead to data exfiltration, system compromise, and further propagation within the network. The low severity suggests a focus on detecting early-stage C2 activity, which if left unchecked, could escalate into a significant incident. The usage of popular web services makes detection difficult, requiring careful analysis and tuning to avoid false positives.

Recommendation

• Deploy the Sigma rule “Connection to Commonly Abused Web Services” to your SIEM and tune it for your environment to minimize false positives.
• Enable Sysmon DNS query logging to accurately capture DNS requests for improved detection capabilities, activating the “DNS Query to Commonly Abused Web Services” rule.
• Investigate any alerts generated by this rule, focusing on the process execution chain and network connections to determine the legitimacy of the activity, referencing the investigation steps described in the rule documentation.
• Review and update the list of excluded processes in the Sigma rule to reflect your organization’s approved software and reduce false positives.

Attack Chain

1. An attacker gains unauthorized access to a GitHub organization or repository with permissions to manage self-hosted runners. This could be achieved through compromised credentials (T1078.004) or exploiting a vulnerability.
2. The attacker modifies the configuration of an existing self-hosted runner group or creates a new runner group (org.runner_group_created).
3. The attacker adds or removes runners from a runner group (org.runner_group_runners_added, org.runner_group_runner_removed, org.runner_group_updated).
4. Alternatively, the attacker registers a new self-hosted runner within the environment (repo.register_self_hosted_runner).
5. The attacker removes an existing self-hosted runner from the environment (repo.remove_self_hosted_runner, org.remove_self_hosted_runner).
6. The attacker uses the compromised runner or runner group to execute malicious code within the GitHub Actions workflow, potentially collecting sensitive data or escalating privileges.
7. The attacker leverages the compromised runner to establish persistence within the GitHub environment, ensuring continued access.
8. The attacker exploits the compromised runner to gain initial access to other systems or networks connected to the GitHub environment.

Impact

Compromised self-hosted runners can lead to a range of impacts, including data exfiltration, code injection, and privilege escalation within the targeted GitHub environment. Successful attacks could result in unauthorized access to sensitive repositories, modification of code, or deployment of malicious software. The impact can vary depending on the scope of the compromised runner and the permissions associated with it. The effects could extend beyond the GitHub environment if the compromised runner has access to other systems or networks.

Recommendation

• Enable the audit log streaming feature in GitHub to capture events related to self-hosted runner modifications, as required by the logsource definition.
• Deploy the Sigma rule “Github Self Hosted Runner Changes Detected” to your SIEM and tune for your specific environment to detect suspicious configuration changes.
• Regularly review the audit logs in the GitHub UI to validate any detected changes to self-hosted runners and runner groups to ensure legitimate modifications.
• Implement strict access control policies for managing self-hosted runners, limiting permissions to only authorized personnel.

Attack Chain

1. An attacker gains initial access to a Windows system through various means, such as exploiting a vulnerability or using stolen credentials.
2. The attacker opens a command prompt or PowerShell session.
3. The attacker uses net.exe or net1.exe to create a new user account. The command includes the user argument along with /add or /ad flags. For example: net user <username> <password> /add.
4. The attacker may add the newly created user to privileged groups, such as Administrators or Domain Admins, to elevate privileges.
5. The attacker uses the new account to move laterally within the network, accessing sensitive data or systems.
6. The attacker establishes persistence by configuring the new account to be a service account or adding it to local administrator groups.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, lateral movement within the network, and long-term persistence on compromised systems. The impact is often determined by the privileges assigned to the newly created account. If the attacker adds the account to the Administrators group, they can effectively take full control of the affected system. In a domain environment, creating a domain account can lead to wider compromise across the entire network.

Recommendation

• Enable Sysmon process-creation logging to capture the necessary events for the rules below.
• Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
• Investigate any instances of net.exe or net1.exe creating user accounts, especially when initiated by unusual parent processes.
• Monitor for newly created accounts being added to privileged groups.
• Review the triage and analysis steps in the rule’s original documentation for guidance on investigating and responding to potential incidents.

Attack Chain

1. An attacker gains initial access to the system through various means (e.g., compromised credentials, software vulnerability).
2. The attacker executes MSBuild.exe, either directly or through another process.
3. MSBuild.exe is used to load and execute a malicious project file or inline code.
4. The malicious code within the MSBuild project file leverages Windows API calls to create a thread in a target process.
5. The created thread injects malicious code or a payload into the target process’s memory space.
6. The injected code executes within the context of the target process, potentially performing malicious activities.
7. These activities could include lateral movement, data exfiltration, or establishing persistence.

Impact

Successful process injection can lead to a variety of malicious outcomes, including privilege escalation, data theft, and system compromise. While the specific number of victims is not available, any Windows system running MSBuild is potentially vulnerable. The use of a trusted Microsoft utility like MSBuild makes detection more difficult, as it can blend in with legitimate developer activity. This can lead to prolonged compromise and significant damage before the malicious activity is detected.

Recommendation

• Enable Sysmon process creation and CreateRemoteThread logging (event IDs 1 and 8) to detect the malicious activity described in the attack chain.
• Deploy the Sigma rule “Process Injection by the Microsoft Build Engine” to your SIEM and tune for your environment to reduce false positives.
• Implement application whitelisting to prevent unauthorized execution of MSBuild.exe in non-development environments.
• Monitor the parent processes of MSBuild.exe for unusual or suspicious activity.

Attack Chain

1. An attacker gains initial access to a Windows system.
2. The attacker executes fsutil.exe via command line.
3. The command fsutil usn deletejournal /D [volume] is used to delete the USN Journal on the specified volume.
4. The operating system processes the command, removing the USN Journal.
5. Subsequent file system activity is no longer recorded in the USN Journal.
6. The attacker performs further actions on the system, such as lateral movement or data exfiltration.
7. Forensic analysis is hampered due to the missing USN Journal entries.

Impact

Successful deletion of the USN Journal impairs forensic investigations and incident response efforts. Without the USN Journal, analysts may struggle to determine the full scope of an intrusion, including files created, modified, or deleted by the attacker. This can lead to incomplete remediation and a higher risk of reinfection.

Recommendation

• Deploy the Sigma rule “Detect USN Journal Deletion via Fsutil” to your SIEM to identify this specific behavior.
• Monitor process execution events for fsutil.exe with arguments related to “deletejournal” and “usn” to detect potential attempts to delete the USN Journal.
• Enable Sysmon process creation logging to capture the execution of fsutil.exe with the relevant arguments.

Attack Chain

1. The attacker gains initial access to the system through unspecified means.
2. The attacker attempts to modify the Windows Error Reporting ReflectDebugger registry key.
3. The attacker modifies the ReflectDebugger value within one of the following registry paths: HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger, \REGISTRY\MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger, or MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger.
4. The attacker sets the ReflectDebugger value to a malicious executable or script.
5. The attacker triggers Werfault.exe with the -pr parameter, either manually or through a system event.
6. Werfault.exe executes the attacker-controlled code specified in the ReflectDebugger registry value.
7. The attacker achieves persistence, as the malicious code is executed each time Werfault is triggered with the -pr parameter.

Impact

Successful exploitation allows attackers to achieve persistence on the targeted system. This can lead to the execution of arbitrary code, potentially resulting in data theft, further malware installation, or complete system compromise. The impact is limited by the permissions of the Werfault process. While no specific victim counts are available, this technique can affect any Windows system where the attacker can modify the registry.

Recommendation

• Deploy the Sigma rule Werfault ReflectDebugger Registry Modification to detect unauthorized modifications to the ReflectDebugger registry key (logsource: registry_set, rule title).
• Enable Sysmon process creation logging to detect the execution of Werfault with the -pr parameter.
• Monitor registry events for changes to the specific ReflectDebugger paths mentioned in the overview section (HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger).

Attack Chain

1. An attacker compromises a Windows host.
2. The attacker installs a malicious agent on the compromised host.
3. The agent is configured to use a domain that utilizes a free SSL certificate for C2 communication.
4. The malicious agent establishes a DNS connection to a domain ending in *.letsencrypt.org, *.sslforfree.com, *.zerossl.com, or *.freessl.org.
5. The infected host bypasses host-based firewalls, as the traffic is encrypted.
6. The agent receives commands from the C2 server over the encrypted channel.
7. The attacker executes commands to perform lateral movement or data exfiltration.
8. The attacker exfiltrates sensitive data from the compromised host.

Impact

Successful exploitation could lead to undetected command and control activity within the network. Attackers could use this encrypted channel to exfiltrate sensitive data, deploy ransomware, or move laterally to other systems. Due to the use of free SSL certificates, the traffic appears legitimate and can bypass basic network security controls. While the rule severity is low, a successful C2 channel can lead to critical impact.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect potentially malicious processes using free SSL certificates for communication, tuning the false positives for your environment.
• Investigate any alerts generated by the Sigma rule, focusing on processes not typically associated with network activity originating from the defined Windows system paths.
• Monitor DNS query logs for connections to domains using free SSL certificates from unusual or untrusted processes.
• Update the Sigma rule with new free SSL certificate providers and adjust the excluded processes based on observed false positives in your environment.
• Enable Sysmon Event ID 22 (DNS Query) logging for better visibility into DNS requests.

Attack Chain

1. An attacker gains initial access to a Windows system through methods such as phishing or exploiting a vulnerability.
2. The attacker leverages a system utility such as cmstp.exe to execute malicious code.
3. cmstp.exe is invoked with a malicious INF file, leading to the execution of arbitrary commands.
4. The executed code initiates a network connection to an external server.
5. The connection is used to download a secondary payload, such as a reverse shell or malware.
6. The attacker uses the downloaded payload to establish a persistent presence on the system.
7. The attacker performs lateral movement to other systems on the network.
8. The attacker exfiltrates sensitive data from compromised systems to a remote server.

Impact

A successful attack can lead to a compromised system with unauthorized code execution, data exfiltration, and potential lateral movement within the network. Due to the low severity and the high probability of false positives, this rule should be tuned for specific environments and paired with other detection mechanisms. This may lead to data breaches, financial loss, or reputational damage.

Recommendation

• Implement the Sigma rules provided in this brief to detect unusual network connections from system utilities within your environment.
• Monitor process execution events for the utilities listed in the rule query to identify potential abuse of these tools.
• Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging for enhanced visibility into process execution and network activity.
• Correlate detections from this rule with other security alerts and logs to gain a more complete understanding of the attack.

Attack Chain

1. An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
2. The attacker enumerates existing scheduled tasks on the system using tools like schtasks.exe or PowerShell cmdlets.
3. The attacker identifies a suitable scheduled task to modify for persistence.
4. The attacker modifies the task’s settings, such as the trigger time, the executable to run, or the arguments passed to the executable. This modification is logged as event ID 4702.
5. The scheduled task is updated using schtasks.exe /change or PowerShell’s Set-ScheduledTask cmdlet.
6. The modified scheduled task executes at the specified time, launching the attacker’s malicious payload.
7. The malicious payload establishes a reverse shell to the attacker’s command and control (C2) server.
8. The attacker uses the reverse shell to perform further actions on the compromised system, such as data exfiltration or lateral movement.

Impact

A successful attack involving the modification of scheduled tasks can lead to persistent access to a compromised system. The attacker can use this access to steal sensitive data, install malware, or perform other malicious activities. While this rule is low severity, it can uncover attackers attempting to persist in a network.

Recommendation

• Enable “Audit Other Object Access Events” to generate the required Windows Security Event Logs (event ID 4702) as described in the setup instructions.
• Deploy the Sigma rule provided below to your SIEM to detect unusual scheduled task updates.
• Investigate any alerts generated by this rule to determine if the scheduled task modification is legitimate or malicious.
• Review the references provided to understand the underlying event IDs and attacker techniques related to scheduled tasks.

Attack Chain

1. An attacker gains initial access to a Windows system through various means (e.g., phishing, exploitation of a vulnerability).
2. The attacker escalates privileges to gain administrative access, allowing them to modify the registry.
3. The attacker directly modifies the HKLM\SYSTEM\ControlSet*\Services\*\ServiceDLL or HKLM\SYSTEM\ControlSet*\Services\*\ImagePath registry keys to point to a malicious DLL or executable.
4. The attacker’s malicious DLL or executable is configured to run as a service, ensuring persistence across system reboots.
5. The compromised service starts automatically during system startup or manually when triggered by the attacker.
6. The malicious service executes arbitrary code, providing the attacker with persistent control over the system.
7. The attacker may use the compromised service to perform further malicious activities, such as data exfiltration or lateral movement.

Impact

Successful exploitation allows attackers to achieve persistence on the compromised system, maintaining access even after reboots or user logoffs. This can lead to long-term control over the system, enabling attackers to perform various malicious activities, including data theft, deployment of ransomware, or use of the system as a foothold for further attacks within the network. The severity is further amplified if critical services are targeted, potentially leading to system instability or denial of service.

Recommendation

• Enable Sysmon registry event logging to capture the necessary data for this detection (Data Source: Sysmon).
• Deploy the provided Sigma rules to your SIEM to detect unusual service registry modifications (Sigma rules).
• Tune the Sigma rules by adding exceptions for legitimate software installations or updates that modify service registry keys directly (Sigma rules).
• Investigate any alerts generated by the Sigma rules, focusing on processes modifying the ServiceDLL or ImagePath registry values (Sigma rules).
• Review endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future (Response and remediation).

Attack Chain

1. Initial Access: The attacker gains initial access to the Windows system through an exploit or compromised credentials.
2. Privilege Escalation (Optional): The attacker may attempt to elevate privileges to a higher level, potentially SYSTEM.
3. Discovery: The attacker executes whoami.exe to determine the current user and their privileges.
4. Information Gathering: The attacker analyzes the output of whoami.exe to understand the context of the compromised system.
5. Lateral Movement (Conditional): Based on the information gathered, the attacker may attempt to move laterally to other systems.
6. Further Exploitation: The attacker leverages the gathered information to further exploit the compromised system or network.
7. Persistence (Optional): The attacker may establish persistence to maintain access to the compromised system.
8. Objective Completion: The attacker achieves their final objective, such as data exfiltration or system disruption.

Impact

Successful exploitation and reconnaissance can allow attackers to gain a deeper understanding of a compromised system. This may lead to further exploitation, lateral movement, and ultimately, the exfiltration of sensitive data or the disruption of critical services. While the whoami command itself is not inherently malicious, its suspicious usage often indicates malicious activity within a compromised environment. The severity is low because the execution of whoami by itself is not enough to confirm malicious activity, and further investigation is needed.

Recommendation

• Enable process creation logging with command line arguments to detect whoami.exe executions (reference: logs-endpoint.events.process-*, logs-system.security*, logs-windows.forwarded*, logs-windows.sysmon_operational-*).
• Deploy the Sigma rule “Whoami Process Activity” to your SIEM and tune for your environment (reference: rule).
• Investigate parent processes of whoami.exe for any suspicious or unusual activity (reference: Attack Chain).
• Monitor for other discovery commands executed around the same time as whoami.exe (reference: Related rules).
• Review and tune the false positives outlined in the rule to minimize noise (reference: false_positives).

Attack Chain

1. An attacker gains initial access to a compromised host within the network.
2. The attacker uses sc.exe with the create command to create a new service on a remote host, specifying a malicious executable as the binPath.
3. The attacker uses sc.exe with the config command to modify an existing service on a remote host, changing its binPath to point to a malicious executable.
4. The attacker uses sc.exe with the failure command to configure service failure options to execute a malicious command.
5. The attacker uses sc.exe with the start command to start a service on a remote host, triggering the execution of the malicious executable.
6. The malicious executable executes on the remote host, providing the attacker with a foothold for further actions.
7. The attacker leverages the newly established foothold to move laterally to other systems within the network, potentially escalating privileges and accessing sensitive data.
8. The attacker establishes persistence through the created or modified service, allowing continued access even after system reboots.

Impact

Successful exploitation can allow attackers to move laterally within a network, gain unauthorized access to sensitive data, and establish persistence on compromised systems. While the source material doesn’t provide specific victim counts or sectors targeted, the impact of successful lateral movement can be significant, potentially leading to data breaches, system disruption, and financial losses.

Recommendation

• Deploy the Sigma rule “Service Command Lateral Movement” to your SIEM and tune for your environment based on observed false positives from administrative activity.
• Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging to enhance visibility into sc.exe activity.
• Review and whitelist legitimate administrative scripts or tools that use sc.exe by their process names or paths to reduce false positives, as described in the rule’s documentation.
• Implement network segmentation to limit the ability of adversaries to move laterally across the network, mitigating the impact of successful exploitation.

Attack Chain

1. Initial infection occurs via an unspecified method (e.g., phishing, exploit).
2. Malware establishes a foothold on the compromised system.
3. Malware configures itself to use SMTP on port 26 for C2 communications.
4. The infected host initiates a TCP connection to a remote server on port 26.
5. The malware sends commands to the infected host over the SMTP connection on port 26.
6. The infected host executes the received commands.
7. The malware may exfiltrate data to the remote server over the SMTP connection on port 26.

Impact

Compromised systems may be remotely controlled by attackers, leading to data theft, malware propagation, or further malicious activities. The use of non-standard ports like 26 can help attackers evade detection. If successful, an attacker can maintain persistence and control over the compromised system.

Recommendation

• Deploy the Sigma rule Detect SMTP Traffic on TCP Port 26 to your SIEM and tune for your environment to detect potential command and control activity.
• Investigate any network connections on TCP port 26 to identify potentially malicious SMTP traffic.
• Review network traffic logs focusing on network_traffic.flow or zeek.smtp events to detect unusual patterns associated with TCP port 26.
• Implement firewall rules to block unauthorized SMTP traffic on port 26.
• Examine source and destination IP addresses of traffic on port 26, and correlate with threat intelligence sources to identify known malicious actors as per the references.

Attack Chain

1. User opens a malicious Microsoft Office document (e.g., Word, Excel).
2. The document executes embedded macro code or exploits a vulnerability.
3. The macro or exploit leverages the Component Object Model (COM).
4. The Office application (e.g., WINWORD.EXE) loads the taskschd.dll library, providing access to the Task Scheduler service.
5. The COM interface is used to programmatically create a new scheduled task.
6. The scheduled task is configured to execute a malicious payload at a later time or on a recurring basis.
7. The malicious payload could be a script, executable, or command-line instruction.
8. Upon execution, the payload achieves the attacker’s objective, such as establishing persistence, downloading additional malware, or compromising the system.

Impact

A successful attack leveraging this technique can allow adversaries to maintain persistent access to a compromised system. This can lead to long-term data exfiltration, lateral movement within the network, and deployment of ransomware. The low severity score assigned to the original rule may underestimate the potential impact, as persistence is a critical component of many advanced attacks. Affected systems may require extensive remediation to remove all traces of the malicious activity.

Recommendation

• Deploy the Sigma rule “Office Application Loading Task Scheduler DLL” to your SIEM and tune for your environment to detect this specific activity.
• Enable Sysmon Event ID 7 (Image Loaded) logging on Windows endpoints to provide visibility into DLL loading events, which is a prerequisite for the Sigma rule.
• Investigate any alerts generated by the Sigma rule, focusing on the specific scheduled tasks that are created and the payloads they execute.
• Monitor for scheduled task creation events (Event ID 4698) and deletion events (Event ID 4699) in the Windows Event Logs, as referenced in the rule’s investigation guide.

Attack Chain

1. An attacker gains initial access to a Windows system.
2. The attacker enables WSL if it is not already enabled.
3. The attacker executes wsl.exe to start a Linux environment.
4. Inside the WSL environment, the attacker uses bash to execute malicious commands.
5. The attacker attempts to access sensitive files such as /etc/shadow or /etc/passwd to gather credentials.
6. The attacker uses network tools like curl to download or upload malicious payloads.
7. The attacker executes scripts to establish persistence within the WSL environment.
8. The attacker uses the compromised WSL environment to move laterally to other systems or exfiltrate data.

Impact

Successful exploitation via WSL can lead to a variety of negative outcomes, including unauthorized access to sensitive information, credential compromise, and lateral movement within the network. While specific victim counts are unavailable, this technique can significantly increase the attack surface and reduce the effectiveness of traditional Windows-based security measures, affecting organizations across various sectors.

Recommendation

• Enable Sysmon process creation logging to capture wsl.exe and bash.exe executions (reference: Sysmon Event ID 1 setup in rule setup section).
• Deploy the Sigma rule “Detect Suspicious WSL Activity” to your SIEM and tune for your environment.
• Monitor process command lines for suspicious arguments used with wsl.exe, such as access to /etc/shadow or /etc/passwd (reference: Sigma rule selection criteria).
• Investigate and whitelist legitimate uses of WSL within your environment to reduce false positives (reference: False positive analysis in the rule description).

Attack Chain

1. The attacker gains initial access to the target system.
2. The attacker identifies registry run key locations for persistence.
3. The attacker modifies a registry run key (e.g., HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run) using tools such as reg.exe.
4. The attacker adds a malicious executable path to the registry key.
5. The system is restarted, or a user logs in.
6. The malicious executable is launched automatically as part of the logon process.
7. The malicious executable establishes a connection to a command-and-control server.
8. The attacker gains remote access to the compromised system.

Impact

Successful exploitation allows attackers to maintain persistent access to compromised systems, enabling them to perform unauthorized activities such as data theft, lateral movement, and deployment of ransomware. While each instance may not cause immediate critical damage, the cumulative effect of multiple persistent infections across an environment can lead to significant data breaches and operational disruption. The Elastic rule attempts to minimize false positives with built-in filters for common legitimate applications and processes like ctfmon.exe, but tuning is required.

Recommendation

• Deploy the Sigma rule provided below to detect suspicious modifications to registry run keys and tune it to filter out legitimate application updates.
• Enable registry event logging to capture modifications made to the registry, ensuring that the Sigma rule can function correctly.
• Investigate any alerts generated by the Sigma rule, examining the parent process of the process modifying the registry for suspicious activity.
• Block known malicious executables and domains identified during triage to prevent further infection.
• Use endpoint detection and response (EDR) solutions like Elastic Defend to gain enhanced visibility into endpoint activity and detect malicious behavior associated with persistence mechanisms.

Attack Chain

1. An attacker gains initial access to a system within the network (e.g., via phishing or exploiting a vulnerability).
2. The attacker uploads or transfers the PsExec tool (PsExec.exe) to the compromised host, potentially using SMB shares or other file transfer methods.
3. The attacker executes PsExec with the -accepteula flag, which suppresses the license dialog, potentially indicating a first-time execution on the machine.
4. PsExec establishes a network connection to a remote target system, leveraging SMB/Windows Admin Shares (T1021.002) to facilitate remote command execution.
5. The attacker uses PsExec to execute commands on the remote system, potentially with SYSTEM privileges, to install malware, gather credentials, or perform reconnaissance.
6. The attacker leverages the newly compromised system as a pivot point to move laterally to other systems within the network, repeating the process.
7. The attacker escalates privileges on multiple systems.
8. The attacker achieves their objective, such as data exfiltration or ransomware deployment.

Impact

Successful exploitation can lead to widespread compromise across the network. Attackers can leverage PsExec to gain control over critical systems, disable security controls, and exfiltrate sensitive data. Lateral movement facilitated by PsExec can enable attackers to rapidly expand their footprint within an organization, impacting numerous systems and services. While the rule’s severity is low due to the dual-use nature of PsExec, the potential impact of unchecked lateral movement is significant.

Recommendation

• Deploy the Sigma rule PsExec Network Connection to your SIEM and tune the process.executable and process.parent.executable filters for your environment to reduce false positives.
• Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging for enhanced visibility into PsExec activity.
• Review and enforce the principle of least privilege to limit the accounts that can run PsExec and access sensitive systems.
• Investigate any alerts generated by the PsExec Network Connection rule promptly to determine if the activity is legitimate or malicious.
• Monitor network connections originating from systems where PsExec is executed using the PsExec Outbound Network Connection Sigma rule.

Attack Chain

1. Initial Access: The attacker gains access to an Okta administrator account, either through compromised credentials (e.g., phishing, credential stuffing) or insider access.
2. Authentication: The attacker authenticates to the Okta admin console using the compromised or legitimate administrator account.
3. Policy Enumeration: The attacker identifies target Okta policies to modify or delete using the Okta admin console or API.
4. Policy Modification/Deletion: The attacker modifies or deletes the targeted Okta policy through the Okta admin console or API. This generates an policy.lifecycle.update or policy.lifecycle.delete event.
5. Privilege Escalation (Potential): By modifying policies, the attacker may escalate privileges, granting themselves or other unauthorized users access to sensitive applications and resources.
6. Lateral Movement (Potential): With escalated privileges, the attacker moves laterally within the Okta environment, accessing other applications and resources.
7. Data Exfiltration/Damage (Potential): The attacker leverages the compromised Okta environment to exfiltrate sensitive data or cause damage to connected systems.

Impact

A successful Okta policy modification or deletion can have significant consequences. Unauthorized policy changes can weaken security controls, allowing attackers to bypass authentication mechanisms, escalate privileges, and gain unauthorized access to sensitive applications and data. This could lead to data breaches, financial loss, and reputational damage. The impact depends on the scope of the affected policy and the applications it protects. The number of victims could range from a few individuals to the entire organization, depending on the scope of the compromised policy.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect Okta policy modifications or deletions (policy.lifecycle.update, policy.lifecycle.delete event types).
• Investigate any detected policy changes to verify their legitimacy and identify the user responsible.
• Review Okta administrator account activity for any signs of compromise or unauthorized access.
• Implement multi-factor authentication (MFA) for all Okta administrator accounts to prevent unauthorized access.
• Regularly review and audit Okta policies to ensure they are configured securely and in accordance with security best practices.

Attack Chain

1. Initial Compromise: An attacker compromises a user account with some level of administrative privileges within the Okta environment (T1078).
2. Privilege Escalation: The attacker leverages the compromised account to modify group application assignments, granting unauthorized access to sensitive applications (T1098).
3. Group Modification: The attacker assigns applications to groups that the compromised user has access to modify. This allows the attacker to extend their reach within the organization.
4. Application Assignment: The attacker assigns applications to a group, potentially giving all members of that group access to the applications without proper authorization.
5. Lateral Movement: With access to new applications, the attacker uses the newly gained privileges to access other systems and resources within the network (T1078).
6. Persistence: The attacker may create or modify additional group application assignments to ensure continued access, even if the initial compromised account is detected and remediated (T1098).
7. Data Access/Exfiltration: The attacker leverages the escalated privileges to access and potentially exfiltrate sensitive data from the applications they now have access to.

Impact

A successful attack could lead to widespread unauthorized access to critical applications and data within the organization. The number of affected users and the extent of data breaches depend on the sensitivity of the applications accessed and the scope of the group membership changes. Consequences range from compliance violations and financial losses to reputational damage and operational disruption.

Recommendation

• Ensure the Privileged Access Detection integration is installed and properly configured in your Elastic Stack environment as described in the setup guide.
• Investigate any alerts generated by the pad_okta_spike_in_group_application_assignment_changes_ea machine learning job, prioritizing those involving sensitive applications or high-privilege groups.
• Review and update access controls and group assignment policies within Okta, as the advisory recommends to prevent similar unauthorized changes in the future.
• Implement the following Sigma rule to detect suspicious Okta group application assignment changes and tune it for your environment.

Attack Chain

1. An attacker gains initial access to the target system (e.g., through phishing or exploitation of a vulnerability).
2. The attacker executes a signed LOLBIN, such as expand.exe, extrac32.exe, ieexec.exe, or makecab.exe.
3. The LOLBIN is used to download or execute a malicious payload from a remote server.
4. The executed binary establishes a network connection to an external IP address.
5. Data exfiltration may occur over the established network connection.
6. The attacker maintains persistence on the system by scheduling tasks or modifying registry keys.
7. The attacker moves laterally within the network, compromising additional systems.

Impact

A successful attack leveraging LOLBINs can result in the installation of malware, data theft, or full system compromise. The use of signed binaries makes it more difficult to detect malicious activity, potentially allowing attackers to operate undetected for extended periods. The financial and reputational damage caused by such attacks can be significant. While the risk score is low, the potential for defense evasion justifies monitoring.

Recommendation

• Implement the provided Sigma rule Network Connection via Signed Binary to detect suspicious network connections initiated by LOLBINs.
• Monitor process execution logs for instances of expand.exe, extrac32.exe, ieexec.exe, and makecab.exe using process creation logging.
• Review network connection logs for outbound connections initiated by these processes, excluding connections to internal networks based on the provided list of private IP ranges.
• Investigate any detected instances of LOLBINs making external network connections, correlating with other suspicious activities on the affected host, as detailed in the “Triage and analysis” section.

Attack Chain

1. An attacker gains initial access to a system (e.g., through phishing or exploiting a vulnerability).
2. The attacker uses a script or command-line interface (e.g., PowerShell) to create a BITS job.
3. The BITS job is configured to download a malicious executable or archive from a remote server using the bitsadmin.exe utility.
4. BITS downloads the file to a temporary location on the system with a BIT*.tmp extension.
5. The svchost.exe process renames the temporary file to its final name and extension (e.g., .exe, .zip).
6. The attacker executes the downloaded file, initiating further malicious activities.
7. The malware establishes persistence through registry keys or scheduled tasks.
8. The malware communicates with a command and control (C2) server to receive instructions and exfiltrate data.

Impact

Successful exploitation enables attackers to download and execute arbitrary code on compromised systems. The use of BITS can bypass traditional security measures, leading to malware infections, data theft, and potentially full system compromise. This technique can be used in conjunction with other attack vectors to establish a persistent foothold within the network. While the rule itself triggers at low severity, the identified activity can be an early warning of more severe attack stages.

Recommendation

• Deploy the “Ingress Transfer via Windows BITS” Sigma rule to your SIEM and tune for your environment.
• Enable Sysmon file creation and process creation logging to enhance visibility into BITS-related activities.
• Monitor network connections initiated by svchost.exe to identify potentially malicious downloads.
• Investigate any instances of bitsadmin.exe being executed, especially with command-line arguments indicative of suspicious downloads.
• Review Microsoft-Windows-Bits-Client/Operational Windows logs (event ID 59) for unusual BITS events.
• Block known malicious domains or IP addresses associated with BITS-related attacks at the firewall or DNS resolver.

Attack Chain

1. An attacker copies malware onto a USB drive from an infected system.
2. The attacker physically inserts the USB drive into a target Windows system.
3. The user, either unknowingly or through social engineering, executes the malicious binary from the USB drive. This could be achieved through Autorun features (if enabled) or by manually clicking on an executable file.
4. The executed process, now running on the target system, lacks a valid code signature, raising suspicion.
5. The malicious process attempts to establish a network connection, potentially to a command and control server or to exfiltrate data.
6. The network connection attempt is logged, capturing details about the destination IP address and port.
7. The attacker gains initial access to the system and can potentially perform reconnaissance, privilege escalation, or lateral movement.

Impact

A successful attack could lead to unauthorized access to sensitive data, system compromise, and potential lateral movement within the network. Although the risk score is low, such attacks on air-gapped systems are high impact. The number of victims is unknown; however, organizations across all sectors are vulnerable.

Recommendation

• Enable process creation and network connection logging to detect this type of activity (logs-endpoint.events.process-* and logs-endpoint.events.network-*).
• Deploy the Sigma rule “Execution from a Removable Media with Network Connection” to your SIEM and tune for your environment.
• Disable Autorun features on all systems to prevent automatic execution of programs from removable media.

Attack Chain

1. Initial Access: An attacker gains initial access to a Windows system through various means, such as phishing or exploiting a software vulnerability.
2. Privilege Escalation (if necessary): The attacker may need to escalate privileges to modify registry settings.
3. Defense Evasion: The attacker modifies the Windows registry to enable DNS-over-HTTPS (DoH) in web browsers like Edge, Chrome, or Firefox. This is achieved by modifying specific registry keys such as HKLM\SOFTWARE\Policies\Microsoft\Edge\BuiltInDnsClientEnabled, HKLM\SOFTWARE\Google\Chrome\DnsOverHttpsMode, or HKLM\SOFTWARE\Policies\Mozilla\Firefox\DNSOverHTTPS.
4. Obfuscation: By enabling DoH, the attacker encrypts DNS queries, making it difficult for network monitoring tools to inspect DNS traffic.
5. Command and Control: The attacker establishes command and control (C2) communication with a remote server over encrypted DNS traffic, evading traditional network-based detection methods.
6. Data Exfiltration: The attacker uses the encrypted DNS channel to exfiltrate sensitive data, bypassing network security controls that rely on DNS inspection.
7. Persistence (Optional): The attacker might establish persistence by ensuring the DoH settings remain enabled across system reboots.

Impact

Successful exploitation leads to a loss of visibility into DNS traffic, hindering incident response and threat hunting efforts. Attackers can effectively hide command-and-control communications and data exfiltration activities. Although this activity by itself isn’t inherently malicious, it removes a layer of defense, increasing the risk that malicious activities will go undetected.

Recommendation

• Deploy the Sigma rules provided in this brief to your SIEM to detect the enabling of DNS-over-HTTPS via registry modifications.
• Enable Sysmon registry event logging to capture the necessary events for the provided Sigma rules to function effectively.
• Review and update security policies to ensure DNS-over-HTTPS is only enabled through approved channels and for legitimate purposes, reducing the risk of misuse, and create exceptions in the detection rule for systems where this is a known requirement.
• Investigate any alerts generated by the Sigma rules, focusing on identifying the user account, process, and associated network activity (reference the investigation guide in the source URL).

Attack Chain

1. The attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
2. The attacker identifies a target COM object to hijack by enumerating COM object entries in the registry.
3. The attacker modifies the InprocServer32 or LocalServer32 registry keys associated with the target COM object to point to a malicious DLL or executable.
4. The attacker may also modify the DelegateExecute registry key to control how the COM object is executed.
5. A legitimate application or service attempts to instantiate the original COM object.
6. Due to the registry modifications, the malicious DLL or executable is loaded and executed instead.
7. The malicious code performs its intended actions, such as establishing persistence, escalating privileges, or executing arbitrary commands.
8. The attacker maintains persistent access to the system and potentially gains elevated privileges through the hijacked COM object.

Impact

Successful COM hijacking enables attackers to establish persistent access to compromised systems and potentially escalate privileges. The impact can range from executing arbitrary code with user privileges to gaining system-level access, depending on the context in which the hijacked COM object is used. The Elastic detection rule aims to identify and prevent such attacks by detecting suspicious registry modifications, but the overall number of affected systems or specific sectors targeted by this technique are not specified in the original source.

Recommendation

• Enable Windows Registry auditing to capture registry modification events and activate the Sigma rule Suspicious COM Hijack Registry Modification to detect potential COM hijacking attempts.
• Investigate any alerts generated by the Sigma rule, focusing on processes modifying COM-related registry keys and their associated executables.
• Implement code signing validation and monitor for unsigned or unexpected DLLs being loaded by legitimate processes, as indicated in the rule’s description.
• Regularly review and update the list of excluded processes and trusted code signers in the Sigma rule to minimize false positives.
• Deploy the EQL rule provided by Elastic, adjusting the from and index fields to match your environment, and tune the process and signature exclusions for your environment.
• Monitor for registry changes in HKEY_USERS hive related to COM objects, as these are considered less common and potentially malicious.

Attack Chain

1. An attacker gains initial access to a Windows system through various means (e.g., compromised credentials, phishing).
2. The attacker downloads the ADExplorer utility (ADExplorer.exe) to the compromised host.
3. The attacker executes ADExplorer.exe to begin enumeration of the Active Directory environment.
4. ADExplorer interacts with the Active Directory domain controllers, querying information about users, groups, computers, and organizational units.
5. The attacker may use ADExplorer to save snapshots of the AD database for offline analysis.
6. The attacker analyzes the gathered information to identify privileged accounts, critical assets, and potential vulnerabilities within the AD environment.
7. The attacker uses the discovered information to plan further attacks, such as lateral movement or privilege escalation.

Impact

Successful execution of ADExplorer by malicious actors can lead to the discovery of sensitive information about the Active Directory environment. This information can be leveraged to facilitate lateral movement, privilege escalation, and data exfiltration. While the initial risk score is low, the reconnaissance activity enables follow-on attacks that can have severe consequences, potentially leading to full domain compromise.

Recommendation

• Implement the Sigma rule Detect ADExplorer Execution via Process Name to detect the execution of ADExplorer based on process name.
• Implement the Sigma rule Detect ADExplorer Execution via Original File Name to detect the execution of ADExplorer based on the process’s original file name.
• Monitor process creation events on Windows endpoints for the execution of ADExplorer.exe or processes with an original file name of “AdExp” to detect potential reconnaissance activities.
• Investigate and validate any execution of ADExplorer by non-administrator accounts.
• Review ADExplorer use and restrict its usage to authorized personnel.

Attack Chain

1. Initial Access: The attacker gains initial access through an existing user account.
2. Execution: The attacker executes a standard Windows process (e.g., cmd.exe, powershell.exe).
3. Defense Evasion: The attacker leverages LOLbins to perform malicious actions, blending in with legitimate system activity.
4. Masquerading: The attacker renames or moves malicious tools to mimic legitimate system files.
5. Privilege Escalation (Optional): The attacker attempts to escalate privileges using the compromised process.
6. Lateral Movement (Optional): The attacker uses the compromised process to move laterally to other systems.
7. Command and Control (Optional): The process establishes a connection to a command and control server for further instructions.
8. Impact: The attacker achieves their objective, such as data exfiltration, system compromise, or persistence.

Impact

A successful attack using these techniques can lead to a full system compromise, data theft, or the installation of persistent backdoors. The use of LOLbins makes detection difficult, potentially allowing attackers to operate undetected for extended periods. The impact is amplified by the potential for lateral movement to other systems within the network. While the severity is rated “low”, successful exploitation allows attackers to move laterally and establish persistence in the network.

Recommendation

• Ensure the Living off the Land (LotL) Attack Detection integration is installed and properly configured, as detailed in the rule setup (Elastic Defend or Winlogbeat).
• Investigate alerts generated by the “Unusual Process Spawned by a User” rule (rule_id: 40155ee4-1e6a-4e4d-a63b-e8ba16980cfb) to determine the legitimacy of the flagged process.
• Tune the anomaly threshold (anomaly_threshold: 75) based on your environment to reduce false positives, as mentioned in the rule parameters.
• Review the “False positive analysis” section in the rule’s note for guidance on identifying and excluding legitimate processes.
• Implement the provided Sigma rule to detect unusual command line arguments associated with LOLBins.

Attack Chain

1. Adversary gains initial access to a Windows system.
2. The attacker leverages a LOLbin (e.g., powershell.exe, cmd.exe, mshta.exe) to execute malicious commands.
3. The LOLbin spawns a child process to perform a specific task, such as downloading a file or modifying system settings.
4. The spawned process exhibits characteristics flagged as suspicious by the ProblemChild ML model.
5. The suspicious process attempts to evade detection by masquerading as a legitimate system process or by obfuscating its activity.
6. The attacker uses the process to establish persistence, escalate privileges, or move laterally within the network.
7. The ultimate objective is to exfiltrate sensitive data, deploy ransomware, or disrupt business operations.

Impact

A successful defense evasion attack can allow adversaries to operate undetected within a network, leading to data breaches, financial losses, and reputational damage. The use of LOLbins makes it difficult to distinguish malicious activity from legitimate system operations. This detection rule aims to reduce the dwell time of attackers by identifying suspicious processes early in the attack chain, even if they are using legitimate tools. False positives may occur due to routine administrative tasks, software updates, or custom scripts.

Recommendation

• Ensure that the Living off the Land (LotL) Attack Detection integration is installed and properly configured, as described in the “Setup” section of this brief.
• Verify that Windows process events are being collected by Elastic Defend or Winlogbeat, as required by the detection rule.
• Deploy the following Sigma rule to detect unusual process spawns and tune the Image|endswith and CommandLine|contains conditions for your specific environment.
• Review the investigation guide provided in the rule description to triage and analyze potential false positives.
• Adjust the anomaly_threshold (currently 75) in the Elastic detection rule based on your environment’s baseline to reduce noise.
• Monitor for MITRE ATT&CK Technique T1218 (System Binary Proxy Execution) to identify potential LOLbin abuse.

Attack Chain

1. Initial Access: An attacker gains initial access to a Windows system through various means such as exploiting a vulnerability or using stolen credentials.
2. Privilege Escalation: The attacker escalates privileges to gain the necessary permissions to execute system utilities.
3. Defense Evasion: The attacker uses attrib.exe to modify the hidden attribute of a malicious file or directory. For example, attrib.exe +h C:\path\to\malicious\file.exe.
4. Concealment: The malicious file or directory is now hidden from normal directory listings, making it harder for users and administrators to detect.
5. Persistence: The attacker establishes persistence by hiding malicious scripts or executables in startup directories or scheduled tasks.
6. Lateral Movement: The attacker uses the hidden files to move laterally within the network, potentially using them as part of a larger attack campaign.

Impact

The impact of this attack includes prolonged attacker presence, increased difficulty in detecting malicious activity, and potential data exfiltration or system compromise. While the risk score is relatively low, the technique contributes to a broader attack chain and can significantly hinder incident response efforts. A successful hiding of artifacts might lead to further compromise, data breaches, or ransomware deployment.

Recommendation

• Deploy the Sigma rule “Adding Hidden File Attribute via Attrib” to your SIEM to detect suspicious usage of attrib.exe.
• Enable process creation logging with command line monitoring in Windows environments to ensure the Sigma rule can capture relevant events.
• Investigate any alerts generated by the Sigma rule, focusing on the parent processes and target files to determine if the activity is legitimate.
• Correlate detections of attrib.exe with other suspicious activities or alerts on the same host.
• Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden attribute.

Attack Chain

1. Initial Access (TA0001): An attacker gains initial access to a user account through credential compromise or other means.
2. Privilege Escalation (TA0004): The attacker attempts to escalate privileges using the compromised account.
3. Unusual Network Location: The attacker leverages a VPN, proxy, or compromised host in a different network segment to conduct privileged operations.
4. Windows Privileged Operation: The attacker performs a privileged action on a Windows system, such as modifying system files, creating new accounts, or accessing sensitive data.
5. ML Anomaly Detection: Elastic’s machine learning job pad_windows_rare_source_ip_by_user_ea detects the unusual source IP for the privileged operation.
6. Alert Triggered: The “Unusual Source IP for Windows Privileged Operations Detected” rule triggers an alert in Elastic Security.
7. Potential Lateral Movement: If successful, the attacker can use the elevated privileges to move laterally within the network and compromise other systems.
8. Data Exfiltration/Impact: The attacker achieves their final objective, such as data exfiltration, system disruption, or ransomware deployment, leveraging the escalated privileges.

Impact

Successful exploitation and privilege escalation can allow an attacker to move laterally through the network, access sensitive data, and disrupt critical systems. While the alert itself is low severity, the underlying activity can lead to significant damage if not addressed promptly. The risk score associated with the rule is 21, indicating a moderate level of risk. Affected organizations may experience data breaches, financial loss, and reputational damage.

Recommendation

• Review and tune the machine learning job pad_windows_rare_source_ip_by_user_ea to reduce false positives and ensure accurate detection of anomalous activity.
• Investigate any alerts triggered by the “Unusual Source IP for Windows Privileged Operations Detected” rule, focusing on identifying the root cause of the unusual source IP and the nature of the privileged operations performed.
• Implement the setup steps outlined in the rule documentation to ensure proper collection and ingestion of Windows events required for the machine learning job to function correctly.
• Correlate the alerts with other security events or logs, such as firewall logs, VPN logs, or endpoint security alerts, to gather additional context about the source IP and user activity.

Attack Chain

1. The attacker gains initial access to a Windows system (T1078) using valid credentials, possibly through compromised accounts or insider threats.
2. The attacker attempts to perform privileged operations, such as accessing sensitive files, modifying system configurations, or installing unauthorized software.
3. To bypass access controls, the attacker leverages a privilege type that is not commonly associated with the compromised user account.
4. Windows event logs record the privilege usage, capturing details about the user, the privilege type, and the associated operation.
5. The Elastic Privileged Access Detection (PAD) integration ingests and processes these logs, feeding them into the machine learning model.
6. The machine learning model identifies the anomalous privilege usage, comparing it against the user’s baseline behavior.
7. If the anomaly score exceeds the configured threshold (e.g., 75), a detection alert is triggered, indicating potential malicious activity.
8. Security analysts investigate the alert to determine the legitimacy of the privilege usage and take appropriate remediation actions.

Impact

A successful privilege escalation attack can grant an attacker complete control over the compromised system, allowing them to steal sensitive data, install malware, or disrupt critical services. Account manipulation can lead to unauthorized access to resources and systems, potentially impacting confidentiality, integrity, and availability. While the provided rule is low severity due to the anomaly-based nature, the potential impact of successful privilege escalation is critical and warrants immediate investigation.

Recommendation

• Ensure the Privileged Access Detection integration assets are installed and configured correctly within your Elastic environment as outlined in the “Setup” section of the rule description.
• Verify Windows event logs are being collected by integrations such as Elastic Defend and the Windows integration to provide data for the ML job.
• Tune the anomaly_threshold within the machine learning job configuration based on your environment’s baseline activity to reduce false positives while maintaining detection sensitivity.
• Review the investigation guide provided in the rule description to effectively triage and analyze alerts generated by the machine learning job.
• Implement and enforce role-based access controls to minimize the number of users with elevated privileges, reducing the attack surface.
• Utilize the MITRE ATT&CK framework references (T1068, T1078, T1098) to understand the potential tactics and techniques associated with privilege escalation and account manipulation.

Attack Chain

1. An attacker gains unauthorized access to a valid user account, potentially through phishing, credential stuffing, or other means.
2. The attacker logs into a Windows system using the compromised account from a device that is not typically used by that user.
3. The attacker attempts to execute privileged operations on the system, such as installing software, modifying system settings, or accessing sensitive data.
4. Windows logs capture the privileged operations being performed by the user account from the unusual device.
5. The Elastic Privileged Access Detection (PAD) integration analyzes the logs using its machine learning model (“pad_windows_rare_device_by_user_ea”).
6. The ML model identifies the activity as anomalous based on the rarity of the device being used by the user for privileged operations.
7. A detection rule triggers, flagging the unusual activity as a potential privileged access attempt.
8. The security team investigates to determine whether the activity is malicious or a legitimate use case (e.g., user working from a new device).

Impact

A successful attack could lead to privilege escalation, allowing the attacker to gain control of the system and potentially the entire network. This can result in data breaches, system compromise, and disruption of services. The severity is rated as low because the detection relies on anomalies and requires further investigation to confirm malicious intent. Identifying unusual access patterns early can prevent more severe incidents.

Recommendation

• Ensure the Privileged Access Detection integration is installed and properly configured, including the preconfigured anomaly detection jobs, as outlined in the setup instructions.
• Investigate alerts generated by the “Unusual Host Name for Windows Privileged Operations Detected” rule, focusing on the specific user and host involved, per the investigation guide.
• Implement multi-factor authentication (MFA) for privileged accounts to mitigate the risk of unauthorized access even if credentials are compromised, as mentioned in the response and remediation section.
• Review and update access controls and permissions to ensure that only authorized devices and users can perform privileged operations.

Attack Chain

1. The attack begins with an initial access vector (not specified in source).
2. The adversary executes cmd.exe.
3. cmd.exe spawns ping.exe with the -n argument to introduce a delay, typically to evade detection (ping.exe -n [number] 127.0.0.1).
4. After the delay introduced by ping.exe, the same cmd.exe process executes a potentially malicious utility such as powershell.exe, mshta.exe, rundll32.exe, certutil.exe, or regsvr32.exe.
5. Alternatively, cmd.exe might execute a binary located within the user’s AppData directory that lacks a valid code signature.
6. The malicious utility executes arbitrary commands or scripts, potentially downloading further payloads or modifying system configurations.
7. The attacker gains a foothold on the system, enabling further malicious activities such as lateral movement or data exfiltration.

Impact

A successful attack can lead to malware installation, system compromise, and data theft. While the source does not quantify the number of victims or specific sectors targeted, a successful compromise can lead to significant operational disruption and data breaches. The use of delayed execution makes it more difficult for traditional security solutions to detect malicious activity.

Recommendation

• Deploy the Sigma rule “Delayed Execution via Ping” to your SIEM to detect the execution of commonly abused Windows utilities via a delayed Ping execution.
• Enable process monitoring with command-line argument logging to capture the execution of ping.exe and subsequent processes for analysis.
• Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the utilities identified in the rule.
• Review and tune the provided Sigma rule, including the listed exclusions, to reduce false positives in your specific environment.
• Monitor process execution from unusual locations like the AppData directory, especially for unsigned executables, as indicated in the rule’s detection logic.

Attack Chain

1. A user connects a removable device (e.g., USB drive) to a Windows system.
2. The operating system detects the new device and attempts to enumerate its properties.
3. The system queries the registry for device-specific settings, including the “FriendlyName,” under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR key.
4. If the device is new to the system, the registry is modified to record the device’s information, including its friendly name.
5. The event generates a registry modification event, which is logged by Sysmon, Elastic Defend, Microsoft Defender XDR, or SentinelOne.
6. An attacker may use the USB device to deploy malware or exfiltrate sensitive data.
7. The attacker copies files to the USB device.
8. The attacker removes the USB device, completing the exfiltration.

Impact

Successful exploitation and data exfiltration via USB can lead to the loss of sensitive information, intellectual property theft, or the introduction of malware into the network. Although this alert is low severity, multiple alerts across the environment may indicate an active campaign. The detection focuses on registry modifications, which are early indicators of device connection, allowing for proactive monitoring and response.

Recommendation

• Enable Sysmon registry event logging to detect registry modifications related to USB devices and activate the Sigma rules below.
• Deploy the Sigma rules provided to your SIEM to detect and monitor first-time seen USB devices.
• Investigate any alerts generated by the Sigma rules, correlating with user activity and file access events.
• Maintain a list of approved USB devices and create exceptions for them in the monitoring system to reduce false positives as described in the rule documentation.
• Monitor for subsequent file access or transfer events involving the new device as described in the rule documentation.

Attack Chain

1. Initial Access: An attacker gains initial access to the system through phishing, exploiting a vulnerability, or using compromised credentials.
2. Privilege Escalation (if needed): The attacker escalates privileges using exploits or by abusing misconfigurations to gain the necessary permissions to create scheduled tasks.
3. Task Creation: The attacker creates a new scheduled task using tools like schtasks.exe or PowerShell.
4. Configuration: The attacker configures the task to execute a malicious script or program at a specific time or event trigger.
5. Persistence: The scheduled task is configured to run at regular intervals or upon system startup, ensuring persistent access to the compromised system.
6. Execution: When the scheduled task triggers, the malicious payload executes, performing actions such as installing malware, stealing data, or establishing a command and control connection.
7. Lateral Movement (optional): The attacker uses the compromised system and scheduled task to move laterally to other systems on the network, repeating the task creation process.

Impact

Successful exploitation via scheduled task creation can lead to persistent access within the compromised environment. The attacker can maintain a foothold even after system restarts, enabling them to perform data exfiltration, deploy ransomware, or cause other disruptive activities. While the risk score is relatively low, the potential for persistence makes this a critical area to monitor, especially in environments where lateral movement is a significant concern. The number of affected systems depends on the scope of the initial compromise and the attacker’s ability to move laterally.

Recommendation

• Enable “Audit Other Object Access Events” to generate the necessary Windows Security Event Logs for detecting scheduled task creation (reference: setup instructions in the original rule).
• Deploy the provided Sigma rules to your SIEM to detect suspicious scheduled task creation events, and tune the rules by adding exclusions for known benign tasks in your environment.
• Review the investigation steps outlined in the rule’s notes to triage alerts related to scheduled task creation, focusing on unfamiliar task names, unusual user accounts, and suspicious scheduled actions.
• Use the references URL to understand the specific details of Windows Event ID 4698, which is generated when a scheduled task is created.

Attack Chain

1. An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
2. The attacker executes fsutil.exe via command line or script.
3. The fsutil command uses the fsinfo subcommand.
4. The fsinfo subcommand uses the drives argument to list connected drives.
5. The system returns a list of attached drives and their types (e.g., local, network, removable).
6. The attacker analyzes the output to identify potentially valuable targets.
7. The attacker moves laterally to access identified drives.
8. The attacker exfiltrates sensitive data or deploys ransomware on the identified drives.

Impact

Successful discovery of peripheral devices can lead to the identification of backup locations, mapped network drives, and removable media containing sensitive information. This information enables attackers to expand their reach within the compromised environment and increase the potential for data theft, encryption, or destruction. The low severity reflects the fact that this activity on its own is simply reconnaissance; the actual damage comes from subsequent actions.

Recommendation

• Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious execution of fsutil.exe (see below).
• Enable process creation logging with command line arguments to capture fsutil executions (see setup instructions in the Overview).
• Investigate any process executions of fsutil.exe where the parent process is unexpected or the user context is unusual (see Triage and Analysis).

Attack Chain

1. Initial compromise of the system via phishing, exploitation, or credential theft.
2. Privilege escalation to gain administrative access to the system.
3. Discovery of event log locations and tools for clearing logs.
4. Execution of commands or tools to clear the Security or System event logs.
5. Verification of event log clearance to confirm the action’s success.
6. Continued malicious activity without leaving obvious traces in the logs.
7. Attempts to disable or tamper with security monitoring tools to prevent future detection.

Impact

The successful clearing of Windows event logs can severely impair an organization’s ability to detect and respond to security incidents. The absence of log data hinders forensic investigations and prevents the identification of malicious activities. This can lead to prolonged intrusions, data breaches, and significant financial losses. The low severity reflects the fact that while impactful, this behavior often occurs post-compromise.

Recommendation

• Deploy the Sigma rule “Windows Event Logs Cleared” to your SIEM to detect attempts to clear event logs (rule.name).
• Investigate any alerts generated by the “Windows Event Logs Cleared” Sigma rule, focusing on the process execution chain and user accounts involved (rule.note).
• Enable Sysmon process creation logging to provide more detailed information about processes involved in clearing event logs (logsource.category).

Attack Chain

1. An attacker gains initial access to a system through various means (e.g., compromised credentials, software vulnerability).
2. The attacker establishes persistence on the system, potentially using scheduled tasks or autorun keys.
3. The attacker identifies sensitive data on the system or network.
4. The attacker copies the sensitive data to a staging directory.
5. The attacker uses a renamed or masqueraded legitimate process (e.g., svchost.exe, powershell.exe) to write the staged data to an external device connected to the system.
6. The system’s file events are monitored by Elastic Defend, capturing the process writing data to the external device.
7. The Elastic Data Exfiltration Detection integration analyzes the file events and identifies the process as rare or unusual for writing to external devices.
8. The “Unusual Process Writing Data to an External Device” rule is triggered, alerting security analysts to the potential exfiltration attempt.

Impact

A successful attack could result in the exfiltration of sensitive data, leading to financial loss, reputational damage, and legal repercussions. While the severity is “low,” a successful exfiltration can have significant consequences. The number of victims and the specific sectors targeted depend on the attacker’s objectives and the compromised system’s access to sensitive information.

Recommendation

• Install and configure the Data Exfiltration Detection integration in Elastic, ensuring the machine learning job ded_rare_process_writing_to_external_device_ea is enabled, as described in the setup documentation.
• Enable file event collection using Elastic Defend to provide the necessary data for the machine learning job, as detailed in the Elastic Defend documentation.
• Deploy the provided Sigma rule to your SIEM and tune the anomaly_threshold based on your environment’s baseline behavior to reduce false positives.
• Investigate any alerts generated by this rule, following the triage and analysis guidance to determine the legitimacy of the activity.

Attack Chain

1. An attacker gains initial access to a Windows system through various means.
2. The attacker executes a command shell (e.g., cmd.exe, PowerShell) or script interpreter (e.g., wscript.exe) on the compromised system.
3. The attacker uses schtasks.exe with the /create parameter to create a new scheduled task.
4. The /TN parameter is used to specify the name of the task, and the /TR parameter defines the program or script to execute.
5. The /SC parameter sets the schedule for the task (e.g., daily, hourly, onlogon), and /RU specifies the user account under which the task will run.
6. The attacker configures the task to run with elevated privileges or under a non-system account to bypass security controls.
7. The scheduled task executes the attacker’s payload at the specified time or event, achieving persistence.
8. The payload may perform various malicious actions, such as installing malware, exfiltrating data, or establishing a command and control channel.

Impact

Successful exploitation can lead to persistent access to the compromised system, allowing attackers to maintain control even after reboots or user logoffs. Attackers can leverage scheduled tasks to escalate privileges, potentially gaining access to sensitive data or critical system resources. The creation of unauthorized scheduled tasks can also be used to move laterally within the network, compromising additional systems and expanding the scope of the attack.

Recommendation

• Enable Sysmon process creation logging with Event ID 1 to capture command-line arguments and process details (reference: Sysmon setup in rule setup).
• Deploy the Sigma rule “Scheduled Task Creation by Non-System Account” to your SIEM to detect suspicious schtasks.exe activity.
• Review and whitelist legitimate scheduled task creation activities in your environment to reduce false positives (reference: False positive analysis).
• Monitor process activity for processes such as cmd.exe, powershell.exe, wscript.exe creating scheduled tasks (reference: query).
• Investigate any scheduled tasks created by non-system accounts that do not have a clear business justification (reference: Investigation Guide).

Attack Chain

1. A user opens a malicious document (e.g., Word, Excel) or executes a seemingly benign application.
2. The document or application contains a macro or script that initiates a cmd.exe process.
3. The cmd.exe process is launched with arguments indicating script execution (/c, /k) and referencing a remote resource (e.g., a URL) or a local batch file.
4. The cmd.exe process attempts to download a payload from a remote server using protocols like HTTP, HTTPS, or FTP.
5. The downloaded payload is saved to disk, often with a disguised filename.
6. The cmd.exe process executes the downloaded payload, initiating further malicious actions.
7. The malicious payload establishes a command and control (C2) channel with a remote server.
8. The attacker uses the C2 channel to send commands to the compromised system, potentially leading to data exfiltration or other malicious activities.

Impact

Successful exploitation can lead to the compromise of Windows endpoints, potentially enabling attackers to download and execute malicious payloads, establish command and control channels, and perform further malicious activities such as data theft, lateral movement, or ransomware deployment. While this detection has a low severity, it serves as an early warning sign of potential compromise and should be investigated promptly.

Recommendation

• Enable process creation logging with command line arguments to capture the full context of cmd.exe executions.
• Monitor network connections from cmd.exe processes, focusing on connections to external IP addresses, using a network monitoring solution.
• Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious cmd.exe network connections.
• Investigate any alerts generated by the Sigma rules, focusing on cmd.exe processes spawned by Office applications or those executing scripts from remote URLs.

Attack Chain

1. The attacker gains initial access to a system within the target network, possibly through compromised credentials or a phishing attack (not directly covered in the provided source).
2. The attacker uses the compromised account to query Active Directory via LDAP.
3. The attacker issues a series of LDAP queries, requesting a large number of attributes for various Active Directory objects, triggering event ID 4662.
4. The event logs record the excessive number of read property accesses (winlog.event_data.Properties), exceeding the threshold of 2000.
5. The attacker analyzes the gathered information to identify potential targets, such as privileged accounts, sensitive data stores, or vulnerable systems.
6. The attacker attempts to elevate privileges by exploiting identified vulnerabilities or misconfigurations within Active Directory.
7. The attacker uses the elevated privileges to access sensitive information or move laterally within the network.
8. The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation allows attackers to gather sensitive information about the Active Directory environment, identify potential vulnerabilities, elevate privileges, and move laterally within the network. This can lead to data breaches, system compromise, and significant disruption to business operations. The number of victims and sectors targeted are dependent on the scope and objectives of the attacker.

Recommendation

• Enable Audit Directory Service Access to generate the necessary events (event code 4662) as mentioned in the setup instructions.
• Deploy the Sigma rule “Suspicious Access to LDAP Attributes” to your SIEM and tune the threshold (length(winlog.event_data.Properties) >= 2000) for your environment.
• Review event logs for event code 4662, focusing on the winlog.event_data.Properties field, to understand which attributes were accessed.
• Investigate the source machine from which the LDAP queries originated by examining the winlog.event_data.SubjectUserSid field.

Attack Chain

1. Initial Access: An attacker gains initial access to a host within the network through an exploit or compromised credentials.
2. Internal Reconnaissance: The attacker performs internal reconnaissance to identify valuable data and potential target systems.
3. Lateral Movement: The attacker uses stolen credentials or exploits remote services (T1210) to gain access to other systems on the network.
4. Tool Transfer: The attacker transfers malicious tools or scripts (T1570) to the compromised systems to facilitate further actions.
5. Data Collection: The attacker gathers sensitive data from the compromised systems.
6. Egress Activity: The attacker initiates numerous small remote file transfers, attempting to blend in with normal network traffic.
7. Data Exfiltration: The attacker exfiltrates the stolen data to an external location.

Impact

A successful lateral movement attack involving anomalous file transfers can lead to data exfiltration, intellectual property theft, and reputational damage. Even though the severity is low, undetected lateral movement can escalate quickly into high severity incidents like ransomware or data breaches. This detection focuses on the early stages of lateral movement, allowing security teams to respond before significant damage occurs.

Recommendation

• Ensure host IP collection is enabled in Elastic Defend configurations, following the steps in the helper guide.
• Install the Lateral Movement Detection integration assets as described in the setup instructions in the rule documentation.
• Investigate alerts generated by the “Spike in Remote File Transfers” rule, paying close attention to the source and destination of the file transfers.
• Review authentication logs for signs of compromised accounts, such as unusual login times or locations, as described in the rule’s triage notes.
• Tune the machine learning job’s anomaly threshold based on your environment’s baseline activity and false positive analysis.

Attack Chain

1. An attacker gains initial access to a Windows system via an exploit or compromised credentials.
2. The attacker executes a script interpreter (e.g., cmd.exe, powershell.exe).
3. Within the script interpreter, the attacker uses sc.exe to manage Windows services.
4. The sc.exe command is used with arguments such as “create”, “start”, “stop”, “delete”, or “config” to manipulate service configurations.
5. A new service is created or an existing service is modified to execute a malicious payload.
6. The malicious service is started, allowing the attacker to execute code with elevated privileges (SYSTEM).
7. The attacker achieves persistence by ensuring the malicious service automatically starts upon system reboot.
8. The attacker may use the created service to execute additional malicious commands or maintain remote access.

Impact

A successful attack could lead to complete system compromise with the attacker gaining SYSTEM level privileges. This can allow for lateral movement within the network, data exfiltration, or installation of persistent backdoors. While the frequency of this specific technique may be low, the potential impact is high due to the elevated privileges gained.

Recommendation

• Deploy the Sigma rule Service Control Spawning via Script Interpreter to your SIEM to detect this specific behavior and tune it to your environment.
• Monitor process creation events for sc.exe being executed by script interpreters like PowerShell or cmd.exe (as covered in the rule description).
• Investigate any instances of sc.exe being used with the arguments “create”, “start”, “stop”, “delete”, or “config” from scripting environments to identify potentially malicious activity.
• Ensure proper access controls are in place to limit the ability of users to create or modify services.