{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/credential-access/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic License v2"],"_cs_severities":["high"],"_cs_tags":["kubernetes","credential-access","execution"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies Kubernetes pod exec sessions accessing sensitive files or credential paths. The goal is to detect attackers attempting to steal credentials or configuration information from within Kubernetes pods. This often occurs after initial access and may precede lateral movement, privilege escalation, or data exfiltration. The detection focuses on command lines that reference paths related to service account tokens, kubelet configuration, host identity stores, common private keys, keystore extensions, process environment dumps, and configuration files with embedded secrets. The rule is designed to catch both interactive and scripted access, and includes exclusions for benign reads of resolv.conf.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster, potentially through a compromised application or misconfigured service.\u003c/li\u003e\n\u003cli\u003eAttacker uses \u003ccode\u003ekubectl exec\u003c/code\u003e or similar tools to execute commands within a pod.\u003c/li\u003e\n\u003cli\u003eThe executed command attempts to read sensitive files or directories within the pod\u0026rsquo;s filesystem, such as \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e to obtain the pod\u0026rsquo;s service account token.\u003c/li\u003e\n\u003cli\u003eThe command may also target host-level files if the pod has hostPath mounts or runs in a privileged context, like \u003ccode\u003e/etc/shadow\u003c/code\u003e or \u003ccode\u003e/etc/passwd\u003c/code\u003e for credential access.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to dump process environments via \u003ccode\u003e/proc/\u0026lt;pid\u0026gt;/environ\u003c/code\u003e to extract sensitive information stored as environment variables.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages obtained credentials or configuration to move laterally to other pods or nodes within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the cluster by abusing stolen service account tokens or node credentials.\u003c/li\u003e\n\u003cli\u003eThe final objective is to exfiltrate sensitive data, deploy malicious workloads, or disrupt services within the Kubernetes environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect sensitive file access within Kubernetes pod exec sessions.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the \u003ccode\u003eEsql.access_type\u003c/code\u003e field to prioritize incidents.\u003c/li\u003e\n\u003cli\u003eReview and tighten RBAC permissions for pod exec to limit access to authorized users and service accounts.\u003c/li\u003e\n\u003cli\u003eImplement admission controls to prevent pods from running in privileged mode or using hostPath mounts unless absolutely necessary.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious \u003ccode\u003ekubectl exec\u003c/code\u003e activity, including unusual command lines or access patterns.\u003c/li\u003e\n\u003cli\u003eRegularly rotate Kubernetes service account tokens and other sensitive credentials to minimize the impact of potential breaches.\u003c/li\u003e\n\u003cli\u003eUse the provided Kubernetes audit log query to proactively search for historical instances of sensitive file access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T21:42:34Z","date_published":"2026-05-04T21:42:34Z","id":"/briefs/2024-01-kubernetes-pod-exec-sensitive-file-access/","summary":"This rule detects Kubernetes pod exec sessions where the decoded command line references sensitive files or paths such as mounted service account tokens, kubelet and control-plane configuration, host identity stores, private keys, and process environment dumps, aiming to identify potential lateral movement, privilege escalation, or credential theft.","title":"Kubernetes Pod Exec Sensitive File or Credential Path Access","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-pod-exec-sensitive-file-access/"},{"_cs_actors":[],"_cs_cves":[{"cvss":6.5,"id":"CVE-2025-62157"}],"_cs_exploited":false,"_cs_products":["argo-workflows"],"_cs_severities":["high"],"_cs_tags":["argo-workflows","credential-access","kubernetes"],"_cs_type":"advisory","_cs_vendors":["Argoproj","Google","Microsoft"],"content_html":"\u003cp\u003eArgo Workflows, a Kubernetes-native workflow engine, is vulnerable to credential exposure. Specifically, versions 4.0.0 through 4.0.4 inadvertently log artifact repository credentials in plaintext during artifact operations. This includes sensitive data like S3 Access Keys, Secret Keys, Session Tokens, Server-Side Customer Keys, OSS Access Keys, Secret Keys, Security Tokens, and GCS Service Account Keys. The vulnerability stems from the logging driver passing the entire ArtifactDriver struct to the structured logger. Any user with read access to workflow pod logs can extract these credentials, creating a significant security risk. This is an incomplete fix of CVE-2025-62157.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn 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.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a workflow that utilizes artifact storage, such as S3 or GCS.\u003c/li\u003e\n\u003cli\u003eThe workflow executes an artifact operation (upload or download).\u003c/li\u003e\n\u003cli\u003eArgo Workflows logs the entire ArtifactDriver struct, including the plaintext credentials, into the pod logs.\u003c/li\u003e\n\u003cli\u003eThe attacker queries the pod logs using \u003ccode\u003ekubectl\u003c/code\u003e or other Kubernetes tooling. For example: \u003ccode\u003ekubectl -n argo logs \u0026quot;cred-leak-test\u0026quot; -c wait\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the plaintext credentials (e.g., S3 Access Key and Secret Key) from the log output.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the extracted credentials to access the artifact repository (e.g., S3 bucket) and potentially steal data or perform other unauthorized actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Argo Workflows to version 4.0.5 or later to remediate the vulnerability (CVE-2026-42295).\u003c/li\u003e\n\u003cli\u003eReview and restrict Kubernetes RBAC permissions to limit access to pod logs, following the principle of least privilege.\u003c/li\u003e\n\u003cli\u003eImplement log monitoring and alerting for unusual access patterns to Kubernetes pod logs.\u003c/li\u003e\n\u003cli\u003eRotate 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T20:12:01Z","date_published":"2026-05-04T20:12:01Z","id":"/briefs/2024-01-09-argo-cred-leak/","summary":"Argo Workflows versions 4.0.0 to 4.0.4 log artifact repository credentials in plaintext, allowing users with read access to pod logs to extract sensitive information such as S3 access keys and GCS service account keys.","title":"Argo Workflows Credentials Exposed in Pod Logs","url":"https://feed.craftedsignal.io/briefs/2024-01-09-argo-cred-leak/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["credential-access","wpad-spoofing","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eWeb Proxy Auto-Discovery (WPAD) is a protocol that allows devices to automatically discover proxy settings, but it can be exploited by attackers to redirect traffic through malicious proxies. This detection identifies the creation of a \u0026ldquo;wpad\u0026rdquo; DNS record, which is a common technique used in WPAD spoofing attacks. Attackers can disable the Global Query Block List (GQBL) and create a rogue \u0026ldquo;wpad\u0026rdquo; record. The event code 5137 is logged when directory service changes are made, and this rule focuses on changes related to the creation of wpad records. This is important for defenders because successful WPAD spoofing can lead to credential access and lateral movement within the network.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a system with sufficient privileges to modify DNS records, often an Active Directory account.\u003c/li\u003e\n\u003cli\u003eThe attacker disables the Global Query Block List (GQBL) to allow the creation of unauthorized DNS records.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new DNS record for \u0026ldquo;wpad\u0026rdquo; in Active Directory DNS, using event code 5137.\u003c/li\u003e\n\u003cli\u003eThe \u0026lsquo;ObjectDN\u0026rsquo; attribute of the DNS record contains \u0026ldquo;DC=wpad,*\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eClients on the network query the DNS server for the \u0026ldquo;wpad\u0026rdquo; record.\u003c/li\u003e\n\u003cli\u003eThe DNS server responds with the attacker-controlled IP address.\u003c/li\u003e\n\u003cli\u003eClients automatically configure their proxy settings to use the attacker\u0026rsquo;s proxy server.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts network traffic, potentially capturing credentials and sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential WPAD Spoofing via DNS Record Creation\u0026rdquo; to your SIEM to detect suspicious \u0026ldquo;wpad\u0026rdquo; record creations.\u003c/li\u003e\n\u003cli\u003eReview 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.\u003c/li\u003e\n\u003cli\u003eRegularly 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-06-wpad-spoofing/","summary":"Detection of a Windows DNS record creation event (5137) with an ObjectDN attribute containing 'DC=wpad', which indicates a potential WPAD spoofing attack to enable privilege escalation and lateral movement.","title":"Potential WPAD Spoofing via DNS Record Creation","url":"https://feed.craftedsignal.io/briefs/2024-06-wpad-spoofing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["credential-access","threat-detection","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies potential NTLM relay attacks targeting Windows computer accounts. The rule focuses on authentication events where a computer account (identified by a name ending in \u0026lsquo;$\u0026rsquo;) is used for network logon from an IP address that does not match the IP address of the host owning the account. Such activity can indicate that an attacker has captured the computer account\u0026rsquo;s NTLM hash through forced authentication techniques and is relaying it from a different machine to gain unauthorized access to resources. The rule is designed to detect activity within the last 9 months and relies on Windows Security Event Logs for analysis.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to the network through various means (e.g., phishing, exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a forced authentication attack (T1187) to coerce a target machine to authenticate to a system under the attacker\u0026rsquo;s control.\u003c/li\u003e\n\u003cli\u003eThe attacker captures the NTLM hash of a computer account, which is automatically generated for every machine joined to the domain.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the captured NTLM hash to relay authentication requests to other systems on the network. This leverages the \u0026ldquo;Adversary-in-the-Middle\u0026rdquo; technique (T1557), specifically \u0026ldquo;LLMNR/NBT-NS Poisoning and SMB Relay\u0026rdquo; (T1557.001).\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to resources or performs actions on behalf of the compromised computer account.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt lateral movement, privilege escalation, or data exfiltration depending on the targeted resource.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Logon in Windows to generate the necessary security events for this rule to function, as described in the provided setup instructions.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule below to your SIEM to detect potential computer account relay activity and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by comparing the source.ip to the target server host.ip addresses to confirm it\u0026rsquo;s indeed a remote use of the machine account.\u003c/li\u003e\n\u003cli\u003eStrengthen network segmentation to limit the attack surface for credential relay attacks, as recommended in the remediation steps.\u003c/li\u003e\n\u003cli\u003eMonitor for anomalous authentication patterns and NTLM-related activity to identify and respond to potential relay attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-07-computer-account-relay/","summary":"Detection of potential NTLM relay attacks targeting computer accounts by identifying authentication events originating from hosts other than the account's owner, indicating possible credential theft and misuse.","title":"Potential Computer Account NTLM Relay Activity","url":"https://feed.craftedsignal.io/briefs/2024-07-computer-account-relay/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["medium"],"_cs_tags":["credential-access","persistence","active-directory","dcsync"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies modifications to the \u003ccode\u003enTSecurityDescriptor\u003c/code\u003e attribute within Active Directory (AD) objects that grant DCSync-related permissions to a user or computer account. This technique allows attackers to create a persistent backdoor, enabling them to re-obtain access to user and computer account hashes. The modification involves assigning specific GUIDs that represent replication rights (\u003ccode\u003e1131f6ad-9c07-11d1-f79f-00c04fc2dcd2\u003c/code\u003e, \u003ccode\u003e1131f6aa-9c07-11d1-f79f-00c04fc2dcd2\u003c/code\u003e, \u003ccode\u003e89e95b76-444d-4c62-991a-0facbeda640c\u003c/code\u003e) to an account\u0026rsquo;s security descriptor. This allows the attacker to then use DCSync to retrieve credentials from the domain, effectively bypassing normal authentication mechanisms.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an account with sufficient privileges to modify Active Directory objects (e.g., Domain Admin).\u003c/li\u003e\n\u003cli\u003eThe attacker uses AD management tools (PowerShell, ADSI Edit, etc.) to target a specific user or computer account.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003enTSecurityDescriptor\u003c/code\u003e attribute of the targeted account.\u003c/li\u003e\n\u003cli\u003eThe attacker grants replication rights to the targeted account by adding specific Access Control Entries (ACEs) containing the GUIDs \u003ccode\u003e1131f6ad-9c07-11d1-f79f-00c04fc2dcd2\u003c/code\u003e, \u003ccode\u003e1131f6aa-9c07-11d1-f79f-00c04fc2dcd2\u003c/code\u003e, and \u003ccode\u003e89e95b76-444d-4c62-991a-0facbeda640c\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the DCSync technique, impersonating a domain controller, to request password hashes.\u003c/li\u003e\n\u003cli\u003eThe Active Directory server, believing the request is legitimate due to the granted replication rights, provides the attacker with the requested credential information.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains password hashes for domain users and computers.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the obtained credentials for lateral movement, privilege escalation, or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Directory Service Changes to generate the necessary event logs for detection (\u003ca href=\"https://ela.st/audit-directory-service-changes)\"\u003ehttps://ela.st/audit-directory-service-changes)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to detect unauthorized modifications to the \u003ccode\u003enTSecurityDescriptor\u003c/code\u003e attribute. Tune the rule to exclude legitimate administrative accounts or scripts that may perform authorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Windows Security Event Logs (event code 5136) for changes to the \u003ccode\u003enTSecurityDescriptor\u003c/code\u003e attribute and investigate any unexpected modifications, focusing on the presence of DCSync-related GUIDs.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Active Directory permissions, focusing on accounts with replication rights, to ensure they are legitimate and necessary.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2026-05-dcsync-backdoor/","summary":"Attackers can modify Active Directory object security descriptors to grant DCSync rights to unauthorized accounts, creating a backdoor to extract credential data.","title":"Potential Active Directory Replication Account Backdoor","url":"https://feed.craftedsignal.io/briefs/2026-05-dcsync-backdoor/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Security"],"_cs_severities":["medium"],"_cs_tags":["account-takeover","credential-access","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies potential account takeover activity by analyzing Windows Security Event Logs for unusual login patterns. Specifically, it looks for user accounts that typically log in with high frequency from a single source IP address but then exhibit successful logins from a different source IP address with significantly lower frequency. This pattern may indicate that an attacker has compromised the account credentials and is accessing the network from a new, potentially malicious, location. This activity is detected by analyzing Windows Security Event ID 4624 events related to successful logins. The rule is designed to trigger when a user account logs in from a new IP address after establishing a pattern of high-volume logins from a primary IP address.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains access to valid user credentials through methods such as phishing, credential stuffing, or malware. (T1078)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccessful Logon:\u003c/strong\u003e 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).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Possible):\u003c/strong\u003e Once authenticated, the attacker may attempt to move laterally within the network to access additional resources or systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Possible):\u003c/strong\u003e The attacker may attempt to escalate their privileges to gain administrative access to the system or domain (TA0004).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration (Possible):\u003c/strong\u003e The attacker may attempt to exfiltrate sensitive data from the compromised system or network.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence (Possible):\u003c/strong\u003e The attacker may attempt to establish persistence mechanisms to maintain access to the system or network over time.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to your SIEM and tune for your environment, paying close attention to the \u003ccode\u003emax_logon\u003c/code\u003e threshold.\u003c/li\u003e\n\u003cli\u003eEnable Audit Logon within Windows to ensure the events needed for detection are available as mentioned in the setup instructions.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by confirming with the account owner if they logged in from the new source IP.\u003c/li\u003e\n\u003cli\u003eCheck the new source IP for reputation, geography, and whether it is expected as described in the rule\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eCorrelate 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-01-account-takeover-new-source-ip/","summary":"The rule identifies a user account that normally logs in with high volume from one source IP suddenly logging in from a different source IP, potentially indicating account takeover or use of stolen credentials from a new location.","title":"Potential Account Takeover - Logon from New Source IP","url":"https://feed.craftedsignal.io/briefs/2024-01-account-takeover-new-source-ip/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Endpoint Security"],"_cs_severities":["high"],"_cs_tags":["genai","credential-access","persistence","collection"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eAttackers are increasingly leveraging GenAI agents to automate the discovery and exfiltration of sensitive information, including credentials, API keys, and tokens stored within files on compromised systems. The observed activity involves GenAI tools accessing critical files such as cloud credentials, SSH keys, browser password databases, and shell configuration files. Successful exploitation allows attackers to harvest credentials, gain unauthorized access to systems, and establish persistence mechanisms for continued access. The GenAI tools mentioned include ollama, textgen, lmstudio, claude, cursor, copilot, codex, jan, gpt4all, gemini-cli, genaiscript, grok, qwen, koboldcpp, llama-server, windsurf, zed, opencode, and goose. This activity highlights the emerging threat landscape of AI-assisted attacks and the need for robust detection and mitigation strategies.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of a system through an unrelated vulnerability or social engineering.\u003c/li\u003e\n\u003cli\u003eInstallation or execution of a GenAI tool (e.g., ollama, lmstudio) on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool is configured or instructed to scan the file system for sensitive files.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool accesses files containing credentials, such as \u003ccode\u003e.aws/credentials\u003c/code\u003e, browser password databases (\u003ccode\u003eLogin Data\u003c/code\u003e, \u003ccode\u003ekey3.db\u003c/code\u003e), or SSH keys (\u003ccode\u003e.ssh/id_*\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe GenAI tool exfiltrates the harvested credentials and API keys to a remote server controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to cloud resources, internal systems, or other sensitive accounts.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool attempts to modify shell configuration files (e.g., \u003ccode\u003e.bashrc\u003c/code\u003e, \u003ccode\u003e.zshrc\u003c/code\u003e) to establish persistence.\u003c/li\u003e\n\u003cli\u003eUpon system restart or user login, the modified shell configuration executes malicious commands, granting the attacker persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;GenAI Process Accessing Sensitive Files\u0026rdquo; to your SIEM to detect GenAI tools accessing sensitive files on endpoints.\u003c/li\u003e\n\u003cli\u003eEnable file access monitoring on systems where GenAI tools are used to capture access events for analysis.\u003c/li\u003e\n\u003cli\u003eReview and restrict the use of GenAI tools within the environment, especially concerning access to sensitive file paths.\u003c/li\u003e\n\u003cli\u003eMonitor for modifications to shell configuration files (e.g., \u003ccode\u003e.bashrc\u003c/code\u003e, \u003ccode\u003e.zshrc\u003c/code\u003e, \u003ccode\u003e.profile\u003c/code\u003e) as an indicator of persistence attempts.\u003c/li\u003e\n\u003cli\u003eImplement regular credential rotation policies to minimize the impact of stolen credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T22:46:51Z","date_published":"2026-05-01T22:46:51Z","id":"/briefs/2024-12-15-genai-sensitive-file-access/","summary":"This threat brief details the detection of GenAI tools accessing sensitive files containing credentials, SSH keys, browser data, and shell configurations, indicating potential credential harvesting and persistence attempts by attackers leveraging GenAI agents.","title":"GenAI Tools Accessing Sensitive Files for Credential Access and Persistence","url":"https://feed.craftedsignal.io/briefs/2024-12-15-genai-sensitive-file-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["high"],"_cs_tags":["credential-access","kerberos","spn-spoofing","dns","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","CrowdStrike","SentinelOne"],"content_html":"\u003cp\u003eThis detection identifies a specific pattern in DNS queries indicative of Kerberos SPN spoofing, a technique used to coerce systems into authenticating to attacker-controlled hosts. The pattern \u0026ldquo;UWhRCA\u0026hellip;BAAAA\u0026rdquo; represents a marshaled CREDENTIAL_TARGET_INFORMATION structure. Attackers exploit this by crafting malicious DNS names to trick victim systems into requesting Kerberos tickets for legitimate services, often their own identity, but directed towards an attacker-controlled endpoint. This can lead to Kerberos relay or NTLM reflection/relay attacks, bypassing normal NTLM fallback mechanisms. The technique is associated with tools like RemoteKrbRelay and wspcoerce. This activity has been observed in various attacks targeting Windows environments where Kerberos authentication is prevalent. Defenders need to detect and mitigate this early stage of credential access.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a target Windows system within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker sets up a malicious server to receive coerced authentication requests.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious DNS query containing a base64-encoded blob \u0026ldquo;UWhRCA\u0026hellip;BAAAA\u0026rdquo; representing a marshaled CREDENTIAL_TARGET_INFORMATION structure.\u003c/li\u003e\n\u003cli\u003eThe victim system, triggered by an external factor (e.g., RPC call, scheduled task, or web request), attempts to resolve the crafted DNS name.\u003c/li\u003e\n\u003cli\u003eThe malicious DNS query is sent to the DNS server, which resolves to the attacker\u0026rsquo;s server.\u003c/li\u003e\n\u003cli\u003eThe victim system initiates a Kerberos authentication request to the attacker\u0026rsquo;s server, believing it to be a legitimate service.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s server relays the Kerberos ticket or uses NTLM reflection/relay techniques to gain unauthorized access.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises the victim system or pivots to other systems within the network using the stolen credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Potential Kerberos SPN Spoofing via Suspicious DNS Query\u0026rdquo; rule to your SIEM and tune for your environment to detect malicious DNS queries.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon Event ID 22 - DNS Query logging to provide the necessary data for detection.\u003c/li\u003e\n\u003cli\u003eInvestigate and block any DNS queries resolving to external IPs that contain the \u0026ldquo;UWhRCA\u0026hellip;BAAAA\u0026rdquo; pattern.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for processes initiating DNS queries containing the suspicious pattern, specifically looking for known coercion tools.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the impact of lateral movement if a system is compromised.\u003c/li\u003e\n\u003cli\u003eReview and harden Kerberos configurations to prevent SPN spoofing and relay attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T17:31:25Z","date_published":"2026-05-01T17:31:25Z","id":"/briefs/2024-10-kerberos-spn-spoofing-dns/","summary":"Detects suspicious DNS queries containing a base64-encoded blob, indicating potential Kerberos coercion attacks and SPN spoofing via DNS to coerce authentication to attacker-controlled hosts, enabling Kerberos or NTLM relay attacks.","title":"Potential Kerberos SPN Spoofing via Suspicious DNS Query","url":"https://feed.craftedsignal.io/briefs/2024-10-kerberos-spn-spoofing-dns/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.8,"id":"CVE-2026-6389"}],"_cs_exploited":false,"_cs_products":["Turbonomic Application Resource Management","Turbonomic prometurbo agent (8.16.0 through 8.17.6)"],"_cs_severities":["critical"],"_cs_tags":["privilege-escalation","credential-access","kubernetes","vulnerability"],"_cs_type":"advisory","_cs_vendors":["IBM"],"content_html":"\u003cp\u003eCVE-2026-6389 affects IBM Turbonomic prometurbo agent versions 8.16.0 through 8.17.6. The vulnerability stems from the agent granting excessive cluster-wide permissions within IBM Turbonomic Application Resource Management. A successful exploit allows an attacker who has compromised the operator or its associated service account to gain unrestricted read access to all secrets within the cluster. This vulnerability was reported on April 30, 2026, and poses a significant risk to organizations using the affected versions, potentially leading to complete cluster compromise. Defenders should prioritize patching and monitoring for unauthorized access to sensitive resources.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker 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.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the IBM Turbonomic prometurbo agent and its associated service account within the compromised cluster.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eUsing 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.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the cluster, compromising additional nodes and workloads to expand their control and access to sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves full cluster compromise, gaining complete control over all resources and data within the Kubernetes environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade IBM Turbonomic prometurbo agent to a version beyond 8.17.6 to patch CVE-2026-6389.\u003c/li\u003e\n\u003cli\u003eReview and restrict the permissions granted to the prometurbo agent service account, adhering to the principle of least privilege (reference: CVE-2026-6389).\u003c/li\u003e\n\u003cli\u003eImplement Kubernetes audit logging to monitor for unauthorized access to secrets and other sensitive resources (reference: Kubernetes documentation).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Kubernetes Secret Access via Turbonomic Agent\u0026rdquo; to identify potential exploitation attempts (reference: Sigma rule below).\u003c/li\u003e\n\u003cli\u003eMonitor 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).\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the potential impact of a compromised cluster, preventing lateral movement to other environments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-30T22:16:26Z","date_published":"2026-04-30T22:16:26Z","id":"/briefs/2026-04-turbonomic-privesc/","summary":"IBM Turbonomic prometurbo agent versions 8.16.0 through 8.17.6 grants excessive cluster-wide permissions, including unrestricted read access to all secrets, allowing a compromised operator or service account to exfiltrate credentials, escalate privileges, and achieve full cluster compromise.","title":"IBM Turbonomic prometurbo Agent Privilege Escalation via Excessive Permissions (CVE-2026-6389)","url":"https://feed.craftedsignal.io/briefs/2026-04-turbonomic-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Cilium"],"_cs_severities":["high"],"_cs_tags":["cilium","wireguard","key-disclosure","credential-access"],"_cs_type":"advisory","_cs_vendors":["Cilium","Isovalent"],"content_html":"\u003cp\u003eA vulnerability exists in the \u003ccode\u003ecilium-bugtool\u003c/code\u003e utility within Cilium, an open-source networking and security platform for cloud-native environments. When used with WireGuard Transparent Encryption enabled, the tool can inadvertently include the WireGuard private key (\u003ccode\u003ecilium_wg0.key\u003c/code\u003e) in its output. This affects Cilium versions v1.19 between v1.19.0 and v1.19.2, v1.18 between v1.18.0 and v1.18.8, and all versions prior to v1.17.15. The exposure occurs because the tool, used for debugging and generating system dumps, collects sensitive configuration files. The vulnerability was reported and addressed by the Cilium community, with patches released in versions v1.19.3, v1.18.9, and v1.17.15. Failure to patch could lead to unauthorized decryption of network traffic.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains access to a system running a vulnerable Cilium version with WireGuard enabled, or obtains a \u003ccode\u003ecilium-bugtool\u003c/code\u003e archive.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ecilium-bugtool\u003c/code\u003e or \u003ccode\u003ecilium sysdump\u003c/code\u003e command is executed, either manually by a user or an automated process (initiated by the attacker if they have access).\u003c/li\u003e\n\u003cli\u003eThe tool collects various debugging information, including the \u003ccode\u003ecilium_wg0.key\u003c/code\u003e file containing the WireGuard private key.\u003c/li\u003e\n\u003cli\u003eThe resulting archive is stored locally, potentially accessible to the attacker.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the \u003ccode\u003ecilium-bugtool\u003c/code\u003e archive containing the WireGuard private key.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the extracted private key to decrypt WireGuard-encrypted traffic between Cilium nodes.\u003c/li\u003e\n\u003cli\u003eThe attacker monitors and intercepts sensitive network communications.\u003c/li\u003e\n\u003cli\u003eAttacker pivots within the cluster using the decrypted traffic to discover additional services or escalate privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Cilium to versions v1.19.3, v1.18.9, or v1.17.15 or later to remediate CVE-2026-41520.\u003c/li\u003e\n\u003cli\u003eRotate WireGuard keys on affected nodes if \u003ccode\u003ecilium-bugtool\u003c/code\u003e archives have been shared externally, as suggested in the advisory. Delete the \u003ccode\u003ecilium_wg0.key\u003c/code\u003e file and restart the Cilium agent.\u003c/li\u003e\n\u003cli\u003eImplement strict access control policies to limit who can execute \u003ccode\u003ecilium-bugtool\u003c/code\u003e or \u003ccode\u003ecilium sysdump\u003c/code\u003e commands, preventing unauthorized key disclosure.\u003c/li\u003e\n\u003cli\u003eMonitor for unusual execution of \u003ccode\u003ecilium-bugtool\u003c/code\u003e or \u003ccode\u003ecilium sysdump\u003c/code\u003e using process monitoring tools. Deploy a Sigma rule that detects unexpected execution paths.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-26T12:00:00Z","date_published":"2026-04-26T12:00:00Z","id":"/briefs/2026-04-cilium-wg-key-disclosure/","summary":"The `cilium-bugtool` debugging tool in Cilium exposes WireGuard private keys, potentially allowing unauthorized access to encrypted node-to-node communication in affected versions.","title":"Cilium `cilium-bugtool` WireGuard Private Key Exposure","url":"https://feed.craftedsignal.io/briefs/2026-04-cilium-wg-key-disclosure/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-6947"}],"_cs_exploited":false,"_cs_products":["DWM-222W USB Wi-Fi Adapter"],"_cs_severities":["high"],"_cs_tags":["brute-force","credential-access","network-device"],"_cs_type":"advisory","_cs_vendors":["D-Link"],"content_html":"\u003cp\u003eThe D-Link DWM-222W USB Wi-Fi Adapter is susceptible to a brute-force protection bypass vulnerability (CVE-2026-6947). This flaw allows an attacker on an adjacent network to circumvent the built-in login attempt limits. By repeatedly attempting different credentials without being blocked, an attacker can successfully brute-force the password and gain unauthorized access to the device. This vulnerability poses a significant risk as it enables attackers to potentially reconfigure the device, intercept network traffic, or use the compromised device as a pivot point for further attacks within the network. Successful exploitation leads to full control over the D-Link Wi-Fi adapter.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker locates a vulnerable D-Link DWM-222W USB Wi-Fi Adapter within adjacent network range.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates network communication with the device, targeting its login interface, likely via HTTP or HTTPS.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a series of login requests with different username and password combinations.\u003c/li\u003e\n\u003cli\u003eDue to the brute-force protection bypass, the device does not enforce login attempt limits or implement account lockout mechanisms.\u003c/li\u003e\n\u003cli\u003eThe attacker continues sending login requests until the correct credentials are found.\u003c/li\u003e\n\u003cli\u003eUpon successful authentication, the attacker gains administrative access to the D-Link DWM-222W USB Wi-Fi Adapter\u0026rsquo;s configuration interface.\u003c/li\u003e\n\u003cli\u003eThe attacker reconfigures the device to their specifications potentially enabling remote access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor 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 \u003ccode\u003eDetect Excessive Authentication Attempts\u003c/code\u003e to identify such activity.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the impact of a compromised D-Link DWM-222W USB Wi-Fi Adapter.\u003c/li\u003e\n\u003cli\u003eIf possible, disable remote management interfaces on the D-Link DWM-222W USB Wi-Fi Adapter to reduce the attack surface.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-24T04:16:23Z","date_published":"2026-04-24T04:16:23Z","id":"/briefs/2026-04-dlink-brute-force-bypass/","summary":"D-Link DWM-222W USB Wi-Fi Adapter is vulnerable to brute-force attacks due to a protection bypass, allowing unauthenticated adjacent network attackers to gain control over the device by circumventing login attempt limits.","title":"D-Link DWM-222W USB Wi-Fi Adapter Brute-Force Protection Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-04-dlink-brute-force-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","genai","file-access","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers are increasingly exploiting GenAI tools to automate the discovery and exfiltration of sensitive information from compromised systems. This involves using GenAI agents to systematically scan file systems for credentials, API keys, tokens, and other secrets. Access to credential stores (.aws/credentials, .ssh/id_*) indicates credential harvesting, while modifications to shell configuration files (.bashrc, .zshrc) point to persistence attempts.  The observed activity leverages legitimate GenAI tool functionality, making it difficult to distinguish between benign use and malicious intent.  This technique has become more prevalent since late 2025, with attackers refining methods to instruct GenAI agents to specifically target and exfiltrate sensitive files. Defenders must monitor for unusual file access patterns by GenAI processes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a system via phishing or exploiting a software vulnerability.\u003c/li\u003e\n\u003cli\u003eAttacker installs or deploys a GenAI tool (e.g., LM Studio, Claude, Copilot) on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the GenAI tool to scan the file system for specific file names and patterns associated with sensitive data (credentials, keys, cookies).\u003c/li\u003e\n\u003cli\u003eThe GenAI tool accesses files such as \u003ccode\u003e.aws/credentials\u003c/code\u003e, \u003ccode\u003e.ssh/id_rsa\u003c/code\u003e, browser login databases (e.g., \u003ccode\u003eLogin Data\u003c/code\u003e, \u003ccode\u003elogins.json\u003c/code\u003e, \u003ccode\u003eCookies\u003c/code\u003e), and other credential stores.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool may modify shell configuration files (\u003ccode\u003e.bashrc\u003c/code\u003e, \u003ccode\u003e.zshrc\u003c/code\u003e) to establish persistence.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool stages the collected data for exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the harvested credentials and data to an external server.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to other systems or cloud resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGenAI Process Accessing Sensitive Files\u003c/code\u003e to your SIEM to detect GenAI tools accessing sensitive files. Tune for your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eMonitor file access events, specifically looking for GenAI processes (ollama, lmstudio, claude) accessing files with names like \u003ccode\u003ecredentials\u003c/code\u003e, \u003ccode\u003eid_rsa\u003c/code\u003e, \u003ccode\u003elogins.json\u003c/code\u003e, and \u003ccode\u003e.bashrc\u003c/code\u003e, as outlined in the Sigma rule.\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls and monitoring for sensitive directories like \u003ccode\u003e.aws\u003c/code\u003e, \u003ccode\u003e.ssh\u003c/code\u003e, and browser profile directories.\u003c/li\u003e\n\u003cli\u003eRegularly audit and rotate credentials, API keys, and tokens, especially those stored in files.\u003c/li\u003e\n\u003cli\u003eEducate developers and users about the risks of using GenAI tools to handle sensitive data.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T16:34:10Z","date_published":"2026-04-22T16:34:10Z","id":"/briefs/2024-01-genai-sensitive-file-access/","summary":"This brief outlines the threat of attackers leveraging GenAI tools to access sensitive files containing credentials, SSH keys, browser data, and shell configurations for credential access and persistence.","title":"GenAI Tool Access to Sensitive Files for Credential Harvesting and Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-genai-sensitive-file-access/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.7,"id":"CVE-2026-40161"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["tekton","git","credential-access","api-token"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability exists in Tekton Pipelines\u0026rsquo; git resolver (versions v1.0.0 through v1.10.0) where the system-configured Git API token is sent to a user-controlled \u003ccode\u003eserverURL\u003c/code\u003e when the user omits the \u003ccode\u003etoken\u003c/code\u003e parameter. This allows a malicious tenant with TaskRun or PipelineRun create permissions to exfiltrate the shared API token (GitHub PAT, GitLab token, etc.) by pointing \u003ccode\u003eserverURL\u003c/code\u003e to an attacker-controlled endpoint. The attacker can then use this token to gain unauthorized access to private repositories, potentially exposing source code, secrets, and CI/CD configurations. This vulnerability is similar to GHSA-j5q5-j9gm-2w5c, where credentials could be exfiltrated. The vulnerability resides in the \u003ccode\u003eResolveAPIGit()\u003c/code\u003e function within \u003ccode\u003epkg/resolution/resolver/git/resolver.go\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains permission to create TaskRuns or PipelineRuns within a Tekton Pipelines namespace.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious TaskRun or PipelineRun configuration.\u003c/li\u003e\n\u003cli\u003eThe configuration specifies the git resolver in API mode.\u003c/li\u003e\n\u003cli\u003eThe configuration omits the \u003ccode\u003etoken\u003c/code\u003e parameter but includes a \u003ccode\u003eserverURL\u003c/code\u003e pointing to an attacker-controlled endpoint.\u003c/li\u003e\n\u003cli\u003eTekton Pipelines executes the TaskRun or PipelineRun, triggering the git resolver.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eResolveAPIGit()\u003c/code\u003e function retrieves the system-configured Git API token using \u003ccode\u003egetAPIToken()\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe function creates an SCM client pointed at the attacker-controlled \u003ccode\u003eserverURL\u003c/code\u003e with the system token as an \u003ccode\u003eAuthorization\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eSubsequent API calls from the resolver to the attacker-controlled URL transmit the system token, allowing the attacker to capture it.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDo not configure a system-level API token\u003c/strong\u003e in the git resolver ConfigMap. Instead, require all users to provide their own tokens via the \u003ccode\u003etoken\u003c/code\u003e parameter, as suggested in the advisory\u0026rsquo;s workaround section.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRestrict TaskRun creation\u003c/strong\u003e to limit which users or ServiceAccounts can create TaskRuns and PipelineRuns that use the git resolver, as recommended in the advisory\u0026rsquo;s workaround section.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eApply NetworkPolicy\u003c/strong\u003e to the \u003ccode\u003etekton-pipelines-resolvers\u003c/code\u003e namespace to restrict outbound traffic to known-good Git servers only, mitigating the risk of token exfiltration to arbitrary \u003ccode\u003eserverURL\u003c/code\u003e values.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T12:00:00Z","date_published":"2026-04-22T12:00:00Z","id":"/briefs/2026-04-tekton-api-token-leak/","summary":"The Tekton Pipelines git resolver in API mode leaks the system-configured Git API token to a user-controlled `serverURL` when the user omits the `token` parameter, allowing an attacker with TaskRun or PipelineRun creation permissions to exfiltrate the shared API token.","title":"Tekton Pipelines Git Resolver API Token Leak via User-Controlled ServerURL","url":"https://feed.craftedsignal.io/briefs/2026-04-tekton-api-token-leak/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.7,"id":"CVE-2026-40161"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["tekton","credential-access","cve-2026-40161"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eTekton Pipelines, a Kubernetes-style resource for declaring CI/CD pipelines, contains a vulnerability (CVE-2026-40161) in its git resolver component. Specifically, versions 1.0.0 to 1.10.0 are affected. When operating in API mode, the resolver inadvertently sends the system-configured Git API token (e.g., GitHub PAT, GitLab token) to a server specified by the user if the token parameter is omitted. This allows an attacker with TaskRun or PipelineRun creation privileges to exfiltrate the shared API token by directing the serverURL to an attacker-controlled endpoint. The vulnerability allows for the potential compromise of CI/CD pipelines and related infrastructure.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to a Kubernetes tenant with permissions to create TaskRun or PipelineRun resources within Tekton Pipelines.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious TaskRun or PipelineRun configuration.\u003c/li\u003e\n\u003cli\u003eThe configuration leverages the Tekton Pipelines git resolver in API mode.\u003c/li\u003e\n\u003cli\u003eThe attacker omits the \u003ccode\u003etoken\u003c/code\u003e parameter in the git resolver configuration, forcing the system to use the system-configured Git API token.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the \u003ccode\u003eserverURL\u003c/code\u003e parameter to an attacker-controlled endpoint.\u003c/li\u003e\n\u003cli\u003eTekton Pipelines, upon execution of the TaskRun or PipelineRun, sends the system-configured Git API token to the attacker-controlled \u003ccode\u003eserverURL\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s server logs and captures the leaked Git API token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the exfiltrated token to access and potentially compromise Git repositories or other services authenticated by the token.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s widespread adoption, a successful attack could affect numerous organizations using the vulnerable versions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Tekton Pipelines to a version greater than 1.10.0 to remediate CVE-2026-40161.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls within the Kubernetes cluster to limit TaskRun and PipelineRun creation privileges to authorized users only.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic originating from Tekton Pipeline pods for connections to unusual or untrusted \u003ccode\u003eserverURL\u003c/code\u003e destinations as specified in CVE-2026-40161. Create a network connection rule for this.\u003c/li\u003e\n\u003cli\u003eReview Tekton Pipeline configurations for suspicious \u003ccode\u003eserverURL\u003c/code\u003e parameters using a file monitoring rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T12:00:00Z","date_published":"2026-04-22T12:00:00Z","id":"/briefs/2026-04-tekton-credential-leak/","summary":"Tekton Pipelines versions 1.0.0 to 1.10.0 are vulnerable to credential access, where the Git resolver in API mode transmits the system-configured Git API token to a user-controlled serverURL, enabling token exfiltration via a malicious server.","title":"Tekton Pipelines Git Resolver API Token Leak via ServerURL Manipulation (CVE-2026-40161)","url":"https://feed.craftedsignal.io/briefs/2026-04-tekton-credential-leak/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.1,"id":"CVE-2026-40903"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve-2026-40903","github_token","credential-access","artipacked"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe goshs SimpleHTTPServer, written in Go, is susceptible to an ArtiPACKED vulnerability (CVE-2026-40903) in versions prior to 2.0.0-beta.6. This vulnerability can lead to the unintended leakage of the \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e through workflow artifacts. Even if the token is not directly present in the repository\u0026rsquo;s source code, the ArtiPACKED issue allows for its exposure during workflow execution. This is a significant risk for projects using goshs in their CI/CD pipelines, as a compromised \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e can grant attackers unauthorized access to the repository and its associated resources. Organizations utilizing goshs should upgrade to version 2.0.0-beta.6 or later to mitigate this vulnerability. The vulnerability was reported and patched in April 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA developer introduces a vulnerable version of goshs (prior to 2.0.0-beta.6) into a project\u0026rsquo;s dependencies.\u003c/li\u003e\n\u003cli\u003eThe project utilizes GitHub Actions or a similar CI/CD system.\u003c/li\u003e\n\u003cli\u003eThe CI/CD workflow is configured to use or interact with the \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDue to the ArtiPACKED vulnerability, the \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e becomes exposed within the workflow\u0026rsquo;s generated artifacts.\u003c/li\u003e\n\u003cli\u003eAn attacker gains access to these workflow artifacts, potentially through misconfigured permissions or compromised systems.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the leaked \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e from the artifacts.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e to authenticate to the GitHub repository.\u003c/li\u003e\n\u003cli\u003eWith the compromised token, the attacker can perform actions such as code modification, secret retrieval, or infrastructure changes depending on the token\u0026rsquo;s permissions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-40903 can lead to the leakage of sensitive \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade goshs to version 2.0.0-beta.6 or later to remediate the ArtiPACKED vulnerability as detailed in CVE-2026-40903.\u003c/li\u003e\n\u003cli\u003eReview and restrict the permissions granted to the \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e in GitHub Actions workflows to minimize potential impact if the token is compromised.\u003c/li\u003e\n\u003cli\u003eImplement artifact scanning tools to detect potential secrets leakage in CI/CD workflow artifacts.\u003c/li\u003e\n\u003cli\u003eMonitor GitHub audit logs for suspicious activity originating from the \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e, particularly after the introduction or update of goshs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T12:00:00Z","date_published":"2026-04-22T12:00:00Z","id":"/briefs/2026-04-goshs-github-token-leakage/","summary":"The goshs SimpleHTTPServer prior to version 2.0.0-beta.6 is vulnerable to ArtiPACKED, potentially leading to leakage of the GITHUB_TOKEN through workflow artifacts.","title":"goshs GitHub Token Leakage via ArtiPACKED Vulnerability (CVE-2026-40903)","url":"https://feed.craftedsignal.io/briefs/2026-04-goshs-github-token-leakage/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-20128"}],"_cs_exploited":false,"_cs_products":["Catalyst SD-WAN Manager"],"_cs_severities":["medium"],"_cs_tags":["cve-2026-20128","credential-access","sd-wan","cisco"],"_cs_type":"advisory","_cs_vendors":["Cisco"],"content_html":"\u003cp\u003eCisco Catalyst SD-WAN Manager is affected by a vulnerability (CVE-2026-20128) that allows for the disclosure of stored passwords. An authenticated, local attacker with low privileges can exploit this vulnerability by accessing a credential file on the filesystem. Successful exploitation grants the attacker DCA user privileges, potentially leading to unauthorized access and control over the SD-WAN environment. CISA has issued Emergency Directive 26-03 and associated guidance to mitigate risks associated with Cisco SD-WAN devices. This vulnerability highlights the importance of proper credential management and access controls in network management systems.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains low-privileged access to the Cisco Catalyst SD-WAN Manager system through legitimate credentials or other vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates the filesystem to locate the DCA user\u0026rsquo;s credential file.\u003c/li\u003e\n\u003cli\u003eThe attacker reads the credential file, which contains the DCA user\u0026rsquo;s password in a recoverable format.\u003c/li\u003e\n\u003cli\u003eThe attacker decodes or decrypts the password using readily available tools or techniques.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the recovered DCA user credentials to authenticate to the SD-WAN Manager with elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the DCA user privileges to perform unauthorized configuration changes or access sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker potentially pivots to other systems or network segments accessible through the SD-WAN infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eReview and apply the mitigations outlined in CISA\u0026rsquo;s Emergency Directive 26-03 and associated guidance for Cisco SD-WAN devices, as referenced in the overview.\u003c/li\u003e\n\u003cli\u003eMonitor file access events on the Cisco Catalyst SD-WAN Manager system for suspicious access patterns to credential files using the \u003ccode\u003eDetect Suspicious SD-WAN Credential File Access\u003c/code\u003e Sigma rule.\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls and password policies on the Cisco Catalyst SD-WAN Manager to prevent unauthorized access.\u003c/li\u003e\n\u003cli\u003eApply the security updates provided by Cisco to patch CVE-2026-20128 as they become available.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-21T12:00:00Z","date_published":"2026-04-21T12:00:00Z","id":"/briefs/2026-04-cisco-sdwan-password-disclosure/","summary":"Cisco Catalyst SD-WAN Manager stores passwords in a recoverable format, allowing an authenticated local attacker to gain DCA user privileges by accessing a credential file.","title":"Cisco Catalyst SD-WAN Manager Password Disclosure Vulnerability (CVE-2026-20128)","url":"https://feed.craftedsignal.io/briefs/2026-04-cisco-sdwan-password-disclosure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["dell","powerprotect","datadomain","vulnerability","privilege-escalation","defense-evasion","credential-access","impact"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eMultiple vulnerabilities exist within Dell PowerProtect Data Domain OS, potentially enabling a malicious actor to compromise systems. Successful exploitation could lead to arbitrary code execution with root privileges, privilege escalation to administrator level, circumvention of security mechanisms, data manipulation, sensitive information disclosure, and the execution of other unspecified malicious activities. The vulnerabilities could be exploited to gain complete control over the affected systems, leading to significant data loss, disruption of services, or other severe consequences. The full scope of affected versions and the specific vulnerabilities involved are not detailed in the source information.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003cp\u003eGiven the broad nature of the advisory, the following attack chain is constructed based on the potential capabilities granted by exploiting the vulnerabilities:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker exploits a remote code execution vulnerability in Dell PowerProtect Data Domain OS, potentially through a network service or web interface.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker leverages an additional vulnerability to escalate privileges from an initial low-privilege shell to root access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e With root privileges, the attacker disables or bypasses security measures, such as intrusion detection systems or anti-malware software.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e The attacker gains access to stored credentials, such as those used for backups or system administration, by dumping the system\u0026rsquo;s credential store.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Manipulation:\u003c/strong\u003e The attacker modifies data stored within the Dell PowerProtect Data Domain system, potentially corrupting backups or injecting malicious code into stored files.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInformation Disclosure:\u003c/strong\u003e The attacker extracts sensitive information, such as customer data, internal documents, or system configurations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their final objective, which may include data exfiltration, system disruption, or ransomware deployment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eInvestigate Dell\u0026rsquo;s security advisories and apply the necessary patches to address the vulnerabilities in PowerProtect Data Domain OS as soon as they become available.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the potential impact of a compromised Data Domain OS on other systems.\u003c/li\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eMonitor for unauthorized access attempts to Dell PowerProtect Data Domain OS through webserver logs, specifically looking for suspicious cs-uri-query strings (see rule \u0026ldquo;Detect Web Request for Potential Dell PowerProtect Exploit\u0026rdquo;).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-21T08:05:52Z","date_published":"2026-04-21T08:05:52Z","id":"/briefs/2026-04-dell-powerprotect-vulns/","summary":"Multiple vulnerabilities in Dell PowerProtect Data Domain OS allow an attacker to execute arbitrary code with root privileges, escalate privileges to administrator, bypass security measures, manipulate data, disclose sensitive information, or conduct unspecified attacks.","title":"Multiple Vulnerabilities in Dell PowerProtect Data Domain OS","url":"https://feed.craftedsignal.io/briefs/2026-04-dell-powerprotect-vulns/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["intel","firmware","vulnerability","privilege-escalation","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eMultiple vulnerabilities exist within Intel IPU and UEFI reference firmware that could be exploited by a local attacker. The specific versions affected and the exact nature of the vulnerabilities are not detailed in this advisory. However, successful exploitation could lead to the disclosure of sensitive information or the escalation of privileges on the targeted system. Defenders should monitor systems for suspicious local activity that could indicate exploitation of these firmware vulnerabilities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial local access to a system running vulnerable Intel firmware (IPU or UEFI Reference Firmware).\u003c/li\u003e\n\u003cli\u003eAttacker executes a specially crafted program designed to interact with the vulnerable firmware components.\u003c/li\u003e\n\u003cli\u003eThe crafted program leverages a vulnerability to bypass security checks or access control mechanisms within the firmware.\u003c/li\u003e\n\u003cli\u003eThe vulnerability allows the attacker to read memory regions containing sensitive information, such as credentials or cryptographic keys.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses the vulnerability to modify firmware settings or inject malicious code into the firmware execution path.\u003c/li\u003e\n\u003cli\u003eModified firmware grants the attacker elevated privileges within the system, potentially allowing them to bypass operating system security controls.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to access sensitive files, install malware, or perform other malicious activities.\u003c/li\u003e\n\u003cli\u003eAttacker maintains persistence by exploiting the firmware vulnerabilities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor 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).\u003c/li\u003e\n\u003cli\u003eInvestigate any suspicious modifications to UEFI settings or firmware configurations.\u003c/li\u003e\n\u003cli\u003eRegularly update firmware to the latest versions provided by the vendor.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-21T08:04:40Z","date_published":"2026-04-21T08:04:40Z","id":"/briefs/2026-04-intel-firmware-vulns/","summary":"A local attacker can exploit multiple vulnerabilities in Intel Firmware to disclose confidential information or gain elevated privileges.","title":"Intel IPU, UEFI Reference Firmware: Multiple Vulnerabilities","url":"https://feed.craftedsignal.io/briefs/2026-04-intel-firmware-vulns/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-32650"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve-2026-32650","credential-access","database"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAnviz CrossChex Standard is susceptible to a critical vulnerability (CVE-2026-32650) where an attacker can manipulate the TDS7 PreLogin process. By exploiting this flaw, an attacker can disable encryption mechanisms, causing sensitive database credentials to be transmitted in plaintext. This exposure enables unauthorized access to the underlying database, potentially leading to data breaches, modification of records, or other malicious activities. The vulnerability was disclosed in April 2026 and poses a significant risk to organizations utilizing the affected Anviz CrossChex Standard software. The vulnerability exists because the application allows for a downgrade to a less secure algorithm during negotiation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies an Anviz CrossChex Standard instance exposed to network access.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a connection to the TDS7 PreLogin port.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious TDS7 PreLogin packet to negotiate a connection without encryption.\u003c/li\u003e\n\u003cli\u003eThe CrossChex Standard software, due to the vulnerability, accepts the unencrypted connection.\u003c/li\u003e\n\u003cli\u003eThe software transmits database credentials in plaintext over the unencrypted channel.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts the plaintext database credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the obtained credentials to authenticate directly to the database server.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the CrossChex Standard database, enabling them to read, modify, or delete sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply available patches or updates for Anviz CrossChex Standard as provided by the vendor to remediate CVE-2026-32650.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for connections to the TDS7 PreLogin port that do not negotiate encryption using the provided network connection Sigma rule.\u003c/li\u003e\n\u003cli\u003eRestrict network access to the TDS7 PreLogin port only to trusted hosts and networks using firewall rules to mitigate the risk of unauthorized access.\u003c/li\u003e\n\u003cli\u003eEnable logging on the database server and monitor for successful logins from unusual IP addresses or accounts after applying the network connection Sigma rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-18T12:00:00Z","date_published":"2026-04-18T12:00:00Z","id":"/briefs/2026-04-anviz-crosschex-vuln/","summary":"Anviz CrossChex Standard is vulnerable to unauthorized database access due to the manipulation of TDS7 PreLogin, which disables encryption, leading to plaintext transmission of database credentials.","title":"Anviz CrossChex Standard TDS7 PreLogin Encryption Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-04-anviz-crosschex-vuln/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.4,"id":"CVE-2026-32631"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["cve","credential-access","windows","git"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eGit for Windows versions before 2.53.0.windows.3 are susceptible to a vulnerability (CVE-2026-32631) that exposes users\u0026rsquo; NTLM hashes to malicious actors. This occurs when a user interacts with a specially crafted Git repository or branch hosted on an attacker-controlled server. The vulnerability stems from the lack of sufficient protections against unauthorized NTLM authentication requests during Git operations. The attack doesn\u0026rsquo;t require user interaction beyond the initial clone or checkout. Successful exploitation allows attackers to capture NTLMv2 hashes, which, while computationally expensive, can be brute-forced to recover user credentials. This vulnerability was patched in Git for Windows version 2.53.0.windows.3.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker 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\u0026rsquo;s server.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a social engineering campaign to entice the victim to clone the malicious repository using the \u003ccode\u003egit clone\u003c/code\u003e command.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker compromises an existing Git repository and adds a malicious branch. The victim is then tricked into checking out this branch using \u003ccode\u003egit checkout\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWhen the victim clones the repository or checks out the malicious branch, Git for Windows attempts to authenticate with the attacker\u0026rsquo;s server using the NTLM protocol.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s NTLMv2 hash is sent to the attacker\u0026rsquo;s server during the NTLM authentication handshake.\u003c/li\u003e\n\u003cli\u003eThe attacker captures the NTLMv2 hash from the authentication traffic.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates an offline brute-force attack against the captured NTLMv2 hash.\u003c/li\u003e\n\u003cli\u003eUpon successful brute-forcing, the attacker recovers the victim\u0026rsquo;s credentials and can use them to access other resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Git for Windows to version 2.53.0.windows.3 or later to remediate CVE-2026-32631.\u003c/li\u003e\n\u003cli\u003eImplement network monitoring to detect NTLM authentication attempts originating from Git processes to unusual or external destinations.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Git Process Spawning Cmd with /c net use\u0026rdquo; to detect potential NTLM authentication attempts and adjust it to monitor outbound network connections from \u003ccode\u003egit.exe\u003c/code\u003e using NTLM.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-15T18:17:17Z","date_published":"2026-04-15T18:17:17Z","id":"/briefs/2026-04-git-ntlm-hash-leak/","summary":"Git for Windows versions prior to 2.53.0.windows.3 are vulnerable to NTLM hash theft by attackers who can trick users into cloning malicious repositories or checking out malicious branches, leading to potential credential compromise.","title":"Git for Windows NTLM Hash Leak Vulnerability (CVE-2026-32631)","url":"https://feed.craftedsignal.io/briefs/2026-04-git-ntlm-hash-leak/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.2,"id":"CVE-2026-20205"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["splunk","credential-access","vulnerability"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-20205 affects Splunk MCP Server app versions prior to 1.0.3. The vulnerability allows a low-privileged user with access to the \u003ccode\u003e_internal\u003c/code\u003e index or the \u003ccode\u003emcp_tool_admin\u003c/code\u003e capability to view sensitive information in cleartext. This information includes user session and authorization tokens. Successful exploitation of this vulnerability requires either local access to the log files where the tokens are stored or administrative access to Splunk\u0026rsquo;s internal indexes. The default configuration limits access to the \u003ccode\u003e_internal\u003c/code\u003e index to the administrator role; however, if roles are misconfigured, less privileged users could gain unauthorized access. This vulnerability could lead to account compromise and lateral movement within the affected Splunk environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains access to a Splunk account with permissions to the \u003ccode\u003e_internal\u003c/code\u003e index or possesses the \u003ccode\u003emcp_tool_admin\u003c/code\u003e capability.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the \u003ccode\u003e_internal\u003c/code\u003e index through the Splunk web interface or directly via file system access (if local access is available).\u003c/li\u003e\n\u003cli\u003eThe attacker searches the \u003ccode\u003e_internal\u003c/code\u003e index for logs related to MCP Server activity.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies log entries containing user session tokens and authorization tokens.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the cleartext tokens from the log entries.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen session tokens to impersonate legitimate users.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the impersonated user\u0026rsquo;s privileges to access sensitive data or perform unauthorized actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Splunk MCP Server app to version 1.0.3 or later to remediate CVE-2026-20205.\u003c/li\u003e\n\u003cli\u003eReview and restrict access to the \u003ccode\u003e_internal\u003c/code\u003e index to administrator-level roles only, following Splunk\u0026rsquo;s documentation on \u003ca href=\"https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities\"\u003edefining roles\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor Splunk audit logs for unusual access patterns to the \u003ccode\u003e_internal\u003c/code\u003e index using the Sigma rule \u003ccode\u003eSplunk Unusual Internal Index Access\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eReview and restrict the \u003ccode\u003emcp_tool_admin\u003c/code\u003e capability to only authorized personnel.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-15T16:16:34Z","date_published":"2026-04-15T16:16:34Z","id":"/briefs/2026-04-splunk-mcp-credential-access/","summary":"A user with access to the `_internal` index or the `mcp_tool_admin` capability in Splunk MCP Server app versions below 1.0.3 can view user session and authorization tokens in clear text, leading to potential credential compromise.","title":"Splunk MCP Server App Cleartext Credential Exposure (CVE-2026-20205)","url":"https://feed.craftedsignal.io/briefs/2026-04-splunk-mcp-credential-access/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.4,"id":"CVE-2026-33707"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["CVE-2026-33707","chamilo","lms","password-reset","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eChamilo LMS, a widely used learning management system, is susceptible to a critical vulnerability (CVE-2026-33707) affecting versions prior to 1.11.38 and 2.0.0-RC.3. The vulnerability lies within the default password reset mechanism, which generates password reset tokens by applying SHA1 hashing directly to user email addresses. This flawed process lacks essential security measures, including the addition of random salts, token expiration, and rate limiting. An attacker who obtains a target user\u0026rsquo;s email address can calculate the password reset token and gain unauthorized access to the user\u0026rsquo;s account, bypassing authentication controls. The vulnerability was publicly disclosed in April 2026 and patched in versions 1.11.38 and 2.0.0-RC.3. Organizations using vulnerable versions of Chamilo LMS are at high risk of account compromise.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a valid email address associated with a Chamilo LMS user. This information may be obtained through OSINT or data breaches.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the password reset page of the Chamilo LMS instance.\u003c/li\u003e\n\u003cli\u003eThe attacker enters the victim\u0026rsquo;s email address into the password reset form.\u003c/li\u003e\n\u003cli\u003eThe system generates a password reset token by applying SHA1 to the victim\u0026rsquo;s email address without any salt or random component.\u003c/li\u003e\n\u003cli\u003eThe attacker computes the SHA1 hash of the victim\u0026rsquo;s email address offline.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the computed SHA1 hash as the password reset token in a crafted request to the password reset confirmation endpoint.\u003c/li\u003e\n\u003cli\u003eThe Chamilo LMS instance validates the attacker-supplied token against the SHA1 hash of the email.\u003c/li\u003e\n\u003cli\u003eThe attacker sets a new password for the victim\u0026rsquo;s account and gains full access to the compromised account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately upgrade Chamilo LMS installations to version 1.11.38 or 2.0.0-RC.3 to remediate CVE-2026-33707.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on password reset requests to mitigate automated attacks attempting to exploit this vulnerability (reference: Overview section).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules below to detect attempts to exploit this vulnerability by monitoring password reset requests (reference: rules section).\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious password reset requests originating from unusual IPs or with unusually high frequency (reference: rules logsource).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T12:00:00Z","date_published":"2026-04-11T12:00:00Z","id":"/briefs/2026-04-chamilo-lms-weak-password-reset/","summary":"Chamilo LMS versions prior to 1.11.38 and 2.0.0-RC.3 are vulnerable to a weak password reset mechanism, allowing attackers to compute password reset tokens using only a user's email address due to the use of SHA1 hashing without randomization, expiration, or rate limiting, leading to unauthorized account takeover.","title":"Chamilo LMS Weak Password Reset Vulnerability (CVE-2026-33707)","url":"https://feed.craftedsignal.io/briefs/2026-04-chamilo-lms-weak-password-reset/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","cloud","kubernetes"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of potential credential compromise and abuse in multi-cloud environments. The core issue is the observation of a single source IP address accessing secret stores across multiple cloud providers (AWS Secrets Manager, Google Secret Manager, Azure Key Vault) and Kubernetes clusters within a short timeframe. This behavior, detected by the Elastic rule \u0026ldquo;Multiple Cloud Secrets Accessed by Source Address\u0026rdquo; published on 2026-04-10, is indicative of an adversary attempting to harvest secrets using stolen credentials, hijacked sessions, or replayed tokens. The rule is designed to identify anomalous cross-cloud secret retrieval, which is uncommon in legitimate multi-cloud orchestration scenarios. Defenders need to identify the source IP, the accessed secrets, and potential compromise scope to mitigate the threat effectively.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e Adversary gains access to valid credentials or session tokens through various means like phishing, malware, or exposed credentials. (T1555, T1566)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication:\u003c/strong\u003e Adversary uses the compromised credentials or tokens to authenticate to one of the cloud provider\u0026rsquo;s API (AWS, Azure, GCP).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (AWS):\u003c/strong\u003e The adversary leverages the AWS CLI or API to enumerate available secrets stored in AWS Secrets Manager using \u003ccode\u003eGetSecretValue\u003c/code\u003e API calls.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (Azure):\u003c/strong\u003e The adversary uses compromised credentials to interact with Azure Key Vault, utilizing \u003ccode\u003eSecretGet\u003c/code\u003e or \u003ccode\u003eKeyGet\u003c/code\u003e actions to discover accessible secrets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (GCP):\u003c/strong\u003e The adversary uses compromised service account or user credentials to access Google Secret Manager and enumerate accessible secrets using \u003ccode\u003egoogle.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion\u003c/code\u003e or \u003ccode\u003egoogle.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (Kubernetes):\u003c/strong\u003e The adversary uses compromised credentials to access the Kubernetes API and enumerate secrets within the cluster, specifically targeting the \u003ccode\u003esecrets\u003c/code\u003e resource with \u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e verbs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e The adversary retrieves the secret values from each cloud provider and Kubernetes cluster. (T1555.006)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExfiltration/Lateral Movement:\u003c/strong\u003e The adversary exfiltrates the retrieved secrets for further malicious activities, such as lateral movement within the cloud environments or unauthorized access to sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;Multiple Cloud Secrets Accessed by Source Address\u0026rdquo; 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.\u003c/li\u003e\n\u003cli\u003eInvestigate 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\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eRestrict or disable affected credentials or service accounts and rotate all accessed secrets if the activity is unauthorized or suspicious, as described in the rule\u0026rsquo;s Response and Remediation steps.\u003c/li\u003e\n\u003cli\u003eHarden 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-02-multi-cloud-secrets-access/","summary":"A single source IP accessing secret-management APIs across multiple cloud providers (AWS, GCP, Azure) and Kubernetes clusters within a short timeframe indicates potential credential theft, session hijacking, or token replay.","title":"Multiple Cloud Secrets Accessed by Single Source IP","url":"https://feed.craftedsignal.io/briefs/2024-02-multi-cloud-secrets-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":true,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","azure-arc","credential-access","initial-access"],"_cs_type":"threat","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies a specific attack sequence targeting Azure Arc-connected Kubernetes clusters. It focuses on the scenario where a service principal authenticates to Microsoft Entra ID and subsequently requests credentials for an Azure Arc-connected Kubernetes cluster. The \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action is used to retrieve tokens that enable kubectl access through the Arc Cluster Connect proxy. This sequence is particularly concerning when the service principal authenticates externally and immediately accesses Arc cluster credentials, especially from unexpected locations or Autonomous System Numbers (ASNs). This behavior, observed in attacks like those described by IBM X-Force in 2025, can lead to attackers gaining unauthorized access to and control over Kubernetes clusters. Defenders should investigate such events, particularly when the sign-in originates from an unexpected location or ASN.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains unauthorized access to a service principal\u0026rsquo;s credentials (e.g., through credential stuffing, phishing, or exposed secrets).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eService Principal Authentication:\u003c/strong\u003e The attacker uses the compromised service principal credentials to authenticate to Microsoft Entra ID (Azure AD) using the \u003ccode\u003eServicePrincipalSignInLogs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Listing Request:\u003c/strong\u003e 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 \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e in the Activity Logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Retrieval:\u003c/strong\u003e The attacker retrieves the Arc cluster credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProxy Tunnel Establishment:\u003c/strong\u003e The attacker uses the retrieved credentials to establish a proxy tunnel into the Kubernetes cluster via the Arc Cluster Connect proxy.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKubernetes Access:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement \u0026amp; Privilege Escalation:\u003c/strong\u003e The attacker exploits vulnerabilities or misconfigurations within the Kubernetes cluster to move laterally to other resources, escalate privileges, and gain further control.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration or Ransomware Deployment:\u003c/strong\u003e The attacker exfiltrates sensitive data from the Kubernetes cluster or deploys ransomware to encrypt critical data, impacting business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy 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.\u003c/li\u003e\n\u003cli\u003eReview 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\u0026rsquo;s note.\u003c/li\u003e\n\u003cli\u003eEnable conditional access policies to restrict service principal authentication by location to prevent logins from unexpected regions, as suggested in the rule\u0026rsquo;s note.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e events to identify potential unauthorized access attempts.\u003c/li\u003e\n\u003cli\u003eRotate service principal credentials regularly and revoke active sessions and tokens for the SP as outlined in the rule\u0026rsquo;s response and remediation steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-11-24-azure-arc-credential-access/","summary":"Detects a service principal authenticating to Azure AD followed by listing credentials for an Azure Arc-connected Kubernetes cluster, indicating potential adversary activity with stolen service principal secrets to establish a proxy tunnel into Kubernetes clusters.","title":"Azure Service Principal Sign-In Followed by Arc Cluster Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-11-24-azure-arc-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["cookie-theft","credential-access","chrome"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eGoogle has introduced Device Bound Session Credentials (DBSC) in Chrome 146 for Windows to combat session cookie theft, with a macOS version planned for a future release. This feature, initially announced in April 2024, aims to protect user accounts from compromise by rendering stolen authentication cookies useless. Session cookies are often stolen using information-stealing malware and traded on cybercrime platforms, allowing attackers to access accounts without passwords. DBSC mitigates this threat by cryptographically binding authentication sessions to the user\u0026rsquo;s device, leveraging hardware-backed security modules to generate unique public/private key pairs. This ensures that even if cookies are exfiltrated, they quickly expire and become unusable, enhancing overall security for Chrome users. Websites can adopt DBSC via registration and refresh endpoints.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker deploys information-stealing malware on a victim\u0026rsquo;s Windows or macOS system.\u003c/li\u003e\n\u003cli\u003eThe malware gains access to the browser\u0026rsquo;s local files and memory, where authentication cookies are stored.\u003c/li\u003e\n\u003cli\u003eThe malware exfiltrates the stolen session cookies to a command-and-control server.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to use the stolen session cookies to access the victim\u0026rsquo;s accounts on various web platforms.\u003c/li\u003e\n\u003cli\u003eIf DBSC is not implemented, the attacker successfully gains unauthorized access to the user\u0026rsquo;s accounts.\u003c/li\u003e\n\u003cli\u003eIf DBSC is implemented, Chrome checks for device-bound credentials.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s attempt to access the account is blocked, preventing unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDetection engineers should familiarize themselves with the concept and deployment of Device Bound Session Credentials (DBSC) to understand its impact on existing detection strategies.\u003c/li\u003e\n\u003cli\u003eMonitor for the presence of information-stealing malware that targets browser cookie storage locations using \u003ccode\u003efile_event\u003c/code\u003e and \u003ccode\u003eprocess_creation\u003c/code\u003e log sources.\u003c/li\u003e\n\u003cli\u003eConsider deploying the Sigma rule to detect anomalous processes accessing browser cookie storage locations to identify potential cookie theft attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T07:50:52Z","date_published":"2026-04-10T07:50:52Z","id":"/briefs/2026-04-chrome-cookie-protection/","summary":"Google's rollout of Device Bound Session Credentials (DBSC) in Chrome 146 for Windows, with a future release planned for macOS, cryptographically binds authentication sessions to the user's device, rendering stolen session cookies unusable and mitigating credential access.","title":"Google Chrome Device Bound Session Credentials (DBSC) Mitigates Cookie Theft","url":"https://feed.craftedsignal.io/briefs/2026-04-chrome-cookie-protection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["litellm","authentication-bypass","credential-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eLiteLLM versions prior to 1.83.0 are vulnerable to an authentication bypass vulnerability. User passwords are stored as unsalted SHA-256 hashes, a weak cryptographic practice that makes them susceptible to rainbow table attacks. Furthermore, these password hashes are exposed through several API endpoints, including \u003ccode\u003e/user/info\u003c/code\u003e, \u003ccode\u003e/user/update\u003c/code\u003e, and \u003ccode\u003e/spend/users\u003c/code\u003e, allowing any authenticated user to retrieve them. The \u003ccode\u003e/v2/login\u003c/code\u003e endpoint also accepts the raw SHA-256 hash as a valid password without proper re-hashing. This combination of vulnerabilities allows an attacker with low-level access to escalate privileges by obtaining another user\u0026rsquo;s password hash and using it to directly log in as that user. Defenders should upgrade to version 1.83.0 or later to mitigate this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to LiteLLM and authenticates as a low-privilege user.\u003c/li\u003e\n\u003cli\u003eAttacker sends a request to \u003ccode\u003e/user/info\u003c/code\u003e to retrieve the password hash of another user.\u003c/li\u003e\n\u003cli\u003eThe API responds with the target user\u0026rsquo;s SHA-256 password hash.\u003c/li\u003e\n\u003cli\u003eAttacker sends a POST request to the \u003ccode\u003e/v2/login\u003c/code\u003e endpoint using the stolen SHA-256 hash as the password.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003e/v2/login\u003c/code\u003e endpoint accepts the raw SHA-256 hash without re-hashing.\u003c/li\u003e\n\u003cli\u003eThe server authenticates the attacker as the target user.\u003c/li\u003e\n\u003cli\u003eAttacker now has the privileges of the target user, potentially gaining access to sensitive data or administrative functions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade LiteLLM to version 1.83.0 or later to patch the vulnerability (reference: Patches section).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect LiteLLM User Info Hash Access\u0026rdquo; to monitor for unauthorized access to user password hashes via the \u003ccode\u003e/user/info\u003c/code\u003e endpoint (reference: rule: \u0026ldquo;Detect LiteLLM User Info Hash Access\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect LiteLLM Login with SHA256 Hash\u0026rdquo; to detect login attempts using SHA256 hashes (reference: rule: \u0026ldquo;Detect LiteLLM Login with SHA256 Hash\u0026rdquo;).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-08T00:04:12Z","date_published":"2026-04-08T00:04:12Z","id":"/briefs/2024-01-09-litellm-auth-bypass/","summary":"LiteLLM versions before 1.83.0 stored user passwords as unsalted SHA-256 hashes and exposed these hashes through multiple API endpoints, enabling an authenticated user to retrieve another user's password hash and use it to log in as that user due to the /v2/login endpoint accepting the raw SHA-256 hash without re-hashing, leading to potential privilege escalation.","title":"LiteLLM Authentication Bypass via Password Hash Exposure and Pass-the-Hash","url":"https://feed.craftedsignal.io/briefs/2024-01-09-litellm-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule, published by Elastic, is designed to correlate AWS security alerts and prioritize investigations related to potentially compromised IAM access keys. Specifically, it focuses on scenarios where a long-term IAM access key is observed originating from a new source IP address (detected by the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule, rule ID 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) and is also associated with other open alerts of medium, high, or critical severity. This correlation aims to surface instances where a newly exposed or compromised access key is actively being used for malicious activities, enabling security teams to respond more effectively to potential credential access incidents and initial access attempts. The rule is a higher-order rule that analyzes existing security alerts within an Elastic Security deployment and leverages the \u003ccode\u003ekibana.alert\u003c/code\u003e fields to identify related events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn 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.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.\u003c/li\u003e\n\u003cli\u003eThe attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.\u003c/li\u003e\n\u003cli\u003eThe correlation rule identifies the co-occurrence of the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; alert and other elevated severity alerts associated with the same access key ID.\u003c/li\u003e\n\u003cli\u003eThe security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts\u0026rdquo; rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by the rule by pivoting on the \u003ccode\u003eaws.cloudtrail.user_identity.access_key_id\u003c/code\u003e in CloudTrail and IAM to understand the context of the access key usage.\u003c/li\u003e\n\u003cli\u003eReview the sibling alerts identified by the rule using \u003ccode\u003eEsql.kibana_alert_rule_name_values\u003c/code\u003e and \u003ccode\u003eEsql.kibana_alert_rule_id_values\u003c/code\u003e to understand the scope and impact of the potential compromise.\u003c/li\u003e\n\u003cli\u003eConfigure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that \u003ccode\u003ekibana.alert.risk_score \u0026gt;= 47\u003c/code\u003e corresponds to medium or higher severity alerts.\u003c/li\u003e\n\u003cli\u003eRotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.\u003c/li\u003e\n\u003cli\u003eImplement the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T14:37:37Z","date_published":"2026-04-06T14:37:37Z","id":"/briefs/2026-06-aws-iam-access-key-correlation/","summary":"This rule correlates AWS Long-Term Access Key First Seen from Source IP alerts with other open alerts of medium or higher severity that share the same IAM access key ID to prioritize investigation of potentially compromised accounts, helping identify post-compromise activity.","title":"AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts","url":"https://feed.craftedsignal.io/briefs/2026-06-aws-iam-access-key-correlation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["kubernetes","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies instances where Kubernetes secrets are accessed through atypical means, specifically flagging requests originating from unusual user agents, usernames, or source IPs. The underlying assumption is that after compromising a pod or stealing a kubeconfig file, adversaries often attempt to harvest sensitive information stored as secrets within the Kubernetes cluster. This includes service account tokens, registry credentials, cloud keys, and other critical data. This activity can lead to privilege escalation and lateral movement within the cluster or the wider cloud environment. The rule focuses on identifying deviations from established access patterns to Kubernetes secrets to detect potentially malicious activity. The rule leverages data from kubernetes.audit_logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to the Kubernetes cluster, potentially by exploiting a vulnerability in a pod or by stealing a kubeconfig file.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker enumerates available resources within the cluster to identify potential targets, including secrets. This might involve using \u003ccode\u003ekubectl get secrets --all-namespaces\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Theft:\u003c/strong\u003e The attacker attempts to access Kubernetes secrets using an unusual user agent, source IP, or user name. For example, using \u003ccode\u003ecurl\u003c/code\u003e from a compromised pod to access the Kubernetes API.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker retrieves the contents of the secrets. Secrets might contain service account tokens, registry credentials, cloud IAM keys, database passwords, etc.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence by creating backdoors or modifying existing deployments. This might involve creating new pods or modifying existing deployments.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their objective, such as data theft, denial of service, or infrastructure compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Secret Access via Unusual User Agent\u003c/code\u003e to your SIEM and tune for your environment to detect unusual access patterns to Kubernetes secrets.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eImplement RBAC least privilege to limit access to secrets to only the required service accounts and users to minimize the potential impact of credential theft.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs (\u003ccode\u003elogs-kubernetes.audit_logs-*\u003c/code\u003e) for suspicious activity, including unusual API calls and access patterns to sensitive resources.\u003c/li\u003e\n\u003cli\u003eRegularly rotate secrets and credentials to minimize the window of opportunity for attackers to use stolen credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T12:05:33Z","date_published":"2026-04-06T12:05:33Z","id":"/briefs/2024-01-09-kubernetes-secret-access/","summary":"Detects unusual access to Kubernetes secrets, potentially indicating an attacker attempting to steal sensitive information after gaining initial access to the cluster.","title":"Kubernetes Secret Access via Unusual User Agent","url":"https://feed.craftedsignal.io/briefs/2024-01-09-kubernetes-secret-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["directus","vulnerability","credential-access","api-token","2fa-bypass"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eDirectus versions prior to 11.17.0 contain a vulnerability where aggregate functions, such as \u003ccode\u003emin\u003c/code\u003e and \u003ccode\u003emax\u003c/code\u003e, when applied to fields with the \u003ccode\u003econceal\u003c/code\u003e special type, incorrectly return raw database values instead of the masked placeholder. This affects authenticated users who have read access to the affected collection, enabling them to extract concealed field values via \u003ccode\u003egroupBy\u003c/code\u003e aggregate queries.  This vulnerability allows for the extraction of sensitive information, such as static API tokens and two-factor authentication secrets stored in \u003ccode\u003edirectus_users\u003c/code\u003e, enabling account takeovers and 2FA bypass. The vulnerability was reported on April 4, 2026, and is identified as CVE-2026-35442. Defenders should prioritize upgrading Directus instances to version 11.17.0 or later to mitigate this risk.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker authenticates to a vulnerable Directus instance with valid user credentials.\u003c/li\u003e\n\u003cli\u003eAttacker identifies a collection containing fields with the \u003ccode\u003econceal\u003c/code\u003e special type, such as \u003ccode\u003edirectus_users\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAttacker crafts an aggregate query using functions like \u003ccode\u003emin\u003c/code\u003e or \u003ccode\u003emax\u003c/code\u003e on the concealed field and includes a \u003ccode\u003egroupBy\u003c/code\u003e clause. Example: \u003ccode\u003eSELECT min(secret_field) FROM collection GROUP BY other_field\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Directus server processes the aggregate query but fails to properly apply the masking logic to the nested results.\u003c/li\u003e\n\u003cli\u003eThe server returns the raw, unmasked values of the concealed field in the aggregate query response.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts static API tokens and TOTP seeds from the returned data.\u003c/li\u003e\n\u003cli\u003eAttacker uses the extracted API tokens to authenticate as other users, including administrators, bypassing username/password requirements.\u003c/li\u003e\n\u003cli\u003eAttacker uses the extracted TOTP seeds to bypass two-factor authentication for other users, gaining unauthorized access to their accounts.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Directus to version 11.17.0 or later to patch the vulnerability (CVE-2026-35442).\u003c/li\u003e\n\u003cli\u003eImplement 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.\u003c/li\u003e\n\u003cli\u003eMonitor Directus application logs for unusual aggregate query patterns, especially those involving \u003ccode\u003egroupBy\u003c/code\u003e and functions like \u003ccode\u003emin\u003c/code\u003e or \u003ccode\u003emax\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-04T06:13:57Z","date_published":"2026-04-04T06:13:57Z","id":"/briefs/2026-04-directus-aggregate-disclosure/","summary":"A vulnerability in Directus versions prior to 11.17.0 allows authenticated users to extract concealed field values, including static API tokens and two-factor authentication secrets from directus_users, via aggregate queries.","title":"Directus Aggregate Query Vulnerability Allows Disclosure of Concealed Data","url":"https://feed.craftedsignal.io/briefs/2026-04-directus-aggregate-disclosure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["credential-access","defense-evasion","brute-force","password-spraying"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis alert triggers when an Elastic machine learning job identifies a significant spike in successful authentication events originating from a specific source IP address. The underlying cause may range from legitimate administrative activity to malicious attempts at credential compromise, such as password spraying, user enumeration, or brute force attacks. The rule requires a minimum Elastic Stack version of 9.4.0 and relies on data ingested via Elastic Defend, Auditd Manager, or the System integration. The machine learning job associated with this rule is named \u0026ldquo;auth_high_count_logon_events_for_a_source_ip_ea\u0026rdquo;. While build servers and CI systems can trigger this alert as false positives, its presence should always prompt investigation to rule out credential compromise attempts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains initial access to a network or system (not explicitly described in source).\u003c/li\u003e\n\u003cli\u003eCredential Harvesting: The attacker attempts to gather valid credentials through password spraying or brute-force attacks (T1110, T1110.003).\u003c/li\u003e\n\u003cli\u003eAccount Discovery: The attacker enumerates user accounts to identify potential targets, often performed in conjunction with password attacks.\u003c/li\u003e\n\u003cli\u003eSuccessful Authentication: Using compromised credentials, the attacker successfully authenticates to a system or service (T1078, T1078.002, T1078.003).\u003c/li\u003e\n\u003cli\u003eLateral Movement: After successful authentication, the attacker potentially moves laterally within the network using valid accounts (not explicitly described in source).\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker may attempt to escalate privileges to gain higher-level access (not explicitly described in source).\u003c/li\u003e\n\u003cli\u003eData 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).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives. This can impact any sector, as credential compromise is a common attack vector across various industries.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable and configure the Elastic Defend, Auditd Manager, or System integrations to provide the necessary data for the machine learning job (see Setup section).\u003c/li\u003e\n\u003cli\u003eInstall the associated Machine Learning job \u0026ldquo;auth_high_count_logon_events_for_a_source_ip_ea\u0026rdquo; to enable the detection (see Setup section).\u003c/li\u003e\n\u003cli\u003eTune the anomaly threshold of the machine learning job based on your environment to reduce false positives (anomaly_threshold metadata).\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by this rule, focusing on identifying the involved assets, users, and source IP addresses (see Note section).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-02T13:25:14Z","date_published":"2026-04-02T13:25:14Z","id":"/briefs/2026-04-auth-spike/","summary":"A machine learning job detected a spike in successful authentication events from a source IP address, which can indicate password spraying, user enumeration, or brute force activity, potentially leading to credential access.","title":"Spike in Successful Logon Events from a Source IP","url":"https://feed.craftedsignal.io/briefs/2026-04-auth-spike/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-20929"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["kerberos","relay","adcs","cve-2026-20929","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-20929, a vulnerability patched in January 2026, allows attackers to perform Kerberos authentication relay attacks by abusing DNS CNAME records. The attack involves manipulating DNS resolution to redirect a client\u0026rsquo;s Kerberos authentication request to an attacker-controlled server. This server then relays the authentication to Active Directory Certificate Services (AD CS) to enroll certificates on behalf of the victim user. This technique allows the attacker to gain persistent access to the domain. The vulnerability has a CVSS score of 7.5. This attack is a Kerberos-based variant of the ESC8 attack, which traditionally relies on NTLM relay. By exploiting Kerberos, the attack can bypass environments where NTLM has been disabled. The primary target is the AD CS web enrollment endpoint (/certsrv).\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe victim attempts to access a web server (e.g., web01.test.local).\u003c/li\u003e\n\u003cli\u003eA DNS query is initiated to resolve the hostname of the target web server.\u003c/li\u003e\n\u003cli\u003eThe 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\u0026rsquo;s IP address.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s system accesses the attacker-controlled web server.\u003c/li\u003e\n\u003cli\u003eThe malicious web server sends a 401 HTTP response to initiate Kerberos authentication.\u003c/li\u003e\n\u003cli\u003eThe victim requests a Kerberos service ticket for HTTP/CA01.test.local from the domain controller.\u003c/li\u003e\n\u003cli\u003eThe domain controller issues a service ticket for the requested SPN.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor for anomalous certificate-based authentication events combined with unusual AD CS service access within a short time window, as highlighted in the \u0026ldquo;CrowdStrike has developed a correlation-based detection\u0026rdquo; statement in the overview.\u003c/li\u003e\n\u003cli\u003eDisable web enrollment over HTTP to enforce Channel Binding Token (CBT) protection, mitigating the risk of successful relay attacks, as mentioned in the \u0026ldquo;Why AD CS Web Enrollment Is an Attractive Relay Target\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM and tune for your environment to detect potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eReview and harden AD CS configurations based on recommendations from \u0026ldquo;Certified Pre-Owned\u0026rdquo; research to reduce the attack surface.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-31T17:49:30Z","date_published":"2026-03-31T17:49:30Z","id":"/briefs/2026-04-kerberos-relay-cname/","summary":"An attacker exploits CVE-2026-20929 by manipulating DNS responses to redirect Kerberos authentication to attacker-controlled AD CS, enabling certificate enrollment for persistent access.","title":"Kerberos Authentication Relay via DNS CNAME Abuse (CVE-2026-20929)","url":"https://feed.craftedsignal.io/briefs/2026-04-kerberos-relay-cname/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["cve-2026-5128","steam-trader","information-disclosure","credential-access","account-takeover"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-5128 identifies a critical vulnerability in version 2.1.1 of the ArthurFiorette steam-trader application. This is a sensitive information exposure issue stemming from two main sources: direct access to the /users API endpoint and insecure logging practices. The vulnerable application, designed for managing Steam trading activities, inadvertently leaks highly sensitive user credentials. As the steam-trader repository is archived and no longer maintained, no patch is available, leaving…\u003c/p\u003e\n","date_modified":"2026-03-30T10:16:02Z","date_published":"2026-03-30T10:16:02Z","id":"/briefs/2024-01-steam-trader-cve/","summary":"CVE-2026-5128 exposes sensitive Steam account data via the /users API endpoint and logs in ArthurFiorette steam-trader 2.1.1, allowing account takeover.","title":"ArthurFiorette steam-trader 2.1.1 Sensitive Information Exposure","url":"https://feed.craftedsignal.io/briefs/2024-01-steam-trader-cve/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","vulnerability","openclaw"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOpenClaw versions before 2026.3.12 are vulnerable to credential exposure. The vulnerability stems from the embedding of long-lived shared gateway credentials directly into pairing setup codes. These codes are generated by the \u003ccode\u003e/pair\u003c/code\u003e endpoint and the \u003ccode\u003eOpenClaw qr\u003c/code\u003e command. An attacker who obtains these setup codes through various means, such as leaked chat histories, logs, or screenshots, can extract the embedded credentials. This allows the attacker to bypass the intended one-time pairing flow and gain unauthorized access to the shared gateway. The exposure of these credentials could lead to further unauthorized access and potential compromise of sensitive data.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user generates a pairing setup code using the \u003ccode\u003e/pair\u003c/code\u003e endpoint or \u003ccode\u003eOpenClaw qr\u003c/code\u003e command. This code contains the embedded shared gateway credentials.\u003c/li\u003e\n\u003cli\u003eThe setup code is shared with the intended recipient via chat, logs or screenshots.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to the setup code through compromised chat history, exposed logs, or publicly shared screenshots.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the long-lived shared gateway credential from the setup code.\u003c/li\u003e\n\u003cli\u003eThe attacker reuses the stolen shared gateway credentials outside of the intended one-time pairing flow.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the shared gateway.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the access gained via the gateway for further malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade OpenClaw to version 2026.3.12 or later to remediate the vulnerability (CVE-2026-33575).\u003c/li\u003e\n\u003cli\u003eImplement strict controls over the handling and storage of pairing setup codes to prevent unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious activity originating from OpenClaw gateways, potentially indicating unauthorized access using leaked credentials.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule to detect the usage of the \u003ccode\u003e/pair\u003c/code\u003e endpoint which could indicate unauthorized pairing attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-29T13:17:03Z","date_published":"2026-03-29T13:17:03Z","id":"/briefs/2026-03-openclaw-credential-exposure/","summary":"OpenClaw before 2026.3.12 embeds long-lived shared gateway credentials in pairing setup codes, allowing attackers with access to leaked codes to reuse credentials and gain unauthorized access.","title":"OpenClaw Credential Exposure via Leaked Pairing Codes","url":"https://feed.craftedsignal.io/briefs/2026-03-openclaw-credential-exposure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["cve-2026-33572","file-permissions","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOpenClaw before version 2026.2.17 is vulnerable to an insufficient file permissions issue. The application creates session transcript JSONL files with overly permissive default access controls. This vulnerability allows local users to read these transcript files, potentially exposing sensitive information such as secrets, API keys, passwords, or other confidential data that might be present in tool outputs or commands executed during a session. The vulnerability is identified as CVE-2026-33572…\u003c/p\u003e\n","date_modified":"2026-03-29T13:17:02Z","date_published":"2026-03-29T13:17:02Z","id":"/briefs/2026-03-openclaw-file-permissions/","summary":"OpenClaw before 2026.2.17 creates session transcript JSONL files with overly broad default permissions, allowing local users to read transcript contents and extract sensitive information.","title":"OpenClaw Insufficient File Permissions Vulnerability (CVE-2026-33572)","url":"https://feed.craftedsignal.io/briefs/2026-03-openclaw-file-permissions/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["vulnerability","timing oracle","credential access","doveadm"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-27856 describes a vulnerability in Doveadm, a component often used in conjunction with mail servers such as Dovecot. The vulnerability stems from the direct comparison method used to verify credentials, making it susceptible to timing oracle attacks. This vulnerability was published on March 27, 2026. An attacker leveraging this flaw can potentially determine the configured credentials by observing the time it takes for the system to respond to different credential attempts. While no…\u003c/p\u003e\n","date_modified":"2026-03-27T09:16:19Z","date_published":"2026-03-27T09:16:19Z","id":"/briefs/2026-03-doveadm-timing-oracle/","summary":"Doveadm credentials are verified using direct comparison, making it susceptible to timing oracle attacks, allowing attackers to determine credentials and gain full access.","title":"Doveadm Credentials Vulnerable to Timing Oracle Attack (CVE-2026-27856)","url":"https://feed.craftedsignal.io/briefs/2026-03-doveadm-timing-oracle/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cpp-httplib","credential-leak","cve-2026-33745","http-redirect","credential-access","cross-origin"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe cpp-httplib library, a C++11 single-file header-only cross platform HTTP/HTTPS library, contains a vulnerability (CVE-2026-33745) in versions prior to 0.39.0. This flaw allows an attacker to potentially steal sensitive credentials by exploiting the library\u0026rsquo;s behavior when handling cross-origin HTTP redirects (301, 302, 307, 308). Specifically, stored Basic Auth, Bearer Token, and Digest Auth credentials are unintentionally forwarded to arbitrary hosts during these redirects. This means a compromised server or a malicious actor can redirect a client using the vulnerable library to a host under their control, effectively capturing the plaintext credentials within the \u003ccode\u003eAuthorization\u003c/code\u003e header. Upgrading to version 0.39.0 resolves this vulnerability. This is critical because it impacts any application using the vulnerable version of the library and relying on HTTP authentication.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker compromises or sets up a malicious HTTP server.\u003c/li\u003e\n\u003cli\u003eAttacker 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\u0026rsquo;s controlled domain.\u003c/li\u003e\n\u003cli\u003eA 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.\u003c/li\u003e\n\u003cli\u003eThe cpp-httplib library in the client application receives the HTTP redirect response.\u003c/li\u003e\n\u003cli\u003eThe vulnerable library incorrectly appends any stored \u003ccode\u003eAuthorization\u003c/code\u003e headers (Basic Auth, Bearer Token, or Digest Auth) to the redirected request, even though it\u0026rsquo;s a cross-origin request.\u003c/li\u003e\n\u003cli\u003eThe client application, through cpp-httplib, sends the redirected request to the attacker-controlled host, including the sensitive \u003ccode\u003eAuthorization\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eThe attacker captures the \u003ccode\u003eAuthorization\u003c/code\u003e header, extracting the plaintext credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to impersonate the user or gain unauthorized access to protected resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to cpp-httplib version 0.39.0 or later to remediate CVE-2026-33745 as mentioned in the \u003cstrong\u003eOverview\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eImplement network monitoring to detect HTTP requests containing \u003ccode\u003eAuthorization\u003c/code\u003e headers being sent to unexpected or untrusted domains, based on the attack chain steps described above, specifically step 6.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately feasible, consider implementing a proxy that strips \u003ccode\u003eAuthorization\u003c/code\u003e headers from HTTP redirect requests to external domains as a temporary mitigation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-27T01:16:21Z","date_published":"2026-03-27T01:16:21Z","id":"/briefs/2026-03-cpp-httplib-credential-leak/","summary":"The cpp-httplib library prior to version 0.39.0 forwards stored authentication credentials to arbitrary hosts via HTTP redirects, potentially exposing sensitive information to malicious actors.","title":"cpp-httplib Vulnerability Leads to Credential Leakage via HTTP Redirects","url":"https://feed.craftedsignal.io/briefs/2026-03-cpp-httplib-credential-leak/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["cve-2025-36258","credential-access","plaintext-storage","infosphere"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eIBM InfoSphere Information Server versions 11.7.0.0 through 11.7.1.6 are vulnerable to plaintext storage of user credentials and other sensitive information. A local user with access to the affected system can potentially read these credentials, leading to unauthorized access or privilege escalation. This vulnerability, identified as CVE-2025-36258, can have significant impact on organizations using the affected IBM InfoSphere versions, as it exposes sensitive data and potentially compromises the entire system. Defenders should identify systems running these versions and apply recommended mitigations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA 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).\u003c/li\u003e\n\u003cli\u003eThe user navigates to the file system location where the application stores configuration files.\u003c/li\u003e\n\u003cli\u003eThe user opens the configuration files using a text editor or command-line tool like \u003ccode\u003ecat\u003c/code\u003e or \u003ccode\u003etype\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe user searches for plaintext credentials or other sensitive information within the configuration files.\u003c/li\u003e\n\u003cli\u003eThe user discovers usernames, passwords, API keys, or other secrets stored in plaintext.\u003c/li\u003e\n\u003cli\u003eThe user uses the discovered credentials to authenticate to the InfoSphere system or related services.\u003c/li\u003e\n\u003cli\u003eThe user gains unauthorized access to data, configurations, or administrative functions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the security update or patch provided by IBM to address CVE-2025-36258; refer to \u003ca href=\"https://www.ibm.com/support/pages/node/7266489\"\u003ehttps://www.ibm.com/support/pages/node/7266489\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement access controls to restrict local user access to sensitive configuration files.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided to detect unauthorized access to configuration files and processes attempting to read them.\u003c/li\u003e\n\u003cli\u003eEnable file integrity monitoring for InfoSphere configuration directories to detect unauthorized modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-25T21:16:24Z","date_published":"2026-03-25T21:16:24Z","id":"/briefs/2026-03-ibm-infosphere-plaintext-creds/","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 stores user credentials in plaintext, allowing local users to read sensitive information.","title":"IBM InfoSphere Information Server Plaintext Credential Storage Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-03-ibm-infosphere-plaintext-creds/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","initial-access","phishing","oauth"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAn active phishing campaign is leveraging Microsoft\u0026rsquo;s Device Code OAuth flow to target users of cloud-based file storage and document workflow platforms. Unlike traditional phishing attacks that aim to steal usernames and passwords directly, this campaign exploits a legitimate authentication mechanism to gain unauthorized access. The campaign impersonates popular cloud services, enticing users to enter a provided device code on a Microsoft login page. By doing so, victims inadvertently grant the attacker access to their accounts on the targeted platforms. This campaign highlights the evolving tactics of phishing actors and the need for robust detection mechanisms beyond simple credential harvesting alerts. The scope and scale of the campaign are currently unknown.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker sends a phishing email impersonating a cloud-based file storage or document workflow service.\u003c/li\u003e\n\u003cli\u003eThe email contains a message prompting the user to \u0026ldquo;activate\u0026rdquo; or \u0026ldquo;authenticate\u0026rdquo; their account.\u003c/li\u003e\n\u003cli\u003eThe email includes a device code and instructs the user to visit a Microsoft login page (e.g., microsoft.com/devicelogin).\u003c/li\u003e\n\u003cli\u003eThe user, believing the request is legitimate, enters the provided device code on the Microsoft login page.\u003c/li\u003e\n\u003cli\u003eThe Microsoft login page prompts the user to grant permissions to an application controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eIf the user approves the permissions, the attacker gains OAuth tokens that allow access to the user\u0026rsquo;s account on the targeted cloud platform.\u003c/li\u003e\n\u003cli\u003eThe attacker can then access, modify, or exfiltrate data stored on the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the compromised account to further propagate the phishing campaign to other users within the organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement user awareness training to educate employees about device code phishing and the risks of entering unknown codes on login pages.\u003c/li\u003e\n\u003cli\u003eMonitor 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 \u0026ldquo;Detect Suspicious Device Code Authentication\u0026rdquo; Sigma rule to identify anomalous activity.\u003c/li\u003e\n\u003cli\u003eImplement Conditional Access policies in Microsoft Entra ID to restrict device code authentication to trusted devices and locations.\u003c/li\u003e\n\u003cli\u003eInvestigate any successful device code authentications where the application requesting permissions is not recognized or approved by the organization.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-25T12:00:00Z","date_published":"2026-03-25T12:00:00Z","id":"/briefs/2026-03-device-code-phishing/","summary":"A phishing campaign abuses Microsoft's Device Code OAuth flow to gain access to cloud-based file storage and document workflow platforms, bypassing traditional credential harvesting.","title":"Device Code Phishing Campaign Targeting Cloud Platforms","url":"https://feed.craftedsignal.io/briefs/2026-03-device-code-phishing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve-2026-32913","credential-access","header-injection","openclaw"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOpenClaw, a Node.js framework, is susceptible to a critical vulnerability (CVE-2026-32913) affecting versions prior to 2026.3.7. The vulnerability lies in the \u003ccode\u003efetchWithSsrFGuard\u003c/code\u003e function, which improperly validates headers. This flaw allows attackers to potentially forward custom authorization headers, such as \u003ccode\u003eX-Api-Key\u003c/code\u003e and \u003ccode\u003ePrivate-Token\u003c/code\u003e, across cross-origin redirects. Successful exploitation enables the interception of sensitive credentials intended for the original, legitimate destination. The vulnerability was reported in March 2026 and impacts applications using the vulnerable versions of OpenClaw. Defenders should prioritize patching and implementing compensating controls to prevent credential leakage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious URL targeting an OpenClaw application using a version prior to 2026.3.7.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s browser or application requests the malicious URL, including custom authorization headers like \u003ccode\u003eX-Api-Key\u003c/code\u003e or \u003ccode\u003ePrivate-Token\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe vulnerable \u003ccode\u003efetchWithSsrFGuard\u003c/code\u003e function in OpenClaw fails to properly validate or sanitize headers during cross-origin redirects.\u003c/li\u003e\n\u003cli\u003eThe attacker configures their malicious server to respond with an HTTP 302 redirect to a different origin controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s client, upon receiving the redirect, unknowingly forwards the sensitive authorization headers to the attacker\u0026rsquo;s server.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s server logs or captures the leaked \u003ccode\u003eX-Api-Key\u003c/code\u003e and/or \u003ccode\u003ePrivate-Token\u003c/code\u003e values.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to resources or data protected by those credentials on the original target application.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade OpenClaw to version 2026.3.7 or later to patch CVE-2026-32913 (see references for patch information).\u003c/li\u003e\n\u003cli\u003eImplement server-side validation to sanitize and strip potentially sensitive authorization headers before following redirects.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Suspicious Header Forwarding\u003c/code\u003e to identify potential exploitation attempts by monitoring for cross-origin redirects involving sensitive headers.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for unusual redirect activity and suspicious user agents (see log source information in the Sigma rules).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-24T12:00:00Z","date_published":"2026-03-24T12:00:00Z","id":"/briefs/2026-03-openclaw-header-leak/","summary":"OpenClaw before 2026.3.7 is vulnerable to improper header validation in fetchWithSsrFGuard, allowing attackers to intercept sensitive authorization headers via cross-origin redirects.","title":"OpenClaw Improper Header Validation Leads to Credential Leakage","url":"https://feed.craftedsignal.io/briefs/2026-03-openclaw-header-leak/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["cve-2026-33297","credential-access","web-application"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eWWBN AVideo is an open-source video platform. A critical vulnerability exists in versions prior to 26.0 within the CustomizeUser plugin. Specifically, the \u003ccode\u003esetPassword.json.php\u003c/code\u003e endpoint is susceptible to a logic error affecting channel password assignments. When an administrator attempts to set a channel password containing non-numeric characters for any user, the system incorrectly coerces the password to the integer zero before storing it. This effectively sets the channel password to \u0026lsquo;0\u0026rsquo;…\u003c/p\u003e\n","date_modified":"2026-03-23T14:16:33Z","date_published":"2026-03-23T14:16:33Z","id":"/briefs/2024-01-avideo-password-bypass/","summary":"WWBN AVideo versions prior to 26.0 are vulnerable to a credential access vulnerability where passwords containing non-numeric characters are incorrectly processed, effectively setting the password to '0' and allowing trivial channel access bypass.","title":"WWBN AVideo Channel Password Bypass Vulnerability (CVE-2026-33297)","url":"https://feed.craftedsignal.io/briefs/2024-01-avideo-password-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["insecure-logging","credential-access","android"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eEquityPandit 1.0, an Android application, is vulnerable to insecure logging practices. Specifically, the application logs sensitive user credentials, including plaintext passwords, within the developer console logs. This vulnerability, identified as CVE-2019-25605, allows an attacker with access to the device or ADB (Android Debug Bridge) to extract these credentials. The vulnerability was reported in 2019, but publicly disclosed details and exploits surfaced more recently. Successful…\u003c/p\u003e\n","date_modified":"2026-03-23T14:00:00Z","date_published":"2026-03-23T14:00:00Z","id":"/briefs/2026-03-equitypandit-logging/","summary":"EquityPandit 1.0 contains an insecure logging vulnerability (CVE-2019-25605) that allows attackers to capture sensitive user credentials by accessing developer console logs via Android Debug Bridge, specifically exposing plaintext passwords during the forgot password function.","title":"EquityPandit 1.0 Insecure Logging Vulnerability (CVE-2019-25605)","url":"https://feed.craftedsignal.io/briefs/2026-03-equitypandit-logging/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["credential-access","netntlm","phishing","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability, tracked as CVE-2025-59284, enables attackers to capture NetNTLM hashes from Windows systems through a specially crafted archive file. This technique exploits how Windows handles file extraction, potentially forcing authentication requests to a malicious server controlled by the attacker. The vulnerability was presented at BsidesLjubljana in March 2026, suggesting recent active research and potential exploitation. The original Reddit post indicates that the Microsoft patch might…\u003c/p\u003e\n","date_modified":"2026-03-18T12:00:00Z","date_published":"2026-03-18T12:00:00Z","id":"/briefs/2026-03-netntlm-phishing/","summary":"A phishing technique, potentially still viable due to incomplete patching, allows attackers to obtain NetNTLM hashes from archive extraction on Windows systems (CVE-2025-59284).","title":"NetNTLM Hash Phishing via Archive Extraction (CVE-2025-59284)","url":"https://feed.craftedsignal.io/briefs/2026-03-netntlm-phishing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","azure-arc","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies a specific attack chain targeting Azure Arc-connected Kubernetes clusters. The attack begins with a service principal authenticating to Microsoft Entra ID and immediately requesting credentials for an Azure Arc-connected Kubernetes cluster. This \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action retrieves tokens enabling \u003ccode\u003ekubectl\u003c/code\u003e access via the Arc Cluster Connect proxy. This behavior is indicative of adversaries using stolen service principal secrets to gain unauthorized access and establish a proxy tunnel into Kubernetes environments. The rule prioritizes external service principal authentications (excluding managed identities) followed by Arc cluster credential access, particularly when sign-in origins are from unexpected locations or Autonomous System Numbers (ASNs). This activity was observed in attacks documented by IBM X-Force and Microsoft, as referenced below.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises or obtains valid credentials for an Azure Service Principal.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to Microsoft Entra ID using the compromised service principal credentials, generating a ServicePrincipalSignInLogs event in Azure.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to list cluster user credentials for a connected Kubernetes cluster using the compromised service principal. This generates an Azure Activity Log event: \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIf successful, the \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action provides the attacker with tokens to access the Kubernetes cluster through the Arc Cluster Connect proxy.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to interact with the Kubernetes cluster via \u003ccode\u003ekubectl\u003c/code\u003e proxied through Azure Arc.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance within the Kubernetes cluster to identify valuable targets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create, read, update, or delete (CRUD) sensitive Kubernetes resources, such as secrets or configmaps.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to escalate privileges within the cluster or pivot to other resources within the Azure environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise 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\u0026rsquo;s objectives and the compromised environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect the described attack chain, tuning the \u003ccode\u003emaxspan\u003c/code\u003e value based on observed authentication patterns and network latency.\u003c/li\u003e\n\u003cli\u003eInvestigate 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).\u003c/li\u003e\n\u003cli\u003eImplement regular rotation of service principal credentials and enforce multi-factor authentication where possible (refer to Microsoft Entra ID documentation).\u003c/li\u003e\n\u003cli\u003eReview and restrict Azure role assignments for service principals on Arc-connected clusters to minimize potential impact from compromised credentials (refer to Azure RBAC documentation).\u003c/li\u003e\n\u003cli\u003eEnable 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).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-17T15:06:47Z","date_published":"2026-03-17T15:06:47Z","id":"/briefs/2024-01-02-azure-arc-credential-access/","summary":"Detects a service principal authenticating to Microsoft Entra ID and then listing credentials for an Azure Arc-connected Kubernetes cluster within a short time window, indicating potential unauthorized access to Kubernetes clusters via stolen service principal secrets.","title":"Azure Service Principal Sign-In Followed by Arc Cluster Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-01-02-azure-arc-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure AD Connect Authentication Agent"],"_cs_severities":["high"],"_cs_tags":["credential-access","dll-side-loading","azure-ad-connect"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe Azure AD Connect Authentication Agent facilitates pass-through authentication (PTA) in hybrid environments. Attackers may attempt to load malicious DLLs into the \u003ccode\u003eAzureADConnectAuthenticationAgentService.exe\u003c/code\u003e process to intercept or persist credentials. This involves placing an untrusted DLL in a location where the service will load it, such as a directory with weak permissions or through DLL side-loading. Successful exploitation allows attackers to capture user credentials as they are processed by the PTA service, potentially leading to domain compromise. This activity specifically targets systems utilizing Azure AD Connect with PTA enabled. Defenders should monitor for unexpected DLL loads by the Azure AD Connect Authentication Agent to identify and prevent credential access attempts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system hosting the Azure AD Connect Authentication Agent.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a location where they can place a malicious DLL that the \u003ccode\u003eAzureADConnectAuthenticationAgentService.exe\u003c/code\u003e process will load, such as a directory with weak permissions or a location susceptible to DLL side-loading.\u003c/li\u003e\n\u003cli\u003eThe attacker places a malicious DLL (e.g., \u003ccode\u003eevil.dll\u003c/code\u003e) into the identified location.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eAzureADConnectAuthenticationAgentService.exe\u003c/code\u003e process is started or restarted.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eAzureADConnectAuthenticationAgentService.exe\u003c/code\u003e process loads the malicious DLL (\u003ccode\u003eevil.dll\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe malicious DLL intercepts or captures credentials as they are processed by the PTA service.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the captured credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to other systems or resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003eUntrusted DLL Loaded by Azure AD Connect Authentication Agent\u003c/code\u003e to detect the loading of untrusted DLLs by the Azure AD Connect Authentication Agent service in your environment.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for \u003ccode\u003eAzureADConnectAuthenticationAgentService.exe\u003c/code\u003e loading DLLs outside of the standard Microsoft directories, as defined in the Sigma rule.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon Event ID 7 (Image Loaded) logging to provide the necessary data for the Sigma rule to function effectively.\u003c/li\u003e\n\u003cli\u003eRestrict write access to the Azure AD Connect Authentication Agent directories to prevent unauthorized DLL placement.\u003c/li\u003e\n\u003cli\u003eReview administrative access to the PTA host to prevent unauthorized modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T12:00:00Z","date_published":"2024-11-02T12:00:00Z","id":"/briefs/2024-11-azureadconnect-dll-load/","summary":"The loading of an untrusted DLL by the Azure AD Connect Authentication Agent, potentially indicating credential access attempts via the Pass-through Authentication service, is detected by this rule.","title":"Untrusted DLL Loaded by Azure AD Connect Authentication Agent","url":"https://feed.craftedsignal.io/briefs/2024-11-azureadconnect-dll-load/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","memory-dump","memprocfs"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eMemProcFS is a memory forensics tool that allows users to mount physical memory as a virtual file system. While legitimate uses exist for forensic analysis, adversaries are abusing it to gain unauthorized access to sensitive information. Observed tactics involve mounting memory dumps of compromised systems and extracting credentials, LSA secrets, SAM data, and cached domain credentials. This activity is particularly concerning as it allows threat actors to bypass traditional security measures and directly access sensitive data within the memory space of targeted processes. Unapproved usage of MemProcFS should be considered suspicious and investigated immediately to prevent credential theft and lateral movement.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a system through unspecified means (e.g., exploiting a vulnerability or using stolen credentials).\u003c/li\u003e\n\u003cli\u003eThe attacker obtains a memory dump of the compromised system, which may contain sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003eMemProcFS.exe\u003c/code\u003e with the \u003ccode\u003e-device\u003c/code\u003e parameter to mount the memory dump as a virtual file system.\u003c/li\u003e\n\u003cli\u003eMemProcFS creates a virtual file system representation of the memory dump, allowing the attacker to browse the memory space as files and directories.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the memory of the LSASS process (lsass.exe) through the mounted file system.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts credentials, such as usernames and passwords, from the LSASS process memory.\u003c/li\u003e\n\u003cli\u003eThe attacker may also access registry hives through the mounted file system to obtain LSA secrets, SAM data, and cached domain credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials for lateral movement, privilege escalation, or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect MemProcFS Execution with Device Parameter\u0026rdquo; to your SIEM to identify suspicious use of MemProcFS based on process creation events.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to provide the necessary data for the Sigma rules above.\u003c/li\u003e\n\u003cli\u003eMonitor for unusual file system access patterns that may indicate a memory dump being mounted as a virtual file system.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T12:00:00Z","date_published":"2024-11-02T12:00:00Z","id":"/briefs/2024-11-memprocfs-memory-dump/","summary":"Adversaries use MemProcFS, a memory forensics tool, to mount memory dumps as virtual file systems and extract sensitive information like credentials from LSASS or registry hives.","title":"MemProcFS Usage for Memory Dump Mounting and Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-11-memprocfs-memory-dump/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","admission-controller","privilege-escalation","persistence","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe Kubernetes admission controller is a crucial component that governs API requests to a Kubernetes cluster. Attackers can modify mutating or validating webhook configurations to intercept and manipulate these requests. By creating, updating, or replacing these configurations, adversaries can inject malicious code, alter resource definitions, or even exfiltrate sensitive information like access credentials. This activity can lead to privilege escalation, persistence within the cluster, and ultimately, a compromise of the entire Kubernetes environment. The attacks are typically stealthy as they operate within the legitimate Kubernetes API framework, making detection challenging. This behavior is particularly concerning for organizations relying on Kubernetes for critical applications and sensitive data.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerability in a deployed application.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker enumerates existing admission controller configurations (mutatingwebhookconfigurations and validatingwebhookconfigurations) to identify potential targets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConfiguration Modification:\u003c/strong\u003e The attacker uses \u003ccode\u003ekubectl\u003c/code\u003e or the Kubernetes API to create, update, or replace a webhook configuration. This involves crafting a malicious webhook that will intercept API requests.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWebhook Deployment:\u003c/strong\u003e The malicious webhook is deployed as a service within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAPI Interception:\u003c/strong\u003e When a user or application makes an API request that matches the webhook\u0026rsquo;s defined rules, the webhook intercepts the request.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMalicious Code Injection:\u003c/strong\u003e The webhook injects malicious code or alters the API request to achieve the attacker\u0026rsquo;s objectives (e.g., granting unauthorized permissions, modifying resource configurations).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence/Privilege Escalation/Credential Access:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement/Data Exfiltration:\u003c/strong\u003e The attacker leverages their gained access to move laterally within the cluster or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Admission Controller Modification\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious modifications to webhook configurations (logsource: kubernetes, service: audit).\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for \u003ccode\u003ecreate\u003c/code\u003e, \u003ccode\u003edelete\u003c/code\u003e, \u003ccode\u003epatch\u003c/code\u003e, \u003ccode\u003ereplace\u003c/code\u003e, and \u003ccode\u003eupdate\u003c/code\u003e verbs on \u003ccode\u003emutatingwebhookconfigurations\u003c/code\u003e and \u003ccode\u003evalidatingwebhookconfigurations\u003c/code\u003e resources (logsource: kubernetes, service: audit).\u003c/li\u003e\n\u003cli\u003eImplement strong RBAC policies to limit access to Kubernetes API resources and prevent unauthorized modification of admission controller configurations.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit existing admission controller configurations to identify any unexpected or malicious webhooks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-01T12:00:00Z","date_published":"2024-11-01T12:00:00Z","id":"/briefs/2024-11-kubernetes-admission-controller-modification/","summary":"An adversary modifies Kubernetes admission controller configurations to achieve persistence, escalate privileges, or gain unauthorized access to credentials within the cluster.","title":"Kubernetes Admission Controller Modification","url":"https://feed.craftedsignal.io/briefs/2024-11-kubernetes-admission-controller-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Veeam Backup"],"_cs_severities":["medium"],"_cs_tags":["veeam","credential-access","mssql","windows","ransomware"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Veeam"],"content_html":"\u003cp\u003eAttackers are increasingly targeting backup infrastructure to maximize the impact of ransomware and data exfiltration attacks. Veeam, a popular backup and disaster recovery solution, stores credentials for backup operations in MSSQL databases. An attacker who gains access to these databases may attempt to use tools like \u003ccode\u003esqlcmd.exe\u003c/code\u003e or PowerShell commands (e.g., \u003ccode\u003eInvoke-Sqlcmd\u003c/code\u003e) to extract and decrypt these credentials. This tactic allows the attacker to compromise the backups themselves, preventing recovery and increasing pressure on the victim. This activity has been observed in real-world incidents, such as those involving the Diavol ransomware. Defenders should monitor for suspicious command-line activity targeting Veeam credentials within MSSQL environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access to the target environment is gained through methods such as phishing or exploiting a vulnerability in a public-facing application.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance to identify the location of the Veeam MSSQL database server.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains valid credentials or exploits a vulnerability to gain access to the Veeam MSSQL database server.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003esqlcmd.exe\u003c/code\u003e or uses PowerShell commands (e.g., \u003ccode\u003eInvoke-Sqlcmd\u003c/code\u003e) to query the \u003ccode\u003e[VeeamBackup].[dbo].[Credentials]\u003c/code\u003e table.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the encrypted Veeam credentials from the database.\u003c/li\u003e\n\u003cli\u003eThe attacker decrypts the Veeam credentials using custom scripts or tools, potentially leveraging the Veeam backup server itself.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised Veeam credentials to access and delete or encrypt backup data.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys ransomware on the remaining systems, knowing that recovery from backups is now impossible.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process creation logging to capture command-line activity, specifically \u003ccode\u003esqlcmd.exe\u003c/code\u003e and PowerShell.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential Veeam Credential Access Command\u0026rdquo; to detect suspicious command executions targeting Veeam credentials in MSSQL databases.\u003c/li\u003e\n\u003cli\u003eReview and restrict access controls to the Veeam MSSQL database, ensuring only authorized personnel and services have access.\u003c/li\u003e\n\u003cli\u003eMonitor for unusual login activity and failed login attempts to the Veeam MSSQL database server.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for all accounts with access to Veeam infrastructure.\u003c/li\u003e\n\u003cli\u003eRegularly audit Veeam backup configurations and logs to identify any unauthorized modifications or access attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T12:00:00Z","date_published":"2024-07-03T12:00:00Z","id":"/briefs/2024-07-veeam-credential-access/","summary":"Attackers can leverage sqlcmd.exe or PowerShell commands like Invoke-Sqlcmd to access Veeam credentials stored in MSSQL databases, potentially targeting backups for destructive operations such as ransomware attacks.","title":"Potential Veeam Credential Access via SQL Commands","url":"https://feed.craftedsignal.io/briefs/2024-07-veeam-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["high"],"_cs_tags":["credential-access","pass-the-hash","ntlm-relay","powershell"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies PowerShell scripts containing artifacts indicative of NTLM relay or pass-the-hash (PtH) attacks. These techniques allow attackers to authenticate to systems without needing plaintext passwords, enabling lateral movement and privilege escalation. The rule focuses on identifying specific byte sequences and strings within PowerShell script blocks that suggest NTLM/SMB negotiation and credential access attempts. This detection helps defenders identify and respond to potential credential theft and abuse within their Windows environments. The rule is based on observed techniques used in various publicly available tools such as Invoke-TheHash, Check-LocalAdminHash, and PoshC2.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a PowerShell script on the compromised system. This script could be directly executed or obfuscated to evade initial detection.\u003c/li\u003e\n\u003cli\u003eThe PowerShell script attempts to perform NTLM relay or pass-the-hash attacks by utilizing specific byte sequences related to NTLM/SMB negotiation, such as \u003ccode\u003eNTLMSSPNegotiate\u003c/code\u003e or \u003ccode\u003e0x4e,0x54,0x4c,0x4d,0x53,0x53,0x50\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe script may utilize tools like Invoke-WMIExec or Invoke-SMBExec to execute commands on remote systems using the stolen credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to other systems on the network using the relayed credentials or password hashes.\u003c/li\u003e\n\u003cli\u003eSuccessful authentication allows the attacker to move laterally, accessing sensitive data or escalating privileges on other systems.\u003c/li\u003e\n\u003cli\u003eThe attacker may deploy additional payloads or establish persistence mechanisms for continued access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s goals and the network\u0026rsquo;s security posture. Organizations can experience significant financial and reputational damage due to data breaches and service disruptions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable PowerShell Script Block Logging to capture the necessary data for this detection. Refer to the setup instructions in the rule documentation for configuration details.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetecting Potential PowerShell Pass-the-Hash/Relay Scripts\u003c/code\u003e to your SIEM and tune it based on your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and access controls to limit the impact of lateral movement.\u003c/li\u003e\n\u003cli\u003eMonitor 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\u0026rsquo;s investigation notes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T12:00:00Z","date_published":"2024-07-03T12:00:00Z","id":"/briefs/2024-07-powershell-pth-relay/","summary":"This rule detects PowerShell scripts associated with NTLM relay or pass-the-hash tooling and SMB/NTLM negotiation artifacts, indicating potential credential access and lateral movement attempts by attackers.","title":"Detecting Potential PowerShell Pass-the-Hash/Relay Scripts","url":"https://feed.craftedsignal.io/briefs/2024-07-powershell-pth-relay/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","CrowdStrike FDR","SentinelOne Cloud Funnel","Sysmon"],"_cs_severities":["medium"],"_cs_tags":["credential-access","windows","wbadmin","ntds.dit"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eThis detection identifies the execution of \u003ccode\u003ewbadmin.exe\u003c/code\u003e with arguments indicative of an attempt to access and dump the NTDS.dit file from a Windows domain controller. Attackers with sufficient privileges, specifically those belonging to groups like Backup Operators, can abuse the legitimate \u003ccode\u003ewbadmin.exe\u003c/code\u003e utility to create a backup of the Active Directory database (NTDS.dit). This file contains sensitive credential information, and once obtained, attackers can extract password hashes and compromise the entire domain. This activity is often part of a larger attack aimed at gaining persistent access and control over the network. The Elastic detection rule was published on 2024-06-05 and last updated on 2026-05-04.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system within the target network. This may be achieved through phishing, exploiting vulnerabilities, or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to obtain membership in the Backup Operators group or a similar privileged group capable of running backups.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003ewbadmin.exe\u003c/code\u003e with the \u003ccode\u003erecovery\u003c/code\u003e argument, targeting the NTDS.dit file. The command line includes parameters to create a system state backup.\u003c/li\u003e\n\u003cli\u003eWbadmin creates a backup of the system state, including the NTDS.dit file, in a specified location.\u003c/li\u003e\n\u003cli\u003eThe attacker copies the NTDS.dit file from the backup location to a separate location for offline analysis.\u003c/li\u003e\n\u003cli\u003eThe attacker uses tools such as \u003ccode\u003entdsutil.exe\u003c/code\u003e or \u003ccode\u003esecretsdump.py\u003c/code\u003e to extract password hashes from the NTDS.dit file.\u003c/li\u003e\n\u003cli\u003eThe attacker cracks the password hashes or uses them in pass-the-hash attacks to gain access to other systems and resources within the domain.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves domain dominance and persistence, allowing them to control critical systems and data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation logging with command line arguments to detect \u003ccode\u003ewbadmin.exe\u003c/code\u003e execution as described in the Attack Chain (Data Source: Windows Security Event Logs, Sysmon).\u003c/li\u003e\n\u003cli\u003eImplement the provided Sigma rule to detect suspicious \u003ccode\u003ewbadmin.exe\u003c/code\u003e execution with NTDS.dit related arguments in your SIEM (Rule: NTDS Dump via Wbadmin).\u003c/li\u003e\n\u003cli\u003eMonitor and restrict membership in privileged groups like Backup Operators to minimize the risk of abuse (Reference: \u003ca href=\"https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960)\"\u003ehttps://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eReview and whitelist legitimate backup schedules or disaster recovery processes to reduce false positives (False positive analysis).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T10:00:00Z","date_published":"2024-07-03T10:00:00Z","id":"/briefs/2024-07-ntds-dump-wbadmin/","summary":"Attackers with Backup Operator privileges may abuse wbadmin.exe to access the NTDS.dit file, enabling credential dumping and domain compromise.","title":"NTDS Dump via Wbadmin","url":"https://feed.craftedsignal.io/briefs/2024-07-ntds-dump-wbadmin/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Endpoint Defense","Windows Defender Advanced Threat Protection","Symantec Endpoint Protection","Endpoint Security","AVDefender","Optics","Padvish AV"],"_cs_severities":["high"],"_cs_tags":["credential-access","regback","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Sophos","Microsoft","Trend Micro","Symantec","Bitdefender","N-able Technologies","Cylance","McAfee","Padvish"],"content_html":"\u003cp\u003eThis detection identifies suspicious attempts to access registry backup hives (SAM, SECURITY, and SYSTEM) located in the \u003ccode\u003eRegBack\u003c/code\u003e folder on Windows systems. These hives contain sensitive credential material, making them attractive targets for attackers seeking to compromise system security. The detection logic focuses on file access events, specifically successful file opens, while excluding known benign processes such as \u003ccode\u003etaskhostw.exe\u003c/code\u003e and various AV/EDR solutions (SophosScanCoordinator.exe, MsSense.exe, ccSvcHst.exe, etc.) to minimize false positives. The rule is designed to provide defenders with high-fidelity alerts when unauthorized access to these critical registry hives is detected. The scope includes any Windows system where endpoint file access logging is enabled.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system through various means.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access the \u003ccode\u003eSAM\u003c/code\u003e, \u003ccode\u003eSECURITY\u003c/code\u003e, or \u003ccode\u003eSYSTEM\u003c/code\u003e registry hives located in the \u003ccode\u003eC:\\\\Windows\\\\System32\\\\config\\\\RegBack\\\\\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eIf the attacker successfully opens the \u003ccode\u003eSAM\u003c/code\u003e and \u003ccode\u003eSYSTEM\u003c/code\u003e hives, they can extract user account credentials, including usernames, password hashes, and other sensitive information. The \u003ccode\u003eSECURITY\u003c/code\u003e hive is also useful.\u003c/li\u003e\n\u003cli\u003eThe attacker may stage the registry hive files by copying them to a different location on the system for further analysis or exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker uses credential dumping tools (e.g., Mimikatz, secretsdump.py) or custom scripts to extract credentials from the staged registry hives.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the extracted credentials to escalate privileges, move laterally within the network, or access sensitive data.\u003c/li\u003e\n\u003cli\u003eThe final objective is typically to gain unauthorized access to critical systems, steal sensitive data, or establish long-term persistence within the compromised environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s activities and the security posture of the targeted organization. Sectors commonly targeted include finance, healthcare, government, and critical infrastructure.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable file access monitoring for the \u003ccode\u003eC:\\\\Windows\\\\System32\\\\config\\\\RegBack\\\\\u003c/code\u003e directory to capture file open events.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eRegistry Hive Access via RegBack\u003c/code\u003e to your SIEM and tune the exclusions based on your environment.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eprocess_creation\u003c/code\u003e events for unusual processes accessing files in \u003ccode\u003eC:\\\\Windows\\\\System32\\\\config\\\\RegBack\\\\\u003c/code\u003e, using the rule \u003ccode\u003eSuspicious Process Accessing RegBack Hives\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging and file creation to activate the rules above.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-02T12:00:00Z","date_published":"2024-07-02T12:00:00Z","id":"/briefs/2024-07-regback-hive-access/","summary":"This rule detects attempts to access registry backup hives (SAM, SECURITY, SYSTEM) via RegBack on Windows systems, which can contain or enable access to credential material.","title":"Suspicious Registry Hive Access via RegBack","url":"https://feed.craftedsignal.io/briefs/2024-07-regback-hive-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["credential-access","windows","active-directory"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eActive Directory Integrated DNS (ADIDNS) is a core component of AD DS, storing DNS zones as AD objects. The default permission settings allow any authenticated user to create DNS-named records. This creates an opportunity for attackers to perform Dynamic Spoofing attacks by monitoring LLMNR/NBT-NS requests and creating DNS-named records to target systems or specific services like WPAD. This attack can enable credential access by redirecting traffic through attacker-controlled systems, leading to the capture of sensitive information. This activity is detectable by monitoring Windows event code 5137 related to DNS record creation and filtering out legitimate system accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a domain-joined system, possibly through compromised credentials or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker passively monitors LLMNR/NBT-NS broadcast traffic to identify systems being requested on the network.\u003c/li\u003e\n\u003cli\u003eUpon observing a request for a target system (e.g., WPAD), the attacker creates a DNS-named record in ADIDNS that resolves the target system\u0026rsquo;s name to an attacker-controlled IP address. This leverages the default permissions in ADIDNS that allow authenticated users to create DNS records.\u003c/li\u003e\n\u003cli\u003eWhen a legitimate user attempts to access the target system, the DNS query resolves to the attacker\u0026rsquo;s IP address.\u003c/li\u003e\n\u003cli\u003eThe user\u0026rsquo;s traffic is redirected to the attacker\u0026rsquo;s system.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts the user\u0026rsquo;s credentials or other sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker may relay captured credentials to other systems on the network.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves credential access and lateral movement within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Directory Service Changes\u0026rdquo; to generate the necessary Windows Security Event Logs (event code 5137) for detection.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eCreation of a DNS-Named Record\u003c/code\u003e to detect suspicious DNS record creation events.\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-22T12:00:00Z","date_published":"2024-05-22T12:00:00Z","id":"/briefs/2024-05-adidns-record-creation/","summary":"Detection of DNS record creation by non-system accounts within Active Directory Integrated DNS (ADIDNS), which attackers can abuse to perform Dynamic Spoofing attacks, potentially targeting services like WPAD for credential access.","title":"Suspicious DNS-Named Record Creation in Active Directory Integrated DNS","url":"https://feed.craftedsignal.io/briefs/2024-05-adidns-record-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory Integrated DNS (ADIDNS)"],"_cs_severities":["high"],"_cs_tags":["credential-access","adidns","windows","active-directory"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eActive Directory Integrated DNS (ADIDNS) stores DNS zones as Active Directory objects, which, while providing access control and replication benefits, introduces security issues. A significant concern is the creation of wildcard records due to the default permission allowing any authenticated user to create DNS-named records. By exploiting this, attackers can establish wildcard records to redirect traffic for domain names lacking explicit DNS records, effectively positioning themselves as an adversary-in-the-middle. This manipulation of ADIDNS can lead to credential interception or relay attacks, similar to LLMNR/NBNS spoofing. This poses a high risk to organizations relying on ADIDNS for domain consistency and secure name resolution.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker authenticates to the domain.\u003c/li\u003e\n\u003cli\u003eAttacker leverages existing privileges to create a wildcard DNS record (A record) within an ADIDNS zone.\u003c/li\u003e\n\u003cli\u003eThe wildcard record is created with a DN like \u003ccode\u003eDC=*,DC=example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=example,DC=com\u003c/code\u003e, where \u003ccode\u003eDC=*\u003c/code\u003e signifies the wildcard. Event ID 5137 is generated.\u003c/li\u003e\n\u003cli\u003eThe wildcard record points to a malicious server controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eA client attempts to resolve a domain name that does not have an explicit DNS record.\u003c/li\u003e\n\u003cli\u003eDue to the wildcard record, the DNS query resolves to the attacker\u0026rsquo;s malicious server.\u003c/li\u003e\n\u003cli\u003eThe client connects to the attacker\u0026rsquo;s server, potentially exposing credentials or other sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts or relays the client\u0026rsquo;s traffic, gaining unauthorized access or control.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Directory Service Changes\u0026rdquo; to generate the necessary Windows Security Event Logs (5137) for detecting ADIDNS wildcard record creation as described in the \u003ca href=\"https://ela.st/audit-directory-service-changes\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential ADIDNS Poisoning via Wildcard Record Creation\u0026rdquo; to detect the creation of wildcard DNS records in ADIDNS based on Windows Event ID 5137.\u003c/li\u003e\n\u003cli\u003eReview and restrict ADIDNS permissions for DNS zones to limit wildcard-creation opportunities, focusing on authenticated-user create-child rights.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on \u003ccode\u003ewinlog.event_data.ObjectDN\u003c/code\u003e, \u003ccode\u003euser.name\u003c/code\u003e, and the originating session as outlined in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-03T14:58:00Z","date_published":"2024-05-03T14:58:00Z","id":"/briefs/2024-05-adidns-wildcard/","summary":"Attackers can create wildcard records in Active Directory Integrated DNS (ADIDNS) to redirect traffic, enabling adversary-in-the-middle attacks for credential interception or relay.","title":"Potential ADIDNS Poisoning via Wildcard Record Creation","url":"https://feed.craftedsignal.io/briefs/2024-05-adidns-wildcard/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Veeam Backup"],"_cs_severities":["medium"],"_cs_tags":["credential-access","veeam","powershell"],"_cs_type":"advisory","_cs_vendors":["Veeam"],"content_html":"\u003cp\u003eThis detection identifies potential credential compromise attempts targeting Veeam Backup software. Attackers may attempt to load the Veeam.Backup.Common.dll library through unauthorized processes, such as PowerShell or unsigned executables, to decrypt and misuse stored credentials. These credentials can then be used to target backups, potentially leading to destructive operations like ransomware attacks. The rule focuses on flagging untrusted or unsigned processes loading the Veeam library, providing an indicator of possible malicious activity. The detection logic specifically looks for scenarios where PowerShell or other unusual processes load the Veeam backup library, which deviates from typical administrative or backup-related operations. This activity warrants further investigation to determine if it\u0026rsquo;s part of a credential access attempt.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system through unspecified means.\u003c/li\u003e\n\u003cli\u003eThe attacker uses PowerShell (powershell.exe, pwsh.exe, powershell_ise.exe) or another unsigned process to execute malicious commands.\u003c/li\u003e\n\u003cli\u003eThe malicious process attempts to load the Veeam.Backup.Common.dll library.\u003c/li\u003e\n\u003cli\u003eThe Veeam.Backup.Common.dll library is loaded into the process memory.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the loaded library to decrypt stored Veeam credentials.\u003c/li\u003e\n\u003cli\u003eUsing the decrypted credentials, the attacker gains access to Veeam backups.\u003c/li\u003e\n\u003cli\u003eThe attacker may then encrypt, delete, or exfiltrate the backups, leading to data loss or ransomware attacks.\u003c/li\u003e\n\u003cli\u003eThe attacker pivots to other systems using the compromised credentials, further expanding the attack.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s ability to recover from incidents, making it a critical target for attackers.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Veeam Backup Library Loaded by Unusual Process\u0026rdquo; to your SIEM to detect suspicious DLL loads (rule.name).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the process details and execution history to determine legitimacy (rule.description).\u003c/li\u003e\n\u003cli\u003eEnable process creation and library load logging to capture the necessary events for the Sigma rule to function correctly.\u003c/li\u003e\n\u003cli\u003eReview and enforce code signing policies to prevent unsigned processes from loading critical libraries like Veeam.Backup.Common.dll.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for Veeam accounts to mitigate the impact of credential compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-03T14:22:00Z","date_published":"2024-05-03T14:22:00Z","id":"/briefs/2024-05-veeam-credential-access/","summary":"Detects potential credential decryption operations by PowerShell or unsigned processes using the Veeam.Backup.Common.dll library, indicating potential credential access attempts to target backups as part of destructive operations.","title":"Veeam Backup Library Loaded by Unusual Process","url":"https://feed.craftedsignal.io/briefs/2024-05-veeam-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["aws","cloud","lateral-movement","credential-access"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe AWS GetSigninToken API, typically used for legitimate console access, can be abused by attackers to generate temporary, federated credentials. This technique, often facilitated by tools like \u003ccode\u003eaws_consoler\u003c/code\u003e, allows attackers to obfuscate the compromised access keys used to generate the tokens. By pivoting from the AWS CLI to console sessions with these temporary credentials, adversaries bypass MFA requirements and complicate forensic investigations. This activity is crucial for defenders to monitor, especially in environments not configured for AWS SSO, as it can indicate unauthorized access and lateral movement within the AWS infrastructure. The tool \u003ccode\u003eaws_consoler\u003c/code\u003e is specifically designed to automate this process, creating a streamlined path for malicious actors to leverage compromised credentials for further exploitation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to AWS environment using compromised credentials (access key, secret key).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials with the AWS CLI or SDK to call the \u003ccode\u003eGetSigninToken\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the \u003ccode\u003eGetSigninToken\u003c/code\u003e event with the event source \u003ccode\u003esignin.amazonaws.com\u003c/code\u003e and event name \u003ccode\u003eGetSigninToken\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eGetSigninToken\u003c/code\u003e API returns a temporary sign-in token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the temporary token along with the AWS account ID to construct a sign-in URL.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the AWS Management Console via the crafted URL, bypassing MFA if the original compromised credentials required it.\u003c/li\u003e\n\u003cli\u003eOnce in the console, the attacker performs reconnaissance, identifies valuable resources, and escalates privileges as needed.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the AWS environment, accessing and potentially exfiltrating sensitive data, or disrupting services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful abuse of the \u003ccode\u003eGetSigninToken\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect suspicious \u003ccode\u003eGetSigninToken\u003c/code\u003e events in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eGetSigninToken\u003c/code\u003e events originating from outside of expected AWS SSO user agents or other known legitimate sources.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for \u003ccode\u003eGetSigninToken\u003c/code\u003e events where the requesting user identity does not match expected patterns.\u003c/li\u003e\n\u003cli\u003eImplement and enforce MFA for all AWS IAM users, even though this attack bypasses it for console access using the temporary tokens.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM policies to adhere to the principle of least privilege, minimizing the potential impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T12:00:00Z","date_published":"2024-04-29T12:00:00Z","id":"/briefs/2024-04-aws-get-signin-token-abuse/","summary":"Adversaries may abuse the AWS GetSigninToken API to create temporary federated credentials for obfuscating compromised AWS access keys and pivoting to console sessions without MFA, potentially leading to lateral movement within the AWS environment.","title":"Potential Abuse of AWS Console GetSigninToken","url":"https://feed.craftedsignal.io/briefs/2024-04-aws-get-signin-token-abuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Bitbucket"],"_cs_severities":["medium"],"_cs_tags":["bitbucket","authentication","brute-force","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting user login failures within Bitbucket environments. Monitoring failed login attempts is crucial as it can indicate various malicious activities, including credential stuffing, brute-force attacks, or attempts to gain unauthorized initial access. The audit logs in Bitbucket record details of these authentication failures, providing valuable data for security monitoring. The rule provided detects these events and can be used for correlation with other security events based on the \u0026ldquo;author.name\u0026rdquo; field for enhanced accuracy and context. Requires \u0026ldquo;Advance\u0026rdquo; log level to receive audit events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access Attempt:\u003c/strong\u003e An attacker attempts to gain initial access to a Bitbucket account using a compromised or guessed username.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Guessing:\u003c/strong\u003e The attacker attempts to guess the user\u0026rsquo;s password through manual attempts or automated tools.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Failure:\u003c/strong\u003e Bitbucket records a \u0026ldquo;User login failed\u0026rdquo; event due to incorrect credentials. The \u003ccode\u003eauditType.category\u003c/code\u003e is Authentication, and \u003ccode\u003eauditType.action\u003c/code\u003e is User login failed.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMultiple Failed Attempts:\u003c/strong\u003e The attacker repeats the login attempts with different password variations or using a list of compromised credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Lockout (Optional):\u003c/strong\u003e Depending on Bitbucket\u0026rsquo;s configuration, repeated failed login attempts may trigger an account lockout.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccessful Login (Potential):\u003c/strong\u003e After multiple attempts, the attacker may eventually guess the correct password or use a valid compromised credential.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation/Persistence (If Successful):\u003c/strong\u003e If successful, the attacker could escalate privileges, establish persistence, or perform other malicious actions within the Bitbucket environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Bitbucket User Login Failure\u0026rdquo; to your SIEM to detect suspicious authentication failures (logsource: bitbucket, service: audit). Tune for your environment by correlating on the author.name field.\u003c/li\u003e\n\u003cli\u003eInvestigate the source IP addresses associated with the failed login attempts to identify potential malicious actors.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to significantly reduce the risk of successful credential-based attacks.\u003c/li\u003e\n\u003cli\u003eMonitor for unusual activity following any successful login after a series of failures.\u003c/li\u003e\n\u003cli\u003eEnforce strong password policies to reduce the effectiveness of brute-force attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-03-08T15:00:00Z","date_published":"2024-03-08T15:00:00Z","id":"/briefs/2024-03-bitbucket-login-fail/","summary":"Detection of Bitbucket user login failures, potentially indicating credential access attempts, initial access attempts, or other malicious activity.","title":"Bitbucket User Login Failure Detection","url":"https://feed.craftedsignal.io/briefs/2024-03-bitbucket-login-fail/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defender XDR","Elastic Defend","Sysmon"],"_cs_severities":["high"],"_cs_tags":["credential-access","netsh","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eAttackers often target wireless credentials to gain unauthorized network access. This involves using the legitimate Windows command-line tool \u003ccode\u003enetsh.exe\u003c/code\u003e to extract Wi-Fi passwords stored on a compromised system. By leveraging \u003ccode\u003enetsh\u003c/code\u003e, attackers can bypass traditional security measures and retrieve sensitive information without deploying custom malware. The technique involves specific command-line arguments that instruct \u003ccode\u003enetsh\u003c/code\u003e to display wireless keys in cleartext, exposing the network passwords. Defenders must monitor \u003ccode\u003enetsh\u003c/code\u003e command-line activity to identify potential credential access attempts. This activity can lead to lateral movement within the network.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a Windows system (e.g., via phishing or exploiting a software vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003enetsh.exe\u003c/code\u003e with specific arguments to list available wireless profiles.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target wireless profile from the list.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003enetsh.exe\u003c/code\u003e again, this time specifying the target profile and requesting the key to be displayed in cleartext using the \u003ccode\u003ekey=clear\u003c/code\u003e argument.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eNetsh.exe\u003c/code\u003e retrieves the Wi-Fi password from the Windows Wireless LAN service.\u003c/li\u003e\n\u003cli\u003eThe password is displayed in the command output, which the attacker captures.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the obtained Wi-Fi password to connect to the wireless network.\u003c/li\u003e\n\u003cli\u003eThe attacker can now perform lateral movement and access internal resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful credential dumping allows attackers to gain unauthorized access to wireless networks. This can lead to lateral movement within the organization\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Wireless Credential Dumping via Netsh\u003c/code\u003e to identify suspicious \u003ccode\u003enetsh.exe\u003c/code\u003e commands in your environment.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to capture the \u003ccode\u003enetsh.exe\u003c/code\u003e command-line arguments.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the process lineage and user context as outlined in the \u0026ldquo;Triage and analysis\u0026rdquo; section of the source.\u003c/li\u003e\n\u003cli\u003eImplement strong password policies for Wi-Fi networks, including the use of WPA2 or WPA3 encryption.\u003c/li\u003e\n\u003cli\u003eReview and restrict the use of \u003ccode\u003enetsh.exe\u003c/code\u003e on systems where it is not required, using application control solutions.\u003c/li\u003e\n\u003cli\u003eMonitor for related alerts indicating lateral movement, staging, remote access, or persistence, as mentioned in the \u0026ldquo;Triage and analysis\u0026rdquo; section of the source.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-30-wireless-creds-dumping/","summary":"Adversaries use the Windows built-in utility Netsh to dump Wireless saved access keys in clear text, potentially leading to credential compromise.","title":"Wireless Credential Dumping via Netsh","url":"https://feed.craftedsignal.io/briefs/2024-01-30-wireless-creds-dumping/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["CMS Backend"],"_cs_severities":["high"],"_cs_tags":["typo3","cleartext-password","credential-access","cve-2026-6553"],"_cs_type":"advisory","_cs_vendors":["TYPO3"],"content_html":"\u003cp\u003eTYPO3 CMS version 14.2.0 contains a vulnerability where user passwords are stored in cleartext within the \u003ccode\u003euc\u003c/code\u003e and \u003ccode\u003euser_settings\u003c/code\u003e fields of the \u003ccode\u003ebe_users\u003c/code\u003e database table. This issue arises due to the \u003ccode\u003eSetupModuleController\u003c/code\u003e incorrectly conflating entity data with user-interface settings during persistence. The vulnerability is triggered when backend users modify their credentials through the backend user settings module while using the affected TYPO3 version. This flaw, reported by Martin Clewing and addressed by the TYPO3 core team, poses a significant risk as it exposes user credentials to unauthorized access and potential compromise. Defenders should prioritize upgrading to TYPO3 version 14.3.0 LTS and executing the User Settings Scrubbing wizard.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to the TYPO3 backend, potentially through brute-force attacks or stolen credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the backend user settings module.\u003c/li\u003e\n\u003cli\u003eA legitimate user or the attacker changes their password within the module while the TYPO3 instance is running version 14.2.0.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eSetupModuleController\u003c/code\u003e processes the password change request.\u003c/li\u003e\n\u003cli\u003eInstead of properly hashing the password, the \u003ccode\u003eSetupModuleController\u003c/code\u003e stores it in cleartext in the \u003ccode\u003euc\u003c/code\u003e and \u003ccode\u003euser_settings\u003c/code\u003e fields of the \u003ccode\u003ebe_users\u003c/code\u003e database table.\u003c/li\u003e\n\u003cli\u003eAn attacker with database access can now retrieve the cleartext passwords from these fields.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to impersonate the user and gain access to sensitive data or perform unauthorized actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to TYPO3 version 14.3.0 LTS to address the underlying vulnerability (reference: Solution section).\u003c/li\u003e\n\u003cli\u003eExecute the User Settings Scrubbing wizard in the TYPO3 Install Tool to sanitize existing cleartext passwords in the \u003ccode\u003euc\u003c/code\u003e and \u003ccode\u003euser_settings\u003c/code\u003e fields (reference: Solution section).\u003c/li\u003e\n\u003cli\u003eRequire affected backend user accounts to reset their passwords immediately (reference: Solution section).\u003c/li\u003e\n\u003cli\u003eMonitor database access logs for suspicious activity, especially access to the \u003ccode\u003ebe_users\u003c/code\u003e table (reference: Attack Chain).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to detect potential unauthorized access attempts following password changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-typo3-cleartext-passwords/","summary":"TYPO3 CMS version 14.2.0 stores passwords in cleartext in the `uc` and `user_settings` fields of the `be_users` database table when users change their credentials in the backend user settings module.","title":"TYPO3 CMS 14.2.0 Stores Passwords in Cleartext","url":"https://feed.craftedsignal.io/briefs/2024-01-typo3-cleartext-passwords/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["credential-access","windows","vaultcmd"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers may abuse the Windows Credential Manager to list or dump credentials stored within. This allows for the exfiltration of saved usernames and passwords. The tool vaultcmd.exe can be used to interact with the Credential Manager and list the stored credentials. This activity is often performed in preparation for lateral movement within a compromised network. This detection focuses on identifying instances where vaultcmd.exe is executed with the \u003ccode\u003e/list*\u003c/code\u003e argument, indicating an attempt to enumerate stored credentials. The detection rule is designed to identify abuse of vaultcmd for credential access, enabling defenders to detect unauthorized credential access activities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system through various means (e.g., phishing, exploitation of a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003evaultcmd.exe\u003c/code\u003e with the \u003ccode\u003e/list\u003c/code\u003e argument to enumerate the credentials stored in the Windows Credential Manager.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003evaultcmd.exe\u003c/code\u003e process accesses the Credential Manager to retrieve the list of saved credentials.\u003c/li\u003e\n\u003cli\u003eThe output of \u003ccode\u003evaultcmd.exe\u003c/code\u003e (the list of credentials) is captured or redirected to a file for later exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker parses the output to identify valuable credentials, such as domain administrator accounts or service accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to authenticate to other systems on the network (lateral movement).\u003c/li\u003e\n\u003cli\u003eThe attacker elevates privileges on the target systems.\u003c/li\u003e\n\u003cli\u003eThe final objective is achieved, such as data theft or ransomware deployment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor process execution events for instances of \u003ccode\u003evaultcmd.exe\u003c/code\u003e being executed with the \u003ccode\u003e/list*\u003c/code\u003e argument (Data Source: Windows Security Event Logs, Sysmon, Microsoft Defender XDR, SentinelOne, Crowdstrike).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect VaultCmd Credential Listing\u0026rdquo; to your SIEM to identify potential credential access attempts.\u003c/li\u003e\n\u003cli\u003eInvestigate any identified instances of \u003ccode\u003evaultcmd.exe\u003c/code\u003e being executed with the \u003ccode\u003e/list*\u003c/code\u003e argument to determine the legitimacy of the activity.\u003c/li\u003e\n\u003cli\u003eReview and update endpoint protection configurations to ensure that similar threats are detected and blocked in the future.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-29-vaultcmd-credential-access/","summary":"Adversaries may use vaultcmd.exe to list credentials stored in the Windows Credential Manager to gain unauthorized access to saved usernames and passwords, potentially in preparation for lateral movement.","title":"VaultCmd Usage for Listing Windows Credentials","url":"https://feed.craftedsignal.io/briefs/2024-01-29-vaultcmd-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["credential-access","brute-force","password-spraying","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies potential password guessing or brute force activity against Windows systems. It focuses on detecting a high number of failed network logon attempts originating from a single source IP address within a short time frame. The rule analyzes Windows Security Event Logs, specifically looking for event category \u0026ldquo;authentication\u0026rdquo; and event action \u0026ldquo;logon-failed\u0026rdquo;. By aggregating failed authentication counts within a 60-second window and filtering out common authentication misconfiguration errors, the rule aims to pinpoint suspicious activity indicative of credential access attempts. This is important for defenders as it highlights potential breaches or malicious actors attempting to compromise user accounts via brute-force or password spraying attacks.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker initiates a network connection to a Windows system, likely targeting a service such as SMB or RDP.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate using a list of usernames and passwords or commonly used passwords, generating failed logon attempts (Event ID 4625).\u003c/li\u003e\n\u003cli\u003eThe Windows system logs the failed authentication attempts in the Security Event Log.\u003c/li\u003e\n\u003cli\u003eThe detection rule monitors the Security Event Log for failed logon events (event.category == \u0026ldquo;authentication\u0026rdquo; and event.action == \u0026ldquo;logon-failed\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe rule aggregates the number of failed logon attempts from the same source IP address within a 60-second time window.\u003c/li\u003e\n\u003cli\u003eIf the number of failed attempts exceeds a threshold (e.g., 100) and involves multiple target usernames (Esql.count_distinct_target_user_name \u0026gt;= 2), the rule triggers a detection.\u003c/li\u003e\n\u003cli\u003eThe attacker may continue attempts after initial failures or pivot to successful credentials for lateral movement.\u003c/li\u003e\n\u003cli\u003eSuccessful credential access can lead to privilege escalation, data exfiltration, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Logon to generate the necessary Windows Security Event Logs. Follow the setup instructions outlined in the rule documentation.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Multiple Logon Failure from the Same Source Address\u0026rdquo; 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.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts by examining the logon failure reason codes and the targeted user names as described in the rule\u0026rsquo;s investigation guide.\u003c/li\u003e\n\u003cli\u003eMonitor network connections from the source IP address for any suspicious outbound traffic or lateral movement activity.\u003c/li\u003e\n\u003cli\u003eReview and enforce strong password policies to mitigate the risk of successful brute-force attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-multiple-logon-failure/","summary":"Detection of multiple consecutive logon failures from the same source address within a short time interval on Windows systems, indicating potential brute force or password spraying attacks targeting multiple user accounts.","title":"Multiple Logon Failure from the Same Source Address","url":"https://feed.craftedsignal.io/briefs/2024-01-multiple-logon-failure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["aws","cloudtrail","initial-access","credential-access"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","Microsoft","MongoDB"],"content_html":"\u003cp\u003eThis detection identifies AWS identities that primarily use API traffic originating from well-known cloud providers (e.g., Amazon, Google, Microsoft), but also exhibit a small amount of traffic from less common Autonomous System (AS) organizations. This pattern can indicate that automation or CI credentials are being reused or pivoted outside of their usual hosted cloud environment. The detection focuses on successful API calls and looks for a combination of high volume from trusted cloud providers and at least one sensitive action originating from an uncommon network. This behavior could be indicative of credential compromise and lateral movement. This rule was published by Elastic on 2026-04-22.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to valid AWS credentials, potentially through phishing, credential stuffing, or exposed secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to make API calls from their own infrastructure, which is associated with a rare AS organization.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance, such as \u003ccode\u003eGetCallerIdentity\u003c/code\u003e, \u003ccode\u003eListBuckets\u003c/code\u003e, or \u003ccode\u003eListSecrets\u003c/code\u003e, to understand the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by calling \u003ccode\u003eAssumeRole\u003c/code\u003e, \u003ccode\u003eAttachUserPolicy\u003c/code\u003e, or \u003ccode\u003eCreateAccessKey\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access sensitive data using actions such as \u003ccode\u003eGetObject\u003c/code\u003e or \u003ccode\u003eGetSecretValue\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create new users or modify existing user profiles using actions such as \u003ccode\u003eCreateUser\u003c/code\u003e, \u003ccode\u003eUpdateLoginProfile\u003c/code\u003e, or \u003ccode\u003eAddUserToGroup\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to invoke cloud ML models using \u003ccode\u003eInvokeModel\u003c/code\u003e or \u003ccode\u003eConverse\u003c/code\u003e to further their objectives.\u003c/li\u003e\n\u003cli\u003eThe attacker persists in the environment by creating new IAM users, roles, or policies, or by modifying existing ones.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable AWS CloudTrail logging in all regions and send logs to a centralized SIEM or logging platform to enable detection capabilities (\u003ca href=\"https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html\"\u003ereferences\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Rare Source AS Organization Activity\u0026rdquo; translated from the provided ESQL query to detect unusual source ASNs for AWS API calls.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the rule, focusing on the \u003ccode\u003euser.name\u003c/code\u003e, \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e, \u003ccode\u003eEsql.src_asn_values\u003c/code\u003e, and \u003ccode\u003eEsql.untrusted_suspicious_actions\u003c/code\u003e to understand the context of the activity.\u003c/li\u003e\n\u003cli\u003eRotate credentials for the affected principal if abuse is suspected and enforce OIDC or short-lived keys for automation.\u003c/li\u003e\n\u003cli\u003eTighten IAM and data-plane permissions to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-29-aws-rare-asn/","summary":"This rule detects AWS identities with API traffic dominated by cloud-provider source AS organization labels, but also exhibit traffic from other AS organizations, potentially indicating credential reuse or pivoting.","title":"AWS Identity API Access from Rare ASN Organizations","url":"https://feed.craftedsignal.io/briefs/2024-01-29-aws-rare-asn/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["medium"],"_cs_tags":["kerberos","credential-access","as-rep-roasting","active-directory","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies instances where the Kerberos pre-authentication requirement is disabled for a user account within an Active Directory environment. Attackers with \u003ccode\u003eGenericWrite\u003c/code\u003e or \u003ccode\u003eGenericAll\u003c/code\u003e permissions over a target account can modify the \u003ccode\u003eUserAccountControl\u003c/code\u003e attribute to disable pre-authentication. This configuration weakens the account\u0026rsquo;s security posture, making it vulnerable to AS-REP roasting attacks, where attackers can request Kerberos tickets and crack the password offline. The activity is logged as Event ID 4738 in the Windows Security Event Logs, specifically when the \u003ccode\u003eNewUACList\u003c/code\u003e includes the \u003ccode\u003eUSER_DONT_REQUIRE_PREAUTH\u003c/code\u003e flag. This poses a significant risk, especially if applied to privileged accounts, as it allows adversaries to potentially compromise credentials and escalate privileges within the domain. The detection is based on research and recommendations from Microsoft regarding Kerberos security best practices.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker leverages their initial access to target a specific user account for which they intend to disable Kerberos pre-authentication.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Modification:\u003c/strong\u003e The attacker modifies the \u003ccode\u003eUserAccountControl\u003c/code\u003e attribute of the target user account, specifically disabling the \u0026ldquo;Do not require pre-authentication\u0026rdquo; setting (setting the \u003ccode\u003eUSER_DONT_REQUIRE_PREAUTH\u003c/code\u003e flag). This is often done using tools like \u003ccode\u003eActive Directory Users and Computers\u003c/code\u003e or PowerShell cmdlets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEvent Logging:\u003c/strong\u003e 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 \u003ccode\u003eNewUACList\u003c/code\u003e field in the event data contains \u003ccode\u003eUSER_DONT_REQUIRE_PREAUTH\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAS-REQ Request:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAS-REP Response:\u003c/strong\u003e The KDC issues an AS-REP (Authentication Service Response) to the attacker, containing an encrypted Ticket Granting Ticket (TGT) for the targeted user account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOffline Cracking:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit User Account Management\u0026rdquo; 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.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect Event ID 4738 events where the \u003ccode\u003eNewUACList\u003c/code\u003e contains \u003ccode\u003eUSER_DONT_REQUIRE_PREAUTH\u003c/code\u003e within your environment to identify potential AS-REP roasting vulnerabilities.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of disabled pre-authentication, especially on privileged accounts, following the triage steps outlined in the rule documentation.\u003c/li\u003e\n\u003cli\u003eEnforce 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.\u003c/li\u003e\n\u003cli\u003eMonitor for suspicious Kerberos authentication patterns and investigate any anomalies that might indicate AS-REP roasting attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-28T12:00:00Z","date_published":"2024-01-28T12:00:00Z","id":"/briefs/2024-01-28-kerberos-preauth-disabled/","summary":"Detection of Kerberos pre-authentication being disabled for a user account, potentially leading to AS-REP roasting and offline password cracking by attackers with GenericWrite or GenericAll rights over the account.","title":"Kerberos Pre-authentication Disabled for User Account","url":"https://feed.craftedsignal.io/briefs/2024-01-28-kerberos-preauth-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["PowerShell"],"_cs_severities":["high"],"_cs_tags":["credential-access","kerberos","powershell","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting PowerShell scripts designed to extract Kerberos tickets from memory. Attackers use these scripts to gain unauthorized access to credentials, which can then be leveraged for lateral movement within a network. The scripts achieve this by interacting with the Local Security Authority (LSA) and accessing Kerberos authentication packages. The observed PowerShell scripts utilize specific Kerberos ticket message types or dynamic Kerberos package lookup to enumerate and retrieve tickets. This behavior is often associated with post-exploitation activity, where attackers are attempting to escalate privileges or move laterally within a compromised environment. Defenders should monitor PowerShell activity for these patterns, as successful Kerberos ticket dumping can lead to significant security breaches. The scripts are not associated with any specific campaign or version.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes a PowerShell script.\u003c/li\u003e\n\u003cli\u003eThe PowerShell script uses \u003ccode\u003eLsaCallAuthenticationPackage\u003c/code\u003e to interact with the LSA.\u003c/li\u003e\n\u003cli\u003eThe script attempts to retrieve Kerberos tickets by using functions like \u003ccode\u003eKerbRetrieveEncodedTicketMessage\u003c/code\u003e, \u003ccode\u003eKerbQueryTicketCacheMessage\u003c/code\u003e, \u003ccode\u003eKerbQueryTicketCacheExMessage\u003c/code\u003e, or \u003ccode\u003eKerbRetrieveTicketMessage\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAlternatively, the script uses \u003ccode\u003eLsaLookupAuthenticationPackage\u003c/code\u003e to dynamically locate the Kerberos package.\u003c/li\u003e\n\u003cli\u003eThe script may then decrypt the ticket data using \u003ccode\u003eKerbDecryptDataMessage\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe script may attempt to serialize or export the extracted tickets to a file.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the dumped Kerberos tickets to impersonate users or services, gaining unauthorized access to resources and facilitating lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable PowerShell Script Block Logging to capture the malicious script content (as mentioned in the \u0026ldquo;Setup\u0026rdquo; section).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;PowerShell Kerberos Ticket Dump\u0026rdquo; to detect scripts exhibiting Kerberos ticket dumping behavior.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the reconstructed script block content and process lineage as outlined in the \u0026ldquo;Triage and analysis\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003eMonitor for file creation events related to ticket material exports (e.g., \u0026ldquo;.kirbi\u0026rdquo; files) to identify potential ticket dumping activity.\u003c/li\u003e\n\u003cli\u003eReview authentication events (event codes 4624, 4625, 4648) to identify suspicious logins originating from compromised systems.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"/briefs/2024-01-26-powershell-kerberos-dump/","summary":"Detection of PowerShell scripts attempting to dump Kerberos tickets from memory by accessing LSA authentication packages, potentially leading to credential access and lateral movement.","title":"PowerShell Kerberos Ticket Dumping via LSA Authentication Package Access","url":"https://feed.craftedsignal.io/briefs/2024-01-26-powershell-kerberos-dump/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["high"],"_cs_tags":["kerberos","coercion","dns","spn","spoofing","credential-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies potential Kerberos coercion attempts via DNS-based SPN spoofing on Windows systems. The technique abuses MicrosoftDNS records, specifically looking for directory-service access or creation events (event codes 4662 and 5137) involving a MicrosoftDNS record that contains a base64-encoded blob matching the pattern \u0026ldquo;UWhRCA\u0026hellip;BAAAA\u0026rdquo;. This blob pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, a known indicator of DNS-based SPN spoofing used in Kerberos coercion tradecraft. The goal is to detect adversaries coercing victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services. This activity is typically observed within Windows Security Event Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe adversary gains initial access to a system with privileges to modify DNS records in Active Directory.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new MicrosoftDNS record or modifies an existing one.\u003c/li\u003e\n\u003cli\u003eWithin the DNS record, specifically in the \u003ccode\u003eAdditionalInfo\u003c/code\u003e or \u003ccode\u003eObjectDN\u003c/code\u003e attributes, the attacker inserts a base64-encoded blob matching the pattern \u0026ldquo;UWhRCA\u0026hellip;BAAAA\u0026rdquo;. This blob contains a marshaled CREDENTIAL_TARGET_INFORMATION structure.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the DNS record to point to an attacker-controlled host. This involves manipulating the record\u0026rsquo;s name and associated IP address.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts the Kerberos authentication request.\u003c/li\u003e\n\u003cli\u003eThe attacker relays the Kerberos ticket to a legitimate service, impersonating the victim system.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the legitimate service using the relayed Kerberos ticket.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Directory Service Access\u0026rdquo; and \u0026ldquo;Audit Directory Service Changes\u0026rdquo; Windows audit policies to ensure relevant events are logged (Setup section).\u003c/li\u003e\n\u003cli\u003eDeploy 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.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on the associated user accounts, systems, and modified DNS records (rule titles).\u003c/li\u003e\n\u003cli\u003eRestrict access to modify DNS records in Active Directory to only authorized personnel and systems to prevent unauthorized manipulation (Overview section).\u003c/li\u003e\n\u003cli\u003eMonitor Windows Security authentication events for any suspicious Kerberos activity following the modification of DNS records (Attack Chain steps 5-8).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"/briefs/2024-01-kerberos-coercion-dns/","summary":"Adversaries may abuse MicrosoftDNS records containing a base64-encoded blob to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services, detected via directory-service access events.","title":"Potential Kerberos Coercion via DNS-Based SPN Spoofing","url":"https://feed.craftedsignal.io/briefs/2024-01-kerberos-coercion-dns/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","Windows Error Reporting"],"_cs_severities":["medium"],"_cs_tags":["credential-access","windows","lsass","wepw"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eThe LSASS Shtinkering attack involves abusing Windows Error Reporting (WER) to dump the memory of the LSASS process, which contains sensitive credentials. By enabling full user-mode dumps system-wide, attackers can fake a crash on LSASS, causing WER to generate a dump file. This setting is not enabled by default and requires modifying the registry. The DeepInstinct researchers publicized this attack at Defcon 30, demonstrating a method to access credentials without directly injecting malware into the LSASS process. This technique allows attackers to bypass traditional endpoint detection mechanisms that focus on malware signatures, making it a stealthy approach to credential theft. Defenders should monitor for registry modifications related to WER dump settings to detect and prevent this attack.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the system, potentially through phishing or exploitation of a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry key \u003ccode\u003eHKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType\u003c/code\u003e to the value \u003ccode\u003e2\u003c/code\u003e or \u003ccode\u003e0x00000002\u003c/code\u003e to enable full user-mode dumps system-wide.\u003c/li\u003e\n\u003cli\u003eThe attacker triggers a crash or fakes a crash of the LSASS process.\u003c/li\u003e\n\u003cli\u003eWindows Error Reporting (WER) generates a full user-mode dump file of the LSASS process.\u003c/li\u003e\n\u003cli\u003eThe dump file is stored in the location specified in the registry, typically \u003ccode\u003eC:\\ProgramData\\Microsoft\\Windows\\WER\\ReportQueue\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the generated dump file.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts credentials from the LSASS dump file using tools like Mimikatz or custom scripts.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to move laterally within the network or access sensitive resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Full User-Mode Dumps Enabled System-Wide\u0026rdquo; to your SIEM to detect suspicious registry modifications related to Windows Error Reporting (WER).\u003c/li\u003e\n\u003cli\u003eExamine process execution logs to identify any suspicious processes that may have triggered the dump, especially those not matching the legitimate \u003ccode\u003esvchost.exe\u003c/code\u003e process with user IDs \u003ccode\u003eS-1-5-18\u003c/code\u003e, \u003ccode\u003eS-1-5-19\u003c/code\u003e, or \u003ccode\u003eS-1-5-20\u003c/code\u003e as described in the rule\u0026rsquo;s investigation guide.\u003c/li\u003e\n\u003cli\u003eMonitor for access to WER dump files located in \u003ccode\u003eC:\\ProgramData\\Microsoft\\Windows\\WER\\ReportQueue\u003c/code\u003e using file monitoring rules.\u003c/li\u003e\n\u003cli\u003eReview and update endpoint protection configurations to ensure they can detect and block credential dumping techniques as mentioned in the rule\u0026rsquo;s response and remediation steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"/briefs/2024-01-26-lsass-shtinkering/","summary":"Attackers can enable full user-mode dumps system-wide via registry modification to facilitate LSASS credential dumping, allowing extraction of credentials from process memory without deploying malware.","title":"LSASS Credential Dumping via Windows Error Reporting (WER) Abuse","url":"https://feed.craftedsignal.io/briefs/2024-01-26-lsass-shtinkering/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["high"],"_cs_tags":["credential-access","privilege-escalation","windows","active-directory"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe DCSync attack is a technique used to retrieve credential information from Active Directory, potentially leading to complete domain compromise. This attack involves initiating the Active Directory replication process, which is normally reserved for domain controllers. This detection identifies user accounts initiating this process for the first time, which can be an indicator of malicious activity. This activity is detected via Windows Security Event Logs and focuses on the identification of the initial use of replication protocols. Attackers exploit this to steal credentials or sensitive data stored within the Active Directory. This technique can be used to escalate privileges and move laterally within the network, eventually leading to data exfiltration or other malicious objectives.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system within the target network.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to obtain the necessary rights to perform DCSync. This may involve exploiting vulnerabilities or using stolen credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a tool like Mimikatz or custom scripts to initiate the Active Directory replication process.\u003c/li\u003e\n\u003cli\u003eThe tool requests replication of directory data, specifically targeting credential information. This involves using the \u003ccode\u003eDS-Replication-Get-Changes\u003c/code\u003e or similar replication-right GUIDs.\u003c/li\u003e\n\u003cli\u003eThe Active Directory server responds by providing the requested data, which includes password hashes and other sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the credential information from the replicated data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the extracted credentials to move laterally within the network and access other systems or data.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration, ransomware deployment, or long-term persistence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Directory Service Access\u0026rdquo; to generate the necessary Windows Security Event Logs (event code 4662) as described in the \u003ca href=\"https://ela.st/audit-directory-service-access\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect First Time DCSync Activity\u0026rdquo; to your SIEM and tune for your environment to identify suspicious DCSync behavior.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the \u003ccode\u003eSubjectUserSid\u003c/code\u003e, \u003ccode\u003eSubjectUserName\u003c/code\u003e, \u003ccode\u003eProperties\u003c/code\u003e, \u003ccode\u003eAccessMask\u003c/code\u003e, and \u003ccode\u003ecomputer_name\u003c/code\u003e fields in the Windows Security Event Logs.\u003c/li\u003e\n\u003cli\u003eMonitor for changes to Active Directory object permissions (5136 events) that could grant unauthorized users DCSync capabilities as outlined in the triage and analysis steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-25T12:00:00Z","date_published":"2024-01-25T12:00:00Z","id":"/briefs/2024-01-25-dcsync-new-account/","summary":"Detection of a user account initiating the Active Directory replication process for the first time, potentially indicating a DCSync attack for credential theft and domain compromise.","title":"First Time Seen Account Performing DCSync","url":"https://feed.craftedsignal.io/briefs/2024-01-25-dcsync-new-account/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["exfiltration","credential-access","windows","smb","ntlm"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne"],"content_html":"\u003cp\u003eThis detection strategy focuses on identifying unusual Server Message Block (SMB) traffic that originates from internal IP addresses and connects to external networks. The SMB protocol, commonly used for file and printer sharing within a network, can be exploited to exfiltrate data by injecting rogue UNC paths to capture NTLM credentials. This activity is often associated with threat actors attempting to steal credentials for lateral movement or data exfiltration. Defenders should be aware of this technique as it allows adversaries to bypass traditional security controls by leveraging a legitimate protocol for malicious purposes. This detection is relevant for environments utilizing Windows operating systems and SMB for internal network communications. The goal is to identify and alert on SMB connections to external IPs, excluding known safe ranges and legitimate business applications.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an internal system via phishing or other means (not detailed in source).\u003c/li\u003e\n\u003cli\u003eThe attacker injects a rogue UNC path into a document, email, or other medium.\u003c/li\u003e\n\u003cli\u003eA user opens the malicious document or clicks the injected link, triggering an SMB connection to a malicious external server.\u003c/li\u003e\n\u003cli\u003eThe SMB connection attempts to authenticate with the user\u0026rsquo;s NTLM credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker captures the NTLM hash from the authentication attempt.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to crack the NTLM hash to obtain the user\u0026rsquo;s password.\u003c/li\u003e\n\u003cli\u003eUsing the cracked password, the attacker gains unauthorized access to other systems and resources on the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect SMB Connection to External IP\u0026rdquo; 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.\u003c/li\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to restrict SMB traffic to only necessary internal communications, reducing the attack surface and mitigating the risk of external exposure.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-25T12:00:00Z","date_published":"2024-01-25T12:00:00Z","id":"/briefs/2024-01-rare-smb-exfiltration/","summary":"This brief details a detection strategy for rare SMB connections originating from internal networks to the internet, potentially indicating NTLM credential theft via rogue UNC path injection.","title":"Detecting Rare SMB Connections for Potential NTLM Credential Theft","url":"https://feed.craftedsignal.io/briefs/2024-01-rare-smb-exfiltration/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Endgame","Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Sysmon","Windows Security Event Logs","Crowdstrike"],"_cs_severities":["high"],"_cs_tags":["credential-access","registry-dump","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThis detection identifies attempts to export registry hives containing sensitive credential information using the Windows \u003ccode\u003ereg.exe\u003c/code\u003e utility. Attackers may target the \u003ccode\u003eHKLM\\SAM\u003c/code\u003e and \u003ccode\u003eHKLM\\SECURITY\u003c/code\u003e hives to extract stored credentials, including password hashes and LSA secrets. The activity is often part of a broader credential access campaign. The rule focuses on detecting the execution of \u003ccode\u003ereg.exe\u003c/code\u003e with specific arguments indicating an attempt to save or export these critical registry hives. The use of \u003ccode\u003ereg.exe\u003c/code\u003e makes this technique accessible to various threat actors, including ransomware groups and nation-state actors. Defenders need to monitor for this activity to prevent unauthorized credential access and potential lateral movement within the network. This rule specifically looks for \u0026ldquo;save\u0026rdquo; and \u0026ldquo;export\u0026rdquo; arguments targeting SAM and SECURITY hives.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003ereg.exe\u003c/code\u003e from the command line or through a script.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ereg.exe\u003c/code\u003e command includes arguments to save or export registry hives.\u003c/li\u003e\n\u003cli\u003eThe target registry hives are \u003ccode\u003eHKLM\\SAM\u003c/code\u003e and \u003ccode\u003eHKLM\\SECURITY\u003c/code\u003e, containing sensitive credential information.\u003c/li\u003e\n\u003cli\u003eThe exported registry hive is saved to a file on disk or a network share.\u003c/li\u003e\n\u003cli\u003eThe attacker may compress or encrypt the exported registry hive to evade detection.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the exported registry hive for offline analysis.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts credential information from the registry hive, such as password hashes and LSA secrets, to use in lateral movement or privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation auditing with command line arguments to capture the execution of \u003ccode\u003ereg.exe\u003c/code\u003e with relevant arguments. (\u003ca href=\"https://ela.st/audit-process-creation\"\u003eData Source: Windows Security Event Logs, Sysmon\u003c/a\u003e)\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Registry Hive Export via Reg.exe\u003c/code\u003e to your SIEM to detect the execution of \u003ccode\u003ereg.exe\u003c/code\u003e with arguments indicative of registry hive dumping.\u003c/li\u003e\n\u003cli\u003eImplement access controls and monitor file system activity to detect unauthorized access or modification of registry hive files.\u003c/li\u003e\n\u003cli\u003eReview and restrict the use of \u003ccode\u003ereg.exe\u003c/code\u003e to authorized personnel and processes.\u003c/li\u003e\n\u003cli\u003eMonitor for parent processes of \u003ccode\u003ereg.exe\u003c/code\u003e that are unusual or unexpected, which might indicate malicious activity.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by reviewing the process command line, parent process, and destination of the exported registry hive.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-24T12:00:00Z","date_published":"2024-01-24T12:00:00Z","id":"/briefs/2024-01-24-registry-hive-dump/","summary":"Detects attempts to export sensitive Windows registry hives (SAM/SECURITY) using reg.exe, potentially leading to credential compromise.","title":"Credential Acquisition via Registry Hive Dumping","url":"https://feed.craftedsignal.io/briefs/2024-01-24-registry-hive-dump/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["low"],"_cs_tags":["okta","identity","user-creation","credential-access"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis alert detects the creation of new user accounts within an Okta environment. While legitimate user creation is common, malicious actors may create accounts to gain unauthorized access to resources, escalate privileges, or establish persistence within the network. Monitoring for anomalous user creation activity, such as accounts created outside of normal business hours or with suspicious naming conventions, is crucial for identifying potential security breaches. Reviewing the source IP and administrator account used for the user creation can also provide valuable context.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta administrator account, potentially through phishing, credential stuffing, or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Okta admin portal.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the user management section within the Okta admin console.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new user account, potentially mimicking an existing user or using a generic naming convention.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns the new user account specific roles and permissions, potentially granting elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the newly created account to access sensitive applications and data within the Okta-protected environment.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised or newly created account to maintain persistence within the Okta environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;New Okta User Created\u0026rdquo; to your SIEM to detect user creation events and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected user creation events for legitimacy, focusing on the source IP address and the administrator account used.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta administrator accounts to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview Okta event logs regularly for suspicious activity, including user creation, permission changes, and application access.\u003c/li\u003e\n\u003cli\u003eEstablish baseline user creation patterns to identify anomalous behavior, such as accounts created outside of normal business hours.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-23-okta-user-created/","summary":"Detection of new user account creation in Okta, which could indicate malicious activity related to credential access.","title":"Okta User Account Created","url":"https://feed.craftedsignal.io/briefs/2024-01-23-okta-user-created/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory","Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["credential-access","privilege-escalation","collection","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies attempts to access sensitive attributes within Active Directory via the Lightweight Directory Access Protocol (LDAP). These attributes, including \u003ccode\u003eunixUserPassword\u003c/code\u003e, \u003ccode\u003ems-PKI-AccountCredentials\u003c/code\u003e, and \u003ccode\u003emsPKI-CredentialRoamingTokens\u003c/code\u003e, are valuable targets for adversaries aiming to steal credentials or escalate privileges. The rule focuses on Windows Security Event Logs, specifically monitoring event code 4662 which indicates an attempt to access an object. By filtering out common benign access patterns, such as those originating from the SYSTEM account or using specific access masks, the rule aims to highlight potentially malicious activity that warrants further investigation. The original rule was created in November 2022 and updated in May 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system within the target domain (e.g., through phishing or exploiting a public-facing application).\u003c/li\u003e\n\u003cli\u003eThe attacker uses valid credentials or exploits a vulnerability to authenticate to the domain.\u003c/li\u003e\n\u003cli\u003eThe attacker uses LDAP queries to enumerate Active Directory objects.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts specific LDAP queries to target sensitive attributes like \u003ccode\u003eunixUserPassword\u003c/code\u003e, \u003ccode\u003ems-PKI-AccountCredentials\u003c/code\u003e, or \u003ccode\u003emsPKI-CredentialRoamingTokens\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWindows Security Event 4662 is generated, logging the access attempt with details about the user, accessed object, and properties.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the accessed attribute data, potentially containing password hashes, certificates, or other sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials or certificates to impersonate other users or gain elevated privileges within the domain.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Access to Sensitive LDAP Attributes\u0026rdquo; to your SIEM to detect access attempts to critical AD attributes (rule.name).\u003c/li\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Directory Service Access\u0026rdquo; to ensure that necessary Windows Security Event Logs (event code 4662) are generated for the Sigma rule to function (setup).\u003c/li\u003e\n\u003cli\u003eReview and tune the \u0026ldquo;Access to Sensitive LDAP Attributes\u0026rdquo; Sigma rule, creating exceptions for legitimate administrative accounts and scheduled system processes to minimize false positives (rule.note).\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls and permissions for sensitive LDAP attributes within Active Directory to restrict access to only necessary personnel (rule.note).\u003c/li\u003e\n\u003cli\u003eInvestigate 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).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-19T16:23:00Z","date_published":"2024-01-19T16:23:00Z","id":"/briefs/2024-01-ldap-attribute-access/","summary":"This rule detects unauthorized access to sensitive Active Directory object attributes such as unixUserPassword, ms-PKI-AccountCredentials, and msPKI-CredentialRoamingTokens, potentially leading to credential theft and privilege escalation.","title":"Detection of Sensitive LDAP Attribute Access","url":"https://feed.craftedsignal.io/briefs/2024-01-ldap-attribute-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","privilege-escalation","credential-access","persistence","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe unauthorized removal of a Conditional Access (CA) policy in Azure Active Directory can significantly weaken an organization\u0026rsquo;s security posture. Conditional Access policies are critical for enforcing multi-factor authentication, device compliance, and other security controls based on user, location, device, and application conditions. When a non-approved actor removes such a policy, it can open the door for privilege escalation, credential access, and persistence by malicious actors. This activity is often performed after an initial compromise to disable security controls and move laterally within the environment. Identifying and responding to such removals promptly is essential to maintain a strong security posture.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial 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.\u003c/li\u003e\n\u003cli\u003ePrivilege 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.\u003c/li\u003e\n\u003cli\u003eDiscovery: 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.\u003c/li\u003e\n\u003cli\u003eDefense Evasion: The attacker disables or modifies logging configurations to reduce the likelihood of detection.\u003c/li\u003e\n\u003cli\u003ePolicy Removal: The attacker removes the targeted Conditional Access policy using the Azure portal, PowerShell, or the Azure CLI. The audit logs will record a \u0026ldquo;Delete conditional access policy\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eCredential 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.\u003c/li\u003e\n\u003cli\u003ePersistence: The attacker establishes persistence by creating new user accounts or modifying existing ones to maintain access even if their initial entry point is discovered.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker leverages the compromised credentials and weakened security controls to move laterally to other systems and resources within the organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect the \u0026ldquo;Delete conditional access policy\u0026rdquo; event in Azure audit logs, indicating a CA policy removal.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Azure Active Directory role assignments to minimize the risk of unauthorized privilege escalation.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for all user accounts, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for unusual activity, such as changes to user accounts, role assignments, and Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of CA policy removal to determine the scope of the compromise and take appropriate remediation steps.\u003c/li\u003e\n\u003cli\u003eReview and harden Conditional Access policies to ensure they are effectively protecting critical resources and applications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T15:00:00Z","date_published":"2024-01-09T15:00:00Z","id":"/briefs/2024-01-09-azure-ca-policy-removal/","summary":"An unauthorized actor removes a Conditional Access policy in Azure, potentially weakening the organization's security posture and enabling privilege escalation or credential access.","title":"Unauthorized Removal of Azure Conditional Access Policy","url":"https://feed.craftedsignal.io/briefs/2024-01-09-azure-ca-policy-removal/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["high"],"_cs_tags":["credential-access","powershell","ninjacopy"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eInvoke-NinjaCopy is a PowerShell script used to perform direct volume file access, enabling attackers to bypass traditional file access controls. This technique allows reading locked system files, such as the NTDS.dit or registry hives, which are essential for credential dumping. The script, often incorporated into post-exploitation frameworks like Empire, leverages stealth functions to minimize detection. Defenders need to monitor PowerShell script block content for the presence of Invoke-NinjaCopy or related \u0026ldquo;Stealth*\u0026rdquo; functions to identify potential credential access attempts. This activity is typically observed in Windows environments where attackers attempt to escalate privileges or move laterally within a network. The use of NinjaCopy allows attackers to grab sensitive data without being blocked by standard security measures.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a PowerShell script, either directly or through a command-line interface.\u003c/li\u003e\n\u003cli\u003eThe PowerShell script contains the Invoke-NinjaCopy function or related StealthReadFile, StealthOpenFile functions.\u003c/li\u003e\n\u003cli\u003eThe script utilizes the StealthOpenFile function to directly access the volume where the target file resides (e.g., NTDS.dit).\u003c/li\u003e\n\u003cli\u003eStealthReadFile is used to read the contents of the target file, bypassing standard file access controls.\u003c/li\u003e\n\u003cli\u003eThe script copies the contents of the NTDS.dit or registry hives to a temporary location.\u003c/li\u003e\n\u003cli\u003eThe attacker dumps credentials from the copied NTDS.dit file using tools like secretsdump.py or other credential harvesting tools.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the harvested credentials to escalate privileges or move laterally within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable PowerShell Script Block Logging and monitor event ID 4104 for script content containing \u003ccode\u003eInvoke-NinjaCopy\u003c/code\u003e, \u003ccode\u003eStealthReadFile\u003c/code\u003e, \u003ccode\u003eStealthOpenFile\u003c/code\u003e, \u003ccode\u003eStealthCloseFileDelegate\u003c/code\u003e as described in the Overview.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;PowerShell Invoke-NinjaCopy script\u0026rdquo; to your SIEM and tune the rule for false positives in your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any PowerShell processes with command-line arguments that contain the identified keywords to identify potential attacker activity as outlined in the Attack Chain.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls on sensitive files like \u003ccode\u003eNTDS.dit\u003c/code\u003e and registry hives to limit the impact of successful credential access attempts.\u003c/li\u003e\n\u003cli\u003eReview PowerShell execution policies to prevent the execution of unsigned or untrusted scripts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T14:27:00Z","date_published":"2024-01-09T14:27:00Z","id":"/briefs/2024-01-09-invoke-ninjacopy/","summary":"The Invoke-NinjaCopy PowerShell script is used by attackers to directly access volume files, such as NTDS.dit or registry hives, for credential dumping.","title":"PowerShell Invoke-NinjaCopy Script Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-09-invoke-ninjacopy/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["high"],"_cs_tags":["ntlm-relay","credential-access","windows","webdav"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThis detection identifies attempts to coerce local NTLM authentication over HTTP through WebDAV named-pipe paths, focusing on Print Spooler and SRVSVC. Attackers can exploit this vulnerability, often combined with tools like NTLMRelay2Self, PetitPotam, or modified versions of krbrelayx\u0026rsquo;s printerbug.py, to relay the obtained credentials and escalate their privileges within the network. This technique allows attackers to bypass traditional security measures by leveraging legitimate Windows protocols for malicious purposes. Successful exploitation can lead to domain dominance and unauthorized access to sensitive resources. This activity is often associated with post-exploitation activity following initial access via other means.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003erundll32.exe\u003c/code\u003e to load \u003ccode\u003edavclnt.dll\u003c/code\u003e using the \u003ccode\u003eDavSetCookie\u003c/code\u003e function.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003erundll32.exe\u003c/code\u003e process is invoked with arguments specifying a named pipe path over HTTP, such as \u003ccode\u003ehttp*/print/pipe/*\u003c/code\u003e, \u003ccode\u003ehttp*/pipe/spoolss\u003c/code\u003e, or \u003ccode\u003ehttp*/pipe/srvsvc\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe system attempts to authenticate to the specified HTTP endpoint using NTLM.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts the NTLM authentication request.\u003c/li\u003e\n\u003cli\u003eUsing a relay tool like NTLMRelay2Self or ntlmrelayx, the attacker relays the captured NTLM credentials to another service or machine.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the relayed credentials to escalate privileges or gain unauthorized access to network resources.\u003c/li\u003e\n\u003cli\u003eThe attacker may then perform lateral movement, data exfiltration, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential Local NTLM Relay via HTTP\u0026rdquo; to your SIEM to detect the execution of \u003ccode\u003erundll32.exe\u003c/code\u003e with specific arguments indicative of NTLM relay attempts.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to ensure the necessary data is available for the Sigma rule to function correctly.\u003c/li\u003e\n\u003cli\u003eMonitor network connections originating from processes that load \u003ccode\u003edavclnt.dll\u003c/code\u003e to identify potential NTLM relay traffic.\u003c/li\u003e\n\u003cli\u003eInvestigate and block the usage of tools like NTLMRelay2Self, PetitPotam, and ntlmrelayx within the environment.\u003c/li\u003e\n\u003cli\u003eImplement mitigations for NTLM relay attacks, such as enabling Extended Protection for Authentication (EPA) and disabling NTLM where possible.\u003c/li\u003e\n\u003cli\u003eReview and restrict the usage of WebClient service and Print Spooler service where not required.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T14:00:00Z","date_published":"2024-01-09T14:00:00Z","id":"/briefs/2024-01-ntlm-relay-http/","summary":"Adversaries may coerce local NTLM authentication over HTTP via WebDAV named-pipe paths (Print Spooler, SRVSVC), then relay credentials to elevate privileges.","title":"Potential Local NTLM Relay via HTTP","url":"https://feed.craftedsignal.io/briefs/2024-01-ntlm-relay-http/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Security Event Logs"],"_cs_severities":["medium"],"_cs_tags":["credential-access","brute-force","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule focuses on identifying brute-force or password guessing attacks against Windows systems. It detects multiple failed logon attempts originating from the same source IP address, followed by a successful logon. This pattern suggests an attacker attempting to guess credentials to gain unauthorized access to an account. The rule leverages Windows Security Event Logs to monitor authentication events. This activity is important for defenders because successful brute-force attacks can lead to account compromise, data breaches, and further malicious activities within the network. The rule uses EQL and analyzes \u003ccode\u003elogs-system.security*\u003c/code\u003e, \u003ccode\u003elogs-windows.forwarded*\u003c/code\u003e, and \u003ccode\u003ewinlogbeat-*\u003c/code\u003e indices.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eAfter several failed attempts, the attacker guesses the correct password for a valid user account.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access to the target system using the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to escalate privileges or move laterally within the network, using the compromised account to access additional resources or systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Audit Logon to generate the necessary events (4624, 4625) in the Windows Security Event Logs for the detection rule to function. Reference: \u003ca href=\"https://ela.st/audit-logon\"\u003ehttps://ela.st/audit-logon\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy 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.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts to determine the scope of the compromise and take appropriate remediation steps.\u003c/li\u003e\n\u003cli\u003eConsider implementing multi-factor authentication (MFA) to mitigate the risk of brute-force attacks.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious activity originating from the source IP address associated with the brute-force attempts.\u003c/li\u003e\n\u003cli\u003eReview and enforce strong password policies to reduce the likelihood of successful password guessing.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T14:00:00Z","date_published":"2024-01-09T14:00:00Z","id":"/briefs/2024-01-09-multiple-logon-failure-success/","summary":"This rule identifies potential password guessing/brute force activity from a single address, followed by a successful logon, indicating that an attacker may have compromised an account by brute-forcing login attempts across multiple users.","title":"Multiple Logon Failure Followed by Logon Success","url":"https://feed.craftedsignal.io/briefs/2024-01-09-multiple-logon-failure-success/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["high"],"_cs_tags":["credential-access","lsass","seclogon","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat leverages the Windows Secondary Logon service (seclogon.dll) to gain unauthorized access to the Local Security Authority Subsystem Service (LSASS) process. The attack involves manipulating the seclogon service to leak an LSASS handle, which can then be used to extract credentials. This technique is often employed as a precursor to credential dumping and lateral movement within a compromised network. The detection focuses on identifying specific call traces to seclogon.dll coupled with suspicious access rights (0x14c0) when accessing LSASS, originating from svchost.exe. Defenders should monitor for this activity as it indicates a potential attempt to compromise sensitive credentials stored within LSASS memory.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the system (e.g., via phishing or exploitation of a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes code within the context of a user account.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the Secondary Logon service (seclogon.dll) to request access to LSASS.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe seclogon service, acting on behalf of the attacker, grants access to LSASS.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the leaked LSASS handle to read memory contents.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts sensitive information, such as user credentials (passwords, NTLM hashes, Kerberos tickets), from the LSASS memory.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials for lateral movement, privilege escalation, or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process creation logging (event ID 1) and process access logging (event ID 10) to detect suspicious LSASS handle access.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious Lsass Handle Access via MalSecLogon\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the call trace, access rights, and source process.\u003c/li\u003e\n\u003cli\u003eMonitor authentication events for signs of credential misuse following suspicious LSASS access.\u003c/li\u003e\n\u003cli\u003eReview local administrator and debug-privilege exposure, LSASS protection such as RunAsPPL or Credential Guard where supported, and Secondary Logon service necessity on critical servers\u003c/li\u003e\n\u003cli\u003eBlock the GrantedAccess value \u0026ldquo;0x14c0\u0026rdquo; in conjunction with CallTrace \u0026ldquo;\u003cem\u003eseclogon.dll\u003c/em\u003e\u0026rdquo; when the TargetImage is \u0026ldquo;lsass.exe\u0026rdquo; (Sysmon Event ID 10).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"/briefs/2024-01-mal-seclogon-lsass/","summary":"An attacker abuses the Secondary Logon service (seclogon.dll) to gain unauthorized access to the LSASS process, potentially leaking credentials.","title":"Suspicious LSASS Access via Malicious Secondary Logon Service","url":"https://feed.craftedsignal.io/briefs/2024-01-mal-seclogon-lsass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["credential-access","lsass","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eThis rule identifies attempts to access the LSASS process via Windows API calls, specifically \u003ccode\u003eOpenProcess\u003c/code\u003e, \u003ccode\u003eOpenThread\u003c/code\u003e, and \u003ccode\u003eReadProcessMemory\u003c/code\u003e. The Local Security Authority Subsystem Service (LSASS) is a critical Windows component responsible for managing user authentication and security policies. Attackers often target LSASS to dump credentials from memory for lateral movement and privilege escalation. This detection focuses on identifying unusual processes attempting to access the LSASS process, excluding common legitimate applications and directories. The rule leverages data from Elastic Defend and Microsoft Defender XDR to identify suspicious activity and provide defenders with actionable alerts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the target system through various means.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges to gain administrative rights.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a custom tool or script to call the \u003ccode\u003eOpenProcess\u003c/code\u003e, \u003ccode\u003eOpenThread\u003c/code\u003e or \u003ccode\u003eReadProcessMemory\u003c/code\u003e Windows APIs.\u003c/li\u003e\n\u003cli\u003eThe tool targets the \u003ccode\u003elsass.exe\u003c/code\u003e process to obtain a handle for memory access.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the obtained handle to read LSASS memory, searching for credential data.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts usernames, passwords, and other sensitive information from the dumped memory.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials for lateral movement to other systems on the network.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, which may include data exfiltration or system compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;LSASS API Access by Non-Standard Process\u0026rdquo; to your SIEM and tune for your environment to detect suspicious access to the LSASS process.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by this rule, focusing on the process execution chain and the access rights requested as documented in the provided Microsoft documentation.\u003c/li\u003e\n\u003cli\u003eEnable process creation and API call logging via Elastic Defend or Microsoft Defender XDR to provide the necessary data for this detection.\u003c/li\u003e\n\u003cli\u003eReview and harden LSASS protection mechanisms such as Credential Guard to minimize the risk of successful credential dumping.\u003c/li\u003e\n\u003cli\u003eImplement the Osquery queries to gather system information like DNS cache, services, and unsigned executables, to aid in investigation and threat hunting.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"/briefs/2024-01-lsass-process-access/","summary":"Detection of access attempts to the LSASS handle, indicating potential credential dumping by monitoring API calls (OpenProcess, OpenThread, ReadProcessMemory) targeting lsass.exe.","title":"LSASS Process Access via Windows API","url":"https://feed.craftedsignal.io/briefs/2024-01-lsass-process-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","lsass","process-injection"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies the creation of an LSASS process clone via \u003ccode\u003ePssCaptureSnapShot\u003c/code\u003e on Windows systems. The rule focuses on scenarios where the parent process of the new LSASS instance is also \u003ccode\u003elsass.exe\u003c/code\u003e. This behavior is often associated with attackers attempting to bypass security controls and dump LSASS memory to extract credentials. The technique is used to evade detection mechanisms that monitor the primary LSASS process. Successful exploitation can lead to the compromise of domain or local credentials stored in memory, allowing for lateral movement and privilege escalation within the network. The detection is based on Windows Security Event Logs, specifically event code 4688, and is designed to identify this specific cloning behavior.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes code on the target system, potentially using tools like PowerShell or command-line utilities.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a process to clone the LSASS process using \u003ccode\u003ePssCaptureSnapShot\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe newly created process, a clone of LSASS, runs alongside the original.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the cloned LSASS process to dump its memory. This may involve tools like \u003ccode\u003ecomsvcs.dll\u003c/code\u003e, \u003ccode\u003erundll32.exe\u003c/code\u003e or custom scripts leveraging the MiniDumpWriteDump function.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts sensitive information from the dumped memory, including usernames, passwords, and Kerberos tickets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the extracted credentials to move laterally within the network, accessing additional systems and resources.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives and the scope of the compromised credentials.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable 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).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect potential LSASS clone creation via \u003ccode\u003ePssCaptureSnapShot\u003c/code\u003e. Tune the rule for your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the processes involved in cloning and dumping LSASS memory.\u003c/li\u003e\n\u003cli\u003eEnable Audit Process Creation and Command Line logging as per the Elastic documentation to ensure the events used by the provided Sigma rules are captured.\u003c/li\u003e\n\u003cli\u003eIf a LSASS clone is detected, review authentication events (4624, 4648, 4625) on the affected host to identify any suspicious logons or credential usage.\u003c/li\u003e\n\u003cli\u003eMonitor for file activity related to memory dumps (e.g., .dmp files) using the process clone to identify potential credential theft attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T10:00:00Z","date_published":"2024-01-09T10:00:00Z","id":"/briefs/2024-01-lsass-clone-creation/","summary":"Detection of LSASS process cloning using PssCaptureSnapShot, where the parent process is also LSASS, indicating a potential attempt to dump LSASS memory for credential access.","title":"Potential LSASS Clone Creation via PssCaptureSnapShot","url":"https://feed.craftedsignal.io/briefs/2024-01-lsass-clone-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["IIS"],"_cs_severities":["medium"],"_cs_tags":["credential-access","iis","appcmd","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers who have gained a foothold on a Windows web server running Internet Information Services (IIS) may attempt to extract sensitive information, such as application pool credentials, to facilitate lateral movement and privilege escalation. This is achieved by leveraging the AppCmd.exe utility, a command-line tool used to manage IIS configurations. By issuing specific commands, attackers can dump the entire web server configuration or target specific fields containing credential-related data, exposing usernames, passwords, and connection strings in clear text. Successful exploitation allows attackers to reuse these credentials to access other systems within the environment, potentially leading to significant data breaches or system compromise. This technique is particularly effective against organizations that store sensitive credentials within their IIS configurations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Windows web server, often through a web shell or by exploiting a vulnerability in a web application.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003eappcmd.exe\u003c/code\u003e via the command line.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003elist\u003c/code\u003e argument to enumerate application pools or other relevant IIS configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003e/text:*password*\u003c/code\u003e, \u003ccode\u003e/text:*processModel*\u003c/code\u003e, \u003ccode\u003e/text:*userName*\u003c/code\u003e, \u003ccode\u003e/config\u003c/code\u003e or \u003ccode\u003e*connectionstring*\u003c/code\u003e parameters with \u003ccode\u003eappcmd.exe\u003c/code\u003e to filter the output and specifically target credential-related data. Alternatively the attacker may use \u003ccode\u003e/text:*\u003c/code\u003e to output the full configuration.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eappcmd.exe\u003c/code\u003e outputs the requested configuration data, which may include usernames, passwords, and connection strings in clear text.\u003c/li\u003e\n\u003cli\u003eThe attacker parses the output to extract valid credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the extracted credentials to authenticate to other systems or services within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves lateral movement, privilege escalation, and access to sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Microsoft IIS Service Account Password Dumped\u0026rdquo; Sigma rule to your SIEM to detect the use of \u003ccode\u003eappcmd.exe\u003c/code\u003e to dump sensitive IIS configuration data.\u003c/li\u003e\n\u003cli\u003eReview IIS and web server activity for signs of exploitation, such as requests to newly created ASPX or PHP files as suggested in the rule\u0026rsquo;s Triage and Analysis section.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to activate the rules above and provide detailed process execution data.\u003c/li\u003e\n\u003cli\u003eImplement the password rotation for affected service accounts as suggested in the rule\u0026rsquo;s Triage and Analysis section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T10:00:00Z","date_published":"2024-01-09T10:00:00Z","id":"/briefs/2024-01-iis-appcmd-credential-dump/","summary":"Attackers with access to IIS web servers may use the AppCmd command-line tool to dump sensitive configuration data, including application pool credentials, potentially leading to lateral movement and privilege escalation.","title":"IIS AppCmd Tool Used to Dump Service Account Credentials","url":"https://feed.craftedsignal.io/briefs/2024-01-iis-appcmd-credential-dump/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["okta","session-hijacking","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief addresses the risk of Okta session hijacking, where adversaries may steal session cookies or tokens to gain unauthorized access to Okta resources. The alert focuses on detecting anomalous Okta sessions characterized by multiple device token hashes and source IP addresses associated with a single authenticated user. This activity may indicate that an authenticated session has been compromised and is being replayed from different devices or networks. Defenders should be aware of the potential for attackers to leverage stolen sessions to access the Okta admin console, applications, tenants, and other sensitive resources. Elastic has published a rule to detect this behavior, last updated on April 13, 2026, which can be used to proactively identify potentially compromised Okta sessions within the environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains access to a valid Okta session token or cookie through methods such as phishing or malware.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSession Token Theft:\u003c/strong\u003e The attacker steals a valid Okta session token/cookie from a compromised endpoint.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSession Replay:\u003c/strong\u003e The attacker replays the stolen session token/cookie from a different device and network location than the original user.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOkta Authentication:\u003c/strong\u003e The replayed session token authenticates to Okta, creating a new session instance.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMultiple Device Hashes:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnauthorized Access:\u003c/strong\u003e The attacker uses the hijacked session to access Okta resources, such as the admin console or applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e If the hijacked session belongs to a privileged user, the attacker may escalate privileges within the Okta environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Manipulation:\u003c/strong\u003e The attacker exfiltrates sensitive data or modifies Okta configurations to establish persistence or further compromise the environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s access and the sensitivity of the data they can access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy 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.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rule by pivoting into Okta system logs using the \u003ccode\u003eokta.actor.alternate_id\u003c/code\u003e and \u003ccode\u003eokta.authentication_context.external_session_id\u003c/code\u003e fields.\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for suspicious post-authentication activity, such as admin console access, policy changes, or application assignment modifications as described in the rule\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eEnforce MFA enrollment for all Okta users to mitigate the risk of session hijacking and credential theft, as recommended in the investigation guide.\u003c/li\u003e\n\u003cli\u003eRevoke active sessions and reset passwords for affected users exhibiting suspicious activity as mentioned in the false positive analysis.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:41:22Z","date_published":"2024-01-03T18:41:22Z","id":"/briefs/2024-01-03-okta-session-hijacking/","summary":"Detection of multiple device token hashes and source IPs for a single Okta session, indicating potential session hijacking and unauthorized access to Okta resources.","title":"Okta Session Hijacking via Multiple Device Token Hashes","url":"https://feed.craftedsignal.io/briefs/2024-01-03-okta-session-hijacking/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies suspicious Kubernetes API access patterns indicative of credential access. Specifically, it focuses on \u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e operations targeting the \u003ccode\u003esecrets\u003c/code\u003e resource performed by node identities (\u003ccode\u003esystem:node:*\u003c/code\u003e) or pod service accounts (\u003ccode\u003esystem:serviceaccount:*\u003c/code\u003e). Attackers who have compromised a pod service account or node credentials might attempt to enumerate secrets to discover sensitive information such as tokens, registry credentials, TLS keys, or application configurations. While legitimate controllers may read secrets, direct access from node or pod service accounts warrants investigation, especially when cross-namespace or involving high-value secrets. The rule is intended to be triaged based on namespace scope, user agent, RBAC, and relevance of the identity to the accessed secret.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster, possibly through compromising a pod or node.\u003c/li\u003e\n\u003cli\u003eAttacker obtains credentials for a service account associated with the compromised pod or accesses node credentials.\u003c/li\u003e\n\u003cli\u003eAttacker uses the stolen credentials to authenticate against the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate secrets within the cluster using \u003ccode\u003ekubectl get secrets --all-namespaces\u003c/code\u003e or similar API calls.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server receives the request and generates an audit log entry.\u003c/li\u003e\n\u003cli\u003eThis audit log entry contains details such as the user (\u003ccode\u003esystem:node:*\u003c/code\u003e or \u003ccode\u003esystem:serviceaccount:*\u003c/code\u003e), the action (\u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e), and the resource (\u003ccode\u003esecrets\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies valuable secrets containing sensitive information such as API keys or database passwords.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the secrets, gaining unauthorized access to other systems or data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized secret access attempts by node or pod service accounts in Kubernetes audit logs.\u003c/li\u003e\n\u003cli\u003eReview RBAC configurations to ensure least privilege for service accounts and nodes, limiting their access to only necessary secrets.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on cross-namespace access, high-value secret names, and unusual user agents.\u003c/li\u003e\n\u003cli\u003eImplement a process for regularly rotating secrets and auditing access to sensitive resources within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eBaseline normal secret access patterns for in-cluster operators, CSI drivers, and GitOps agents, and create allowlists to reduce false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:00Z","date_published":"2024-01-03T18:22:00Z","id":"/briefs/2024-01-kubernetes-secret-access/","summary":"This rule detects Kubernetes audit events where a node or pod service account attempts to read secrets directly, which is often a sign of credential access.","title":"Kubernetes Secret Access by Node or Pod Service Account","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-secret-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","CrowdStrike","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["credential-access","defense-evasion","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","CrowdStrike","SentinelOne"],"content_html":"\u003cp\u003eThis rule identifies the creation of symbolic links to shadow copies on Windows systems. Attackers use this technique to gain access to sensitive files stored within shadow copies, including the ntds.dit file (containing password hashes), system boot keys, and browser offline credentials. This approach allows them to bypass normal file access controls and extract credentials for lateral movement or privilege escalation. The detection rule is designed to ingest data from various sources, including Elastic Defend, CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs, providing broad coverage across different endpoint security solutions. The activity is typically initiated by command-line tools like cmd.exe or powershell.exe, making detection through process monitoring feasible. This technique is particularly relevant as it targets credential dumping, a critical stage in many attack campaigns.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system, possibly through phishing or exploitation of a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker elevates privileges to gain administrative rights, which are required to create shadow copies and symbolic links.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a volume shadow copy using \u003ccode\u003evssadmin.exe\u003c/code\u003e or similar tools.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003emklink\u003c/code\u003e command or PowerShell \u003ccode\u003eNew-Item -ItemType SymbolicLink\u003c/code\u003e to create a symbolic link to the shadow copy path.\u003c/li\u003e\n\u003cli\u003eThe symbolic link points to a directory within the shadow copy containing sensitive files like \u003ccode\u003entds.dit\u003c/code\u003e or browser credential stores.\u003c/li\u003e\n\u003cli\u003eThe attacker copies the targeted sensitive files (e.g., \u003ccode\u003entds.dit\u003c/code\u003e) from the shadow copy using the symbolic link.\u003c/li\u003e\n\u003cli\u003eThe attacker removes the shadow copy to cover their tracks, although the symbolic link creation remains as evidence.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts credentials from the copied \u003ccode\u003entds.dit\u003c/code\u003e file offline for use in lateral movement or further attacks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003entds.dit\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;Symbolic Link to Shadow Copy Created via Cmd\u0026rdquo; to detect the creation of symbolic links to shadow copies via \u003ccode\u003ecmd.exe\u003c/code\u003e (rules).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;Symbolic Link to Shadow Copy Created via PowerShell\u0026rdquo; to detect the creation of symbolic links to shadow copies via \u003ccode\u003epowershell.exe\u003c/code\u003e (rules).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon Event ID 1 (Process Creation) logging to provide necessary data for the Sigma rules to function correctly (setup).\u003c/li\u003e\n\u003cli\u003eReview the \u0026ldquo;Investigating Symbolic Link to Shadow Copy Created\u0026rdquo; section in the rule\u0026rsquo;s notes for triage and analysis steps when the rule triggers.\u003c/li\u003e\n\u003cli\u003eMonitor for the usage of \u003ccode\u003emklink\u003c/code\u003e command with the \u003ccode\u003eHarddiskVolumeShadowCopy\u003c/code\u003e argument in process command lines.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:15:00Z","date_published":"2024-01-03T18:15:00Z","id":"/briefs/2024-01-shadow-copy-symlink/","summary":"Adversaries may create symbolic links to shadow copies to access sensitive files such as ntds.dit and browser credentials, enabling credential dumping using cmd.exe or powershell.exe.","title":"Symbolic Link Creation to Shadow Copies for Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-01-shadow-copy-symlink/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Edge","Chrome","Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["high"],"_cs_tags":["credential-access","windows","browser-exploitation"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Google","Elastic","SentinelOne"],"content_html":"\u003cp\u003eThis detection identifies instances where a browser process, specifically Google Chrome or Microsoft Edge, is initiated from an unexpected parent process on a Windows system. The rule focuses on scenarios where browsers are launched with arguments indicative of remote debugging, headless automation, or minimal user interaction. Such activity can signal an attempt to manipulate a browser session for malicious purposes, potentially leading to credential theft or unauthorized access to sensitive information. The rule is designed to leverage data from Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Process Creation Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes a script or command to launch a browser process (chrome.exe or msedge.exe).\u003c/li\u003e\n\u003cli\u003eThe browser is launched with specific command-line arguments, such as \u003ccode\u003e--remote-debugging-port\u003c/code\u003e, \u003ccode\u003e--headless\u003c/code\u003e, or \u003ccode\u003e--window-position=-x,-y\u003c/code\u003e, to enable remote control or hide the browser window.\u003c/li\u003e\n\u003cli\u003eThe parent process of the browser is an unusual executable, not typically associated with launching browsers (e.g., not explorer.exe).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the remote debugging port to interact with the browser session programmatically.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to steal credentials or session cookies from the browser.\u003c/li\u003e\n\u003cli\u003eThe attacker uses stolen credentials to access sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eBrowser Process Spawned from Unusual Parent\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process-creation logging (Event ID 1) to collect the necessary data for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eBrowser Process Spawned from Unusual Parent\u003c/code\u003e Sigma rule.\u003c/li\u003e\n\u003cli\u003eReview process command lines for arguments like \u003ccode\u003e--remote-debugging-port\u003c/code\u003e or \u003ccode\u003e--headless\u003c/code\u003e to identify potential browser manipulation attempts.\u003c/li\u003e\n\u003cli\u003eMonitor network connections originating from browser processes for unexpected destinations, as described in the investigation guide from the source.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:15:00Z","date_published":"2024-01-03T18:15:00Z","id":"/briefs/2024-01-browser-unusual-parent/","summary":"Attackers may attempt credential theft by launching browsers (Chrome, Edge) with remote debugging, headless automation, or minimal arguments from an unusual parent process on Windows systems.","title":"Browser Process Spawned from an Unusual Parent","url":"https://feed.craftedsignal.io/briefs/2024-01-browser-unusual-parent/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["credential-access","lsass","duplicatehandle","mirrordump","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies suspicious attempts to access the Local Security Authority Subsystem Service (LSASS) memory via the DuplicateHandle function on Windows systems. LSASS is a critical process that manages user credentials, making it a prime target for credential dumping attacks. Attackers may use DuplicateHandle to bypass the NtOpenProcess API, which is commonly monitored, to evade detection. The rule focuses on EventCode 10, looking for lsass.exe requesting DuplicateHandle access rights (0x40) where the call trace originates from an unknown executable region (\u003cem\u003eUNKNOWN\u003c/em\u003e). This technique is often associated with tools like MirrorDump.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the target system (e.g., via phishing or exploitation of a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes a malicious program or script on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe malicious code attempts to open a handle to the LSASS process.\u003c/li\u003e\n\u003cli\u003eInstead of using NtOpenProcess, the attacker leverages the DuplicateHandle function to obtain a handle to LSASS.\u003c/li\u003e\n\u003cli\u003eThe DuplicateHandle call originates from an unknown or suspicious module, as indicated by \u0026ldquo;\u003cem\u003eUNKNOWN\u003c/em\u003e\u0026rdquo; in the call trace.\u003c/li\u003e\n\u003cli\u003eWith a valid handle to LSASS, the attacker dumps the LSASS memory to a file or other location.\u003c/li\u003e\n\u003cli\u003eThe attacker parses the dumped memory to extract sensitive credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials for lateral movement, privilege escalation, or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process creation and event 10 logging to capture the necessary telemetry for this detection. (Setup instructions: \u003ca href=\"https://ela.st/sysmon-event-10-setup\"\u003ehttps://ela.st/sysmon-event-10-setup\u003c/a\u003e)\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential Credential Access via DuplicateHandle in LSASS\u0026rdquo; to your SIEM and tune for your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by this rule by reviewing the event logs and call trace details to identify suspicious modules or processes.\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T17:30:00Z","date_published":"2024-01-03T17:30:00Z","id":"/briefs/2024-01-lsass-dupehandle/","summary":"Detection of suspicious LSASS handle access via DuplicateHandle from an unknown call trace module, indicating a potential attempt to bypass the NtOpenProcess API to evade detection and dump LSASS memory for credential access.","title":"Potential Credential Access via LSASS Handle Duplication","url":"https://feed.craftedsignal.io/briefs/2024-01-lsass-dupehandle/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","appid","uri","application","serviceprincipal","credential-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may modify the AppID URI of an application in Azure to facilitate various malicious activities, including gaining unauthorized access, establishing persistence, accessing credentials, escalating privileges, or maintaining stealth within the environment. The AppID URI serves as a unique identifier for an application within the Azure Active Directory (Azure AD) ecosystem. Changes to this URI could indicate that an attacker is attempting to impersonate a legitimate application or service, potentially bypassing security controls and gaining elevated access. Monitoring for these changes is crucial for defenders to identify and respond to potentially malicious activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure account, possibly through compromised credentials or exploiting a vulnerability (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available applications and service principals within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target application with a high-value AppID URI.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the AppID URI of the target application, potentially to impersonate another service or application (T1552).\u003c/li\u003e\n\u003cli\u003eThis change might be done to allow the attacker to request tokens for that application.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified AppID URI to request access tokens, potentially gaining unauthorized access to resources (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired access tokens to move laterally within the Azure environment and access sensitive data or systems.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by using the modified application for continued unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Application AppID Uri Configuration Changes\u0026rdquo; to your SIEM to detect unauthorized modifications to AppID URIs (rule provided below).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the AppID URI changes.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit application permissions and configurations to identify and remediate any misconfigurations.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for other suspicious activities related to application and service principal management.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T17:24:00Z","date_published":"2024-01-03T17:24:00Z","id":"/briefs/2024-01-azure-appid-uri-change/","summary":"Detection of configuration changes to an application's AppID URI in Azure, potentially indicating malicious activity related to initial access, persistence, credential access, privilege escalation, or stealth.","title":"Detect Application AppID URI Configuration Changes in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-appid-uri-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory"],"_cs_severities":["high"],"_cs_tags":["credential-access","persistence","windows","active-directory"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe SeEnableDelegationPrivilege user right, when assigned to a security principal, allows that principal to be trusted for delegation within Active Directory. Attackers can abuse this right to compromise accounts and elevate privileges by impersonating other users or services. This technique can be used for lateral movement, persistence, and ultimately, domain dominance. Defenders should monitor for the assignment of this privilege, especially to accounts that should not have it. The targeted behavior is logged as event ID 4704 in Windows Security logs. This activity is critical to monitor as it represents a powerful tool for attackers to move laterally and maintain persistence within a compromised environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a compromised account with sufficient privileges to modify user rights.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns the SeEnableDelegationPrivilege to a target account using tools like \u003ccode\u003entrights.exe\u003c/code\u003e or PowerShell cmdlets.\u003c/li\u003e\n\u003cli\u003eWindows Security Event 4704 is generated, logging the privilege assignment.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the target account\u0026rsquo;s attributes, such as \u003ccode\u003euserAccountControl\u003c/code\u003e or \u003ccode\u003emsDS-AllowedToDelegateTo\u003c/code\u003e, to enable delegation.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages Kerberos delegation to impersonate other users or services.\u003c/li\u003e\n\u003cli\u003eUsing the impersonated credentials, the attacker accesses sensitive resources or performs privileged actions.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the network, compromising additional systems and accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration or domain dominance.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Authorization Policy Change\u0026rdquo; to generate Windows Security Event ID 4704 (Setup instructions: \u003ca href=\"https://ela.st/audit-authorization-policy-change)\"\u003ehttps://ela.st/audit-authorization-policy-change)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal\u0026rdquo; to your SIEM to detect the assignment of this privilege.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where SeEnableDelegationPrivilege is assigned, focusing on the targeted account and the source of the change.\u003c/li\u003e\n\u003cli\u003eMonitor for modifications to delegation-related attributes on user and computer objects.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T17:23:00Z","date_published":"2024-01-03T17:23:00Z","id":"/briefs/2024-01-se-enable-delegation/","summary":"Detection of the assignment of the SeEnableDelegationPrivilege user right to a principal can indicate potential Active Directory compromise and privilege elevation by attackers.","title":"SeEnableDelegationPrivilege Assignment Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-se-enable-delegation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","CrowdStrike"],"_cs_severities":["high"],"_cs_tags":["credential-access","mimikatz","memssp","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThis detection identifies the creation of the \u003ccode\u003emimilsa.log\u003c/code\u003e file, a default log generated by the Mimikatz \u003ccode\u003emisc::memssp\u003c/code\u003e module. The \u003ccode\u003emisc::memssp\u003c/code\u003e module injects a malicious Security Support Provider (SSP) into the Local Security Authority Subsystem Service (LSASS) process. This injected SSP logs credentials from subsequent logons to the compromised host, allowing attackers to capture sensitive information. The creation of this log file is a strong indicator of credential access attempts and the potential compromise of user accounts and system security. This rule is designed for data generated by Elastic Defend and also supports data from CrowdStrike, Microsoft Defender XDR, and SentinelOne Cloud Funnel.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes Mimikatz or a similar tool with the \u003ccode\u003emisc::memssp\u003c/code\u003e module.\u003c/li\u003e\n\u003cli\u003eMimikatz injects a malicious SSP library (e.g., \u003ccode\u003emimilib.dll\u003c/code\u003e) into the LSASS process (\u003ccode\u003elsass.exe\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe injected SSP hooks into the authentication process.\u003c/li\u003e\n\u003cli\u003eWhen users log on to the system, the SSP captures their credentials.\u003c/li\u003e\n\u003cli\u003eThe captured credentials are written to the \u003ccode\u003emimilsa.log\u003c/code\u003e file, typically located in \u003ccode\u003eC:\\Windows\\System32\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the \u003ccode\u003emimilsa.log\u003c/code\u003e file to obtain the captured credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to escalate privileges, move laterally within the network, and access sensitive resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eMimikatz Memssp Log File Detected\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon file creation logging to detect the creation of \u003ccode\u003emimilsa.log\u003c/code\u003e files.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the process that created the log file and any subsequent file access.\u003c/li\u003e\n\u003cli\u003eMonitor for the presence of \u003ccode\u003emimilib.dll\u003c/code\u003e and any LSA Security Packages registry modifications, as these may indicate persistent SSP installation.\u003c/li\u003e\n\u003cli\u003eReview and restrict interactive logons to high-value hosts to minimize the potential for credential theft.\u003c/li\u003e\n\u003cli\u003eInvestigate related alerts for the same \u003ccode\u003ehost.id\u003c/code\u003e in the last 48 hours covering delivery, privilege escalation, LSASS access, persistence, lateral movement, or additional credential access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T17:00:00Z","date_published":"2024-01-03T17:00:00Z","id":"/briefs/2024-01-mimikatz-memssp-log/","summary":"This rule detects the creation of the default Mimikatz MemSSP credential log file, mimilsa.log, which is created after the misc::memssp module injects a malicious Security Support Provider into LSASS, potentially capturing credentials from subsequent logons.","title":"Mimikatz MemSSP Log File Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-mimikatz-memssp-log/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","kubernetes","admission-controller","persistence","privilege-escalation","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eKubernetes Admission Controllers are critical components that intercept and potentially modify requests to the Kubernetes API server. These controllers rely on admission webhooks (MutatingAdmissionWebhook or ValidatingAdmissionWebhook) deployed within the cluster. A malicious actor can abuse these webhooks to establish persistence by modifying pod creation operations and injecting malicious containers into new pods via MutatingAdmissionWebhook. Alternatively, ValidatingAdmissionWebhook can be used to intercept API server requests, potentially exposing secrets and sensitive information. This activity allows for credential access and privilege escalation, impacting the overall security posture of the Kubernetes cluster.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Azure Kubernetes cluster, possibly through compromised credentials or a vulnerability in a deployed application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the existing Admission Controller configuration within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious MutatingAdmissionWebhook configuration to intercept pod creation requests.\u003c/li\u003e\n\u003cli\u003eThe malicious webhook is deployed to the cluster, configured to modify pod specifications.\u003c/li\u003e\n\u003cli\u003eWhen new pods are created, the webhook injects a malicious container into the pod specification before deployment.\u003c/li\u003e\n\u003cli\u003eThe malicious container executes within the newly created pod, providing the attacker with persistent access to the cluster.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker crafts a malicious ValidatingAdmissionWebhook to intercept API requests.\u003c/li\u003e\n\u003cli\u003eThe webhook captures sensitive data, such as secrets, and sends it to an attacker-controlled server, resulting in credential access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Kubernetes Admission Controller Configuration Change\u0026rdquo; to detect unauthorized modifications to Admission Controller configurations in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit existing Admission Controller configurations for any unexpected or malicious webhooks.\u003c/li\u003e\n\u003cli\u003eImplement strong RBAC policies to restrict access to Admission Controller configuration and prevent unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO\u003c/code\u003e and \u003ccode\u003eMICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO\u003c/code\u003e operations to identify potential abuse.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:30:00Z","date_published":"2024-01-03T15:30:00Z","id":"/briefs/2024-01-azure-kubernetes-admission-controller/","summary":"An adversary can exploit Kubernetes Admission Controllers in Azure to achieve persistence, privilege escalation, or credential access by manipulating webhook configurations.","title":"Malicious Azure Kubernetes Admission Controller Configuration","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-kubernetes-admission-controller/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Firefox","Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud"],"_cs_severities":["high"],"_cs_tags":["credential-access","malware","firefox"],"_cs_type":"advisory","_cs_vendors":["Mozilla","Splunk"],"content_html":"\u003cp\u003eThis detection focuses on identifying unauthorized access to Firefox profile directories. The Firefox profile directory stores sensitive user data, including login credentials, browsing history, and cookies. When a non-Firefox process accesses this directory, it could be an indicator of malicious activity, such as a Remote Access Trojan (RAT) or other malware attempting to steal user information. The analytic leverages Windows Security Event logs, specifically event code 4663, to monitor access attempts. This is relevant because successful credential theft can lead to account compromise, data breaches, and further propagation of malware within the network. The threat encompasses a broad range of malware families, including stealers (Azorult, RedLine Stealer, 0bj3ctivity Stealer), RATs (Remcos, Quasar RAT, Warzone RAT), keyloggers (Snake Keylogger, VIP Keylogger), and other malware like DarkGate, NjRAT, AgentTesla, and Lokibot. The activity has been observed in campaigns such as CISA AA23-347A and the 3CX Supply Chain Attack.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe user executes a malicious file, potentially delivered via phishing or drive-by download (not covered in source).\u003c/li\u003e\n\u003cli\u003eThe malicious file executes and establishes persistence on the system.\u003c/li\u003e\n\u003cli\u003eThe malware attempts to access the Firefox profile directory, located at \u003ccode\u003e*\\AppData\\Roaming\\Mozilla\\Firefox\\Profiles*\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWindows Security Event 4663 is generated, logging the access attempt to the Firefox profile directory.\u003c/li\u003e\n\u003cli\u003eThe malware reads sensitive data, such as login credentials, cookies, and browsing history, from the profile directory.\u003c/li\u003e\n\u003cli\u003eThe stolen data is exfiltrated to a command-and-control (C2) server.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to user accounts and sensitive systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Object Access\u0026rdquo; 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.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect non-Firefox processes accessing Firefox profile directories.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, paying close attention to the \u003ccode\u003eProcessName\u003c/code\u003e and \u003ccode\u003eObjectName\u003c/code\u003e to identify potentially malicious processes and the specific profile data being accessed.\u003c/li\u003e\n\u003cli\u003eReview and update your organization\u0026rsquo;s security policies to restrict unauthorized access to sensitive user data.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:22:32Z","date_published":"2024-01-03T15:22:32Z","id":"/briefs/2024-01-firefox-profile-access/","summary":"This analytic detects non-Firefox processes accessing the Firefox profile directory, potentially indicating malware attempting to harvest sensitive user data like login credentials, browsing history, and cookies.","title":"Non-Firefox Process Accessing Firefox Profile Directory","url":"https://feed.craftedsignal.io/briefs/2024-01-firefox-profile-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["high"],"_cs_tags":["credential-access","lateral-movement","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies potential remote access to the Windows registry to dump credential data from the Security Account Manager (SAM) registry hive. This activity often precedes credential access and privilege elevation attempts. The rule focuses on detecting the creation of specific file types by \u003ccode\u003esvchost.exe\u003c/code\u003e, a legitimate Windows process, in temporary directories. However, when \u003ccode\u003esvchost.exe\u003c/code\u003e creates files with registry file (REGF) header bytes in temporary locations, and those files are also of a significant size, it indicates a potential secretsdump-style attack. The rule is designed for data generated by Elastic Defend.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to the target system via compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eAttacker uses remote registry tools or scripts, such as those based on Impacket\u0026rsquo;s \u003ccode\u003esecretsdump.py\u003c/code\u003e, to connect to the target system\u0026rsquo;s registry service.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a connection to the RemoteRegistry service.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003esvchost.exe\u003c/code\u003e process on the target system is leveraged to access the SAM, SECURITY, and SYSTEM registry hives.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esvchost.exe\u003c/code\u003e creates a temporary file (e.g., a \u003ccode\u003e.tmp\u003c/code\u003e file) in the \u003ccode\u003e\\Windows\\System32\\\u003c/code\u003e or \u003ccode\u003e\\WINDOWS\\Temp\\\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eThe temporary file contains the contents of the registry hive, identifiable by the \u0026ldquo;72656766\u0026rdquo; (REGF) header bytes and a file size greater than 30000 bytes.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the dumped registry hive files from the target system.\u003c/li\u003e\n\u003cli\u003eThe attacker parses the registry hives offline to extract sensitive credential information, such as password hashes. This leads to lateral movement and privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious Svchost.exe Registry Hive Dump\u003c/code\u003e to detect the creation of registry hive files by \u003ccode\u003esvchost.exe\u003c/code\u003e in temporary directories based on the \u003ccode\u003efile.Ext.header_bytes\u003c/code\u003e and \u003ccode\u003efile.path\u003c/code\u003e fields.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious RemoteRegistry File Creation\u003c/code\u003e to detect files with REGF header bytes created by svchost.exe, outside the standard system path to catch unusual service context.\u003c/li\u003e\n\u003cli\u003eEnable and monitor process creation events, specifically focusing on \u003ccode\u003esvchost.exe\u003c/code\u003e and its command-line arguments, to identify suspicious service groups.\u003c/li\u003e\n\u003cli\u003eMonitor file creation events for files with the \u003ccode\u003e.tmp\u003c/code\u003e extension in the \u003ccode\u003e\\Windows\\System32\\\u003c/code\u003e and \u003ccode\u003e\\WINDOWS\\Temp\\\u003c/code\u003e directories, paying attention to file sizes and header bytes, as indicated by the file path and size conditions in the rule.\u003c/li\u003e\n\u003cli\u003eReview the investigation steps outlined in the rule documentation to properly triage and analyze potential incidents.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-remote-sam-secretsdump/","summary":"Detects remote access to the registry, potentially dumping credential data from the Security Account Manager (SAM) registry hive, indicating preparation for credential access and privilege elevation.","title":"Potential Remote Credential Access via Registry","url":"https://feed.craftedsignal.io/briefs/2024-01-remote-sam-secretsdump/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Security Event Logs"],"_cs_severities":["high"],"_cs_tags":["credential-access","ntlm-relay","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection rule identifies potential NTLM relay attacks targeting computer accounts in Windows environments. The attack involves coercing a target server to authenticate to an attacker-controlled system and then relaying that authentication to another service. It focuses on detecting a sequence of events: initial coercion attempts against specific named pipes known to be vulnerable, followed by authentication attempts using the target server\u0026rsquo;s computer account from a different host. This activity can allow an attacker to gain unauthorized access and execute commands with the privileges of the compromised computer account. The rule leverages Windows Security Event Logs to identify these patterns, providing a mechanism for defenders to detect and respond to NTLM relay attacks. The detection is based on research from 2025/2026 on coerced authentication methods and NTLM reflection techniques.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a machine within the network.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003eSpoolss\u003c/code\u003e, \u003ccode\u003enetdfs\u003c/code\u003e, \u003ccode\u003elsarpc\u003c/code\u003e, \u003ccode\u003elsass\u003c/code\u003e, \u003ccode\u003enetlogon\u003c/code\u003e, \u003ccode\u003esamr\u003c/code\u003e, \u003ccode\u003eefsrpc\u003c/code\u003e, \u003ccode\u003eFssagentRpc\u003c/code\u003e, \u003ccode\u003eeventlog\u003c/code\u003e, \u003ccode\u003ewinreg\u003c/code\u003e, \u003ccode\u003esrvsvc\u003c/code\u003e, \u003ccode\u003ednsserver\u003c/code\u003e, or \u003ccode\u003eWinsPipe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker captures the NTLM authentication attempt from the target server.\u003c/li\u003e\n\u003cli\u003eThe 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 \u0026ldquo;$\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe authentication attempt originates from a different IP address than the target server\u0026rsquo;s IP, indicating the relay.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker gains unauthorized access to the service and can execute commands or access data with the privileges of the target server\u0026rsquo;s computer account.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised computer account to move laterally within the network, potentially gaining access to sensitive resources or escalating privileges further.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eDeploy 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.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eReview and harden NTLM configuration to mitigate relay attacks, and consider disabling NTLM where possible in favor of more secure authentication protocols like Kerberos.\u003c/li\u003e\n\u003cli\u003eEnable SMB signing and Extended Protection for Authentication to prevent NTLM relay attacks.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and access controls to limit the scope of potential NTLM relay attacks.\u003c/li\u003e\n\u003cli\u003eApply the \u0026ldquo;Setup\u0026rdquo; configurations by enabling the recommended Windows audit policies to ensure the events required by the rules are generated.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-ntlm-relay-computer-account/","summary":"This rule detects potential NTLM relay attacks against computer accounts by identifying coercion attempts followed by authentication events originating from a different host, indicating that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system.","title":"Potential NTLM Relay Attack against a Computer Account","url":"https://feed.craftedsignal.io/briefs/2024-01-ntlm-relay-computer-account/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","password-reset","privilege-escalation","initial-access","persistence","credential-access","stealth"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting user-initiated password resets within Azure Active Directory (Azure AD). While legitimate password resets are common, monitoring this activity can help identify potentially malicious behavior, such as an attacker attempting to gain unauthorized access to an account or an insider threat actor escalating privileges. Attackers may leverage compromised credentials or social engineering to initiate password resets, bypassing multi-factor authentication (MFA) if it is not properly configured or enforced. This detection is important for defenders because successful password resets can lead to a complete account takeover, allowing attackers to access sensitive data, resources, and systems.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a user\u0026rsquo;s credentials through phishing, credential stuffing, or malware.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to log in to an Azure AD-protected resource using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker fails to authenticate, either because they do not have the correct password or MFA is enabled.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a password reset request using the \u0026ldquo;Forgot password\u0026rdquo; feature or a similar mechanism.\u003c/li\u003e\n\u003cli\u003eAzure AD sends a password reset verification code or link to the user\u0026rsquo;s registered email address or phone number.\u003c/li\u003e\n\u003cli\u003eIf the attacker controls the registered email address or phone number (due to prior compromise), they can access the verification code or link.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the verification code or link to set a new password for the user\u0026rsquo;s Azure AD account.\u003c/li\u003e\n\u003cli\u003eThe attacker logs in to the Azure AD account with the new password, gaining unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003ePassword Reset By User Account\u003c/code\u003e to your SIEM to detect user-initiated password resets in Azure AD audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected password resets, especially those initiated by users who have not recently requested a password change.\u003c/li\u003e\n\u003cli\u003eReview and enforce multi-factor authentication (MFA) policies to prevent attackers from bypassing password-based authentication.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for suspicious activity related to password resets, such as multiple failed login attempts followed by a successful reset.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-03-azure-user-password-reset/","summary":"Detects when a user successfully resets their own password in Azure Active Directory, which may indicate malicious activity or account compromise.","title":"Azure AD User Password Reset Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-user-password-reset/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail","EKS IAM Roles for Service Accounts"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","kubernetes","lateral-movement","credential-access","discovery"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies lateral movement in AWS environments stemming from Kubernetes service accounts utilizing \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e. It focuses on detecting instances where credentials obtained via this method are subsequently used to perform several distinct AWS control-plane actions within a single session. This behavior deviates from typical pod traffic and could signify unauthorized access or privilege escalation. The rule prioritizes the detection of sensitive API usage, including reconnaissance activities, access to secrets, IAM modifications, and compute creation events, while strategically excluding high-volume S3 data-plane operations to minimize false positives. The targeted environments are those leveraging EKS IAM Roles for Service Accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA Kubernetes service account projects a token.\u003c/li\u003e\n\u003cli\u003eThe service account uses \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e to exchange the token for short-lived IAM credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the assumed role to perform reconnaissance activities such as \u003ccode\u003eListUsers\u003c/code\u003e, \u003ccode\u003eListRoles\u003c/code\u003e, and \u003ccode\u003eDescribeInstances\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access secrets using actions like \u003ccode\u003eGetSecretValue\u003c/code\u003e and \u003ccode\u003eListSecrets\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges by modifying IAM policies with actions like \u003ccode\u003eAttachRolePolicy\u003c/code\u003e and \u003ccode\u003ePutRolePolicy\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create new users or roles within the AWS environment using actions like \u003ccode\u003eCreateUser\u003c/code\u003e and \u003ccode\u003eCreateRole\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement using actions like \u003ccode\u003eSendCommand\u003c/code\u003e and \u003ccode\u003eStartSession\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to evade detection by stopping logging with the \u003ccode\u003eStopLogging\u003c/code\u003e action.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect potentially malicious activity related to \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the \u003ca href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html\"\u003eIAM OIDC identity provider\u003c/a\u003e documentation.\u003c/li\u003e\n\u003cli\u003eImplement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in \u003ca href=\"https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html\"\u003eEKS IAM roles for service accounts\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-aws-k8s-lateral-movement/","summary":"This rule detects lateral movement in AWS environments originating from Kubernetes service accounts by identifying instances where credentials obtained for a service account are used for multiple distinct AWS control-plane actions, potentially indicating unauthorized access.","title":"AWS Lateral Movement from Kubernetes Service Account via AssumeRoleWithWebIdentity","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-k8s-lateral-movement/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Active Directory","Azure AD Connect","ADFS"],"_cs_severities":["high"],"_cs_tags":["credential-access","shadow-credentials","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe \u0026ldquo;Shadow Credentials\u0026rdquo; attack involves manipulating the \u003ccode\u003emsDS-KeyCredentialLink\u003c/code\u003e attribute in Active Directory (AD) to gain unauthorized access to user or computer accounts. Attackers can create a key pair, append the raw public key to the attribute, and authenticate as the target object. This technique allows for persistent and stealthy access, as it leverages Kerberos key trust account mapping. The original detection rule was created in January 2022 and last updated in April 2026. This attack abuses control over an object to create the shadow credentials. Defenders should monitor for modifications to the \u003ccode\u003emsDS-KeyCredentialLink\u003c/code\u003e attribute, especially those not associated with legitimate Azure AD Connect or ADFS provisioning.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e Attacker gains initial access to a system with sufficient privileges to modify Active Directory objects.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker identifies a target user or computer object within Active Directory to compromise.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e The attacker generates a new key pair.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker modifies the \u003ccode\u003emsDS-KeyCredentialLink\u003c/code\u003e attribute of the target object to include the attacker\u0026rsquo;s public key. This requires specific permissions on the target object.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker uses the private key to authenticate as the target object, bypassing normal authentication mechanisms.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker uses the compromised account to move laterally within the network, accessing resources and systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their objective, such as data exfiltration, system compromise, or further privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable and monitor Windows Security Event Logs, specifically event ID 5136, for modifications to the \u003ccode\u003emsDS-KeyCredentialLink\u003c/code\u003e attribute as described in the rule description.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect suspicious modifications to the \u003ccode\u003emsDS-KeyCredentialLink\u003c/code\u003e attribute, and tune for your environment.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and auditing on Active Directory objects, particularly those with sensitive privileges, to prevent unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by examining the \u003ccode\u003ewinlog.event_data.ObjectDN\u003c/code\u003e, \u003ccode\u003ewinlog.event_data.SubjectUserName\u003c/code\u003e, and \u003ccode\u003ewinlog.event_data.AttributeValue\u003c/code\u003e fields to determine the legitimacy of the changes.\u003c/li\u003e\n\u003cli\u003eFollow the triage and analysis steps in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field to investigate alerts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:57:22Z","date_published":"2024-01-03T14:57:22Z","id":"/briefs/2024-01-shadow-credentials/","summary":"This rule detects the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object, which could indicate an attacker is creating shadow credentials to gain persistent and stealthy access.","title":"Potential Shadow Credentials added to AD Object","url":"https://feed.craftedsignal.io/briefs/2024-01-shadow-credentials/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["gcloud","azd","gh","aws","kubectl","doctl","oci"],"_cs_severities":["high"],"_cs_tags":["credential-access","cloud","cli","token-harvesting"],"_cs_type":"advisory","_cs_vendors":["Elastic","Google","Microsoft","GitHub","DigitalOcean","Oracle"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting command-line credential harvesting across multiple cloud platforms. Attackers may attempt to steal application access tokens or extract credentials from files by executing specific commands via command-line interfaces (CLIs) for GCP, Azure, AWS, GitHub, DigitalOcean, Oracle, and Kubernetes. This activity is particularly concerning when originating from the same host within a short time frame (e.g., five minutes), potentially indicating automated credential theft. This technique can lead to unauthorized access to cloud resources, data breaches, and lateral movement within cloud environments. Defenders should monitor for suspicious command-line activity involving cloud CLIs and credential access patterns.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system, possibly via compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a shell (cmd.exe, PowerShell, bash, etc.) to execute cloud CLI commands.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to list available credentials or tokens (e.g., \u003ccode\u003eaws configure list\u003c/code\u003e, \u003ccode\u003eaz account list\u003c/code\u003e, \u003ccode\u003ekubectl config view\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to print access tokens for various cloud providers (e.g., \u003ccode\u003egcloud auth print-access-token\u003c/code\u003e, \u003ccode\u003eaz account get-access-token\u003c/code\u003e, \u003ccode\u003egh auth token\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker uses credential harvesting commands across multiple cloud platforms within a short timeframe.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the harvested credentials to a remote location.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to access sensitive cloud resources and data.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement within the cloud environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s ability to exploit them.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Multi-Cloud CLI Token and Credential Access Commands\u0026rdquo; to your SIEM to detect suspicious command-line activity related to cloud credential harvesting.\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eEsql.process_command_line_values\u003c/code\u003e in the rule output to identify the exact commands executed and determine if the activity was legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eCorrelate the detected activity with authentication, Kubernetes audit, and cloud API logs to confirm unauthorized access and misuse of printed tokens.\u003c/li\u003e\n\u003cli\u003eImplement monitoring and alerting for unusual CLI activity originating from user workstations or build servers, focusing on the CLIs mentioned in the Overview section.\u003c/li\u003e\n\u003cli\u003eFollow vendor-specific guidance to revoke compromised credentials, such as revoking tokens and rotating secrets, as outlined in the rule\u0026rsquo;s \u0026ldquo;Response and remediation\u0026rdquo; section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-multi-cloud-cli-token-harvesting/","summary":"This rule detects command-line activity indicative of credential access across multiple cloud platforms (GCP, Azure, AWS, GitHub, DigitalOcean, Oracle, Kubernetes), looking for specific commands used to print or access tokens and credentials, flagging hosts where multiple cloud targets are accessed within a five-minute window, suggesting potential credential harvesting activity.","title":"Multi-Cloud CLI Token and Credential Access via Command-Line Harvesting","url":"https://feed.craftedsignal.io/briefs/2024-01-multi-cloud-cli-token-harvesting/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Identity Center"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","identity","persistence","credential-access","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS Identity Center (formerly AWS SSO) enables centralized management of access to AWS accounts and applications. Attackers can manipulate the configured identity provider to gain unauthorized access. The modification of the configured Identity Provider (IdP) within AWS Identity Center can lead to a full compromise of the AWS environment. By associating a malicious directory or disabling/disassociating legitimate directories, attackers can potentially establish persistent access, escalate privileges, and impersonate legitimate users. This can be achieved by utilizing compromised AWS credentials or exploiting vulnerabilities in the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained via compromised AWS credentials or by exploiting an AWS vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates the current AWS Identity Center configuration to identify the currently associated directory.\u003c/li\u003e\n\u003cli\u003eThe attacker disassociates the existing, legitimate directory using \u003ccode\u003eDisassociateDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker associates a malicious directory they control using \u003ccode\u003eAssociateDirectory\u003c/code\u003e. This malicious directory is configured to impersonate legitimate users.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker disables external IdP configuration for the directory using \u003ccode\u003eDisableExternalIdPConfigurationForDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker enables external IdP configuration for the directory, pointing to an attacker-controlled IdP, using \u003ccode\u003eEnableExternalIdPConfigurationForDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the malicious or attacker-controlled IdP to authenticate as legitimate users, gaining access to AWS resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions within the AWS environment, such as data exfiltration or resource destruction.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized changes to the AWS Identity Center identity provider.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected events related to \u003ccode\u003eAssociateDirectory\u003c/code\u003e, \u003ccode\u003eDisableExternalIdPConfigurationForDirectory\u003c/code\u003e, \u003ccode\u003eDisassociateDirectory\u003c/code\u003e, or \u003ccode\u003eEnableExternalIdPConfigurationForDirectory\u003c/code\u003e in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts and users to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM permissions to minimize the blast radius of compromised credentials.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for unusual activity patterns that might indicate malicious directory association attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-aws-idp-change/","summary":"An adversary modifies the AWS Identity Center identity provider configuration, potentially leading to persistent access and privilege escalation through user impersonation.","title":"AWS Identity Center Identity Provider Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-idp-change/"},{"_cs_actors":["Snake Keylogger"],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud"],"_cs_severities":["high"],"_cs_tags":["credential-access","stealer","windows"],"_cs_type":"threat","_cs_vendors":["Splunk"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting unauthorized access to browser password stores, a technique commonly employed by credential-stealing malware such as Snake Keylogger. These attackers aim to exfiltrate sensitive information, including stored credentials and browsing history, by accessing browser user data profiles. This activity is detected by monitoring Windows Security Event logs (EventCode 4663) and comparing process access patterns against an expected list of browser applications via the \u003ccode\u003ebrowser_app_list\u003c/code\u003e lookup table. The detection identifies processes that are not recognized as legitimate browser applications but are attempting to access browser user data. This technique has been observed in trojan stealers, where credential access is a key component of their information-gathering strategy. This method allows defenders to quickly pivot and discover potentially malicious processes on the system, such as credential stealers.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user downloads and executes a malicious file, often disguised as a legitimate application or document.\u003c/li\u003e\n\u003cli\u003eThe malicious file executes, dropping a stealer component into the system.\u003c/li\u003e\n\u003cli\u003eThe stealer process initiates an attempt to access browser user data profiles.\u003c/li\u003e\n\u003cli\u003eWindows generates a Security Event Log (EventCode 4663) when the stealer attempts to access a browser data file.\u003c/li\u003e\n\u003cli\u003eThe detection analytic identifies processes accessing the browser data folder not present in the \u003ccode\u003ebrowser_app_list\u003c/code\u003e lookup file.\u003c/li\u003e\n\u003cli\u003eThe stealer process reads sensitive information, such as usernames, passwords, and browsing history, from the accessed files.\u003c/li\u003e\n\u003cli\u003eThe collected data is staged for exfiltration, potentially compressed or encrypted.\u003c/li\u003e\n\u003cli\u003eThe stolen credentials and information are exfiltrated to a command-and-control server.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable 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).\u003c/li\u003e\n\u003cli\u003ePopulate and maintain the \u003ccode\u003ebrowser_app_list\u003c/code\u003e lookup table with known and allowed browser processes and their associated paths (reference: search description).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect anomalous processes accessing browser password stores, and tune it for your specific environment (reference: rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to identify potentially compromised systems and user accounts (reference: rules).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:22:00Z","date_published":"2024-01-03T14:22:00Z","id":"/briefs/2024-01-browser-credential-access/","summary":"Detection of non-browser processes accessing browser user data folders, a tactic used by malware such as Snake Keylogger to steal credentials and sensitive information.","title":"Suspicious Process Accessing Browser Password Store","url":"https://feed.craftedsignal.io/briefs/2024-01-browser-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["cloud","azure","application","uri","modification","persistence","credential-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may modify application URIs within Azure Active Directory to redirect users or applications to malicious resources, obtain unauthorized access, or establish persistence. The modification of an application\u0026rsquo;s URI can be a subtle but effective technique for gaining a foothold in an environment. By manipulating the URI settings, attackers can redirect traffic to attacker-controlled servers, intercept credentials, or perform other malicious actions. This activity is often difficult to detect because it can blend in with legitimate administrative tasks. Investigation is merited if URIs for domain names no longer exist, are not using HTTPS, have wildcards at the end of the domain, are not unique to that app, or point to domains that the organization does not control.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure account with sufficient privileges to modify application registrations.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Azure Active Directory portal.\u003c/li\u003e\n\u003cli\u003eThe attacker locates a target application registration.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the application\u0026rsquo;s URI settings, such as the reply URLs or identifier URIs.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the URI to point to a malicious server or a phishing page.\u003c/li\u003e\n\u003cli\u003eUsers or applications are redirected to the malicious URI when attempting to authenticate or access the application.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts credentials or performs other malicious actions.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining control over the application\u0026rsquo;s URI settings.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s security posture.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eApplication URI Configuration Changes\u003c/code\u003e to your SIEM to detect suspicious modifications to application URIs in Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u003ccode\u003eApplication URI Configuration Changes\u003c/code\u003e to determine if the URI modification is legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for any changes to application URI settings (as indicated by \u003ccode\u003eproperties.message: Update Application Sucess- Property Name AppAddress\u003c/code\u003e) and validate the legitimacy of the changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:21:00Z","date_published":"2024-01-03T14:21:00Z","id":"/briefs/2024-01-03-azure-app-uri-modification/","summary":"Detection of Azure application URI modifications that can be indicative of malicious activity, such as using dangling URIs, non-HTTPS URIs, wildcard domains, or URIs pointing to uncontrolled domains, potentially leading to initial access, stealth, persistence, credential access, and privilege escalation.","title":"Azure Application URI Configuration Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-app-uri-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","command-and-control","credential-access","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eCertUtil is a command-line utility included with Windows, designed for managing digital certificates and certificate services. Attackers frequently abuse it to \u0026ldquo;live off the land\u0026rdquo; by downloading malware, deobfuscating files, and establishing command and control channels within compromised environments. This activity leverages certutil.exe to perform actions typically associated with malicious payloads, blending in with legitimate system activity and evading traditional security measures. The tool\u0026rsquo;s capability to encode, decode, and retrieve files from URLs makes it a versatile asset for attackers aiming to maintain a low profile while executing malicious operations. This detection focuses on identifying specific command-line arguments indicative of this abuse, such as those used for encoding, decoding, and URL retrieval.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access through an undisclosed means (e.g., phishing, exploit).\u003c/li\u003e\n\u003cli\u003eThe attacker executes certutil.exe via cmd.exe or PowerShell.\u003c/li\u003e\n\u003cli\u003eCertutil is used with the \u003ccode\u003eurlcache\u003c/code\u003e parameter to download a malicious payload from a remote server.\u003c/li\u003e\n\u003cli\u003eCertutil uses the \u003ccode\u003edecode\u003c/code\u003e parameter to decode a base64-encoded payload, saving it to disk.\u003c/li\u003e\n\u003cli\u003eThe attacker uses certutil with \u003ccode\u003eencodehex\u003c/code\u003e to encode a binary into a hexadecimal representation to evade signature-based detection.\u003c/li\u003e\n\u003cli\u003eThe attacker then uses certutil with \u003ccode\u003edecodehex\u003c/code\u003e to decode the hexadecimal encoded data.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the decoded payload, gaining further control of the system.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes a command and control channel, using certutil to encode/decode communications.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious CertUtil Usage for Encoding/Decoding\u0026rdquo; to detect abuse of encoding/decoding functions within certutil.exe, focusing on unusual file types or destinations.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious CertUtil URL Download\u0026rdquo; to identify certutil.exe being used to download files from URLs, and tune the rule based on known good software deployment practices.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to ensure the rules above function correctly by capturing command-line arguments (as referenced in the logsource for each rule).\u003c/li\u003e\n\u003cli\u003eReview historical process execution logs for instances of certutil.exe using suspicious parameters like \u003ccode\u003edecode\u003c/code\u003e, \u003ccode\u003eencode\u003c/code\u003e, \u003ccode\u003eurlcache\u003c/code\u003e, \u003ccode\u003everifyctl\u003c/code\u003e, \u003ccode\u003eencodehex\u003c/code\u003e, \u003ccode\u003edecodehex\u003c/code\u003e, or \u003ccode\u003eexportPFX\u003c/code\u003e to identify potentially compromised systems.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:00:00Z","date_published":"2024-01-03T14:00:00Z","id":"/briefs/2024-01-suspicious-certutil/","summary":"Attackers abuse certutil.exe, a native Windows utility, to download/deobfuscate malware for command and control or data exfiltration, evading defenses.","title":"Suspicious CertUtil Commands Used for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-certutil/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","SentinelOne Cloud Funnel","Corretto JDK","UEM Proxy Server","UEM Core","dbeaver.exe","Docker","Chrome","Internet Explorer","PyCharm Community Edition","Firefox","VirtualBox","Puppet","nexpose","Silverfort AD Adapter","Nessus","VMware View","Advanced Port Scanner","DesktopCentral Agent","LanGuard","SAP BusinessObjects","SuperScan","ZSATunnel"],"_cs_severities":["medium"],"_cs_tags":["kerberoasting","credential-access","lateral-movement","windows"],"_cs_type":"threat","_cs_vendors":["Elastic","SentinelOne","Amazon","BlackBerry","DBeaver","Docker","Google","Microsoft","JetBrains","Mozilla","Oracle","Puppet Labs","Rapid7","Silverfort","Tenable","VMware","GFI","SAP","Zscaler"],"content_html":"\u003cp\u003eThis detection identifies unusual processes initiating network connections to the standard Kerberos port (88) on Windows systems. Typically, the \u003ccode\u003elsass.exe\u003c/code\u003e process handles Kerberos traffic on domain-joined hosts. The rule aims to detect processes other than \u003ccode\u003elsass.exe\u003c/code\u003e communicating with the Kerberos port, which could indicate malicious activity such as Kerberoasting (T1558.003) or Pass-the-Ticket (T1550.003). The detection is designed to work with data from Elastic Defend and SentinelOne Cloud Funnel. This can help security teams identify potential credential access attempts and lateral movement within the network.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises a user account or system within the domain.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a malicious binary or script (e.g., PowerShell) on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker uses tools like \u003ccode\u003eRubeus\u003c/code\u003e or \u003ccode\u003eKerberoast.ps1\u003c/code\u003e to enumerate and request TGS tickets.\u003c/li\u003e\n\u003cli\u003eThe unusual process (not \u003ccode\u003elsass.exe\u003c/code\u003e) sends Kerberos traffic to the domain controller.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the Kerberos tickets from memory or network traffic.\u003c/li\u003e\n\u003cli\u003eThe attacker cracks the offline TGS tickets to obtain service account passwords (Kerberoasting).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised service account credentials to move laterally within the network or access sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Kerberos Traffic from Unusual Process\u0026rdquo; Sigma rule to your SIEM and tune for your environment. Enable network connection logging to capture the necessary traffic.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the process execution chain and potential malicious binaries.\u003c/li\u003e\n\u003cli\u003eReview event ID 4769 for suspicious ticket requests as mentioned in the rule\u0026rsquo;s documentation.\u003c/li\u003e\n\u003cli\u003eExamine host services for suspicious entries as outlined in the original Elastic detection rule using Osquery.\u003c/li\u003e\n\u003cli\u003eMonitor for processes connecting to port 88, filtering out legitimate Kerberos clients like \u003ccode\u003elsass.exe\u003c/code\u003e, using the \u0026ldquo;Detect Kerberos Traffic from Non-Standard Process\u0026rdquo; Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate processes identified by the rule and compare them to the list of legitimate processes to identify unauthorized connections to the Kerberos port.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:00:00Z","date_published":"2024-01-03T14:00:00Z","id":"/briefs/2024-01-03-kerberoasting-unusual-process/","summary":"Detects network connections to the standard Kerberos port from an unusual process other than lsass.exe, potentially indicating Kerberoasting or Pass-the-Ticket activity on Windows systems.","title":"Kerberos Traffic from Unusual Process","url":"https://feed.craftedsignal.io/briefs/2024-01-03-kerberoasting-unusual-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Secure Access Firewall","Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud"],"_cs_severities":["high"],"_cs_tags":["rdp","bruteforce","credential-access","windows","network"],"_cs_type":"advisory","_cs_vendors":["Cisco","Splunk"],"content_html":"\u003cp\u003eThis analytic identifies potential Remote Desktop Protocol (RDP) brute force attacks by monitoring network traffic for RDP application activity. It detects potential RDP brute force attacks by identifying source IPs that have made more than 10 connection attempts to the same RDP port on a host within a one-hour window. The results are presented in a table that includes the source and destination IPs, destination port, number of attempts, and the times of the first and last connection attempts, helping to prioritize IPs based on the intensity of activity. This activity can lead to account compromise and potential ransomware deployment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker scans the network to identify systems with open RDP ports (TCP 3389).\u003c/li\u003e\n\u003cli\u003eThe attacker initiates multiple RDP connection attempts to a target host, using a list of common usernames and passwords or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe firewall logs each connection attempt, recording the source and destination IPs, ports, and timestamps.\u003c/li\u003e\n\u003cli\u003eSysmon logs the network connections with Event ID 3.\u003c/li\u003e\n\u003cli\u003eThe attacker continues to attempt connections, typically exceeding 10 attempts within an hour.\u003c/li\u003e\n\u003cli\u003eUpon successful authentication, the attacker gains unauthorized access to the target system.\u003c/li\u003e\n\u003cli\u003eThe attacker may then install malware, move laterally, or exfiltrate sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker might deploy ransomware like SamSam or Ryuk, as referenced in external reports.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure network traffic data is populating the Network_Traffic data model to enable the provided search query.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eRDP Bruteforce via Network Traffic\u003c/code\u003e to detect brute force attempts based on network connection patterns.\u003c/li\u003e\n\u003cli\u003eAdjust the count and duration thresholds in the detection query to tune the sensitivity for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate source IPs identified by the detection rule as potential attackers.\u003c/li\u003e\n\u003cli\u003eMonitor Sysmon EventID 3 for network connections to detect RDP brute-force attempts.\u003c/li\u003e\n\u003cli\u003eReview the referenced Zscaler and ReliaQuest articles for additional context and mitigation strategies.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-rdp-bruteforce/","summary":"This detection identifies potential RDP brute force attacks by monitoring network traffic for RDP application activity by detecting source IPs that have made more than 10 connection attempts to the same RDP port on a host within a one-hour window.","title":"Windows Remote Desktop Network Bruteforce Attempt","url":"https://feed.craftedsignal.io/briefs/2024-01-rdp-bruteforce/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Outlook"],"_cs_severities":["high"],"_cs_tags":["credential-access","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may attempt to access unsecured Outlook credentials stored within the Windows registry to compromise user email accounts. This involves leveraging tools or scripts to directly read sensitive registry keys containing password or authentication information. This activity often occurs after initial access has been gained through phishing, exploitation of vulnerabilities, or other means. Successful compromise of Outlook credentials can lead to significant data breaches, financial losses, and reputational damage. The credential access activity is detected via Windows Security Event logs, specifically Event ID 4663, focusing on registry paths associated with Outlook profiles. Multiple stealers and keyloggers have been observed utilizing this technique.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained via phishing, exploiting vulnerabilities, or other methods.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a malicious process (e.g., Snake Keylogger) on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe malicious process attempts to access the Windows registry using standard Windows APIs.\u003c/li\u003e\n\u003cli\u003eThe process targets specific registry paths where Outlook stores profile information: \u003ccode\u003e*\\Profiles\\Outlook\\9375CFF0413111d3B88A00104B2A6676*\u003c/code\u003e and \u003ccode\u003e*\\Windows Messaging Subsystem\\Profiles\\9375CFF0413111d3B88A00104B2A6676*\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWindows Security Event logging generates Event ID 4663 when the registry object is accessed.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the unsecured Outlook credentials from the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to access the victim\u0026rsquo;s Outlook account.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive information, sends malicious emails, or performs other unauthorized actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable \u0026ldquo;Audit Object Access\u0026rdquo; in Group Policy for Windows Security Event logs to track Event ID 4663 (per the \u0026ldquo;how_to_implement\u0026rdquo; section) and monitor registry access.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Suspicious Outlook Registry Access\u003c/code\u003e to identify unauthorized processes accessing Outlook credential registry paths.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u003ccode\u003eDetect Suspicious Outlook Registry Access\u003c/code\u003e to determine if credential theft occurred.\u003c/li\u003e\n\u003cli\u003eMonitor for processes other than \u003ccode\u003eoutlook.exe\u003c/code\u003e accessing the specific registry paths outlined in the \u003ccode\u003esearch\u003c/code\u003e field to identify potentially malicious activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-unsecured-outlook-credentials-access/","summary":"An attacker attempts to access unsecured Outlook credentials stored in the Windows registry, potentially leading to unauthorized access to email accounts and sensitive information.","title":"Unsecured Outlook Credentials Access in Windows Registry","url":"https://feed.craftedsignal.io/briefs/2024-01-unsecured-outlook-credentials-access/"}],"language":"en","next_url":"/tags/credential-access/page/2/feed.json","title":"CraftedSignal Threat Feed — Credential Access","version":"https://jsonfeed.org/version/1.1"}