Attack Chain

1. Attacker gains initial access to a Kubernetes cluster, potentially through a compromised application or misconfigured service.
2. Attacker uses kubectl exec or similar tools to execute commands within a pod.
3. The executed command attempts to read sensitive files or directories within the pod’s filesystem, such as /var/run/secrets/kubernetes.io/serviceaccount/token to obtain the pod’s service account token.
4. The command may also target host-level files if the pod has hostPath mounts or runs in a privileged context, like /etc/shadow or /etc/passwd for credential access.
5. The attacker may attempt to dump process environments via /proc/<pid>/environ to extract sensitive information stored as environment variables.
6. The attacker leverages obtained credentials or configuration to move laterally to other pods or nodes within the cluster.
7. The attacker escalates privileges within the cluster by abusing stolen service account tokens or node credentials.
8. The final objective is to exfiltrate sensitive data, deploy malicious workloads, or disrupt services within the Kubernetes environment.

Impact

A successful attack can lead to the compromise of sensitive data, including credentials, configuration files, and application secrets. This can enable attackers to move laterally within the Kubernetes cluster, escalate privileges, and potentially gain control over the entire environment. The severity of the impact depends on the sensitivity of the data exposed and the level of access achieved by the attacker.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect sensitive file access within Kubernetes pod exec sessions.
• Investigate any alerts triggered by the Sigma rule, focusing on the Esql.access_type field to prioritize incidents.
• Review and tighten RBAC permissions for pod exec to limit access to authorized users and service accounts.
• Implement admission controls to prevent pods from running in privileged mode or using hostPath mounts unless absolutely necessary.
• Monitor Kubernetes audit logs for suspicious kubectl exec activity, including unusual command lines or access patterns.
• Regularly rotate Kubernetes service account tokens and other sensitive credentials to minimize the impact of potential breaches.
• Use the provided Kubernetes audit log query to proactively search for historical instances of sensitive file access.

Attack Chain

1. An attacker gains read access to Kubernetes pod logs within the Argo Workflows namespace. This could be achieved through compromised credentials, misconfigured RBAC policies, or other Kubernetes vulnerabilities.
2. The attacker identifies a workflow that utilizes artifact storage, such as S3 or GCS.
3. The workflow executes an artifact operation (upload or download).
4. Argo Workflows logs the entire ArtifactDriver struct, including the plaintext credentials, into the pod logs.
5. The attacker queries the pod logs using kubectl or other Kubernetes tooling. For example: kubectl -n argo logs "cred-leak-test" -c wait.
6. The attacker extracts the plaintext credentials (e.g., S3 Access Key and Secret Key) from the log output.
7. The attacker uses the extracted credentials to access the artifact repository (e.g., S3 bucket) and potentially steal data or perform other unauthorized actions.

Impact

Successful exploitation of this vulnerability allows unauthorized access to artifact repositories used by Argo Workflows. This can lead to data breaches, as sensitive data stored in S3 buckets, GCS buckets, or other storage solutions can be exposed. The impact is especially severe if the compromised credentials have broad permissions or if the artifact repository contains highly sensitive data. This affects Argo Workflows versions 4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4.

Recommendation

• Upgrade Argo Workflows to version 4.0.5 or later to remediate the vulnerability (CVE-2026-42295).
• Review and restrict Kubernetes RBAC permissions to limit access to pod logs, following the principle of least privilege.
• Implement log monitoring and alerting for unusual access patterns to Kubernetes pod logs.
• Rotate any potentially exposed artifact repository credentials (S3 access keys, GCS service account keys, etc.) if Argo Workflows versions 4.0.0-4.0.4 were in use.

Attack Chain

1. The attacker gains initial access to a system with sufficient privileges to modify DNS records, often an Active Directory account.
2. The attacker disables the Global Query Block List (GQBL) to allow the creation of unauthorized DNS records.
3. The attacker creates a new DNS record for “wpad” in Active Directory DNS, using event code 5137.
4. The ‘ObjectDN’ attribute of the DNS record contains “DC=wpad,*”.
5. Clients on the network query the DNS server for the “wpad” record.
6. The DNS server responds with the attacker-controlled IP address.
7. Clients automatically configure their proxy settings to use the attacker’s proxy server.
8. The attacker intercepts network traffic, potentially capturing credentials and sensitive data.

Impact

Successful WPAD spoofing can allow attackers to intercept sensitive information, including credentials, as users browse the web. This can lead to further compromise of systems and data within the network. While the number of victims is difficult to quantify, the impact can be significant within an organization if the attack is successful. This attack targets organizations using default WPAD settings.

Recommendation

• Enable Audit Directory Service Changes to generate Windows Security Event Logs (event code 5137) as described in the setup instructions to ensure the rule functions correctly.
• Deploy the Sigma rule “Potential WPAD Spoofing via DNS Record Creation” to your SIEM to detect suspicious “wpad” record creations.
• Review Active Directory change history when the Sigma rule triggers to determine who made the changes to the DNS records and whether these changes were authorized, as outlined in the investigation guide.
• Regularly verify the configuration of the Global Query Block List (GQBL) to ensure it has not been disabled or altered, as described in the investigation guide.

Attack Chain

1. Attacker gains initial access to the network through various means (e.g., phishing, exploiting a vulnerability).
2. The attacker initiates a forced authentication attack (T1187) to coerce a target machine to authenticate to a system under the attacker’s control.
3. The attacker captures the NTLM hash of a computer account, which is automatically generated for every machine joined to the domain.
4. The attacker uses the captured NTLM hash to relay authentication requests to other systems on the network. This leverages the “Adversary-in-the-Middle” technique (T1557), specifically “LLMNR/NBT-NS Poisoning and SMB Relay” (T1557.001).
5. The relay attack manifests as a network logon event (event code 4624 or 4625) where the source IP address does not match the IP address of the host that owns the computer account. The AuthenticationPackageName is NTLM.
6. The attacker gains unauthorized access to resources or performs actions on behalf of the compromised computer account.
7. The attacker may then attempt lateral movement, privilege escalation, or data exfiltration depending on the targeted resource.

Impact

Successful NTLM relay attacks against computer accounts can grant attackers unauthorized access to critical systems and data within the Windows domain. This could lead to privilege escalation, lateral movement, and ultimately, compromise of the entire domain. While the exact number of affected organizations is unknown, any organization relying on NTLM authentication and Active Directory is potentially vulnerable. The impact includes data breaches, system compromise, and significant disruption to business operations.

Recommendation

• Enable Audit Logon in Windows to generate the necessary security events for this rule to function, as described in the provided setup instructions.
• Deploy the Sigma rule below to your SIEM to detect potential computer account relay activity and tune for your environment.
• Investigate any alerts generated by the Sigma rule by comparing the source.ip to the target server host.ip addresses to confirm it’s indeed a remote use of the machine account.
• Strengthen network segmentation to limit the attack surface for credential relay attacks, as recommended in the remediation steps.
• Monitor for anomalous authentication patterns and NTLM-related activity to identify and respond to potential relay attacks.

Attack Chain

1. The attacker gains initial access to an account with sufficient privileges to modify Active Directory objects (e.g., Domain Admin).
2. The attacker uses AD management tools (PowerShell, ADSI Edit, etc.) to target a specific user or computer account.
3. The attacker modifies the nTSecurityDescriptor attribute of the targeted account.
4. The attacker grants replication rights to the targeted account by adding specific Access Control Entries (ACEs) containing the GUIDs 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, and 89e95b76-444d-4c62-991a-0facbeda640c.
5. The attacker uses the DCSync technique, impersonating a domain controller, to request password hashes.
6. The Active Directory server, believing the request is legitimate due to the granted replication rights, provides the attacker with the requested credential information.
7. The attacker obtains password hashes for domain users and computers.
8. The attacker uses the obtained credentials for lateral movement, privilege escalation, or data exfiltration.

Impact

Successful exploitation allows attackers to compromise the entire Active Directory domain by gaining access to sensitive credential data. This could lead to complete control over the network, including access to critical systems, sensitive data, and the ability to disrupt business operations. The modification of security descriptors creates a persistent backdoor that can be used repeatedly to harvest credentials.

Recommendation

• Enable Audit Directory Service Changes to generate the necessary event logs for detection (https://ela.st/audit-directory-service-changes).
• Deploy the Sigma rule provided below to detect unauthorized modifications to the nTSecurityDescriptor attribute. Tune the rule to exclude legitimate administrative accounts or scripts that may perform authorized modifications.
• Monitor Windows Security Event Logs (event code 5136) for changes to the nTSecurityDescriptor attribute and investigate any unexpected modifications, focusing on the presence of DCSync-related GUIDs.
• Regularly review and audit Active Directory permissions, focusing on accounts with replication rights, to ensure they are legitimate and necessary.

Attack Chain

1. Initial Access: The attacker gains access to valid user credentials through methods such as phishing, credential stuffing, or malware. (T1078)
2. Successful Logon: The attacker uses the compromised credentials to successfully log in to a Windows system from a new IP address (Event ID 4624, Logon Type Network/RemoteInteractive).
3. Lateral Movement (Possible): Once authenticated, the attacker may attempt to move laterally within the network to access additional resources or systems.
4. Privilege Escalation (Possible): The attacker may attempt to escalate their privileges to gain administrative access to the system or domain (TA0004).
5. Data Exfiltration (Possible): The attacker may attempt to exfiltrate sensitive data from the compromised system or network.
6. Persistence (Possible): The attacker may attempt to establish persistence mechanisms to maintain access to the system or network over time.

Impact

A successful account takeover can have significant consequences, including unauthorized access to sensitive data, lateral movement within the network, privilege escalation, and data exfiltration. The rule specifically looks for logon patterns indicative of account takeover. If an account is taken over, attackers could potentially gain access to systems and data the user has rights to access.

Recommendation

• Deploy the Sigma rule provided below to your SIEM and tune for your environment, paying close attention to the max_logon threshold.
• Enable Audit Logon within Windows to ensure the events needed for detection are available as mentioned in the setup instructions.
• Investigate any alerts generated by the Sigma rule by confirming with the account owner if they logged in from the new source IP.
• Check the new source IP for reputation, geography, and whether it is expected as described in the rule’s triage steps.
• Correlate any generated alerts with other alerts for the same user or source IP such as logon failures, password changes, or MFA changes as part of your investigation.

Attack Chain

1. Initial compromise of a system through an unrelated vulnerability or social engineering.
2. Installation or execution of a GenAI tool (e.g., ollama, lmstudio) on the compromised system.
3. The GenAI tool is configured or instructed to scan the file system for sensitive files.
4. The GenAI tool accesses files containing credentials, such as .aws/credentials, browser password databases (Login Data, key3.db), or SSH keys (.ssh/id_*).
5. The GenAI tool exfiltrates the harvested credentials and API keys to a remote server controlled by the attacker.
6. The attacker uses the stolen credentials to gain unauthorized access to cloud resources, internal systems, or other sensitive accounts.
7. The GenAI tool attempts to modify shell configuration files (e.g., .bashrc, .zshrc) to establish persistence.
8. Upon system restart or user login, the modified shell configuration executes malicious commands, granting the attacker persistent access.

Impact

Successful exploitation of this threat can lead to significant data breaches, unauthorized access to critical systems, and persistent compromise of affected environments. Attackers can leverage stolen credentials to escalate privileges, move laterally within the network, and exfiltrate sensitive data. The number of victims and sectors targeted are currently unknown, but the potential impact is widespread given the increasing adoption of GenAI tools in various industries. Credential theft leads to financial loss, intellectual property theft, and reputational damage.

Recommendation

• Deploy the Sigma rule “GenAI Process Accessing Sensitive Files” to your SIEM to detect GenAI tools accessing sensitive files on endpoints.
• Enable file access monitoring on systems where GenAI tools are used to capture access events for analysis.
• Review and restrict the use of GenAI tools within the environment, especially concerning access to sensitive file paths.
• Monitor for modifications to shell configuration files (e.g., .bashrc, .zshrc, .profile) as an indicator of persistence attempts.
• Implement regular credential rotation policies to minimize the impact of stolen credentials.

Attack Chain

1. The attacker identifies a target Windows system within the network.
2. The attacker sets up a malicious server to receive coerced authentication requests.
3. The attacker crafts a malicious DNS query containing a base64-encoded blob “UWhRCA…BAAAA” representing a marshaled CREDENTIAL_TARGET_INFORMATION structure.
4. The victim system, triggered by an external factor (e.g., RPC call, scheduled task, or web request), attempts to resolve the crafted DNS name.
5. The malicious DNS query is sent to the DNS server, which resolves to the attacker’s server.
6. The victim system initiates a Kerberos authentication request to the attacker’s server, believing it to be a legitimate service.
7. The attacker’s server relays the Kerberos ticket or uses NTLM reflection/relay techniques to gain unauthorized access.
8. The attacker compromises the victim system or pivots to other systems within the network using the stolen credentials.

Impact

Successful exploitation can lead to credential compromise, lateral movement, and domain takeover. Victims in Active Directory environments are particularly vulnerable. The impact includes unauthorized access to sensitive data, disruption of services, and potential ransomware deployment. If the coerced service has high privileges, the attacker can gain complete control over the compromised system or even the entire domain. Organizations using Kerberos authentication are at risk.

Recommendation

• Deploy the “Potential Kerberos SPN Spoofing via Suspicious DNS Query” rule to your SIEM and tune for your environment to detect malicious DNS queries.
• Enable Sysmon Event ID 22 - DNS Query logging to provide the necessary data for detection.
• Investigate and block any DNS queries resolving to external IPs that contain the “UWhRCA…BAAAA” pattern.
• Monitor process creation events for processes initiating DNS queries containing the suspicious pattern, specifically looking for known coercion tools.
• Implement network segmentation to limit the impact of lateral movement if a system is compromised.
• Review and harden Kerberos configurations to prevent SPN spoofing and relay attacks.

Attack Chain

1. Attacker gains initial access to the Kubernetes cluster, potentially through exploiting a vulnerability in a separate application or service running within the cluster, or via compromised credentials.
2. The attacker identifies the IBM Turbonomic prometurbo agent and its associated service account within the compromised cluster.
3. The attacker leverages the compromised service account or operator to interact with the Kubernetes API, exploiting the excessive cluster-wide permissions granted to the prometurbo agent.
4. The attacker utilizes the unrestricted read access to enumerate and exfiltrate sensitive credentials stored as secrets within the cluster, including database passwords, API keys, and other sensitive information.
5. Using the stolen credentials, the attacker escalates privileges by accessing other services and resources within the cluster, such as deploying malicious pods or modifying existing deployments.
6. The attacker achieves persistence by creating or modifying service accounts, roles, and role bindings to maintain access to the cluster even if the initial point of compromise is remediated.
7. The attacker moves laterally within the cluster, compromising additional nodes and workloads to expand their control and access to sensitive data.
8. The attacker achieves full cluster compromise, gaining complete control over all resources and data within the Kubernetes environment.

Impact

A successful exploitation of CVE-2026-6389 can lead to a full compromise of the Kubernetes cluster. This includes unrestricted access to sensitive data and the ability to control all workloads and resources within the environment. The impact includes potential data breaches, service disruptions, and significant financial and reputational damage. Organizations in any sector using the affected versions of IBM Turbonomic are at risk, and the severity is heightened in environments handling sensitive data or critical infrastructure.

Recommendation

• Upgrade IBM Turbonomic prometurbo agent to a version beyond 8.17.6 to patch CVE-2026-6389.
• Review and restrict the permissions granted to the prometurbo agent service account, adhering to the principle of least privilege (reference: CVE-2026-6389).
• Implement Kubernetes audit logging to monitor for unauthorized access to secrets and other sensitive resources (reference: Kubernetes documentation).
• Deploy the Sigma rule “Detect Kubernetes Secret Access via Turbonomic Agent” to identify potential exploitation attempts (reference: Sigma rule below).
• Monitor for unusual activity originating from the prometurbo agent service account, such as attempts to access or exfiltrate large amounts of data (reference: network_connection log source).
• Implement network segmentation to limit the potential impact of a compromised cluster, preventing lateral movement to other environments.

Attack Chain

1. Attacker gains access to a system running a vulnerable Cilium version with WireGuard enabled, or obtains a cilium-bugtool archive.
2. The cilium-bugtool or cilium sysdump command is executed, either manually by a user or an automated process (initiated by the attacker if they have access).
3. The tool collects various debugging information, including the cilium_wg0.key file containing the WireGuard private key.
4. The resulting archive is stored locally, potentially accessible to the attacker.
5. Attacker exfiltrates the cilium-bugtool archive containing the WireGuard private key.
6. The attacker uses the extracted private key to decrypt WireGuard-encrypted traffic between Cilium nodes.
7. The attacker monitors and intercepts sensitive network communications.
8. Attacker pivots within the cluster using the decrypted traffic to discover additional services or escalate privileges.

Impact

Successful exploitation of this vulnerability allows an attacker to decrypt network traffic between Cilium nodes that are using WireGuard encryption. This could lead to the exposure of sensitive data, such as credentials, API keys, or proprietary information. The number of affected deployments is currently unknown, but any Cilium environment using WireGuard encryption and running a vulnerable version is at risk. The impact is significant because it compromises the confidentiality of network communications, potentially enabling further attacks and data breaches.

Recommendation

• Upgrade Cilium to versions v1.19.3, v1.18.9, or v1.17.15 or later to remediate CVE-2026-41520.
• Rotate WireGuard keys on affected nodes if cilium-bugtool archives have been shared externally, as suggested in the advisory. Delete the cilium_wg0.key file and restart the Cilium agent.
• Implement strict access control policies to limit who can execute cilium-bugtool or cilium sysdump commands, preventing unauthorized key disclosure.
• Monitor for unusual execution of cilium-bugtool or cilium sysdump using process monitoring tools. Deploy a Sigma rule that detects unexpected execution paths.

Attack Chain

1. The attacker locates a vulnerable D-Link DWM-222W USB Wi-Fi Adapter within adjacent network range.
2. The attacker initiates network communication with the device, targeting its login interface, likely via HTTP or HTTPS.
3. The attacker sends a series of login requests with different username and password combinations.
4. Due to the brute-force protection bypass, the device does not enforce login attempt limits or implement account lockout mechanisms.
5. The attacker continues sending login requests until the correct credentials are found.
6. Upon successful authentication, the attacker gains administrative access to the D-Link DWM-222W USB Wi-Fi Adapter’s configuration interface.
7. The attacker reconfigures the device to their specifications potentially enabling remote access.

Impact

Successful exploitation of CVE-2026-6947 allows an attacker to gain complete control over the D-Link DWM-222W USB Wi-Fi Adapter. This can lead to unauthorized access to the network it connects to, data interception, or the device being used as a launchpad for further attacks within the network. The impact is significant, as it bypasses standard security measures and grants full administrative privileges to the attacker.

Recommendation

• Monitor network traffic for excessive authentication attempts targeting the D-Link DWM-222W USB Wi-Fi Adapter to detect potential brute-force attacks. Deploy the Sigma rule Detect Excessive Authentication Attempts to identify such activity.
• Implement network segmentation to limit the impact of a compromised D-Link DWM-222W USB Wi-Fi Adapter.
• If possible, disable remote management interfaces on the D-Link DWM-222W USB Wi-Fi Adapter to reduce the attack surface.

Attack Chain

1. Attacker gains initial access to a system via phishing or exploiting a software vulnerability.
2. Attacker installs or deploys a GenAI tool (e.g., LM Studio, Claude, Copilot) on the compromised system.
3. The attacker configures the GenAI tool to scan the file system for specific file names and patterns associated with sensitive data (credentials, keys, cookies).
4. The GenAI tool accesses files such as .aws/credentials, .ssh/id_rsa, browser login databases (e.g., Login Data, logins.json, Cookies), and other credential stores.
5. The GenAI tool may modify shell configuration files (.bashrc, .zshrc) to establish persistence.
6. The GenAI tool stages the collected data for exfiltration.
7. The attacker exfiltrates the harvested credentials and data to an external server.
8. The attacker uses the stolen credentials to gain unauthorized access to other systems or cloud resources.

Impact

Successful exploitation can lead to widespread credential compromise, allowing attackers to move laterally within a network, access sensitive data, and potentially disrupt critical business operations. A single compromised developer workstation could expose cloud infrastructure credentials, impacting hundreds of systems and services. The use of GenAI tools allows for rapid and automated credential harvesting, significantly increasing the scale and speed of potential breaches. Sectors at high risk include software development, cloud computing, and any organization that relies heavily on API keys and secrets for authentication.

Recommendation

• Deploy the Sigma rule GenAI Process Accessing Sensitive Files to your SIEM to detect GenAI tools accessing sensitive files. Tune for your environment to reduce false positives.
• Monitor file access events, specifically looking for GenAI processes (ollama, lmstudio, claude) accessing files with names like credentials, id_rsa, logins.json, and .bashrc, as outlined in the Sigma rule.
• Implement stricter access controls and monitoring for sensitive directories like .aws, .ssh, and browser profile directories.
• Regularly audit and rotate credentials, API keys, and tokens, especially those stored in files.
• Educate developers and users about the risks of using GenAI tools to handle sensitive data.

Attack Chain

1. Attacker gains permission to create TaskRuns or PipelineRuns within a Tekton Pipelines namespace.
2. Attacker crafts a malicious TaskRun or PipelineRun configuration.
3. The configuration specifies the git resolver in API mode.
4. The configuration omits the token parameter but includes a serverURL pointing to an attacker-controlled endpoint.
5. Tekton Pipelines executes the TaskRun or PipelineRun, triggering the git resolver.
6. The ResolveAPIGit() function retrieves the system-configured Git API token using getAPIToken().
7. The function creates an SCM client pointed at the attacker-controlled serverURL with the system token as an Authorization header.
8. Subsequent API calls from the resolver to the attacker-controlled URL transmit the system token, allowing the attacker to capture it.

Impact

Successful exploitation allows an attacker to exfiltrate the system Git API token (GitHub PAT, GitLab token, etc.). The exfiltrated token can be used to access private repositories, potentially leading to the exposure of sensitive information like source code, secrets, and CI/CD configurations. This can lead to supply chain compromise, data breaches, or other unauthorized activities. All Tekton Pipeline instances running versions v1.0.0 through v1.10.0 are potentially vulnerable if a system-level API token is configured.

Recommendation

• Do not configure a system-level API token in the git resolver ConfigMap. Instead, require all users to provide their own tokens via the token parameter, as suggested in the advisory’s workaround section.
• Restrict TaskRun creation to limit which users or ServiceAccounts can create TaskRuns and PipelineRuns that use the git resolver, as recommended in the advisory’s workaround section.
• Apply NetworkPolicy to the tekton-pipelines-resolvers namespace to restrict outbound traffic to known-good Git servers only, mitigating the risk of token exfiltration to arbitrary serverURL values.

Attack Chain

1. An attacker gains access to a Kubernetes tenant with permissions to create TaskRun or PipelineRun resources within Tekton Pipelines.
2. The attacker crafts a malicious TaskRun or PipelineRun configuration.
3. The configuration leverages the Tekton Pipelines git resolver in API mode.
4. The attacker omits the token parameter in the git resolver configuration, forcing the system to use the system-configured Git API token.
5. The attacker sets the serverURL parameter to an attacker-controlled endpoint.
6. Tekton Pipelines, upon execution of the TaskRun or PipelineRun, sends the system-configured Git API token to the attacker-controlled serverURL.
7. The attacker’s server logs and captures the leaked Git API token.
8. The attacker uses the exfiltrated token to access and potentially compromise Git repositories or other services authenticated by the token.

Impact

Successful exploitation of CVE-2026-40161 allows an attacker to steal the system-configured Git API token used by Tekton Pipelines. This could lead to unauthorized access to Git repositories, the modification of code, and the potential compromise of the entire CI/CD pipeline. Given Tekton’s widespread adoption, a successful attack could affect numerous organizations using the vulnerable versions.

Recommendation

• Upgrade Tekton Pipelines to a version greater than 1.10.0 to remediate CVE-2026-40161.
• Implement strict access controls within the Kubernetes cluster to limit TaskRun and PipelineRun creation privileges to authorized users only.
• Monitor network traffic originating from Tekton Pipeline pods for connections to unusual or untrusted serverURL destinations as specified in CVE-2026-40161. Create a network connection rule for this.
• Review Tekton Pipeline configurations for suspicious serverURL parameters using a file monitoring rule.

Attack Chain

1. A developer introduces a vulnerable version of goshs (prior to 2.0.0-beta.6) into a project’s dependencies.
2. The project utilizes GitHub Actions or a similar CI/CD system.
3. The CI/CD workflow is configured to use or interact with the GITHUB_TOKEN.
4. Due to the ArtiPACKED vulnerability, the GITHUB_TOKEN becomes exposed within the workflow’s generated artifacts.
5. An attacker gains access to these workflow artifacts, potentially through misconfigured permissions or compromised systems.
6. The attacker extracts the leaked GITHUB_TOKEN from the artifacts.
7. The attacker uses the compromised GITHUB_TOKEN to authenticate to the GitHub repository.
8. With the compromised token, the attacker can perform actions such as code modification, secret retrieval, or infrastructure changes depending on the token’s permissions.

Impact

Successful exploitation of CVE-2026-40903 can lead to the leakage of sensitive GITHUB_TOKEN credentials, potentially granting unauthorized access to the affected GitHub repository. The impact of this vulnerability could include code tampering, unauthorized access to secrets, and potential compromise of associated infrastructure. The CVSS v3.1 score of 9.1 highlights the critical nature of this vulnerability. The number of affected organizations depends on the adoption rate of vulnerable goshs versions.

Recommendation

• Upgrade goshs to version 2.0.0-beta.6 or later to remediate the ArtiPACKED vulnerability as detailed in CVE-2026-40903.
• Review and restrict the permissions granted to the GITHUB_TOKEN in GitHub Actions workflows to minimize potential impact if the token is compromised.
• Implement artifact scanning tools to detect potential secrets leakage in CI/CD workflow artifacts.
• Monitor GitHub audit logs for suspicious activity originating from the GITHUB_TOKEN, particularly after the introduction or update of goshs.

Attack Chain

1. An attacker gains low-privileged access to the Cisco Catalyst SD-WAN Manager system through legitimate credentials or other vulnerabilities.
2. The attacker navigates the filesystem to locate the DCA user’s credential file.
3. The attacker reads the credential file, which contains the DCA user’s password in a recoverable format.
4. The attacker decodes or decrypts the password using readily available tools or techniques.
5. The attacker uses the recovered DCA user credentials to authenticate to the SD-WAN Manager with elevated privileges.
6. The attacker leverages the DCA user privileges to perform unauthorized configuration changes or access sensitive data.
7. The attacker potentially pivots to other systems or network segments accessible through the SD-WAN infrastructure.

Impact

Successful exploitation of this vulnerability allows an attacker to gain complete control over the Cisco Catalyst SD-WAN Manager. This could lead to significant disruption of network services, data breaches, and potential compromise of connected systems. The impact is magnified by the widespread use of SD-WAN in enterprise environments, making this a critical vulnerability for organizations utilizing Cisco Catalyst SD-WAN Manager.

Recommendation

• Review and apply the mitigations outlined in CISA’s Emergency Directive 26-03 and associated guidance for Cisco SD-WAN devices, as referenced in the overview.
• Monitor file access events on the Cisco Catalyst SD-WAN Manager system for suspicious access patterns to credential files using the Detect Suspicious SD-WAN Credential File Access Sigma rule.
• Implement stricter access controls and password policies on the Cisco Catalyst SD-WAN Manager to prevent unauthorized access.
• Apply the security updates provided by Cisco to patch CVE-2026-20128 as they become available.

Attack Chain

Given the broad nature of the advisory, the following attack chain is constructed based on the potential capabilities granted by exploiting the vulnerabilities:

1. Initial Access: An attacker exploits a remote code execution vulnerability in Dell PowerProtect Data Domain OS, potentially through a network service or web interface.
2. Privilege Escalation: The attacker leverages an additional vulnerability to escalate privileges from an initial low-privilege shell to root access.
3. Defense Evasion: With root privileges, the attacker disables or bypasses security measures, such as intrusion detection systems or anti-malware software.
4. Credential Access: The attacker gains access to stored credentials, such as those used for backups or system administration, by dumping the system’s credential store.
5. Data Manipulation: The attacker modifies data stored within the Dell PowerProtect Data Domain system, potentially corrupting backups or injecting malicious code into stored files.
6. Information Disclosure: The attacker extracts sensitive information, such as customer data, internal documents, or system configurations.
7. Lateral Movement: Using the compromised Data Domain OS, the attacker can pivot to other systems within the network leveraging the credentials obtained or the trust relationships established.
8. Impact: The attacker achieves their final objective, which may include data exfiltration, system disruption, or ransomware deployment.

Impact

Successful exploitation of these vulnerabilities could result in significant damage to organizations utilizing Dell PowerProtect Data Domain OS. This could include data loss due to corruption or deletion, financial losses from service disruption, reputational damage, and legal repercussions from the disclosure of sensitive information. The absence of specific victim counts or sector targeting makes quantifying the impact difficult, but the potential for widespread disruption and data compromise is high.

Recommendation

• Investigate Dell’s security advisories and apply the necessary patches to address the vulnerabilities in PowerProtect Data Domain OS as soon as they become available.
• Implement network segmentation to limit the potential impact of a compromised Data Domain OS on other systems.
• Enable logging on Dell PowerProtect Data Domain OS, including process creation and network connection logs, to detect potential exploitation attempts and investigate suspicious activity, allowing the deployment of the Sigma rules below.
• Monitor for unauthorized access attempts to Dell PowerProtect Data Domain OS through webserver logs, specifically looking for suspicious cs-uri-query strings (see rule “Detect Web Request for Potential Dell PowerProtect Exploit”).

Attack Chain

1. Attacker gains initial local access to a system running vulnerable Intel firmware (IPU or UEFI Reference Firmware).
2. Attacker executes a specially crafted program designed to interact with the vulnerable firmware components.
3. The crafted program leverages a vulnerability to bypass security checks or access control mechanisms within the firmware.
4. The vulnerability allows the attacker to read memory regions containing sensitive information, such as credentials or cryptographic keys.
5. Alternatively, the attacker uses the vulnerability to modify firmware settings or inject malicious code into the firmware execution path.
6. Modified firmware grants the attacker elevated privileges within the system, potentially allowing them to bypass operating system security controls.
7. The attacker leverages the elevated privileges to access sensitive files, install malware, or perform other malicious activities.
8. Attacker maintains persistence by exploiting the firmware vulnerabilities.

Impact

Successful exploitation of these vulnerabilities could allow a local attacker to gain complete control over the affected system. This could result in the theft of sensitive data, the installation of persistent malware, or the disruption of system operations. Since the vulnerable components are low-level firmware, the impact is significant, as it can bypass most operating system security measures.

Recommendation

• Monitor process creation events for unusual or unsigned binaries attempting to access memory regions typically reserved for firmware components (covered by the process creation rule below).
• Investigate any suspicious modifications to UEFI settings or firmware configurations.
• Regularly update firmware to the latest versions provided by the vendor.

Attack Chain

1. The attacker identifies an Anviz CrossChex Standard instance exposed to network access.
2. The attacker initiates a connection to the TDS7 PreLogin port.
3. The attacker crafts a malicious TDS7 PreLogin packet to negotiate a connection without encryption.
4. The CrossChex Standard software, due to the vulnerability, accepts the unencrypted connection.
5. The software transmits database credentials in plaintext over the unencrypted channel.
6. The attacker intercepts the plaintext database credentials.
7. The attacker uses the obtained credentials to authenticate directly to the database server.
8. The attacker gains unauthorized access to the CrossChex Standard database, enabling them to read, modify, or delete sensitive data.

Impact

Successful exploitation of CVE-2026-32650 allows unauthorized access to the Anviz CrossChex Standard database. This can lead to the exposure of sensitive employee data, including personal information and access control details. Depending on the database permissions, an attacker could also modify time and attendance records, manipulate user accounts, or even compromise the entire physical access control system managed by CrossChex Standard. The impact could range from privacy violations to significant security breaches affecting physical premises.

Recommendation

• Apply available patches or updates for Anviz CrossChex Standard as provided by the vendor to remediate CVE-2026-32650.
• Monitor network traffic for connections to the TDS7 PreLogin port that do not negotiate encryption using the provided network connection Sigma rule.
• Restrict network access to the TDS7 PreLogin port only to trusted hosts and networks using firewall rules to mitigate the risk of unauthorized access.
• Enable logging on the database server and monitor for successful logins from unusual IP addresses or accounts after applying the network connection Sigma rule.

Attack Chain

1. Attacker sets up a malicious Git repository on a server under their control. This repository contains a Git configuration that triggers an NTLM authentication request to the attacker’s server.
2. The attacker crafts a social engineering campaign to entice the victim to clone the malicious repository using the git clone command.
3. Alternatively, the attacker compromises an existing Git repository and adds a malicious branch. The victim is then tricked into checking out this branch using git checkout.
4. When the victim clones the repository or checks out the malicious branch, Git for Windows attempts to authenticate with the attacker’s server using the NTLM protocol.
5. The victim’s NTLMv2 hash is sent to the attacker’s server during the NTLM authentication handshake.
6. The attacker captures the NTLMv2 hash from the authentication traffic.
7. The attacker initiates an offline brute-force attack against the captured NTLMv2 hash.
8. Upon successful brute-forcing, the attacker recovers the victim’s credentials and can use them to access other resources.

Impact

Successful exploitation of CVE-2026-32631 allows attackers to steal user credentials. The impact includes unauthorized access to sensitive data, systems, and applications accessible with the compromised credentials. The number of potential victims is directly related to the number of users running vulnerable versions of Git for Windows who interact with malicious repositories or branches. Targeted sectors are broad, encompassing any organization using Git for Windows for software development and version control.

Recommendation

• Upgrade Git for Windows to version 2.53.0.windows.3 or later to remediate CVE-2026-32631.
• Implement network monitoring to detect NTLM authentication attempts originating from Git processes to unusual or external destinations.
• Deploy the Sigma rule “Detect Git Process Spawning Cmd with /c net use” to detect potential NTLM authentication attempts and adjust it to monitor outbound network connections from git.exe using NTLM.

Attack Chain

1. Attacker gains access to a Splunk account with permissions to the _internal index or possesses the mcp_tool_admin capability.
2. The attacker accesses the _internal index through the Splunk web interface or directly via file system access (if local access is available).
3. The attacker searches the _internal index for logs related to MCP Server activity.
4. The attacker identifies log entries containing user session tokens and authorization tokens.
5. The attacker extracts the cleartext tokens from the log entries.
6. The attacker uses the stolen session tokens to impersonate legitimate users.
7. The attacker leverages the impersonated user’s privileges to access sensitive data or perform unauthorized actions.

Impact

Successful exploitation of CVE-2026-20205 allows an attacker to obtain user session and authorization tokens in cleartext. This compromises the confidentiality and integrity of the Splunk environment. An attacker could impersonate legitimate users, escalate privileges, and gain unauthorized access to sensitive data. The number of potential victims depends on the number of Splunk users and the extent of the misconfiguration. Sectors that heavily rely on Splunk for security monitoring, such as finance, healthcare, and government, are particularly at risk.

Recommendation

• Upgrade Splunk MCP Server app to version 1.0.3 or later to remediate CVE-2026-20205.
• Review and restrict access to the _internal index to administrator-level roles only, following Splunk’s documentation on defining roles.
• Monitor Splunk audit logs for unusual access patterns to the _internal index using the Sigma rule Splunk Unusual Internal Index Access.
• Review and restrict the mcp_tool_admin capability to only authorized personnel.

Attack Chain

1. The attacker identifies a valid email address associated with a Chamilo LMS user. This information may be obtained through OSINT or data breaches.
2. The attacker navigates to the password reset page of the Chamilo LMS instance.
3. The attacker enters the victim’s email address into the password reset form.
4. The system generates a password reset token by applying SHA1 to the victim’s email address without any salt or random component.
5. The attacker computes the SHA1 hash of the victim’s email address offline.
6. The attacker uses the computed SHA1 hash as the password reset token in a crafted request to the password reset confirmation endpoint.
7. The Chamilo LMS instance validates the attacker-supplied token against the SHA1 hash of the email.
8. The attacker sets a new password for the victim’s account and gains full access to the compromised account.

Impact

Successful exploitation of CVE-2026-33707 allows an attacker to take complete control of user accounts within the Chamilo LMS platform. This can lead to data breaches, modification of course content, disruption of educational activities, and potential reputational damage for the affected institution. The lack of rate limiting on password reset requests can allow for automated account takeover attempts affecting many users. Given the widespread use of Chamilo LMS in educational institutions and organizations globally, the potential impact is significant.

Recommendation

• Immediately upgrade Chamilo LMS installations to version 1.11.38 or 2.0.0-RC.3 to remediate CVE-2026-33707.
• Implement rate limiting on password reset requests to mitigate automated attacks attempting to exploit this vulnerability (reference: Overview section).
• Deploy the Sigma rules below to detect attempts to exploit this vulnerability by monitoring password reset requests (reference: rules section).
• Monitor web server logs for suspicious password reset requests originating from unusual IPs or with unusually high frequency (reference: rules logsource).

Attack Chain

1. Initial Access: Adversary gains access to valid credentials or session tokens through various means like phishing, malware, or exposed credentials. (T1555, T1566)
2. Authentication: Adversary uses the compromised credentials or tokens to authenticate to one of the cloud provider’s API (AWS, Azure, GCP).
3. Discovery (AWS): The adversary leverages the AWS CLI or API to enumerate available secrets stored in AWS Secrets Manager using GetSecretValue API calls.
4. Discovery (Azure): The adversary uses compromised credentials to interact with Azure Key Vault, utilizing SecretGet or KeyGet actions to discover accessible secrets.
5. Discovery (GCP): The adversary uses compromised service account or user credentials to access Google Secret Manager and enumerate accessible secrets using google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion or google.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest.
6. Discovery (Kubernetes): The adversary uses compromised credentials to access the Kubernetes API and enumerate secrets within the cluster, specifically targeting the secrets resource with get or list verbs.
7. Credential Access: The adversary retrieves the secret values from each cloud provider and Kubernetes cluster. (T1555.006)
8. Exfiltration/Lateral Movement: The adversary exfiltrates the retrieved secrets for further malicious activities, such as lateral movement within the cloud environments or unauthorized access to sensitive data.

Impact

A successful attack can lead to the exfiltration of sensitive data, including API keys, database passwords, and encryption keys. This could result in unauthorized access to critical systems and data, potentially leading to data breaches, financial loss, and reputational damage. The impact is amplified in multi-cloud environments as the adversary can leverage the compromised secrets to move laterally between different cloud providers, increasing the scope and severity of the attack.

Recommendation

• Deploy the provided Sigma rule “Multiple Cloud Secrets Accessed by Source Address” to your SIEM to detect this activity across your cloud environments. Enable required logging: GCP Audit DATA_READ for Secret Manager API, Azure Key Vault Diagnostic Logging, and AWS CloudTrail for Secrets Manager.
• Investigate any alerts triggered by the Sigma rule by validating the principal (user, service account) and reviewing related activity (authentication, privilege escalation). Check application context, user agent, and IP reputation as detailed in the rule’s triage steps.
• Restrict or disable affected credentials or service accounts and rotate all accessed secrets if the activity is unauthorized or suspicious, as described in the rule’s Response and Remediation steps.
• Harden identity security by enforcing MFA, reducing permissions to least privilege, and reviewing trust relationships. Audit visibility should be improved by ensuring logging is enabled across all cloud environments.

Attack Chain

1. Initial Compromise: An attacker gains unauthorized access to a service principal’s credentials (e.g., through credential stuffing, phishing, or exposed secrets).
2. Service Principal Authentication: The attacker uses the compromised service principal credentials to authenticate to Microsoft Entra ID (Azure AD) using the ServicePrincipalSignInLogs.
3. Credential Listing Request: Immediately following successful authentication, the attacker leverages the service principal to initiate a request to list the cluster user credentials for an Azure Arc-connected Kubernetes cluster, triggering the MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION in the Activity Logs.
4. Credential Retrieval: The attacker retrieves the Arc cluster credentials.
5. Proxy Tunnel Establishment: The attacker uses the retrieved credentials to establish a proxy tunnel into the Kubernetes cluster via the Arc Cluster Connect proxy.
6. Kubernetes Access: With the tunnel established, the attacker can now execute kubectl commands, perform unauthorized actions within the cluster, such as creating, reading, updating, and deleting (CRUD) secrets and configmaps.
7. Lateral Movement & Privilege Escalation: The attacker exploits vulnerabilities or misconfigurations within the Kubernetes cluster to move laterally to other resources, escalate privileges, and gain further control.
8. Data Exfiltration or Ransomware Deployment: The attacker exfiltrates sensitive data from the Kubernetes cluster or deploys ransomware to encrypt critical data, impacting business operations.

Impact

Successful exploitation of this attack chain can lead to complete compromise of Azure Arc-connected Kubernetes clusters. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and potentially deploy ransomware. The IBM X-Force team has documented cases of attackers using similar techniques for hybrid escalation and persistence. This can impact organizations across all sectors utilizing Azure Arc for managing Kubernetes clusters, potentially affecting dozens or hundreds of clusters per victim organization.

Recommendation

• Deploy the provided Sigma rules to your SIEM and tune for your environment to detect the sequence of service principal sign-in followed by Arc cluster credential access.
• Review Azure AD Audit Logs for recent changes to service principals, focusing on new credentials, federated identities, and owner changes, based on the investigation steps outlined in the rule’s note.
• Enable conditional access policies to restrict service principal authentication by location to prevent logins from unexpected regions, as suggested in the rule’s note.
• Monitor Azure Activity Logs for MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION events to identify potential unauthorized access attempts.
• Rotate service principal credentials regularly and revoke active sessions and tokens for the SP as outlined in the rule’s response and remediation steps.

Attack Chain

1. The attacker deploys information-stealing malware on a victim’s Windows or macOS system.
2. The malware gains access to the browser’s local files and memory, where authentication cookies are stored.
3. The malware exfiltrates the stolen session cookies to a command-and-control server.
4. The attacker attempts to use the stolen session cookies to access the victim’s accounts on various web platforms.
5. If DBSC is not implemented, the attacker successfully gains unauthorized access to the user’s accounts.
6. If DBSC is implemented, Chrome checks for device-bound credentials.
7. The web server requires proof of possession of the private key associated with the session. Since the attacker lacks this key, the exfiltrated cookies are useless.
8. The attacker’s attempt to access the account is blocked, preventing unauthorized access.

Impact

The successful exploitation of stolen session cookies can lead to unauthorized access to user accounts across various platforms, potentially resulting in data breaches, financial loss, and reputational damage. While the article does not cite specific victim counts or sectors affected, the widespread use of Chrome and the prevalence of cookie-stealing malware makes this a significant threat. The implementation of DBSC aims to significantly reduce the risk of account compromise via stolen cookies.

Recommendation

• Detection engineers should familiarize themselves with the concept and deployment of Device Bound Session Credentials (DBSC) to understand its impact on existing detection strategies.
• Monitor for the presence of information-stealing malware that targets browser cookie storage locations using file_event and process_creation log sources.
• Consider deploying the Sigma rule to detect anomalous processes accessing browser cookie storage locations to identify potential cookie theft attempts.

Attack Chain

1. Attacker gains initial access to LiteLLM and authenticates as a low-privilege user.
2. Attacker sends a request to /user/info to retrieve the password hash of another user.
3. The API responds with the target user’s SHA-256 password hash.
4. Attacker sends a POST request to the /v2/login endpoint using the stolen SHA-256 hash as the password.
5. The /v2/login endpoint accepts the raw SHA-256 hash without re-hashing.
6. The server authenticates the attacker as the target user.
7. Attacker now has the privileges of the target user, potentially gaining access to sensitive data or administrative functions.

Impact

Successful exploitation of this vulnerability leads to unauthorized access and privilege escalation within the LiteLLM application. An attacker can impersonate other users, including administrators, potentially leading to data breaches, system compromise, and unauthorized modifications. The number of victims depends on the deployment size, but any LiteLLM instance running a version prior to 1.83.0 is vulnerable. Sectors utilizing LiteLLM are at risk.

Recommendation

• Upgrade LiteLLM to version 1.83.0 or later to patch the vulnerability (reference: Patches section).
• Deploy the Sigma rule “Detect LiteLLM User Info Hash Access” to monitor for unauthorized access to user password hashes via the /user/info endpoint (reference: rule: “Detect LiteLLM User Info Hash Access”).
• Deploy the Sigma rule “Detect LiteLLM Login with SHA256 Hash” to detect login attempts using SHA256 hashes (reference: rule: “Detect LiteLLM Login with SHA256 Hash”).

Attack Chain

1. An attacker gains access to a valid AWS IAM Long-Term Access Key. This could be through phishing, credential stuffing, or exposed credentials in source code.
2. The attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the “AWS Long-Term Access Key First Seen from Source IP” rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).
3. The attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.
4. The attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.
5. The attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.
6. The attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.
7. The correlation rule identifies the co-occurrence of the “AWS Long-Term Access Key First Seen from Source IP” alert and other elevated severity alerts associated with the same access key ID.
8. The security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.

Impact

A successful attack leveraging compromised AWS IAM credentials can lead to significant data breaches, service disruption, and financial losses. Attackers can gain unauthorized access to sensitive data stored in S3 buckets, compromise EC2 instances, and disrupt critical AWS services. The correlation rule aims to reduce the dwell time of attackers by prioritizing the investigation of compromised credentials associated with ongoing malicious activity. This can prevent attackers from further escalating their attacks and minimizing the overall impact of the breach. Failure to detect and respond to these attacks can result in regulatory fines, reputational damage, and loss of customer trust.

Recommendation

• Deploy the “AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts” rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.
• Investigate alerts triggered by the rule by pivoting on the aws.cloudtrail.user_identity.access_key_id in CloudTrail and IAM to understand the context of the access key usage.
• Review the sibling alerts identified by the rule using Esql.kibana_alert_rule_name_values and Esql.kibana_alert_rule_id_values to understand the scope and impact of the potential compromise.
• Configure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that kibana.alert.risk_score >= 47 corresponds to medium or higher severity alerts.
• Rotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.
• Enable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.
• Implement the “AWS Long-Term Access Key First Seen from Source IP” rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.

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. Attacker authenticates to a vulnerable Directus instance with valid user credentials.
2. Attacker identifies a collection containing fields with the conceal special type, such as directus_users.
3. Attacker crafts an aggregate query using functions like min or max on the concealed field and includes a groupBy clause. Example: SELECT min(secret_field) FROM collection GROUP BY other_field.
4. The Directus server processes the aggregate query but fails to properly apply the masking logic to the nested results.
5. The server returns the raw, unmasked values of the concealed field in the aggregate query response.
6. The attacker extracts static API tokens and TOTP seeds from the returned data.
7. Attacker uses the extracted API tokens to authenticate as other users, including administrators, bypassing username/password requirements.
8. Attacker uses the extracted TOTP seeds to bypass two-factor authentication for other users, gaining unauthorized access to their accounts.

Impact

Successful exploitation of this vulnerability can lead to complete account takeover, including administrative accounts. Two-factor authentication mechanisms can be bypassed, invalidating this security control. The number of affected organizations depends on the adoption rate of Directus, but all instances running versions prior to 11.17.0 are vulnerable. If the attack succeeds, attackers gain full control over the Directus instance and associated data, potentially leading to data breaches, service disruption, and reputational damage.

Recommendation

• Upgrade Directus to version 11.17.0 or later to patch the vulnerability (CVE-2026-35442).
• Implement a Web Application Firewall (WAF) rule to detect and block aggregate queries targeting concealed fields in sensitive collections. See the Sigma rule example for guidance.
• Monitor Directus application logs for unusual aggregate query patterns, especially those involving groupBy and functions like min or max.

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 victim attempts to access a web server (e.g., web01.test.local).
2. A DNS query is initiated to resolve the hostname of the target web server.
3. The attacker intercepts the DNS query and responds with a crafted DNS response containing a CNAME record that redirects the original hostname (web01.test.local) to an attacker-controlled target (e.g., CA01.test.local), along with an A record pointing to the attacker’s IP address.
4. The victim’s system accesses the attacker-controlled web server.
5. The malicious web server sends a 401 HTTP response to initiate Kerberos authentication.
6. The victim requests a Kerberos service ticket for HTTP/CA01.test.local from the domain controller.
7. The domain controller issues a service ticket for the requested SPN.
8. The attacker relays the Kerberos ticket to the AD CS web enrollment endpoint (/certsrv) to request a certificate for the victim user, thereby achieving persistent access.

Impact

Successful exploitation of CVE-2026-20929 allows an attacker to enroll certificates on behalf of domain users, granting them persistent access to the network. Certificates are often valid for extended periods (1+ years) and are less frequently monitored than password-based authentication. This attack can bypass controls that disable NTLM authentication, and web enrollment over HTTP prevents Channel Binding Token (CBT) protection, making AD CS web enrollment an attractive relay target. The number of potential victims depends on the number of vulnerable AD CS deployments.

Recommendation

• Monitor for anomalous certificate-based authentication events combined with unusual AD CS service access within a short time window, as highlighted in the “CrowdStrike has developed a correlation-based detection” statement in the overview.
• Disable web enrollment over HTTP to enforce Channel Binding Token (CBT) protection, mitigating the risk of successful relay attacks, as mentioned in the “Why AD CS Web Enrollment Is an Attractive Relay Target” section.
• Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect potential exploitation attempts.
• Review and harden AD CS configurations based on recommendations from “Certified Pre-Owned” research to reduce the attack surface.

Attack Chain

1. A user generates a pairing setup code using the /pair endpoint or OpenClaw qr command. This code contains the embedded shared gateway credentials.
2. The setup code is shared with the intended recipient via chat, logs or screenshots.
3. The attacker gains access to the setup code through compromised chat history, exposed logs, or publicly shared screenshots.
4. The attacker extracts the long-lived shared gateway credential from the setup code.
5. The attacker reuses the stolen shared gateway credentials outside of the intended one-time pairing flow.
6. The attacker gains unauthorized access to the shared gateway.
7. The attacker leverages the access gained via the gateway for further malicious activities.

Impact

Successful exploitation of this vulnerability allows attackers to bypass the intended one-time pairing flow and gain unauthorized access to the shared gateway. The number of potential victims is dependent on the number of OpenClaw deployments and the exposure of pairing setup codes. The primary impact is unauthorized access and potential compromise of sensitive data accessible through the shared gateway.

Recommendation

• Upgrade OpenClaw to version 2026.3.12 or later to remediate the vulnerability (CVE-2026-33575).
• Implement strict controls over the handling and storage of pairing setup codes to prevent unauthorized access.
• Monitor network traffic for suspicious activity originating from OpenClaw gateways, potentially indicating unauthorized access using leaked credentials.
• Deploy the Sigma rule to detect the usage of the /pair endpoint which could indicate unauthorized pairing attempts.

Attack Chain

1. Attacker compromises or sets up a malicious HTTP server.
2. Attacker crafts a response that includes an HTTP redirect (301, 302, 307, or 308) to a domain controlled by the attacker. This redirect targets a resource on the attacker’s controlled domain.
3. A client application using a vulnerable version of cpp-httplib (prior to 0.39.0) attempts to access a resource on the compromised or malicious server.
4. The cpp-httplib library in the client application receives the HTTP redirect response.
5. The vulnerable library incorrectly appends any stored Authorization headers (Basic Auth, Bearer Token, or Digest Auth) to the redirected request, even though it’s a cross-origin request.
6. The client application, through cpp-httplib, sends the redirected request to the attacker-controlled host, including the sensitive Authorization header.
7. The attacker captures the Authorization header, extracting the plaintext credentials.
8. The attacker uses the stolen credentials to impersonate the user or gain unauthorized access to protected resources.

Impact

Successful exploitation of CVE-2026-33745 allows attackers to steal authentication credentials from applications utilizing the vulnerable cpp-httplib library. The impact could range from unauthorized access to user accounts and sensitive data to full compromise of the application and its related systems. The number of potential victims depends on the usage and distribution of the vulnerable cpp-httplib library across different software projects and organizations. Organizations across all sectors are potentially vulnerable if they use affected applications.

Recommendation

• Upgrade to cpp-httplib version 0.39.0 or later to remediate CVE-2026-33745 as mentioned in the Overview.
• Implement network monitoring to detect HTTP requests containing Authorization headers being sent to unexpected or untrusted domains, based on the attack chain steps described above, specifically step 6.
• If upgrading is not immediately feasible, consider implementing a proxy that strips Authorization headers from HTTP redirect requests to external domains as a temporary mitigation.

Attack Chain

1. A local user gains access to a server running a vulnerable version of IBM InfoSphere Information Server (11.7.0.0 through 11.7.1.6).
2. The user navigates to the file system location where the application stores configuration files.
3. The user opens the configuration files using a text editor or command-line tool like cat or type.
4. The user searches for plaintext credentials or other sensitive information within the configuration files.
5. The user discovers usernames, passwords, API keys, or other secrets stored in plaintext.
6. The user uses the discovered credentials to authenticate to the InfoSphere system or related services.
7. The user gains unauthorized access to data, configurations, or administrative functions.

Impact

Successful exploitation of CVE-2025-36258 allows a local user to read sensitive information, including user credentials stored in plaintext. This can lead to unauthorized access to the InfoSphere system and potentially other connected systems. The impact includes data breaches, privilege escalation, and complete system compromise. The severity is rated as HIGH with a CVSS v3.1 score of 7.1.

Recommendation

• Apply the security update or patch provided by IBM to address CVE-2025-36258; refer to https://www.ibm.com/support/pages/node/7266489.
• Implement access controls to restrict local user access to sensitive configuration files.
• Deploy the Sigma rules provided to detect unauthorized access to configuration files and processes attempting to read them.
• Enable file integrity monitoring for InfoSphere configuration directories to detect unauthorized modifications.

Attack Chain

1. The attacker sends a phishing email impersonating a cloud-based file storage or document workflow service.
2. The email contains a message prompting the user to “activate” or “authenticate” their account.
3. The email includes a device code and instructs the user to visit a Microsoft login page (e.g., microsoft.com/devicelogin).
4. The user, believing the request is legitimate, enters the provided device code on the Microsoft login page.
5. The Microsoft login page prompts the user to grant permissions to an application controlled by the attacker.
6. If the user approves the permissions, the attacker gains OAuth tokens that allow access to the user’s account on the targeted cloud platform.
7. The attacker can then access, modify, or exfiltrate data stored on the compromised account.
8. The attacker may use the compromised account to further propagate the phishing campaign to other users within the organization.

Impact

Successful attacks can lead to unauthorized access to sensitive data stored in cloud-based file storage and document workflow platforms. This can result in data breaches, financial loss, and reputational damage for affected organizations. The use of a legitimate Microsoft authentication flow makes this campaign difficult to detect with traditional phishing detection methods. The lack of credential harvesting may also bypass security controls focused on monitoring password theft. The specific number of victims and sectors targeted remains unknown, but the potential impact is significant given the widespread use of cloud services.

Recommendation

• Implement user awareness training to educate employees about device code phishing and the risks of entering unknown codes on login pages.
• Monitor Microsoft Entra ID (Azure AD) logs for unusual device code authentication patterns, focusing on applications requesting broad permissions (reference: Attack Chain steps 5 and 6). Deploy the “Detect Suspicious Device Code Authentication” Sigma rule to identify anomalous activity.
• Implement Conditional Access policies in Microsoft Entra ID to restrict device code authentication to trusted devices and locations.
• Investigate any successful device code authentications where the application requesting permissions is not recognized or approved by the organization.

Attack Chain

1. An attacker crafts a malicious URL targeting an OpenClaw application using a version prior to 2026.3.7.
2. The victim’s browser or application requests the malicious URL, including custom authorization headers like X-Api-Key or Private-Token.
3. The vulnerable fetchWithSsrFGuard function in OpenClaw fails to properly validate or sanitize headers during cross-origin redirects.
4. The attacker configures their malicious server to respond with an HTTP 302 redirect to a different origin controlled by the attacker.
5. The victim’s client, upon receiving the redirect, unknowingly forwards the sensitive authorization headers to the attacker’s server.
6. The attacker’s server logs or captures the leaked X-Api-Key and/or Private-Token values.
7. The attacker uses the stolen credentials to gain unauthorized access to resources or data protected by those credentials on the original target application.

Impact

Successful exploitation of CVE-2026-32913 can lead to the leakage of sensitive API keys and private tokens. This allows unauthorized access to protected resources, potentially leading to data breaches, account compromise, and other malicious activities. While the specific number of affected applications remains unknown, all OpenClaw deployments prior to version 2026.3.7 are vulnerable. The impact is significant due to the potential for widespread credential compromise across various sectors utilizing OpenClaw for their applications.

Recommendation

• Upgrade OpenClaw to version 2026.3.7 or later to patch CVE-2026-32913 (see references for patch information).
• Implement server-side validation to sanitize and strip potentially sensitive authorization headers before following redirects.
• Deploy the Sigma rule Detect Suspicious Header Forwarding to identify potential exploitation attempts by monitoring for cross-origin redirects involving sensitive headers.
• Monitor web server logs for unusual redirect activity and suspicious user agents (see log source information in the Sigma rules).

Attack Chain

1. The attacker compromises or obtains valid credentials for an Azure Service Principal.
2. The attacker authenticates to Microsoft Entra ID using the compromised service principal credentials, generating a ServicePrincipalSignInLogs event in Azure.
3. The attacker attempts to list cluster user credentials for a connected Kubernetes cluster using the compromised service principal. This generates an Azure Activity Log event: MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION.
4. If successful, the listClusterUserCredential action provides the attacker with tokens to access the Kubernetes cluster through the Arc Cluster Connect proxy.
5. The attacker uses the acquired credentials to interact with the Kubernetes cluster via kubectl proxied through Azure Arc.
6. The attacker performs reconnaissance within the Kubernetes cluster to identify valuable targets.
7. The attacker attempts to create, read, update, or delete (CRUD) sensitive Kubernetes resources, such as secrets or configmaps.
8. The attacker may attempt to escalate privileges within the cluster or pivot to other resources within the Azure environment.

Impact

Compromise of service principal credentials and subsequent access to Azure Arc-connected Kubernetes clusters can lead to significant data breaches, service disruption, and unauthorized resource access. Successful exploitation allows attackers to gain control over Kubernetes clusters, potentially leading to lateral movement within the environment, exfiltration of sensitive data, and deployment of malicious workloads. The number of victims and specific sectors targeted vary based on the attacker’s objectives and the compromised environment.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect the described attack chain, tuning the maxspan value based on observed authentication patterns and network latency.
• Investigate any alerts generated by the Sigma rule, focusing on unexpected sign-in locations or ASNs for the service principal (refer to the investigation fields in the rule definition).
• Implement regular rotation of service principal credentials and enforce multi-factor authentication where possible (refer to Microsoft Entra ID documentation).
• Review and restrict Azure role assignments for service principals on Arc-connected clusters to minimize potential impact from compromised credentials (refer to Azure RBAC documentation).
• Enable logging for Azure sign-in logs and activity logs to ensure the data sources are available for the detection rule (refer to Azure Monitor documentation).

Attack Chain

1. An attacker gains initial access to a system hosting the Azure AD Connect Authentication Agent.
2. The attacker identifies a location where they can place a malicious DLL that the AzureADConnectAuthenticationAgentService.exe process will load, such as a directory with weak permissions or a location susceptible to DLL side-loading.
3. The attacker places a malicious DLL (e.g., evil.dll) into the identified location.
4. The AzureADConnectAuthenticationAgentService.exe process is started or restarted.
5. The AzureADConnectAuthenticationAgentService.exe process loads the malicious DLL (evil.dll).
6. The malicious DLL intercepts or captures credentials as they are processed by the PTA service.
7. The attacker exfiltrates the captured credentials.
8. The attacker uses the stolen credentials to gain unauthorized access to other systems or resources.

Impact

Successful exploitation allows attackers to intercept credentials handled by the Azure AD Connect Authentication Agent. This can lead to the compromise of user accounts and the ability to move laterally within the environment. Organizations using Azure AD Connect with Pass-through Authentication are at risk. The impact includes potential data breaches, unauthorized access to sensitive information, and domain compromise.

Recommendation

• Implement the Sigma rule Untrusted DLL Loaded by Azure AD Connect Authentication Agent to detect the loading of untrusted DLLs by the Azure AD Connect Authentication Agent service in your environment.
• Monitor process creation events for AzureADConnectAuthenticationAgentService.exe loading DLLs outside of the standard Microsoft directories, as defined in the Sigma rule.
• Enable Sysmon Event ID 7 (Image Loaded) logging to provide the necessary data for the Sigma rule to function effectively.
• Restrict write access to the Azure AD Connect Authentication Agent directories to prevent unauthorized DLL placement.
• Review administrative access to the PTA host to prevent unauthorized modifications.

Attack Chain

1. The attacker gains initial access to a system through unspecified means (e.g., exploiting a vulnerability or using stolen credentials).
2. The attacker obtains a memory dump of the compromised system, which may contain sensitive information.
3. The attacker executes MemProcFS.exe with the -device parameter to mount the memory dump as a virtual file system.
4. MemProcFS creates a virtual file system representation of the memory dump, allowing the attacker to browse the memory space as files and directories.
5. The attacker accesses the memory of the LSASS process (lsass.exe) through the mounted file system.
6. The attacker extracts credentials, such as usernames and passwords, from the LSASS process memory.
7. The attacker may also access registry hives through the mounted file system to obtain LSA secrets, SAM data, and cached domain credentials.
8. The attacker uses the stolen credentials for lateral movement, privilege escalation, or data exfiltration.

Impact

Successful exploitation allows threat actors to steal sensitive information, including credentials, LSA secrets, SAM data, and cached domain credentials. Compromised credentials can be used for lateral movement within the network, privilege escalation, and further data breaches. The number of potential victims is unknown, but the severity of the impact is high due to the potential for widespread compromise. Sectors at risk include any organization that stores sensitive data on Windows systems.

Recommendation

• Deploy the Sigma rule “Detect MemProcFS Execution with Device Parameter” to your SIEM to identify suspicious use of MemProcFS based on process creation events.
• Enable Sysmon process creation logging to provide the necessary data for the Sigma rules above.
• Monitor for unusual file system access patterns that may indicate a memory dump being mounted as a virtual file system.

Attack Chain

1. Initial Access: The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerability in a deployed application.
2. Discovery: The attacker enumerates existing admission controller configurations (mutatingwebhookconfigurations and validatingwebhookconfigurations) to identify potential targets.
3. Configuration Modification: The attacker uses kubectl or the Kubernetes API to create, update, or replace a webhook configuration. This involves crafting a malicious webhook that will intercept API requests.
4. Webhook Deployment: The malicious webhook is deployed as a service within the Kubernetes cluster.
5. API Interception: When a user or application makes an API request that matches the webhook’s defined rules, the webhook intercepts the request.
6. Malicious Code Injection: The webhook injects malicious code or alters the API request to achieve the attacker’s objectives (e.g., granting unauthorized permissions, modifying resource configurations).
7. Persistence/Privilege Escalation/Credential Access: Depending on the injected code, the attacker achieves persistence by ensuring malicious code is always present, escalates privileges by modifying role bindings, or accesses credentials by intercepting secret creation requests.
8. Lateral Movement/Data Exfiltration: The attacker leverages their gained access to move laterally within the cluster or exfiltrate sensitive data.

Impact

Successful modification of Kubernetes admission controllers can have severe consequences. This can result in unauthorized access to sensitive data, complete cluster compromise, and denial of service. The impact ranges from data breaches and service disruptions to long-term persistence within the environment, allowing attackers to maintain control over the cluster. The stealthy nature of this attack makes it difficult to detect, potentially allowing attackers to operate undetected for extended periods.

Recommendation

• Deploy the Sigma rule “Kubernetes Admission Controller Modification” to your SIEM and tune it for your environment to detect suspicious modifications to webhook configurations (logsource: kubernetes, service: audit).
• Monitor Kubernetes audit logs for create, delete, patch, replace, and update verbs on mutatingwebhookconfigurations and validatingwebhookconfigurations resources (logsource: kubernetes, service: audit).
• Implement strong RBAC policies to limit access to Kubernetes API resources and prevent unauthorized modification of admission controller configurations.
• Regularly review and audit existing admission controller configurations to identify any unexpected or malicious webhooks.

Attack Chain

1. Initial access to the target environment is gained through methods such as phishing or exploiting a vulnerability in a public-facing application.
2. The attacker performs reconnaissance to identify the location of the Veeam MSSQL database server.
3. The attacker obtains valid credentials or exploits a vulnerability to gain access to the Veeam MSSQL database server.
4. The attacker executes sqlcmd.exe or uses PowerShell commands (e.g., Invoke-Sqlcmd) to query the [VeeamBackup].[dbo].[Credentials] table.
5. The attacker retrieves the encrypted Veeam credentials from the database.
6. The attacker decrypts the Veeam credentials using custom scripts or tools, potentially leveraging the Veeam backup server itself.
7. The attacker uses the compromised Veeam credentials to access and delete or encrypt backup data.
8. The attacker deploys ransomware on the remaining systems, knowing that recovery from backups is now impossible.

Impact

Successful compromise of Veeam credentials can have devastating consequences. Attackers can encrypt or delete backup data, making recovery impossible and significantly increasing the impact of ransomware attacks. This can lead to prolonged downtime, data loss, financial losses, and reputational damage. Organizations relying on Veeam for backup and recovery should prioritize monitoring and securing their Veeam infrastructure to prevent credential access and backup compromise.

Recommendation

• Enable Sysmon process creation logging to capture command-line activity, specifically sqlcmd.exe and PowerShell.
• Deploy the Sigma rule “Potential Veeam Credential Access Command” to detect suspicious command executions targeting Veeam credentials in MSSQL databases.
• Review and restrict access controls to the Veeam MSSQL database, ensuring only authorized personnel and services have access.
• Monitor for unusual login activity and failed login attempts to the Veeam MSSQL database server.
• Implement multi-factor authentication for all accounts with access to Veeam infrastructure.
• Regularly audit Veeam backup configurations and logs to identify any unauthorized modifications or access attempts.

Attack Chain

1. An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
2. The attacker executes a PowerShell script on the compromised system. This script could be directly executed or obfuscated to evade initial detection.
3. The PowerShell script attempts to perform NTLM relay or pass-the-hash attacks by utilizing specific byte sequences related to NTLM/SMB negotiation, such as NTLMSSPNegotiate or 0x4e,0x54,0x4c,0x4d,0x53,0x53,0x50.
4. The script may utilize tools like Invoke-WMIExec or Invoke-SMBExec to execute commands on remote systems using the stolen credentials.
5. The attacker attempts to authenticate to other systems on the network using the relayed credentials or password hashes.
6. Successful authentication allows the attacker to move laterally, accessing sensitive data or escalating privileges on other systems.
7. The attacker may deploy additional payloads or establish persistence mechanisms for continued access.

Impact

A successful pass-the-hash or NTLM relay attack can grant an attacker unauthorized access to sensitive systems and data within the network. This can lead to data breaches, financial loss, or disruption of critical services. The impact could range from compromising a few systems to gaining domain administrator privileges, depending on the attacker’s goals and the network’s security posture. Organizations can experience significant financial and reputational damage due to data breaches and service disruptions.

Recommendation

• Enable PowerShell Script Block Logging to capture the necessary data for this detection. Refer to the setup instructions in the rule documentation for configuration details.
• Deploy the Sigma rule Detecting Potential PowerShell Pass-the-Hash/Relay Scripts to your SIEM and tune it based on your environment.
• Investigate any alerts generated by this rule to determine the scope and impact of the potential attack. Refer to the triage and analysis section in the rule documentation for guidance on investigation steps.
• Implement network segmentation and access controls to limit the impact of lateral movement.
• Monitor authentication events (event codes 4624, 4625, 4648) for suspicious activity, such as NTLM authentication from unexpected source IPs or to unusual target systems, as described in the rule’s investigation notes.

Attack Chain

1. An attacker gains initial access to a system within the target network. This may be achieved through phishing, exploiting vulnerabilities, or compromised credentials.
2. The attacker escalates privileges to obtain membership in the Backup Operators group or a similar privileged group capable of running backups.
3. The attacker executes wbadmin.exe with the recovery argument, targeting the NTDS.dit file. The command line includes parameters to create a system state backup.
4. Wbadmin creates a backup of the system state, including the NTDS.dit file, in a specified location.
5. The attacker copies the NTDS.dit file from the backup location to a separate location for offline analysis.
6. The attacker uses tools such as ntdsutil.exe or secretsdump.py to extract password hashes from the NTDS.dit file.
7. The attacker cracks the password hashes or uses them in pass-the-hash attacks to gain access to other systems and resources within the domain.
8. The attacker achieves domain dominance and persistence, allowing them to control critical systems and data.

Impact

Successful exploitation allows attackers to dump credentials from the NTDS.dit file, leading to complete compromise of the Active Directory domain. This enables them to move laterally, access sensitive data, and establish persistent control over the environment. The impact can include data breaches, ransomware deployment, and long-term disruption of business operations. The medium risk score indicates that while the attack requires specific privileges, the consequences are significant if successful.

Recommendation

• Enable process creation logging with command line arguments to detect wbadmin.exe execution as described in the Attack Chain (Data Source: Windows Security Event Logs, Sysmon).
• Implement the provided Sigma rule to detect suspicious wbadmin.exe execution with NTDS.dit related arguments in your SIEM (Rule: NTDS Dump via Wbadmin).
• Monitor and restrict membership in privileged groups like Backup Operators to minimize the risk of abuse (Reference: https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960).
• Review and whitelist legitimate backup schedules or disaster recovery processes to reduce false positives (False positive analysis).

Attack Chain

1. An attacker gains initial access to the system through various means.
2. The attacker attempts to access the SAM, SECURITY, or SYSTEM registry hives located in the C:\\Windows\\System32\\config\\RegBack\\ directory.
3. The attacker leverages a tool or script to open one or more of these registry hives. This could involve using built-in Windows utilities, scripting languages, or custom-developed tools.
4. If the attacker successfully opens the SAM and SYSTEM hives, they can extract user account credentials, including usernames, password hashes, and other sensitive information. The SECURITY hive is also useful.
5. The attacker may stage the registry hive files by copying them to a different location on the system for further analysis or exfiltration.
6. The attacker uses credential dumping tools (e.g., Mimikatz, secretsdump.py) or custom scripts to extract credentials from the staged registry hives.
7. The attacker leverages the extracted credentials to escalate privileges, move laterally within the network, or access sensitive data.
8. The final objective is typically to gain unauthorized access to critical systems, steal sensitive data, or establish long-term persistence within the compromised environment.

Impact

Successful exploitation of this technique can lead to the compromise of user account credentials, enabling attackers to escalate privileges, move laterally within the network, and gain unauthorized access to sensitive data. The impact can range from data breaches and financial losses to reputational damage and disruption of critical business operations. The number of victims can vary depending on the scope of the attacker’s activities and the security posture of the targeted organization. Sectors commonly targeted include finance, healthcare, government, and critical infrastructure.

Recommendation

• Enable file access monitoring for the C:\\Windows\\System32\\config\\RegBack\\ directory to capture file open events.
• Deploy the Sigma rule Registry Hive Access via RegBack to your SIEM and tune the exclusions based on your environment.
• Monitor process_creation events for unusual processes accessing files in C:\\Windows\\System32\\config\\RegBack\\, using the rule Suspicious Process Accessing RegBack Hives.
• Enable Sysmon process creation logging and file creation to activate the rules above.

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. Attacker authenticates to the domain.
2. Attacker leverages existing privileges to create a wildcard DNS record (A record) within an ADIDNS zone.
3. The wildcard record is created with a DN like DC=*,DC=example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=example,DC=com, where DC=* signifies the wildcard. Event ID 5137 is generated.
4. The wildcard record points to a malicious server controlled by the attacker.
5. A client attempts to resolve a domain name that does not have an explicit DNS record.
6. Due to the wildcard record, the DNS query resolves to the attacker’s malicious server.
7. The client connects to the attacker’s server, potentially exposing credentials or other sensitive information.
8. The attacker intercepts or relays the client’s traffic, gaining unauthorized access or control.

Impact

Successful exploitation allows attackers to intercept network traffic, steal credentials, and potentially gain control over systems within the affected domain. The impact includes unauthorized access to sensitive data, lateral movement within the network, and potential compromise of critical domain services. This can affect any organization using Active Directory Integrated DNS, leading to widespread disruption and data breaches.

Recommendation

• Enable “Audit Directory Service Changes” to generate the necessary Windows Security Event Logs (5137) for detecting ADIDNS wildcard record creation as described in the setup instructions.
• Deploy the Sigma rule “Potential ADIDNS Poisoning via Wildcard Record Creation” to detect the creation of wildcard DNS records in ADIDNS based on Windows Event ID 5137.
• Review and restrict ADIDNS permissions for DNS zones to limit wildcard-creation opportunities, focusing on authenticated-user create-child rights.
• Investigate any alerts generated by the Sigma rule, focusing on winlog.event_data.ObjectDN, user.name, and the originating session as outlined in the rule’s note field.

Attack Chain

1. An attacker gains initial access to a Windows system through unspecified means.
2. The attacker uses PowerShell (powershell.exe, pwsh.exe, powershell_ise.exe) or another unsigned process to execute malicious commands.
3. The malicious process attempts to load the Veeam.Backup.Common.dll library.
4. The Veeam.Backup.Common.dll library is loaded into the process memory.
5. The attacker leverages the loaded library to decrypt stored Veeam credentials.
6. Using the decrypted credentials, the attacker gains access to Veeam backups.
7. The attacker may then encrypt, delete, or exfiltrate the backups, leading to data loss or ransomware attacks.
8. The attacker pivots to other systems using the compromised credentials, further expanding the attack.

Impact

Successful exploitation allows attackers to gain access to sensitive Veeam backup data. This can lead to data exfiltration, data encryption, or complete data loss. The impact includes potential ransomware attacks, significant business disruption, and financial losses due to recovery efforts and downtime. The compromise of Veeam backups can severely impact an organization’s ability to recover from incidents, making it a critical target for attackers.

Recommendation

• Deploy the Sigma rule “Veeam Backup Library Loaded by Unusual Process” to your SIEM to detect suspicious DLL loads (rule.name).
• Investigate any alerts generated by the Sigma rule, focusing on the process details and execution history to determine legitimacy (rule.description).
• Enable process creation and library load logging to capture the necessary events for the Sigma rule to function correctly.
• Review and enforce code signing policies to prevent unsigned processes from loading critical libraries like Veeam.Backup.Common.dll.
• Implement multi-factor authentication for Veeam accounts to mitigate the impact of credential compromise.

Attack Chain

1. An attacker gains initial access to AWS environment using compromised credentials (access key, secret key).
2. The attacker uses the compromised credentials with the AWS CLI or SDK to call the GetSigninToken API.
3. AWS CloudTrail logs the GetSigninToken event with the event source signin.amazonaws.com and event name GetSigninToken.
4. The GetSigninToken API returns a temporary sign-in token.
5. The attacker uses the temporary token along with the AWS account ID to construct a sign-in URL.
6. The attacker accesses the AWS Management Console via the crafted URL, bypassing MFA if the original compromised credentials required it.
7. Once in the console, the attacker performs reconnaissance, identifies valuable resources, and escalates privileges as needed.
8. The attacker moves laterally within the AWS environment, accessing and potentially exfiltrating sensitive data, or disrupting services.

Impact

Successful abuse of the GetSigninToken API can lead to unauthorized access to the AWS Management Console, enabling lateral movement and data exfiltration. The obfuscation of the original compromised credentials makes incident response more difficult. While the exact number of victims is unknown, this technique has been observed in intrusions targeting telecom and BPO companies. The impact includes potential data breaches, service disruptions, and reputational damage.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect suspicious GetSigninToken events in AWS CloudTrail logs.
• Investigate any GetSigninToken events originating from outside of expected AWS SSO user agents or other known legitimate sources.
• Monitor AWS CloudTrail logs for GetSigninToken events where the requesting user identity does not match expected patterns.
• Implement and enforce MFA for all AWS IAM users, even though this attack bypasses it for console access using the temporary tokens.
• Review and restrict IAM policies to adhere to the principle of least privilege, minimizing the potential impact of compromised credentials.

Attack Chain

1. Initial Access Attempt: An attacker attempts to gain initial access to a Bitbucket account using a compromised or guessed username.
2. Credential Guessing: The attacker attempts to guess the user’s password through manual attempts or automated tools.
3. Authentication Failure: Bitbucket records a “User login failed” event due to incorrect credentials. The auditType.category is Authentication, and auditType.action is User login failed.
4. Multiple Failed Attempts: The attacker repeats the login attempts with different password variations or using a list of compromised credentials.
5. Account Lockout (Optional): Depending on Bitbucket’s configuration, repeated failed login attempts may trigger an account lockout.
6. Successful Login (Potential): After multiple attempts, the attacker may eventually guess the correct password or use a valid compromised credential.
7. Privilege Escalation/Persistence (If Successful): If successful, the attacker could escalate privileges, establish persistence, or perform other malicious actions within the Bitbucket environment.

Impact

Successful exploitation can lead to unauthorized access to sensitive code repositories, intellectual property theft, and potential supply chain compromise. Attackers could inject malicious code, modify existing code, or exfiltrate sensitive data. Detecting these failed login attempts early can prevent significant damage. Although the number of victims cannot be determined with this specific detection, a successful attack can have far-reaching impacts.

Recommendation

• Deploy the Sigma rule “Bitbucket User Login Failure” to your SIEM to detect suspicious authentication failures (logsource: bitbucket, service: audit). Tune for your environment by correlating on the author.name field.
• Investigate the source IP addresses associated with the failed login attempts to identify potential malicious actors.
• Implement multi-factor authentication (MFA) to significantly reduce the risk of successful credential-based attacks.
• Monitor for unusual activity following any successful login after a series of failures.
• Enforce strong password policies to reduce the effectiveness of brute-force attacks.

Attack Chain

1. The attacker gains initial access to a Windows system (e.g., via phishing or exploiting a software vulnerability).
2. The attacker executes netsh.exe with specific arguments to list available wireless profiles.
3. The attacker identifies a target wireless profile from the list.
4. The attacker executes netsh.exe again, this time specifying the target profile and requesting the key to be displayed in cleartext using the key=clear argument.
5. Netsh.exe retrieves the Wi-Fi password from the Windows Wireless LAN service.
6. The password is displayed in the command output, which the attacker captures.
7. The attacker uses the obtained Wi-Fi password to connect to the wireless network.
8. The attacker can now perform lateral movement and access internal resources.

Impact

Successful credential dumping allows attackers to gain unauthorized access to wireless networks. This can lead to lateral movement within the organization’s network, access to sensitive data, and further compromise of systems and resources. The impact includes potential data breaches, financial losses, and reputational damage. This technique allows attackers to bypass traditional network access controls.

Recommendation

• Deploy the Sigma rule Detect Wireless Credential Dumping via Netsh to identify suspicious netsh.exe commands in your environment.
• Enable Sysmon process creation logging to capture the netsh.exe command-line arguments.
• Investigate any alerts triggered by the Sigma rule, focusing on the process lineage and user context as outlined in the “Triage and analysis” section of the source.
• Implement strong password policies for Wi-Fi networks, including the use of WPA2 or WPA3 encryption.
• Review and restrict the use of netsh.exe on systems where it is not required, using application control solutions.
• Monitor for related alerts indicating lateral movement, staging, remote access, or persistence, as mentioned in the “Triage and analysis” section of the source.

Attack Chain

1. An attacker gains unauthorized access to the TYPO3 backend, potentially through brute-force attacks or stolen credentials.
2. The attacker navigates to the backend user settings module.
3. A legitimate user or the attacker changes their password within the module while the TYPO3 instance is running version 14.2.0.
4. The SetupModuleController processes the password change request.
5. Instead of properly hashing the password, the SetupModuleController stores it in cleartext in the uc and user_settings fields of the be_users database table.
6. An attacker with database access can now retrieve the cleartext passwords from these fields.
7. The attacker uses the compromised credentials to impersonate the user and gain access to sensitive data or perform unauthorized actions.

Impact

Successful exploitation of this vulnerability allows attackers with database access to retrieve cleartext passwords, potentially leading to complete compromise of backend user accounts. While the vulnerability is limited to TYPO3 CMS version 14.2.0, the impact on affected instances is significant, as administrative accounts could be hijacked, allowing attackers to modify website content, install malicious extensions, or exfiltrate sensitive data. This could result in data breaches, financial loss, and reputational damage.

Recommendation

• Upgrade to TYPO3 version 14.3.0 LTS to address the underlying vulnerability (reference: Solution section).
• Execute the User Settings Scrubbing wizard in the TYPO3 Install Tool to sanitize existing cleartext passwords in the uc and user_settings fields (reference: Solution section).
• Require affected backend user accounts to reset their passwords immediately (reference: Solution section).
• Monitor database access logs for suspicious activity, especially access to the be_users table (reference: Attack Chain).
• Deploy the Sigma rule provided below to detect potential unauthorized access attempts following password changes.

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 executes vaultcmd.exe with the /list argument to enumerate the credentials stored in the Windows Credential Manager.
3. The vaultcmd.exe process accesses the Credential Manager to retrieve the list of saved credentials.
4. The output of vaultcmd.exe (the list of credentials) is captured or redirected to a file for later exfiltration.
5. The attacker parses the output to identify valuable credentials, such as domain administrator accounts or service accounts.
6. The attacker uses the acquired credentials to authenticate to other systems on the network (lateral movement).
7. The attacker elevates privileges on the target systems.
8. The final objective is achieved, such as data theft or ransomware deployment.

Impact

Successful execution of this attack chain can lead to unauthorized access to sensitive resources, lateral movement within the network, and ultimately, data theft, system compromise, or ransomware deployment. A compromised user account can grant the attacker access to internal systems, confidential data, and critical infrastructure. If the attacker gains domain administrator credentials, they can compromise the entire Windows domain.

Recommendation

• Monitor process execution events for instances of vaultcmd.exe being executed with the /list* argument (Data Source: Windows Security Event Logs, Sysmon, Microsoft Defender XDR, SentinelOne, Crowdstrike).
• Deploy the Sigma rule “Detect VaultCmd Credential Listing” to your SIEM to identify potential credential access attempts.
• Investigate any identified instances of vaultcmd.exe being executed with the /list* argument to determine the legitimacy of the activity.
• Review and update endpoint protection configurations to ensure that similar threats are detected and blocked in the future.

Attack Chain

1. The attacker initiates a network connection to a Windows system, likely targeting a service such as SMB or RDP.
2. The attacker attempts to authenticate using a list of usernames and passwords or commonly used passwords, generating failed logon attempts (Event ID 4625).
3. The Windows system logs the failed authentication attempts in the Security Event Log.
4. The detection rule monitors the Security Event Log for failed logon events (event.category == “authentication” and event.action == “logon-failed”).
5. The rule aggregates the number of failed logon attempts from the same source IP address within a 60-second time window.
6. If the number of failed attempts exceeds a threshold (e.g., 100) and involves multiple target usernames (Esql.count_distinct_target_user_name >= 2), the rule triggers a detection.
7. The attacker may continue attempts after initial failures or pivot to successful credentials for lateral movement.
8. Successful credential access can lead to privilege escalation, data exfiltration, or other malicious activities.

Impact

Successful brute-force or password spraying attacks can lead to unauthorized access to user accounts and sensitive data. The impact can range from minor inconvenience to significant data breaches and financial losses, depending on the compromised accounts and the data they have access to. The rule aims to reduce the window of opportunity for attackers to gain a foothold in the environment.

Recommendation

• Enable Audit Logon to generate the necessary Windows Security Event Logs. Follow the setup instructions outlined in the rule documentation.
• Deploy the Sigma rule “Multiple Logon Failure from the Same Source Address” to your SIEM and tune the threshold values (Esql.failed_auth_count and Esql.count_distinct_target_user_name) to minimize false positives in your environment.
• Investigate any triggered alerts by examining the logon failure reason codes and the targeted user names as described in the rule’s investigation guide.
• Monitor network connections from the source IP address for any suspicious outbound traffic or lateral movement activity.
• Review and enforce strong password policies to mitigate the risk of successful brute-force attacks.

Attack Chain

1. An attacker gains access to valid AWS credentials, potentially through phishing, credential stuffing, or exposed secrets.
2. The attacker uses the compromised credentials to make API calls from their own infrastructure, which is associated with a rare AS organization.
3. The attacker performs reconnaissance, such as GetCallerIdentity, ListBuckets, or ListSecrets, to understand the AWS environment.
4. The attacker attempts to escalate privileges by calling AssumeRole, AttachUserPolicy, or CreateAccessKey.
5. The attacker attempts to access sensitive data using actions such as GetObject or GetSecretValue.
6. The attacker attempts to create new users or modify existing user profiles using actions such as CreateUser, UpdateLoginProfile, or AddUserToGroup.
7. The attacker may attempt to invoke cloud ML models using InvokeModel or Converse to further their objectives.
8. The attacker persists in the environment by creating new IAM users, roles, or policies, or by modifying existing ones.

Impact

A successful attack can lead to unauthorized access to sensitive data stored in S3 buckets, Secrets Manager, or other AWS services. It can also allow the attacker to escalate privileges, create new users, and modify existing configurations, leading to long-term control of the AWS environment. The severity of the impact depends on the level of access granted to the compromised credentials. This can lead to exfiltration of sensitive data, denial of service, or complete compromise of the AWS account.

Recommendation

• Enable AWS CloudTrail logging in all regions and send logs to a centralized SIEM or logging platform to enable detection capabilities (references).
• Deploy the Sigma rule “AWS Rare Source AS Organization Activity” translated from the provided ESQL query to detect unusual source ASNs for AWS API calls.
• Investigate alerts generated by the rule, focusing on the user.name, aws.cloudtrail.user_identity.type, Esql.src_asn_values, and Esql.untrusted_suspicious_actions to understand the context of the activity.
• Rotate credentials for the affected principal if abuse is suspected and enforce OIDC or short-lived keys for automation.
• Tighten IAM and data-plane permissions to limit the impact of compromised credentials.

Attack Chain

1. Initial Access: An attacker gains unauthorized access to an account with sufficient privileges (e.g., Domain Admin, or an account with delegated permissions) to modify user account attributes in Active Directory.
2. Privilege Escalation: The attacker leverages their initial access to target a specific user account for which they intend to disable Kerberos pre-authentication.
3. Account Modification: The attacker modifies the UserAccountControl attribute of the target user account, specifically disabling the “Do not require pre-authentication” setting (setting the USER_DONT_REQUIRE_PREAUTH flag). This is often done using tools like Active Directory Users and Computers or PowerShell cmdlets.
4. Event Logging: The modification triggers a Windows Security Event Log event (Event ID 4738) on the Domain Controller, indicating that the user account attribute has been changed. The NewUACList field in the event data contains USER_DONT_REQUIRE_PREAUTH.
5. AS-REQ Request: The attacker crafts an AS-REQ (Authentication Service Request) to the Kerberos Key Distribution Center (KDC) for the targeted user account. Since pre-authentication is disabled, the KDC processes the request without requiring pre-authentication.
6. AS-REP Response: The KDC issues an AS-REP (Authentication Service Response) to the attacker, containing an encrypted Ticket Granting Ticket (TGT) for the targeted user account.
7. Offline Cracking: The attacker extracts the encrypted TGT from the AS-REP response and attempts to crack it offline using password cracking tools and techniques, such as hashcat or John the Ripper.
8. Credential Access: Upon successfully cracking the TGT, the attacker obtains the plaintext password for the targeted user account. This password can then be used for lateral movement, privilege escalation, and further malicious activities within the domain.

Impact

Compromising user accounts through AS-REP roasting can have significant consequences. Attackers can gain unauthorized access to sensitive resources, escalate privileges, and move laterally within the network. Successful AS-REP roasting leads to credential compromise, which could result in data breaches, system compromise, and disruption of services. Organizations failing to monitor and prevent Kerberos pre-authentication disabling are at an increased risk of credential theft and subsequent exploitation, potentially affecting all systems within the compromised domain.

Recommendation

• Enable “Audit User Account Management” and ensure Windows Security Event Logs (specifically Event ID 4738) are being collected and forwarded to your SIEM for analysis as described in the setup instructions linked in the rule source.
• Deploy the provided Sigma rule to detect Event ID 4738 events where the NewUACList contains USER_DONT_REQUIRE_PREAUTH within your environment to identify potential AS-REP roasting vulnerabilities.
• Investigate any instances of disabled pre-authentication, especially on privileged accounts, following the triage steps outlined in the rule documentation.
• Enforce the principle of least privilege by reviewing and restricting the privileges assigned to users and groups to prevent unauthorized modification of Active Directory user account attributes.
• Monitor for suspicious Kerberos authentication patterns and investigate any anomalies that might indicate AS-REP roasting attempts.

Attack Chain

1. An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
2. The attacker executes a PowerShell script.
3. The PowerShell script uses LsaCallAuthenticationPackage to interact with the LSA.
4. The script attempts to retrieve Kerberos tickets by using functions like KerbRetrieveEncodedTicketMessage, KerbQueryTicketCacheMessage, KerbQueryTicketCacheExMessage, or KerbRetrieveTicketMessage.
5. Alternatively, the script uses LsaLookupAuthenticationPackage to dynamically locate the Kerberos package.
6. The script may then decrypt the ticket data using KerbDecryptDataMessage.
7. The script may attempt to serialize or export the extracted tickets to a file.
8. The attacker uses the dumped Kerberos tickets to impersonate users or services, gaining unauthorized access to resources and facilitating lateral movement.

Impact

Successful exploitation allows attackers to steal Kerberos tickets from memory. The attacker can then use these tickets to impersonate legitimate users or services, enabling them to move laterally within the network, access sensitive data, and potentially compromise critical systems. The impact includes unauthorized access to resources, data breaches, and potentially a complete compromise of the targeted Windows domain.

Recommendation

• Enable PowerShell Script Block Logging to capture the malicious script content (as mentioned in the “Setup” section).
• Deploy the Sigma rule “PowerShell Kerberos Ticket Dump” to detect scripts exhibiting Kerberos ticket dumping behavior.
• Investigate any alerts triggered by the Sigma rule, focusing on the reconstructed script block content and process lineage as outlined in the “Triage and analysis” section.
• Monitor for file creation events related to ticket material exports (e.g., “.kirbi” files) to identify potential ticket dumping activity.
• Review authentication events (event codes 4624, 4625, 4648) to identify suspicious logins originating from compromised systems.

Attack Chain

1. The adversary gains initial access to a system with privileges to modify DNS records in Active Directory.
2. The attacker creates a new MicrosoftDNS record or modifies an existing one.
3. Within the DNS record, specifically in the AdditionalInfo or ObjectDN attributes, the attacker inserts a base64-encoded blob matching the pattern “UWhRCA…BAAAA”. This blob contains a marshaled CREDENTIAL_TARGET_INFORMATION structure.
4. The attacker configures the DNS record to point to an attacker-controlled host. This involves manipulating the record’s name and associated IP address.
5. The attacker triggers a victim system to resolve the manipulated DNS record, causing the victim to attempt Kerberos authentication with the attacker-controlled host, believing it to be a legitimate service.
6. The attacker intercepts the Kerberos authentication request.
7. The attacker relays the Kerberos ticket to a legitimate service, impersonating the victim system.
8. The attacker gains unauthorized access to the legitimate service using the relayed Kerberos ticket.

Impact

Successful Kerberos coercion can grant attackers unauthorized access to critical systems and services within the Active Directory domain. This may lead to privilege escalation, lateral movement, data exfiltration, and other malicious activities. The scope of impact depends on the permissions and access rights of the coerced victim system and the targeted services.

Recommendation

• Enable “Audit Directory Service Access” and “Audit Directory Service Changes” Windows audit policies to ensure relevant events are logged (Setup section).
• Deploy the Sigma rules provided in this brief to your SIEM to detect potential Kerberos coercion attempts via DNS-based SPN spoofing. Tune the rules based on your environment and known legitimate activity.
• Investigate any alerts generated by the Sigma rules, focusing on the associated user accounts, systems, and modified DNS records (rule titles).
• Restrict access to modify DNS records in Active Directory to only authorized personnel and systems to prevent unauthorized manipulation (Overview section).
• Monitor Windows Security authentication events for any suspicious Kerberos activity following the modification of DNS records (Attack Chain steps 5-8).

Attack Chain

1. The attacker gains initial access to the system, potentially through phishing or exploitation of a vulnerability.
2. The attacker modifies the registry key HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\DumpType to the value 2 or 0x00000002 to enable full user-mode dumps system-wide.
3. The attacker triggers a crash or fakes a crash of the LSASS process.
4. Windows Error Reporting (WER) generates a full user-mode dump file of the LSASS process.
5. The dump file is stored in the location specified in the registry, typically C:\ProgramData\Microsoft\Windows\WER\ReportQueue.
6. The attacker accesses the generated dump file.
7. The attacker extracts credentials from the LSASS dump file using tools like Mimikatz or custom scripts.
8. The attacker uses the stolen credentials to move laterally within the network or access sensitive resources.

Impact

Successful exploitation can lead to the compromise of domain credentials and other sensitive information stored in LSASS memory, such as NTLM hashes and Kerberos tickets. This can enable attackers to move laterally within the network, escalate privileges, and access critical systems and data. A single compromised system can lead to a widespread breach affecting numerous users and systems. The sectors most vulnerable are those handling sensitive data or critical infrastructure.

Recommendation

• Deploy the Sigma rule “Full User-Mode Dumps Enabled System-Wide” to your SIEM to detect suspicious registry modifications related to Windows Error Reporting (WER).
• Examine process execution logs to identify any suspicious processes that may have triggered the dump, especially those not matching the legitimate svchost.exe process with user IDs S-1-5-18, S-1-5-19, or S-1-5-20 as described in the rule’s investigation guide.
• Monitor for access to WER dump files located in C:\ProgramData\Microsoft\Windows\WER\ReportQueue using file monitoring rules.
• Review and update endpoint protection configurations to ensure they can detect and block credential dumping techniques as mentioned in the rule’s response and remediation steps.

Attack Chain

1. An attacker gains initial access to a system within the target network.
2. The attacker escalates privileges to obtain the necessary rights to perform DCSync. This may involve exploiting vulnerabilities or using stolen credentials.
3. The attacker uses a tool like Mimikatz or custom scripts to initiate the Active Directory replication process.
4. The tool requests replication of directory data, specifically targeting credential information. This involves using the DS-Replication-Get-Changes or similar replication-right GUIDs.
5. The Active Directory server responds by providing the requested data, which includes password hashes and other sensitive information.
6. The attacker extracts the credential information from the replicated data.
7. The attacker uses the extracted credentials to move laterally within the network and access other systems or data.
8. The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or long-term persistence.

Impact

A successful DCSync attack can lead to the compromise of the entire Active Directory domain. This can result in widespread data breaches, loss of sensitive information, and significant disruption to business operations. Attackers can gain access to critical systems and data, potentially leading to financial losses, reputational damage, and legal liabilities. The number of potential victims is dependent on the size of the compromised Active Directory environment.

Recommendation

• Enable “Audit Directory Service Access” to generate the necessary Windows Security Event Logs (event code 4662) as described in the setup instructions.
• Deploy the Sigma rule “Detect First Time DCSync Activity” to your SIEM and tune for your environment to identify suspicious DCSync behavior.
• Investigate any alerts generated by the Sigma rule, focusing on the SubjectUserSid, SubjectUserName, Properties, AccessMask, and computer_name fields in the Windows Security Event Logs.
• Monitor for changes to Active Directory object permissions (5136 events) that could grant unauthorized users DCSync capabilities as outlined in the triage and analysis steps.

Attack Chain

1. An attacker compromises an internal system via phishing or other means (not detailed in source).
2. The attacker injects a rogue UNC path into a document, email, or other medium.
3. A user opens the malicious document or clicks the injected link, triggering an SMB connection to a malicious external server.
4. The SMB connection attempts to authenticate with the user’s NTLM credentials.
5. The attacker captures the NTLM hash from the authentication attempt.
6. The attacker attempts to crack the NTLM hash to obtain the user’s password.
7. Using the cracked password, the attacker gains unauthorized access to other systems and resources on the network.

Impact

Successful exploitation can lead to credential theft, allowing attackers to gain unauthorized access to sensitive data and systems within the organization. This can result in data breaches, financial losses, and reputational damage. The impact is significant because SMB is a common protocol within many Windows environments, making this technique highly effective if not properly monitored.

Recommendation

• Deploy the Sigma rule “Detect SMB Connection to External IP” to your SIEM to identify potentially malicious SMB connections to the internet. Tune the rule by excluding known good external IPs used by legitimate services.
• Enable Sysmon Event ID 3 (Network Connection) with proper filtering to capture SMB traffic details as recommended in the linked setup guide, to enhance the fidelity of the detection.
• Implement network segmentation to restrict SMB traffic to only necessary internal communications, reducing the attack surface and mitigating the risk of external exposure.

Attack Chain

1. An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
2. The attacker executes reg.exe from the command line or through a script.
3. The reg.exe command includes arguments to save or export registry hives.
4. The target registry hives are HKLM\SAM and HKLM\SECURITY, containing sensitive credential information.
5. The exported registry hive is saved to a file on disk or a network share.
6. The attacker may compress or encrypt the exported registry hive to evade detection.
7. The attacker retrieves the exported registry hive for offline analysis.
8. The attacker extracts credential information from the registry hive, such as password hashes and LSA secrets, to use in lateral movement or privilege escalation.

Impact

Successful exploitation allows attackers to acquire sensitive credentials stored within the registry. This can lead to lateral movement within the network, privilege escalation, and ultimately, data exfiltration or system compromise. Compromised credentials can be used to access critical systems and data, causing significant damage to the organization. The impact is considered high due to the potential for widespread access and control over the compromised environment.

Recommendation

• Enable process creation auditing with command line arguments to capture the execution of reg.exe with relevant arguments. (Data Source: Windows Security Event Logs, Sysmon)
• Deploy the Sigma rule Detect Registry Hive Export via Reg.exe to your SIEM to detect the execution of reg.exe with arguments indicative of registry hive dumping.
• Implement access controls and monitor file system activity to detect unauthorized access or modification of registry hive files.
• Review and restrict the use of reg.exe to authorized personnel and processes.
• Monitor for parent processes of reg.exe that are unusual or unexpected, which might indicate malicious activity.
• Investigate any alerts generated by the Sigma rule by reviewing the process command line, parent process, and destination of the exported registry hive.

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. An attacker gains initial access to a system within the target domain (e.g., through phishing or exploiting a public-facing application).
2. The attacker uses valid credentials or exploits a vulnerability to authenticate to the domain.
3. The attacker uses LDAP queries to enumerate Active Directory objects.
4. The attacker crafts specific LDAP queries to target sensitive attributes like unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens.
5. Windows Security Event 4662 is generated, logging the access attempt with details about the user, accessed object, and properties.
6. The attacker exfiltrates the accessed attribute data, potentially containing password hashes, certificates, or other sensitive information.
7. The attacker uses the stolen credentials or certificates to impersonate other users or gain elevated privileges within the domain.

Impact

Successful exploitation can lead to the compromise of domain accounts, including privileged accounts. Attackers can use stolen credentials to move laterally within the network, access sensitive data, and disrupt business operations. Depending on the attributes accessed, this could also expose private keys and authentication certificates leading to further attacks.

Recommendation

• Deploy the Sigma rule “Access to Sensitive LDAP Attributes” to your SIEM to detect access attempts to critical AD attributes (rule.name).
• Enable “Audit Directory Service Access” to ensure that necessary Windows Security Event Logs (event code 4662) are generated for the Sigma rule to function (setup).
• Review and tune the “Access to Sensitive LDAP Attributes” Sigma rule, creating exceptions for legitimate administrative accounts and scheduled system processes to minimize false positives (rule.note).
• Implement stricter access controls and permissions for sensitive LDAP attributes within Active Directory to restrict access to only necessary personnel (rule.note).
• Investigate any triggered alerts from the Sigma rule, focusing on identifying the user/process attempting access (winlog.event_data.SubjectUserSid) and the specific sensitive attribute accessed (winlog.event_data.Properties) (rule.note).

Attack Chain

1. Initial Access: The attacker gains initial access to an account with sufficient privileges to view and modify Azure Active Directory settings. This could be through phishing, password spraying, or exploiting a vulnerability.
2. Privilege Escalation: The attacker escalates privileges within Azure AD to gain the necessary permissions to manage Conditional Access policies. This might involve adding themselves to a privileged role or exploiting misconfigurations in existing roles.
3. Discovery: The attacker enumerates existing Conditional Access policies to identify targets for removal. They may focus on policies that enforce MFA or restrict access based on location.
4. Defense Evasion: The attacker disables or modifies logging configurations to reduce the likelihood of detection.
5. Policy Removal: The attacker removes the targeted Conditional Access policy using the Azure portal, PowerShell, or the Azure CLI. The audit logs will record a “Delete conditional access policy” event.
6. Credential Access: With the CA policy removed, the attacker may attempt to access sensitive resources or applications without MFA, potentially gaining access to credentials or sensitive data.
7. Persistence: The attacker establishes persistence by creating new user accounts or modifying existing ones to maintain access even if their initial entry point is discovered.
8. Lateral Movement: The attacker leverages the compromised credentials and weakened security controls to move laterally to other systems and resources within the organization.

Impact

A successful removal of a Conditional Access policy can lead to widespread compromise. Attackers can bypass multi-factor authentication, gain unauthorized access to sensitive data, and escalate privileges within the organization. The impact can range from data breaches and financial losses to reputational damage and compliance violations. Depending on the scope of the compromised policy, the number of affected users could range from dozens to thousands.

Recommendation

• Deploy the provided Sigma rule to detect the “Delete conditional access policy” event in Azure audit logs, indicating a CA policy removal.
• Regularly review and audit Azure Active Directory role assignments to minimize the risk of unauthorized privilege escalation.
• Implement multi-factor authentication for all user accounts, especially those with administrative privileges.
• Monitor Azure audit logs for unusual activity, such as changes to user accounts, role assignments, and Conditional Access policies.
• Investigate any detected instances of CA policy removal to determine the scope of the compromise and take appropriate remediation steps.
• Review and harden Conditional Access policies to ensure they are effectively protecting critical resources and applications.

Attack Chain

1. An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
2. The attacker executes a PowerShell script, either directly or through a command-line interface.
3. The PowerShell script contains the Invoke-NinjaCopy function or related StealthReadFile, StealthOpenFile functions.
4. The script utilizes the StealthOpenFile function to directly access the volume where the target file resides (e.g., NTDS.dit).
5. StealthReadFile is used to read the contents of the target file, bypassing standard file access controls.
6. The script copies the contents of the NTDS.dit or registry hives to a temporary location.
7. The attacker dumps credentials from the copied NTDS.dit file using tools like secretsdump.py or other credential harvesting tools.
8. The attacker uses the harvested credentials to escalate privileges or move laterally within the network.

Impact

Successful exploitation can lead to the compromise of domain credentials, granting the attacker access to sensitive information and systems. Credential dumping from NTDS.dit or registry hives can expose user accounts, service accounts, and other privileged credentials. The impact ranges from data breaches and financial losses to complete network compromise and disruption of services. If successful, attackers may gain persistent access and control over critical infrastructure, potentially affecting thousands of users and systems.

Recommendation

• Enable PowerShell Script Block Logging and monitor event ID 4104 for script content containing Invoke-NinjaCopy, StealthReadFile, StealthOpenFile, StealthCloseFileDelegate as described in the Overview.
• Deploy the Sigma rule “PowerShell Invoke-NinjaCopy script” to your SIEM and tune the rule for false positives in your environment.
• Investigate any PowerShell processes with command-line arguments that contain the identified keywords to identify potential attacker activity as outlined in the Attack Chain.
• Implement strict access controls on sensitive files like NTDS.dit and registry hives to limit the impact of successful credential access attempts.
• Review PowerShell execution policies to prevent the execution of unsigned or untrusted scripts.

Attack Chain

1. An attacker gains initial access to a Windows system.
2. The attacker executes rundll32.exe to load davclnt.dll using the DavSetCookie function.
3. The rundll32.exe process is invoked with arguments specifying a named pipe path over HTTP, such as http*/print/pipe/*, http*/pipe/spoolss, or http*/pipe/srvsvc.
4. The system attempts to authenticate to the specified HTTP endpoint using NTLM.
5. The attacker intercepts the NTLM authentication request.
6. Using a relay tool like NTLMRelay2Self or ntlmrelayx, the attacker relays the captured NTLM credentials to another service or machine.
7. The attacker leverages the relayed credentials to escalate privileges or gain unauthorized access to network resources.
8. The attacker may then perform lateral movement, data exfiltration, or other malicious activities.

Impact

Successful exploitation allows attackers to escalate privileges within the compromised system and potentially the entire domain. This can lead to unauthorized access to sensitive data, deployment of ransomware, or other destructive activities. The impact ranges from data breaches and financial losses to complete system compromise. Depending on the targeted accounts, the attacker may be able to achieve domain administrator privileges.

Recommendation

• Deploy the Sigma rule “Potential Local NTLM Relay via HTTP” to your SIEM to detect the execution of rundll32.exe with specific arguments indicative of NTLM relay attempts.
• Enable Sysmon process creation logging to ensure the necessary data is available for the Sigma rule to function correctly.
• Monitor network connections originating from processes that load davclnt.dll to identify potential NTLM relay traffic.
• Investigate and block the usage of tools like NTLMRelay2Self, PetitPotam, and ntlmrelayx within the environment.
• Implement mitigations for NTLM relay attacks, such as enabling Extended Protection for Authentication (EPA) and disabling NTLM where possible.
• Review and restrict the usage of WebClient service and Print Spooler service where not required.

Attack Chain

1. The attacker initiates multiple failed logon attempts to a Windows system using various username and password combinations. These attempts originate from a single source IP address and target network logon types.
2. The system records each failed logon attempt as a Windows Security Event Log event (Event ID 4625). The event includes information about the source IP address, target username, and failure reason.
3. After several failed attempts, the attacker guesses the correct password for a valid user account.
4. The system records a successful logon event (Event ID 4624) for the compromised account, originating from the same source IP address as the previous failed attempts, also via a network logon type.
5. The attacker gains initial access to the target system using the compromised account.
6. The attacker may then attempt to escalate privileges or move laterally within the network, using the compromised account to access additional resources or systems.

Impact

A successful brute-force attack can lead to unauthorized access to sensitive data, system compromise, and further malicious activities within the network. Compromised accounts can be used to escalate privileges, move laterally, and deploy ransomware. The severity depends on the privileges of the compromised account and the sensitivity of the data it can access.

Recommendation

• Enable Audit Logon to generate the necessary events (4624, 4625) in the Windows Security Event Logs for the detection rule to function. Reference: https://ela.st/audit-logon.
• Deploy the provided Sigma rule to your SIEM to detect multiple logon failures followed by a successful logon. Tune the rule based on your environment and baseline activity.
• Investigate any triggered alerts to determine the scope of the compromise and take appropriate remediation steps.
• Consider implementing multi-factor authentication (MFA) to mitigate the risk of brute-force attacks.
• Monitor network traffic for suspicious activity originating from the source IP address associated with the brute-force attempts.
• Review and enforce strong password policies to reduce the likelihood of successful password guessing.

Attack Chain

1. The attacker gains initial access to the system (e.g., via phishing or exploitation of a vulnerability).
2. The attacker executes code within the context of a user account.
3. The attacker leverages the Secondary Logon service (seclogon.dll) to request access to LSASS.
4. The malicious code interacts with the seclogon service to obtain a handle to the LSASS process with specific access rights (0x14c0), typically from a svchost.exe process.
5. The seclogon service, acting on behalf of the attacker, grants access to LSASS.
6. The attacker uses the leaked LSASS handle to read memory contents.
7. The attacker extracts sensitive information, such as user credentials (passwords, NTLM hashes, Kerberos tickets), from the LSASS memory.
8. The attacker uses the stolen credentials for lateral movement, privilege escalation, or data exfiltration.

Impact

Successful exploitation allows attackers to steal user credentials, leading to unauthorized access to sensitive systems and data. This can result in data breaches, financial losses, and reputational damage. The compromise of domain administrator credentials can grant the attacker complete control over the entire Windows domain.

Recommendation

• Enable Sysmon process creation logging (event ID 1) and process access logging (event ID 10) to detect suspicious LSASS handle access.
• Deploy the Sigma rule “Suspicious Lsass Handle Access via MalSecLogon” to your SIEM and tune for your environment.
• Investigate any alerts generated by the Sigma rule, focusing on the call trace, access rights, and source process.
• Monitor authentication events for signs of credential misuse following suspicious LSASS access.
• Review local administrator and debug-privilege exposure, LSASS protection such as RunAsPPL or Credential Guard where supported, and Secondary Logon service necessity on critical servers
• Block the GrantedAccess value “0x14c0” in conjunction with CallTrace “seclogon.dll” when the TargetImage is “lsass.exe” (Sysmon Event ID 10).

Attack Chain

1. An attacker gains initial access to the target system through various means.
2. The attacker attempts to escalate privileges to gain administrative rights.
3. The attacker uses a custom tool or script to call the OpenProcess, OpenThread or ReadProcessMemory Windows APIs.
4. The tool targets the lsass.exe process to obtain a handle for memory access.
5. The attacker uses the obtained handle to read LSASS memory, searching for credential data.
6. The attacker extracts usernames, passwords, and other sensitive information from the dumped memory.
7. The attacker uses the stolen credentials for lateral movement to other systems on the network.
8. The attacker achieves their final objective, which may include data exfiltration or system compromise.

Impact

Successful exploitation can lead to the compromise of domain credentials, allowing attackers to move laterally within the network and gain access to sensitive resources. This can result in data breaches, system compromise, and significant financial or reputational damage. The rule aims to detect these attacks early, limiting the scope of the potential compromise.

Recommendation

• Deploy the Sigma rule “LSASS API Access by Non-Standard Process” to your SIEM and tune for your environment to detect suspicious access to the LSASS process.
• Investigate any alerts triggered by this rule, focusing on the process execution chain and the access rights requested as documented in the provided Microsoft documentation.
• Enable process creation and API call logging via Elastic Defend or Microsoft Defender XDR to provide the necessary data for this detection.
• Review and harden LSASS protection mechanisms such as Credential Guard to minimize the risk of successful credential dumping.
• Implement the Osquery queries to gather system information like DNS cache, services, and unsigned executables, to aid in investigation and threat hunting.

Attack Chain

1. The attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
2. The attacker executes code on the target system, potentially using tools like PowerShell or command-line utilities.
3. The attacker initiates a process to clone the LSASS process using PssCaptureSnapShot.
4. The newly created process, a clone of LSASS, runs alongside the original.
5. The attacker leverages the cloned LSASS process to dump its memory. This may involve tools like comsvcs.dll, rundll32.exe or custom scripts leveraging the MiniDumpWriteDump function.
6. The attacker extracts sensitive information from the dumped memory, including usernames, passwords, and Kerberos tickets.
7. The attacker uses the extracted credentials to move laterally within the network, accessing additional systems and resources.
8. The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

Successful exploitation can result in the compromise of sensitive credentials stored in LSASS memory, including domain and local account credentials. This can lead to unauthorized access to critical systems and data, potentially resulting in data breaches, financial loss, and reputational damage. Domain controllers, jump hosts, and systems with privileged accounts are at especially high risk. The number of affected systems can range from a single machine to a large portion of the network, depending on the attacker’s objectives and the scope of the compromised credentials.

Recommendation

• Enable and monitor Windows Security Event Logs with event code 4688 for process creation events, specifically focusing on the process and parent process names to identify LSASS cloning attempts (see rule below).
• Deploy the provided Sigma rule to your SIEM to detect potential LSASS clone creation via PssCaptureSnapShot. Tune the rule for your environment to reduce false positives.
• Investigate any alerts generated by the Sigma rule, focusing on identifying the processes involved in cloning and dumping LSASS memory.
• Enable Audit Process Creation and Command Line logging as per the Elastic documentation to ensure the events used by the provided Sigma rules are captured.
• If a LSASS clone is detected, review authentication events (4624, 4648, 4625) on the affected host to identify any suspicious logons or credential usage.
• Monitor for file activity related to memory dumps (e.g., .dmp files) using the process clone to identify potential credential theft attempts.

Attack Chain

1. The attacker gains initial access to the Windows web server, often through a web shell or by exploiting a vulnerability in a web application.
2. The attacker executes appcmd.exe via the command line.
3. The attacker uses the list argument to enumerate application pools or other relevant IIS configurations.
4. The attacker uses /text:*password*, /text:*processModel*, /text:*userName*, /config or *connectionstring* parameters with appcmd.exe to filter the output and specifically target credential-related data. Alternatively the attacker may use /text:* to output the full configuration.
5. appcmd.exe outputs the requested configuration data, which may include usernames, passwords, and connection strings in clear text.
6. The attacker parses the output to extract valid credentials.
7. The attacker uses the extracted credentials to authenticate to other systems or services within the network.
8. The attacker achieves lateral movement, privilege escalation, and access to sensitive data.

Impact

Successful exploitation allows attackers to recover service account passwords and other sensitive credentials stored within the IIS configuration. This can lead to unauthorized access to databases, file shares, and other internal systems, potentially resulting in data breaches, financial loss, and reputational damage. While the rule itself is low severity, the subsequent impact of exposed credentials can be severe.

Recommendation

• Deploy the “Microsoft IIS Service Account Password Dumped” Sigma rule to your SIEM to detect the use of appcmd.exe to dump sensitive IIS configuration data.
• Review IIS and web server activity for signs of exploitation, such as requests to newly created ASPX or PHP files as suggested in the rule’s Triage and Analysis section.
• Enable Sysmon process creation logging to activate the rules above and provide detailed process execution data.
• Implement the password rotation for affected service accounts as suggested in the rule’s Triage and Analysis section.

Attack Chain

1. Initial Access: An attacker gains access to a valid Okta session token or cookie through methods such as phishing or malware.
2. Session Token Theft: The attacker steals a valid Okta session token/cookie from a compromised endpoint.
3. Session Replay: The attacker replays the stolen session token/cookie from a different device and network location than the original user.
4. Okta Authentication: The replayed session token authenticates to Okta, creating a new session instance.
5. Multiple Device Hashes: Because the session is accessed from a different device, a new device token hash is generated. The attacker may also use proxy services from different locations.
6. Unauthorized Access: The attacker uses the hijacked session to access Okta resources, such as the admin console or applications.
7. Privilege Escalation (Optional): If the hijacked session belongs to a privileged user, the attacker may escalate privileges within the Okta environment.
8. Data Exfiltration/Manipulation: The attacker exfiltrates sensitive data or modifies Okta configurations to establish persistence or further compromise the environment.

Impact

A successful Okta session hijacking attack can lead to unauthorized access to sensitive applications and data, privilege escalation, and disruption of business operations. The impact can range from data breaches and financial loss to reputational damage and regulatory fines. Attackers can potentially access and modify user accounts, security policies, and application integrations. The number of potential victims depends on the scope of the attacker’s access and the sensitivity of the data they can access.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect multiple device token hashes and source IPs for single Okta sessions and tune for your environment.
• Investigate alerts generated by the Sigma rule by pivoting into Okta system logs using the okta.actor.alternate_id and okta.authentication_context.external_session_id fields.
• Monitor Okta system logs for suspicious post-authentication activity, such as admin console access, policy changes, or application assignment modifications as described in the rule’s triage steps.
• Enforce MFA enrollment for all Okta users to mitigate the risk of session hijacking and credential theft, as recommended in the investigation guide.
• Revoke active sessions and reset passwords for affected users exhibiting suspicious activity as mentioned in the false positive analysis.

Attack Chain

1. Attacker gains initial access to a Kubernetes cluster, possibly through compromising a pod or node.
2. Attacker obtains credentials for a service account associated with the compromised pod or accesses node credentials.
3. Attacker uses the stolen credentials to authenticate against the Kubernetes API.
4. The attacker attempts to enumerate secrets within the cluster using kubectl get secrets --all-namespaces or similar API calls.
5. The Kubernetes API server receives the request and generates an audit log entry.
6. This audit log entry contains details such as the user (system:node:* or system:serviceaccount:*), the action (get or list), and the resource (secrets).
7. The attacker identifies valuable secrets containing sensitive information such as API keys or database passwords.
8. Attacker exfiltrates the secrets, gaining unauthorized access to other systems or data.

Impact

Compromised Kubernetes secrets can lead to a wide range of security breaches, including unauthorized access to sensitive data, lateral movement within the cluster, and compromised external services that rely on the exposed credentials. If successful, attackers could gain complete control over the cluster and its applications, leading to data breaches, service disruption, and reputational damage. The risk is elevated in environments where secrets are not properly managed or where RBAC is overly permissive.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized secret access attempts by node or pod service accounts in Kubernetes audit logs.
• Review RBAC configurations to ensure least privilege for service accounts and nodes, limiting their access to only necessary secrets.
• Investigate any alerts generated by the Sigma rule, focusing on cross-namespace access, high-value secret names, and unusual user agents.
• Implement a process for regularly rotating secrets and auditing access to sensitive resources within the Kubernetes cluster.
• Baseline normal secret access patterns for in-cluster operators, CSI drivers, and GitOps agents, and create allowlists to reduce false positives.

Attack Chain

1. An attacker gains initial access to a Windows system, possibly through phishing or exploitation of a vulnerability.
2. The attacker elevates privileges to gain administrative rights, which are required to create shadow copies and symbolic links.
3. The attacker creates a volume shadow copy using vssadmin.exe or similar tools.
4. The attacker uses mklink command or PowerShell New-Item -ItemType SymbolicLink to create a symbolic link to the shadow copy path.
5. The symbolic link points to a directory within the shadow copy containing sensitive files like ntds.dit or browser credential stores.
6. The attacker copies the targeted sensitive files (e.g., ntds.dit) from the shadow copy using the symbolic link.
7. The attacker removes the shadow copy to cover their tracks, although the symbolic link creation remains as evidence.
8. The attacker extracts credentials from the copied ntds.dit file offline for use in lateral movement or further attacks.

Impact

Successful exploitation allows attackers to gain unauthorized access to sensitive credentials stored on the compromised system. This can lead to lateral movement within the network, privilege escalation, and ultimately, the compromise of critical assets. If the ntds.dit file is accessed, the entire Active Directory domain could be at risk, potentially affecting thousands of users and systems. This type of attack is particularly damaging as it allows attackers to operate undetected for extended periods while they harvest credentials.

Recommendation

• Deploy the provided Sigma rule “Symbolic Link to Shadow Copy Created via Cmd” to detect the creation of symbolic links to shadow copies via cmd.exe (rules).
• Deploy the provided Sigma rule “Symbolic Link to Shadow Copy Created via PowerShell” to detect the creation of symbolic links to shadow copies via powershell.exe (rules).
• Enable Sysmon Event ID 1 (Process Creation) logging to provide necessary data for the Sigma rules to function correctly (setup).
• Review the “Investigating Symbolic Link to Shadow Copy Created” section in the rule’s notes for triage and analysis steps when the rule triggers.
• Monitor for the usage of mklink command with the HarddiskVolumeShadowCopy argument in process command lines.

Attack Chain

1. An attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).
2. The attacker executes a script or command to launch a browser process (chrome.exe or msedge.exe).
3. The browser is launched with specific command-line arguments, such as --remote-debugging-port, --headless, or --window-position=-x,-y, to enable remote control or hide the browser window.
4. The parent process of the browser is an unusual executable, not typically associated with launching browsers (e.g., not explorer.exe).
5. The attacker leverages the remote debugging port to interact with the browser session programmatically.
6. The attacker attempts to steal credentials or session cookies from the browser.
7. The attacker uses stolen credentials to access sensitive data.

Impact

Successful exploitation can lead to the theft of user credentials, enabling unauthorized access to sensitive data and systems. This could result in financial loss, data breaches, and reputational damage for affected organizations. The targeted use of browser manipulation techniques increases the likelihood of bypassing traditional security controls.

Recommendation

• Deploy the Sigma rule Browser Process Spawned from Unusual Parent to your SIEM and tune for your environment.
• Enable Sysmon process-creation logging (Event ID 1) to collect the necessary data for the Sigma rule.
• Investigate any alerts generated by the Browser Process Spawned from Unusual Parent Sigma rule.
• Review process command lines for arguments like --remote-debugging-port or --headless to identify potential browser manipulation attempts.
• Monitor network connections originating from browser processes for unexpected destinations, as described in the investigation guide from the source.

Attack Chain

1. An attacker gains initial access to the target system (e.g., via phishing or exploitation of a vulnerability).
2. The attacker executes a malicious program or script on the compromised system.
3. The malicious code attempts to open a handle to the LSASS process.
4. Instead of using NtOpenProcess, the attacker leverages the DuplicateHandle function to obtain a handle to LSASS.
5. The DuplicateHandle call originates from an unknown or suspicious module, as indicated by “UNKNOWN” in the call trace.
6. With a valid handle to LSASS, the attacker dumps the LSASS memory to a file or other location.
7. The attacker parses the dumped memory to extract sensitive credentials.
8. The attacker uses the stolen credentials for lateral movement, privilege escalation, or data exfiltration.

Impact

Successful exploitation could lead to the compromise of user credentials, including domain administrator accounts. This can give attackers unrestricted access to the entire domain, allowing them to steal sensitive data, install malware, or disrupt critical services. The impact can range from data breaches and financial loss to complete infrastructure compromise.

Recommendation

• Enable Sysmon process creation and event 10 logging to capture the necessary telemetry for this detection. (Setup instructions: https://ela.st/sysmon-event-10-setup)
• Deploy the Sigma rule “Potential Credential Access via DuplicateHandle in LSASS” to your SIEM and tune for your environment to reduce false positives.
• Investigate any alerts generated by this rule by reviewing the event logs and call trace details to identify suspicious modules or processes.
• Implement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function.

Attack Chain

1. An attacker gains initial access to an Azure account, possibly through compromised credentials or exploiting a vulnerability (T1078.004).
2. The attacker enumerates available applications and service principals within the Azure environment.
3. The attacker identifies a target application with a high-value AppID URI.
4. The attacker modifies the AppID URI of the target application, potentially to impersonate another service or application (T1552).
5. This change might be done to allow the attacker to request tokens for that application.
6. The attacker leverages the modified AppID URI to request access tokens, potentially gaining unauthorized access to resources (T1078.004).
7. The attacker uses the acquired access tokens to move laterally within the Azure environment and access sensitive data or systems.
8. The attacker maintains persistence by using the modified application for continued unauthorized access.

Impact

Successful modification of an AppID URI can lead to significant security breaches, including unauthorized access to sensitive data, privilege escalation, and persistent compromise of the Azure environment. An attacker can impersonate legitimate applications, bypassing security controls and potentially affecting numerous resources and users. The scope of the impact depends on the permissions and access levels associated with the compromised application.

Recommendation

• Deploy the Sigma rule “Application AppID Uri Configuration Changes” to your SIEM to detect unauthorized modifications to AppID URIs (rule provided below).
• Investigate any alerts generated by the Sigma rule to determine the legitimacy of the AppID URI changes.
• Implement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.
• Regularly review and audit application permissions and configurations to identify and remediate any misconfigurations.
• Monitor Azure audit logs for other suspicious activities related to application and service principal management.

Attack Chain

1. An attacker gains initial access to a compromised account with sufficient privileges to modify user rights.
2. The attacker assigns the SeEnableDelegationPrivilege to a target account using tools like ntrights.exe or PowerShell cmdlets.
3. Windows Security Event 4704 is generated, logging the privilege assignment.
4. The attacker modifies the target account’s attributes, such as userAccountControl or msDS-AllowedToDelegateTo, to enable delegation.
5. The attacker leverages Kerberos delegation to impersonate other users or services.
6. Using the impersonated credentials, the attacker accesses sensitive resources or performs privileged actions.
7. The attacker moves laterally within the network, compromising additional systems and accounts.
8. The attacker achieves their final objective, such as data exfiltration or domain dominance.

Impact

Successful exploitation allows attackers to compromise Active Directory accounts and elevate privileges, potentially leading to full control over the domain. The impact includes unauthorized access to sensitive data, lateral movement to critical systems, and the potential for long-term persistence. Depending on the compromised accounts, the entire organization can be at risk.

Recommendation

• Enable “Audit Authorization Policy Change” to generate Windows Security Event ID 4704 (Setup instructions: https://ela.st/audit-authorization-policy-change).
• Deploy the Sigma rule “Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal” to your SIEM to detect the assignment of this privilege.
• Investigate any instances where SeEnableDelegationPrivilege is assigned, focusing on the targeted account and the source of the change.
• Monitor for modifications to delegation-related attributes on user and computer objects.

Attack Chain

1. An attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).
2. The attacker executes Mimikatz or a similar tool with the misc::memssp module.
3. Mimikatz injects a malicious SSP library (e.g., mimilib.dll) into the LSASS process (lsass.exe).
4. The injected SSP hooks into the authentication process.
5. When users log on to the system, the SSP captures their credentials.
6. The captured credentials are written to the mimilsa.log file, typically located in C:\Windows\System32\.
7. The attacker retrieves the mimilsa.log file to obtain the captured credentials.
8. The attacker uses the stolen credentials to escalate privileges, move laterally within the network, and access sensitive resources.

Impact

A successful Mimikatz MemSSP attack can lead to the compromise of user accounts, including those with administrative privileges. This allows attackers to gain unauthorized access to sensitive data, systems, and resources within the organization. Lateral movement becomes easier, potentially impacting a large number of systems. The compromised credentials can also be used for external attacks, such as gaining access to cloud services or other external resources.

Recommendation

• Deploy the Sigma rule Mimikatz Memssp Log File Detected to your SIEM and tune for your environment.
• Enable Sysmon file creation logging to detect the creation of mimilsa.log files.
• Investigate any alerts generated by the Sigma rule, focusing on the process that created the log file and any subsequent file access.
• Monitor for the presence of mimilib.dll and any LSA Security Packages registry modifications, as these may indicate persistent SSP installation.
• Review and restrict interactive logons to high-value hosts to minimize the potential for credential theft.
• Investigate related alerts for the same host.id in the last 48 hours covering delivery, privilege escalation, LSASS access, persistence, lateral movement, or additional credential access.

Attack Chain

1. The attacker gains initial access to the Azure Kubernetes cluster, possibly through compromised credentials or a vulnerability in a deployed application.
2. The attacker identifies the existing Admission Controller configuration within the Kubernetes cluster.
3. The attacker crafts a malicious MutatingAdmissionWebhook configuration to intercept pod creation requests.
4. The malicious webhook is deployed to the cluster, configured to modify pod specifications.
5. When new pods are created, the webhook injects a malicious container into the pod specification before deployment.
6. The malicious container executes within the newly created pod, providing the attacker with persistent access to the cluster.
7. Alternatively, the attacker crafts a malicious ValidatingAdmissionWebhook to intercept API requests.
8. The webhook captures sensitive data, such as secrets, and sends it to an attacker-controlled server, resulting in credential access.

Impact

Compromising the Kubernetes Admission Controller can lead to persistent access within the cluster. The attacker can inject malicious containers into numerous pods, potentially affecting all applications deployed in the cluster. Sensitive information, like secrets, can be stolen, enabling lateral movement and privilege escalation within the Azure environment. The impact ranges from data breaches to complete cluster compromise.

Recommendation

• Deploy the Sigma rule “Azure Kubernetes Admission Controller Configuration Change” to detect unauthorized modifications to Admission Controller configurations in Azure Activity Logs.
• Regularly review and audit existing Admission Controller configurations for any unexpected or malicious webhooks.
• Implement strong RBAC policies to restrict access to Admission Controller configuration and prevent unauthorized modifications.
• Monitor Azure Activity Logs for MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO and MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO operations to identify potential abuse.

Attack Chain

1. The user executes a malicious file, potentially delivered via phishing or drive-by download (not covered in source).
2. The malicious file executes and establishes persistence on the system.
3. The malware attempts to access the Firefox profile directory, located at *\AppData\Roaming\Mozilla\Firefox\Profiles*.
4. Windows Security Event 4663 is generated, logging the access attempt to the Firefox profile directory.
5. The malware reads sensitive data, such as login credentials, cookies, and browsing history, from the profile directory.
6. The stolen data is exfiltrated to a command-and-control (C2) server.
7. The attacker uses the stolen credentials to gain unauthorized access to user accounts and sensitive systems.

Impact

Successful exploitation and credential theft can lead to a wide range of negative outcomes, including unauthorized access to sensitive data, financial fraud, and further compromise of systems within the organization. The impact can range from individual user account compromise to large-scale data breaches affecting thousands of users. Industries heavily reliant on web-based applications and sensitive user data, such as finance, healthcare, and e-commerce, are particularly vulnerable. The consequences include financial losses, reputational damage, and legal liabilities.

Recommendation

• Enable “Audit Object Access” in Group Policy and configure it to log both success and failure events for object access to activate the underlying log source required for this detection.
• Deploy the provided Sigma rule to your SIEM to detect non-Firefox processes accessing Firefox profile directories.
• Investigate any alerts generated by the Sigma rule, paying close attention to the ProcessName and ObjectName to identify potentially malicious processes and the specific profile data being accessed.
• Review and update your organization’s security policies to restrict unauthorized access to sensitive user data.

Attack Chain

1. Attacker gains initial access to the target system via compromised credentials or exploiting a vulnerability.
2. Attacker uses remote registry tools or scripts, such as those based on Impacket’s secretsdump.py, to connect to the target system’s registry service.
3. The attacker initiates a connection to the RemoteRegistry service.
4. The svchost.exe process on the target system is leveraged to access the SAM, SECURITY, and SYSTEM registry hives.
5. svchost.exe creates a temporary file (e.g., a .tmp file) in the \Windows\System32\ or \WINDOWS\Temp\ directory.
6. The temporary file contains the contents of the registry hive, identifiable by the “72656766” (REGF) header bytes and a file size greater than 30000 bytes.
7. The attacker retrieves the dumped registry hive files from the target system.
8. The attacker parses the registry hives offline to extract sensitive credential information, such as password hashes. This leads to lateral movement and privilege escalation.

Impact

A successful attack allows adversaries to extract sensitive credentials, including password hashes, from the compromised system. This can lead to lateral movement within the network, privilege escalation, and ultimately, domain compromise. The extraction of credentials provides the attacker with persistent access and the ability to move undetected through the environment.

Recommendation

• Deploy the Sigma rule Suspicious Svchost.exe Registry Hive Dump to detect the creation of registry hive files by svchost.exe in temporary directories based on the file.Ext.header_bytes and file.path fields.
• Deploy the Sigma rule Suspicious RemoteRegistry File Creation to detect files with REGF header bytes created by svchost.exe, outside the standard system path to catch unusual service context.
• Enable and monitor process creation events, specifically focusing on svchost.exe and its command-line arguments, to identify suspicious service groups.
• Monitor file creation events for files with the .tmp extension in the \Windows\System32\ and \WINDOWS\Temp\ directories, paying attention to file sizes and header bytes, as indicated by the file path and size conditions in the rule.
• Review the investigation steps outlined in the rule documentation to properly triage and analyze potential incidents.

Attack Chain

1. The attacker gains initial access to a machine within the network.
2. The attacker initiates a coercion attack against a target server, forcing it to authenticate to a malicious endpoint. This often involves leveraging vulnerabilities in services such as Spoolss, Netlogon, or other RPC services. The attacker uses methods outlined in the referenced coercion authentication research.
3. The target server attempts to access a named pipe on the attacker-controlled system. This is logged as a File Share event (Event ID 5145) on the target server, indicating access to a named pipe like Spoolss, netdfs, lsarpc, lsass, netlogon, samr, efsrpc, FssagentRpc, eventlog, winreg, srvsvc, dnsserver, or WinsPipe.
4. The attacker captures the NTLM authentication attempt from the target server.
5. The attacker relays the captured NTLM authentication to another service on the network, impersonating the target server. The authentication event is logged (Event ID 4624 or 4625), showing a logon attempt using the NTLM protocol and a computer account (username ending in “$”).
6. The authentication attempt originates from a different IP address than the target server’s IP, indicating the relay.
7. If successful, the attacker gains unauthorized access to the service and can execute commands or access data with the privileges of the target server’s computer account.
8. The attacker leverages the compromised computer account to move laterally within the network, potentially gaining access to sensitive resources or escalating privileges further.

Impact

A successful NTLM relay attack can allow attackers to gain control of critical systems and data. By compromising a computer account, attackers can move laterally within the network, access sensitive information, and potentially disrupt business operations. The number of victims and the extent of the damage can vary depending on the scope of the attacker’s activities after compromising the computer account. Organizations in any sector that rely on Windows networks and Active Directory are vulnerable. Failure to detect and prevent these attacks can lead to significant financial losses, reputational damage, and regulatory penalties.

Recommendation

• Enable and monitor Windows Security Event Logs, specifically for Event IDs 5145 (File Share access), 4624 (Successful Logon), and 4625 (Failed Logon), as these are crucial for detecting NTLM relay attempts.
• Deploy the Sigma rules provided in this brief to your SIEM to detect potential NTLM relay attacks based on the sequence of file access and authentication events.
• Investigate any alerts generated by the Sigma rules, focusing on the source and target of the authentication events, the named pipes accessed, and any follow-on activity.
• Review and harden NTLM configuration to mitigate relay attacks, and consider disabling NTLM where possible in favor of more secure authentication protocols like Kerberos.
• Enable SMB signing and Extended Protection for Authentication to prevent NTLM relay attacks.
• Implement network segmentation and access controls to limit the scope of potential NTLM relay attacks.
• Apply the “Setup” configurations by enabling the recommended Windows audit policies to ensure the events required by the rules are generated.

Attack Chain

1. An attacker gains initial access to a user’s credentials through phishing, credential stuffing, or malware.
2. The attacker attempts to log in to an Azure AD-protected resource using the compromised credentials.
3. The attacker fails to authenticate, either because they do not have the correct password or MFA is enabled.
4. The attacker initiates a password reset request using the “Forgot password” feature or a similar mechanism.
5. Azure AD sends a password reset verification code or link to the user’s registered email address or phone number.
6. If the attacker controls the registered email address or phone number (due to prior compromise), they can access the verification code or link.
7. The attacker uses the verification code or link to set a new password for the user’s Azure AD account.
8. The attacker logs in to the Azure AD account with the new password, gaining unauthorized access.

Impact

Successful password resets by attackers can lead to complete account takeover, allowing them to access sensitive data, resources, and systems protected by Azure AD. This can result in data breaches, financial loss, reputational damage, and disruption of business operations. The impact depends on the privileges and permissions assigned to the compromised account.

Recommendation

• Deploy the Sigma rule Password Reset By User Account to your SIEM to detect user-initiated password resets in Azure AD audit logs.
• Investigate any detected password resets, especially those initiated by users who have not recently requested a password change.
• Review and enforce multi-factor authentication (MFA) policies to prevent attackers from bypassing password-based authentication.
• Monitor Azure AD audit logs for suspicious activity related to password resets, such as multiple failed login attempts followed by a successful reset.

Attack Chain

1. A Kubernetes service account projects a token.
2. The service account uses AssumeRoleWithWebIdentity to exchange the token for short-lived IAM credentials.
3. The attacker leverages the assumed role to perform reconnaissance activities such as ListUsers, ListRoles, and DescribeInstances.
4. The attacker attempts to access secrets using actions like GetSecretValue and ListSecrets.
5. The attacker escalates privileges by modifying IAM policies with actions like AttachRolePolicy and PutRolePolicy.
6. The attacker attempts to create new users or roles within the AWS environment using actions like CreateUser and CreateRole.
7. The attacker performs lateral movement using actions like SendCommand and StartSession.
8. The attacker attempts to evade detection by stopping logging with the StopLogging action.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, privilege escalation, and the potential compromise of the entire AWS environment. Lateral movement within the AWS infrastructure allows attackers to gain access to critical systems and data, potentially leading to data breaches, service disruptions, or other malicious activities.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect potentially malicious activity related to AssumeRoleWithWebIdentity and tune for your environment.
• Review and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the IAM OIDC identity provider documentation.
• Implement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in EKS IAM roles for service accounts.
• Monitor CloudTrail logs for AssumeRoleWithWebIdentity events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.

Attack Chain

1. Initial Access: Attacker gains initial access to a system with sufficient privileges to modify Active Directory objects.
2. Discovery: The attacker identifies a target user or computer object within Active Directory to compromise.
3. Credential Access: The attacker generates a new key pair.
4. Privilege Escalation: The attacker modifies the msDS-KeyCredentialLink attribute of the target object to include the attacker’s public key. This requires specific permissions on the target object.
5. Persistence: The attacker uses the private key to authenticate as the target object, bypassing normal authentication mechanisms.
6. Lateral Movement: The attacker uses the compromised account to move laterally within the network, accessing resources and systems.
7. Impact: The attacker achieves their objective, such as data exfiltration, system compromise, or further privilege escalation.

Impact

Successful exploitation allows attackers to maintain persistent and stealthy access to Active Directory objects, potentially compromising sensitive accounts and resources. Shadow Credentials can be used to bypass multi-factor authentication and other security controls, leading to significant data breaches or system-wide compromises. Without proper monitoring and alerting, these attacks can remain undetected for extended periods.

Recommendation

• Enable and monitor Windows Security Event Logs, specifically event ID 5136, for modifications to the msDS-KeyCredentialLink attribute as described in the rule description.
• Deploy the provided Sigma rule to your SIEM to detect suspicious modifications to the msDS-KeyCredentialLink attribute, and tune for your environment.
• Implement strict access controls and auditing on Active Directory objects, particularly those with sensitive privileges, to prevent unauthorized modifications.
• Investigate any alerts generated by the Sigma rule by examining the winlog.event_data.ObjectDN, winlog.event_data.SubjectUserName, and winlog.event_data.AttributeValue fields to determine the legitimacy of the changes.
• Follow the triage and analysis steps in the rule’s note field to investigate alerts.

Attack Chain

1. An attacker gains initial access to a system, possibly via compromised credentials or exploiting a vulnerability.
2. The attacker uses a shell (cmd.exe, PowerShell, bash, etc.) to execute cloud CLI commands.
3. The attacker executes commands to list available credentials or tokens (e.g., aws configure list, az account list, kubectl config view).
4. The attacker executes commands to print access tokens for various cloud providers (e.g., gcloud auth print-access-token, az account get-access-token, gh auth token).
5. The attacker uses credential harvesting commands across multiple cloud platforms within a short timeframe.
6. The attacker exfiltrates the harvested credentials to a remote location.
7. The attacker uses the stolen credentials to access sensitive cloud resources and data.
8. The attacker performs lateral movement within the cloud environment.

Impact

A successful attack can lead to unauthorized access to sensitive cloud resources, data breaches, and lateral movement within cloud environments. The impact includes potential data exfiltration, service disruption, and financial loss. The number of affected victims will depend on the scope of the compromised credentials and the attacker’s ability to exploit them.

Recommendation

• Deploy the Sigma rule “Multi-Cloud CLI Token and Credential Access Commands” to your SIEM to detect suspicious command-line activity related to cloud credential harvesting.
• Review Esql.process_command_line_values in the rule output to identify the exact commands executed and determine if the activity was legitimate or malicious.
• Correlate the detected activity with authentication, Kubernetes audit, and cloud API logs to confirm unauthorized access and misuse of printed tokens.
• Implement monitoring and alerting for unusual CLI activity originating from user workstations or build servers, focusing on the CLIs mentioned in the Overview section.
• Follow vendor-specific guidance to revoke compromised credentials, such as revoking tokens and rotating secrets, as outlined in the rule’s “Response and remediation” section.

Attack Chain

1. Initial access is gained via compromised AWS credentials or by exploiting an AWS vulnerability.
2. The attacker enumerates the current AWS Identity Center configuration to identify the currently associated directory.
3. The attacker disassociates the existing, legitimate directory using DisassociateDirectory.
4. The attacker associates a malicious directory they control using AssociateDirectory. This malicious directory is configured to impersonate legitimate users.
5. Alternatively, the attacker disables external IdP configuration for the directory using DisableExternalIdPConfigurationForDirectory.
6. The attacker enables external IdP configuration for the directory, pointing to an attacker-controlled IdP, using EnableExternalIdPConfigurationForDirectory.
7. The attacker uses the malicious or attacker-controlled IdP to authenticate as legitimate users, gaining access to AWS resources.
8. The attacker performs malicious actions within the AWS environment, such as data exfiltration or resource destruction.

Impact

Successful modification of the AWS Identity Center identity provider can lead to complete compromise of an AWS environment. Attackers can gain persistent access, escalate privileges, and impersonate legitimate users. This can result in data breaches, service disruption, financial loss, and reputational damage. The impact can extend to all AWS accounts and applications managed by the compromised Identity Center instance.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized changes to the AWS Identity Center identity provider.
• Investigate any detected events related to AssociateDirectory, DisableExternalIdPConfigurationForDirectory, DisassociateDirectory, or EnableExternalIdPConfigurationForDirectory in AWS CloudTrail logs.
• Implement multi-factor authentication (MFA) for all AWS accounts and users to reduce the risk of credential compromise.
• Review and restrict IAM permissions to minimize the blast radius of compromised credentials.
• Monitor AWS CloudTrail logs for unusual activity patterns that might indicate malicious directory association attempts.

Attack Chain

1. A user downloads and executes a malicious file, often disguised as a legitimate application or document.
2. The malicious file executes, dropping a stealer component into the system.
3. The stealer process initiates an attempt to access browser user data profiles.
4. Windows generates a Security Event Log (EventCode 4663) when the stealer attempts to access a browser data file.
5. The detection analytic identifies processes accessing the browser data folder not present in the browser_app_list lookup file.
6. The stealer process reads sensitive information, such as usernames, passwords, and browsing history, from the accessed files.
7. The collected data is staged for exfiltration, potentially compressed or encrypted.
8. The stolen credentials and information are exfiltrated to a command-and-control server.

Impact

Successful exploitation leads to the theft of user credentials, potentially granting attackers unauthorized access to sensitive accounts and systems. This can result in data breaches, financial loss, and reputational damage. The Snake Keylogger, for example, is known to target credentials, potentially impacting a wide range of users and organizations. Other stealers like Meduza Stealer, 0bj3ctivity Stealer, and BlankGrabber Stealer also utilize similar techniques, showing the widespread impact. The impact spans across various sectors, as credential theft is a generic attack applicable to almost any environment.

Recommendation

• Enable Windows Security Event Logging, specifically event code 4663, with auditing enabled for both success and failure events, to capture object access attempts (reference: search description).
• Populate and maintain the browser_app_list lookup table with known and allowed browser processes and their associated paths (reference: search description).
• Deploy the provided Sigma rule to your SIEM to detect anomalous processes accessing browser password stores, and tune it for your specific environment (reference: rules).
• Investigate any alerts generated by the Sigma rule to identify potentially compromised systems and user accounts (reference: rules).

Attack Chain

1. The attacker gains initial access to an Azure account with sufficient privileges to modify application registrations.
2. The attacker navigates to the Azure Active Directory portal.
3. The attacker locates a target application registration.
4. The attacker modifies the application’s URI settings, such as the reply URLs or identifier URIs.
5. The attacker configures the URI to point to a malicious server or a phishing page.
6. Users or applications are redirected to the malicious URI when attempting to authenticate or access the application.
7. The attacker intercepts credentials or performs other malicious actions.
8. The attacker establishes persistence by maintaining control over the application’s URI settings.

Impact

A successful attack could lead to credential theft, data breaches, or unauthorized access to sensitive resources. By compromising application URIs, attackers can redirect users to phishing pages, intercept credentials, or gain a foothold in the environment for further exploitation. This activity can be difficult to detect and can have a significant impact on the organization’s security posture.

Recommendation

• Deploy the Sigma rule Application URI Configuration Changes to your SIEM to detect suspicious modifications to application URIs in Azure Audit Logs.
• Investigate any alerts generated by the Sigma rule Application URI Configuration Changes to determine if the URI modification is legitimate or malicious.
• Monitor Azure Audit Logs for any changes to application URI settings (as indicated by properties.message: Update Application Sucess- Property Name AppAddress) and validate the legitimacy of the changes.

Attack Chain

1. The attacker gains initial access through an undisclosed means (e.g., phishing, exploit).
2. The attacker executes certutil.exe via cmd.exe or PowerShell.
3. Certutil is used with the urlcache parameter to download a malicious payload from a remote server.
4. Certutil uses the decode parameter to decode a base64-encoded payload, saving it to disk.
5. The attacker uses certutil with encodehex to encode a binary into a hexadecimal representation to evade signature-based detection.
6. The attacker then uses certutil with decodehex to decode the hexadecimal encoded data.
7. The attacker executes the decoded payload, gaining further control of the system.
8. The attacker establishes a command and control channel, using certutil to encode/decode communications.

Impact

Successful exploitation allows attackers to download and execute arbitrary code, bypass security measures, and maintain persistence within the compromised system. This can lead to data exfiltration, system compromise, and further propagation of the attack within the network. The lack of directly observed IOCs in the originating advisory limits quantification of victim count and impact scope, but the technique is widely applicable.

Recommendation

• Deploy the Sigma rule “Suspicious CertUtil Usage for Encoding/Decoding” to detect abuse of encoding/decoding functions within certutil.exe, focusing on unusual file types or destinations.
• Deploy the Sigma rule “Suspicious CertUtil URL Download” to identify certutil.exe being used to download files from URLs, and tune the rule based on known good software deployment practices.
• Enable Sysmon process creation logging to ensure the rules above function correctly by capturing command-line arguments (as referenced in the logsource for each rule).
• Review historical process execution logs for instances of certutil.exe using suspicious parameters like decode, encode, urlcache, verifyctl, encodehex, decodehex, or exportPFX to identify potentially compromised systems.

Attack Chain

1. An attacker compromises a user account or system within the domain.
2. The attacker executes a malicious binary or script (e.g., PowerShell) on the compromised system.
3. The malicious process attempts to request Kerberos service tickets (TGS) for various services within the domain. This is done by connecting to the Kerberos port (88) on a domain controller.
4. The attacker uses tools like Rubeus or Kerberoast.ps1 to enumerate and request TGS tickets.
5. The unusual process (not lsass.exe) sends Kerberos traffic to the domain controller.
6. The attacker extracts the Kerberos tickets from memory or network traffic.
7. The attacker cracks the offline TGS tickets to obtain service account passwords (Kerberoasting).
8. The attacker uses the compromised service account credentials to move laterally within the network or access sensitive data.

Impact

A successful Kerberoasting or Pass-the-Ticket attack can lead to unauthorized access to sensitive resources and lateral movement within the network. Attackers can compromise service accounts with elevated privileges, potentially leading to domain-wide compromise. Detection of this behavior can prevent attackers from gaining access to critical assets. While the exact number of victims and sectors targeted are unknown, this technique is widely used by various threat actors in targeted attacks.

Recommendation

• Deploy the “Kerberos Traffic from Unusual Process” Sigma rule to your SIEM and tune for your environment. Enable network connection logging to capture the necessary traffic.
• Investigate any alerts triggered by the Sigma rule, focusing on the process execution chain and potential malicious binaries.
• Review event ID 4769 for suspicious ticket requests as mentioned in the rule’s documentation.
• Examine host services for suspicious entries as outlined in the original Elastic detection rule using Osquery.
• Monitor for processes connecting to port 88, filtering out legitimate Kerberos clients like lsass.exe, using the “Detect Kerberos Traffic from Non-Standard Process” Sigma rule.
• Investigate processes identified by the rule and compare them to the list of legitimate processes to identify unauthorized connections to the Kerberos port.

Attack Chain

1. The attacker scans the network to identify systems with open RDP ports (TCP 3389).
2. The attacker initiates multiple RDP connection attempts to a target host, using a list of common usernames and passwords or compromised credentials.
3. The firewall logs each connection attempt, recording the source and destination IPs, ports, and timestamps.
4. Sysmon logs the network connections with Event ID 3.
5. The attacker continues to attempt connections, typically exceeding 10 attempts within an hour.
6. Upon successful authentication, the attacker gains unauthorized access to the target system.
7. The attacker may then install malware, move laterally, or exfiltrate sensitive data.
8. The attacker might deploy ransomware like SamSam or Ryuk, as referenced in external reports.

Impact

Successful RDP brute force attacks can lead to unauthorized access to systems, data breaches, malware infections, and ransomware deployment. Compromised systems can be used as a staging point for further attacks within the network. The references indicate that ransomware attacks have been delivered using RDP brute-force techniques.

Recommendation

• Ensure network traffic data is populating the Network_Traffic data model to enable the provided search query.
• Deploy the Sigma rule RDP Bruteforce via Network Traffic to detect brute force attempts based on network connection patterns.
• Adjust the count and duration thresholds in the detection query to tune the sensitivity for your environment.
• Investigate source IPs identified by the detection rule as potential attackers.
• Monitor Sysmon EventID 3 for network connections to detect RDP brute-force attempts.
• Review the referenced Zscaler and ReliaQuest articles for additional context and mitigation strategies.

Attack Chain

1. Initial access is gained via phishing, exploiting vulnerabilities, or other methods.
2. The attacker executes a malicious process (e.g., Snake Keylogger) on the compromised system.
3. The malicious process attempts to access the Windows registry using standard Windows APIs.
4. The process targets specific registry paths where Outlook stores profile information: *\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676* and *\Windows Messaging Subsystem\Profiles\9375CFF0413111d3B88A00104B2A6676*.
5. Windows Security Event logging generates Event ID 4663 when the registry object is accessed.
6. The attacker extracts the unsecured Outlook credentials from the registry.
7. The attacker uses the stolen credentials to access the victim’s Outlook account.
8. The attacker exfiltrates sensitive information, sends malicious emails, or performs other unauthorized actions.

Impact

Compromised Outlook credentials can lead to unauthorized access to email accounts, enabling attackers to steal sensitive information, impersonate users, and conduct further malicious activities. This can result in significant financial losses, data breaches, and reputational damage. The impact ranges from individual user compromise to enterprise-wide breaches depending on the scope of the attack. Threat actors may use compromised accounts to launch further attacks, potentially impacting other systems and data.

Recommendation

• Enable “Audit Object Access” in Group Policy for Windows Security Event logs to track Event ID 4663 (per the “how_to_implement” section) and monitor registry access.
• Deploy the Sigma rule Detect Suspicious Outlook Registry Access to identify unauthorized processes accessing Outlook credential registry paths.
• Investigate any alerts generated by the Sigma rule Detect Suspicious Outlook Registry Access to determine if credential theft occurred.
• Monitor for processes other than outlook.exe accessing the specific registry paths outlined in the search field to identify potentially malicious activity.