{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/registry-modification/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Sysmon Registry Events","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["port-forwarding","registry-modification","command-and-control","defense-evasion","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers may configure port forwarding rules to bypass network segmentation restrictions, effectively using the compromised host as a jump box to access previously unreachable systems. This involves modifying the registry to redirect incoming TCP connections from a local port to another port or a remote computer. The technique is typically employed post-compromise to facilitate lateral movement and maintain unauthorized access within the network. This activity is detected by monitoring changes to the \u003ccode\u003eHKLM\\SYSTEM\\*ControlSet*\\Services\\PortProxy\\v4tov4\\\u003c/code\u003e registry subkeys.\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 target system through an exploit or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a command-line interface (e.g., \u003ccode\u003ecmd.exe\u003c/code\u003e or \u003ccode\u003epowershell.exe\u003c/code\u003e) with administrative privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell\u0026rsquo;s \u003ccode\u003eSet-ItemProperty\u003c/code\u003e cmdlet to modify the \u003ccode\u003eHKLM\\SYSTEM\\CurrentControlSet\\Services\\PortProxy\\v4tov4\\\u003c/code\u003e registry key.\u003c/li\u003e\n\u003cli\u003eThe attacker configures a new port forwarding rule by creating a new subkey under \u003ccode\u003ev4tov4\\\u003c/code\u003e with specific settings for the local port, remote address, and remote port.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the \u003ccode\u003eListenAddress\u003c/code\u003e, \u003ccode\u003eListenPort\u003c/code\u003e, \u003ccode\u003eConnectAddress\u003c/code\u003e, and \u003ccode\u003eConnectPort\u003c/code\u003e values within the new subkey.\u003c/li\u003e\n\u003cli\u003eThe attacker verifies the successful creation and activation of the port forwarding rule using \u003ccode\u003enetsh interface portproxy show v4tov4\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly created port forwarding rule to tunnel traffic through the compromised host, bypassing network segmentation.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the proxied connection to access internal resources and conduct further attacks, such as lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation enables attackers to bypass network segmentation restrictions, leading to unauthorized access to internal systems and data. This can facilitate lateral movement, data exfiltration, and further compromise of the network. The severity of the impact depends on the sensitivity of the accessible resources and the extent of the attacker\u0026rsquo;s lateral movement.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture modifications to the \u003ccode\u003eHKLM\\SYSTEM\\*ControlSet*\\Services\\PortProxy\\v4tov4\\\u003c/code\u003e registry subkeys, enabling detection of malicious port forwarding rule additions.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Port Forwarding Rule Addition via Registry Modification\u0026rdquo; to your SIEM to detect suspicious registry modifications related to port forwarding.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the process execution chain and the user account that performed the action.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit existing port forwarding rules to identify and remove any unauthorized or suspicious configurations.\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-port-forwarding-registry/","summary":"An adversary may abuse port forwarding to bypass network segmentation restrictions by creating a new port forwarding rule through modification of the Windows registry.","title":"Windows Port Forwarding Rule Addition via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2026-05-port-forwarding-registry/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","windows","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThis detection rule identifies modifications to Subject Interface Package (SIP) providers, a critical component of the Windows cryptographic system responsible for validating file signatures. Attackers may attempt to subvert trust controls by modifying SIP providers, allowing them to bypass signature validation checks and potentially inject malicious code into trusted processes. This activity is a form of defense evasion, allowing unauthorized code execution. The rule focuses on detecting suspicious registry changes associated with SIP providers, while excluding known benign processes to minimize false positives. The rule is designed for data generated by Elastic Defend, but also supports third-party data sources like CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon. This activity is related to MITRE ATT\u0026amp;CK technique T1553.003 (SIP and Trust Provider Hijacking).\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 through various means (e.g., phishing, exploitation of vulnerabilities).\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to gain necessary permissions to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry keys associated with SIP providers, specifically targeting \u003ccode\u003eCryptSIPDllPutSignedDataMsg\u003c/code\u003e and \u003ccode\u003eTrust\\\\FinalPolicy\u003c/code\u003e locations.\u003c/li\u003e\n\u003cli\u003eThe attacker changes the \u003ccode\u003eDll\u003c/code\u003e value within these registry keys to point to a malicious DLL.\u003c/li\u003e\n\u003cli\u003eThe system, upon attempting to validate a file signature, loads the malicious DLL instead of the legitimate SIP provider.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL executes arbitrary code, potentially injecting it into other processes.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the injected code to further compromise the system or network.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration, ransomware deployment, or establishing persistence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of SIP providers allows attackers to bypass signature validation checks, leading to the execution of unsigned or malicious code. This can compromise the integrity of the system, leading to data breaches, system instability, or further propagation of malware within the network. The impact can range from individual workstation compromise to widespread organizational damage, depending on the scope of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect SIP Provider Modification via Registry\u003c/code\u003e to your SIEM and tune it for your environment to detect suspicious registry modifications related to SIP providers.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to collect the necessary data for the Sigma rules above.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the rules, focusing on the process responsible for the registry change and the DLL being loaded, as described in the rule\u0026rsquo;s triage section.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unsigned or untrusted code.\u003c/li\u003e\n\u003cli\u003eMonitor the registry paths listed in the Sigma rules for unexpected changes.\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-sip-provider-modification/","summary":"This rule detects modifications to the registered Subject Interface Package (SIP) providers, which are used by the Windows cryptographic system to validate file signatures, potentially indicating an attempt to bypass signature validation or inject code for defense evasion.","title":"SIP Provider Modification for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-sip-provider-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","Elastic Endgame"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","ntlm","registry-modification","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eThis rule detects a specific defense evasion technique where an attacker modifies the Windows registry to force a system to use the less secure NTLMv1 authentication protocol. This is known as a NetNTLMv1 downgrade attack. The registry modification involves changing the \u003ccode\u003eLmCompatibilityLevel\u003c/code\u003e value, which controls the authentication level. Attackers with local administrator privileges can perform this modification to weaken the authentication mechanism, making it easier to intercept and crack credentials. The rule is designed to detect this activity by monitoring registry events from various sources, including Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Crowdstrike. It is important to monitor for this activity as it can lead to credential theft and further compromise of the system.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains local administrator privileges on a Windows system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a registry editor or command-line tool (e.g., \u003ccode\u003ereg.exe\u003c/code\u003e, PowerShell) to modify the \u003ccode\u003eLmCompatibilityLevel\u003c/code\u003e value in the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to one of the following registry paths: \u003ccode\u003eHKLM\\System\\CurrentControlSet\\Control\\Lsa\\LmCompatibilityLevel\u003c/code\u003e or \u003ccode\u003eHKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the \u003ccode\u003eLmCompatibilityLevel\u003c/code\u003e value to \u0026ldquo;0\u0026rdquo;, \u0026ldquo;1\u0026rdquo;, or \u0026ldquo;2\u0026rdquo; (or their hexadecimal equivalents \u0026ldquo;0x00000000\u0026rdquo;, \u0026ldquo;0x00000001\u0026rdquo;, \u0026ldquo;0x00000002\u0026rdquo;). These values force the system to use NTLMv1.\u003c/li\u003e\n\u003cli\u003eThe system now uses NTLMv1 for authentication attempts.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a man-in-the-middle attack to capture NTLMv1 authentication traffic using tools like Responder or Inveigh.\u003c/li\u003e\n\u003cli\u003eThe captured NTLMv1 hashes are cracked using brute-force or dictionary attacks, revealing the user\u0026rsquo;s credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to gain unauthorized access to network resources or other systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful NetNTLMv1 downgrade attack can lead to the compromise of user credentials, enabling attackers to move laterally within the network, access sensitive data, and potentially escalate privileges. The impact can range from data breaches to complete system compromise, depending on the attacker\u0026rsquo;s objectives and the compromised user\u0026rsquo;s privileges.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential NetNTLMv1 Downgrade Attack\u0026rdquo; to detect registry modifications setting \u003ccode\u003eLmCompatibilityLevel\u003c/code\u003e to insecure values (0, 1, 2) within the specified registry paths.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to ensure the necessary data is available for the Sigma rule to function correctly.\u003c/li\u003e\n\u003cli\u003eReview registry event logs for unauthorized modifications of \u003ccode\u003eLmCompatibilityLevel\u003c/code\u003e to confirm legitimate administrative actions.\u003c/li\u003e\n\u003cli\u003eImplement strict access control policies to limit local administrator privileges and reduce the attack surface.\u003c/li\u003e\n\u003cli\u003eMonitor the references URL for updates on recommended security configurations related to NTLM authentication.\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-netntlmv1-downgrade/","summary":"This brief details a registry modification attack that downgrades the system to NTLMv1 authentication, enabling NetNTLMv1 downgrade attacks, typically performed with local administrator privileges on Windows systems.","title":"Potential NetNTLMv1 Downgrade Attack via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2026-05-netntlmv1-downgrade/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Crowdstrike FDR"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","lateral-movement","persistence","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThe LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled (set to 1), allows remote connections from local members of the Administrators group to be granted full high-integrity tokens during negotiation. This bypasses User Account Control (UAC) restrictions, allowing for elevated privileges remotely. Attackers may modify this registry setting to facilitate lateral movement within a network. This rule detects modifications to this specific registry setting, alerting on potential unauthorized changes that could lead to defense evasion and privilege escalation. The modification of this policy has been observed being leveraged in conjunction with pass-the-hash attacks.\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 an exploit, such as phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains local administrator credentials on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the LocalAccountTokenFilterPolicy registry key to a value of 1. This is done to allow remote connections from local administrator accounts to receive high-integrity tokens. The registry key is typically located at \u003ccode\u003eHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\LocalAccountTokenFilterPolicy\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages a \u0026ldquo;pass the hash\u0026rdquo; attack (T1550.002) using the compromised local administrator credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to move laterally to other systems within the network using the \u0026ldquo;pass the hash\u0026rdquo; technique and the modified LocalAccountTokenFilterPolicy.\u003c/li\u003e\n\u003cli\u003eDue to the LocalAccountTokenFilterPolicy being enabled, the remote connection from the local administrator account receives a full high-integrity token.\u003c/li\u003e\n\u003cli\u003eThe attacker bypasses UAC on the remote system, gaining elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious activities on the remote system, 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 modification of the LocalAccountTokenFilterPolicy allows attackers to bypass User Account Control (UAC) and gain elevated privileges on remote systems, potentially leading to unauthorized access to sensitive data, lateral movement across the network, and the deployment of ransomware. The overall impact can include data breaches, financial loss, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eLocal Account TokenFilter Policy Enabled\u003c/code\u003e to your SIEM and tune for your environment to detect unauthorized modifications to the LocalAccountTokenFilterPolicy registry key.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture modifications to the registry, which is required for the \u003ccode\u003eLocal Account TokenFilter Policy Enabled\u003c/code\u003e Sigma rule.\u003c/li\u003e\n\u003cli\u003eReview the processes excluded in the rule query and ensure they are legitimate and necessary to prevent false positives.\u003c/li\u003e\n\u003cli\u003eMonitor registry events for changes to the \u003ccode\u003eHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\LocalAccountTokenFilterPolicy\u003c/code\u003e path, specifically looking for changes to the value data.\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-02-local-account-token-filter-policy-disabled/","summary":"Adversaries may modify the LocalAccountTokenFilterPolicy registry key to bypass User Account Control (UAC) and gain elevated privileges remotely by granting high-integrity tokens to remote connections from local administrators, facilitating lateral movement and defense evasion.","title":"Local Account TokenFilter Policy Modification for Defense Evasion and Lateral Movement","url":"https://feed.craftedsignal.io/briefs/2024-01-02-local-account-token-filter-policy-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["registry-modification","persistence","defense-evasion","scripting-engine"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis brief covers suspicious registry modifications made by scripting engine processes like WScript, CScript, and MSHTA. These processes are often abused by attackers to modify the registry without using standard tools like regedit.exe or reg.exe, potentially for evasion and persistence. Legitimate use of these scripting engines to modify the registry is uncommon, making this behavior a good indicator of potential malicious activity. Defenders should monitor for these processes interacting with sensitive registry keys. This activity was observed as of 2025 and continues to be a relevant technique for persistence and defense evasion in 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 via an exploit or social engineering.\u003c/li\u003e\n\u003cli\u003eThe attacker uses MSHTA.exe to execute malicious HTML Application code.\u003c/li\u003e\n\u003cli\u003eMSHTA.exe is used to launch a PowerShell script.\u003c/li\u003e\n\u003cli\u003eThe PowerShell script uses the Registry module to add a new registry key.\u003c/li\u003e\n\u003cli\u003eThe registry key is configured to execute a payload upon system startup.\u003c/li\u003e\n\u003cli\u003eThe attacker uses wscript.exe or cscript.exe to execute VBScript or JScript.\u003c/li\u003e\n\u003cli\u003eThe script modifies registry values to disable security features.\u003c/li\u003e\n\u003cli\u003eThe compromised system restarts, executing the payload defined in the registry, granting the attacker persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to establish persistence on the targeted system, enabling them to maintain access even after a reboot. This can lead to data theft, further malware deployment, or complete system compromise. The impact ranges from minor data breaches to significant operational disruptions. The scope of the impact depends on the attacker\u0026rsquo;s objectives and the compromised system\u0026rsquo;s role within the organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Registry Tampering by Potentially Suspicious Processes\u0026rdquo; to your SIEM to detect this specific activity, and tune for your environment (rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of wscript.exe, cscript.exe or mshta.exe modifying registry keys outside of known-good paths (rules).\u003c/li\u003e\n\u003cli\u003eMonitor registry events for unexpected modifications by scripting engines, focusing on persistence-related keys (rules).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T12:50:16Z","date_published":"2026-04-14T12:50:16Z","id":"/briefs/2026-04-susp-reg-mod/","summary":"Scripting engines such as WScript, CScript, and MSHTA are being used to make registry modifications, potentially for persistence or defense evasion.","title":"Suspicious Registry Modifications by Scripting Engines","url":"https://feed.craftedsignal.io/briefs/2026-04-susp-reg-mod/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Elastic Endgame","Crowdstrike"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","registry-modification","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThe DNS Global Query Block List (GQBL) is a Windows security feature designed to prevent the resolution of specific DNS names, commonly exploited in attacks like WPAD spoofing. Attackers who have obtained elevated privileges, such as DNSAdmin, can modify or disable this list to bypass security controls. This allows exploitation of hosts running WPAD with default settings. The modification of the GQBL can be used for privilege escalation and lateral movement within a network. This rule detects changes to the registry values associated with the GQBL, specifically \u0026ldquo;EnableGlobalQueryBlockList\u0026rdquo; and \u0026ldquo;GlobalQueryBlockList.\u0026rdquo; This activity could indicate an attacker attempting to weaken defenses to facilitate further malicious 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 system, possibly through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to obtain DNSAdmin rights.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u0026ldquo;EnableGlobalQueryBlockList\u0026rdquo; registry value to \u0026ldquo;0\u0026rdquo; or \u0026ldquo;0x00000000,\u0026rdquo; effectively disabling the GQBL.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker modifies the \u0026ldquo;GlobalQueryBlockList\u0026rdquo; registry value to remove \u0026ldquo;wpad\u0026rdquo; from the list.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the disabled GQBL to conduct WPAD spoofing attacks, redirecting network traffic to attacker-controlled servers.\u003c/li\u003e\n\u003cli\u003eThe attacker captures user credentials transmitted during WPAD authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the captured credentials to move laterally to other systems on the network.\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 modification or disabling of the DNS Global Query Block List can lead to WPAD spoofing attacks, credential theft, lateral movement, and ultimately, complete compromise of the network. Attackers can leverage this technique to gain unauthorized access to sensitive data or systems. The impact includes potential data breaches, financial loss, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eRegistry Modification of DNS Global Query Block List\u003c/code\u003e to your SIEM to detect unauthorized changes to the GQBL configuration.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture the necessary events for the Sigma rule to function (reference the logsource in the rule).\u003c/li\u003e\n\u003cli\u003eReview and restrict DNSAdmin privileges to only necessary accounts to minimize the attack surface (reference: Overview section).\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for unusual DNS queries or WPAD-related activity, correlating with registry modification events (reference: Attack Chain step 5).\u003c/li\u003e\n\u003cli\u003eRegularly audit registry settings related to DNS configuration, including the GQBL, to identify unauthorized modifications (reference: Attack Chain steps 3 \u0026amp; 4).\u003c/li\u003e\n\u003cli\u003eUpdate security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List (reference: Impact section).\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-dns-gqbl-modified/","summary":"Attackers with DNSAdmin privileges can modify or disable the DNS Global Query Block List (GQBL) in Windows, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement.","title":"DNS Global Query Block List Modified or Disabled","url":"https://feed.craftedsignal.io/briefs/2024-07-dns-gqbl-modified/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","Elastic Endgame","SentinelOne Cloud Funnel","Sysmon"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","lateral-movement","registry-modification","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eNetwork Level Authentication (NLA) is a security feature in Windows that requires users to authenticate before establishing a full RDP session, adding an extra layer of protection against unauthorized access. Attackers might attempt to disable NLA to gain access to the Windows sign-in screen without proper authentication. This tactic can facilitate the deployment of persistence mechanisms, such as leveraging Accessibility Features like Sticky Keys, or enable unauthorized remote access. This brief addresses the registry modifications associated with disabling NLA and provides detection strategies to identify such attempts. The references indicate that this technique is used in conjunction with other attacks for lateral movement within a compromised network.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access to the system is gained (potentially via compromised credentials or vulnerability exploitation).\u003c/li\u003e\n\u003cli\u003eThe attacker elevates privileges to modify system-level settings.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry key \u003ccode\u003eHKLM\\SYSTEM\\ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication\u003c/code\u003e to disable NLA.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eUserAuthentication\u003c/code\u003e value is set to \u0026ldquo;0\u0026rdquo; or \u0026ldquo;0x00000000\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to establish an RDP connection to the compromised system.\u003c/li\u003e\n\u003cli\u003eDue to the disabled NLA, the attacker bypasses the initial authentication screen.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages accessibility features (e.g., Sticky Keys) for persistence or further exploitation.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful disabling of NLA allows attackers to bypass authentication and gain unauthorized access to systems via RDP. This can lead to data theft, malware installation, or further lateral movement within the network. While the exact number of victims and sectors targeted are unspecified, the potential impact includes significant data breaches and system compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process-creation and registry event logging to detect the registry modifications (Elastic Defend, Elastic Endgame, Microsoft Defender XDR, SentinelOne, Sysmon).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided to detect attempts to modify the \u003ccode\u003eUserAuthentication\u003c/code\u003e registry key (Sysmon Registry Events).\u003c/li\u003e\n\u003cli\u003eReview and harden RDP configurations across the environment to prevent unauthorized access (Microsoft documentation).\u003c/li\u003e\n\u003cli\u003eMonitor endpoint security policies to detect unauthorized registry modifications (Endpoint Security Policies).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-31T12:00:00Z","date_published":"2024-01-31T12:00:00Z","id":"/briefs/2024-01-disable-nla/","summary":"Adversaries may disable Network-Level Authentication (NLA) by modifying specific registry keys to bypass authentication requirements for Remote Desktop Protocol (RDP) and enable persistence mechanisms.","title":"Network-Level Authentication (NLA) Disabled via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-disable-nla/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","persistence","execution","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may leverage scripting engines, such as \u003ccode\u003ewscript.exe\u003c/code\u003e and \u003ccode\u003ecscript.exe\u003c/code\u003e, to directly modify the Windows Registry. These scripting engines are often abused for malicious purposes, including establishing persistence, escalating privileges, or disabling security controls. These scripting engines can modify the registry without using standard tools like \u003ccode\u003eregedit.exe\u003c/code\u003e or \u003ccode\u003ereg.exe\u003c/code\u003e, making it harder to detect malicious registry changes. Defenders should be aware of processes using these engines to modify the registry, as this behavior is uncommon in legitimate software installations or administrative tasks.\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, potentially through social engineering or exploiting a software vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a script (VBScript, JScript) via \u003ccode\u003ewscript.exe\u003c/code\u003e or \u003ccode\u003ecscript.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe script contains commands to modify specific registry keys, such as the Run key for persistence (T1547.001).\u003c/li\u003e\n\u003cli\u003eThe scripting engine process (e.g., \u003ccode\u003ewscript.exe\u003c/code\u003e) directly interacts with the Windows Registry to set the new values.\u003c/li\u003e\n\u003cli\u003eUpon system restart or user logon, the modified registry key triggers the execution of a malicious payload.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence on the compromised system, allowing for continued access and control.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the persistent access to perform lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to persistent access on compromised systems, enabling attackers to execute malicious code, steal sensitive information, or disrupt critical services. The registry modifications performed by scripting engines can bypass traditional security measures and make it difficult to detect and remediate the attack. This can result in significant data loss, financial damage, and reputational harm to affected organizations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Registry Tampering by Potentially Suspicious Processes\u0026rdquo; to your SIEM to detect suspicious registry modifications made by scripting engines.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u0026ldquo;Registry Tampering by Potentially Suspicious Processes\u0026rdquo; for unusual or unauthorized registry changes.\u003c/li\u003e\n\u003cli\u003eMonitor registry events for modifications made by processes such as \u003ccode\u003ewscript.exe\u003c/code\u003e and \u003ccode\u003ecscript.exe\u003c/code\u003e (logsource: registry_event).\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-susp-reg-mod/","summary":"The use of scripting engines like WScript and CScript to modify the Windows registry can indicate an attempt to bypass standard tools and evade defenses, potentially for persistence or other malicious activities.","title":"Suspicious Registry Modifications by Scripting Engines","url":"https://feed.craftedsignal.io/briefs/2024-01-29-susp-reg-mod/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Defender","Security Agent"],"_cs_severities":["low"],"_cs_tags":["defense-evasion","windows","registry modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Trend Micro"],"content_html":"\u003cp\u003eAttackers commonly disable Windows Defender to evade detection and facilitate malicious activities. This involves modifying specific registry settings to either disable the service entirely or prevent it from starting automatically. The rule specifically identifies modifications to the \u003ccode\u003eDisableAntiSpyware\u003c/code\u003e and \u003ccode\u003eWinDefend\\\\Start\u003c/code\u003e registry keys. The DFIR Report has documented this technique in real-world incidents, highlighting its effectiveness in bypassing built-in security measures. This allows threat actors to operate with reduced risk of detection, enabling them to deploy malware, exfiltrate data, or perform other malicious actions without immediate interference from the endpoint security solution.\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, potentially through phishing or exploiting a software vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker elevates privileges to obtain the necessary permissions to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003eHKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\DisableAntiSpyware\u003c/code\u003e registry key to disable Windows Defender, setting its value to \u0026ldquo;1\u0026rdquo; or \u0026ldquo;0x00000001\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker modifies the \u003ccode\u003eHKLM\\\\System\\\\*ControlSet*\\\\Services\\\\WinDefend\\\\Start\u003c/code\u003e registry key to prevent the Windows Defender service from starting automatically. The attacker sets the value to \u0026ldquo;3\u0026rdquo; or \u0026ldquo;4\u0026rdquo; (or their hexadecimal equivalents \u0026ldquo;0x00000003\u0026rdquo;, \u0026ldquo;0x00000004\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe attacker verifies that Windows Defender is disabled by checking the Security Center or attempting to run a scan.\u003c/li\u003e\n\u003cli\u003eWith Windows Defender disabled, the attacker proceeds to deploy malware or execute malicious commands without interference from the antivirus software.\u003c/li\u003e\n\u003cli\u003eThe attacker may further disable security settings and block security-related indicators.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eIf successful, this attack can lead to a complete compromise of the affected system. With Windows Defender disabled, the system becomes vulnerable to malware infections, data exfiltration, and other malicious activities. This can result in financial losses, data breaches, and reputational damage for the targeted organization. The lack of immediate detection allows attackers to establish persistence and expand their foothold within the network.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Registry Modification to Disable Windows Defender\u0026rdquo; to your SIEM and tune for your environment to detect unauthorized changes to Windows Defender registry settings.\u003c/li\u003e\n\u003cli\u003eMonitor registry events for changes to the \u003ccode\u003eHKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\DisableAntiSpyware\u003c/code\u003e and \u003ccode\u003eHKLM\\\\System\\\\*ControlSet*\\\\Services\\\\WinDefend\\\\Start\u003c/code\u003e registry keys using the provided log sources.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the process and user account responsible for the registry modifications.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture the necessary data for the Sigma rule to function effectively.\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-defender-registry-disable/","summary":"Attackers modify the Windows Defender registry settings to disable the service or set the service to be started manually, evading defenses.","title":"Windows Defender Disabled via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-defender-registry-disable/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel"],"_cs_severities":["low"],"_cs_tags":["persistence","windows","registry modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne"],"content_html":"\u003cp\u003eThis detection identifies processes that modify the Windows services registry key directly, bypassing the standard Windows APIs. This behavior can signify an adversary\u0026rsquo;s attempt to establish persistence stealthily by creating new services or altering existing ones in an unexpected manner. The detection logic focuses on changes to the \u003ccode\u003eServiceDLL\u003c/code\u003e and \u003ccode\u003eImagePath\u003c/code\u003e values within specific registry paths associated with service configurations. This rule is designed for data generated by Elastic Defend and also supports Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon Registry Events. The rule helps security analysts identify potentially malicious activity related to service manipulation, which can lead to persistent access and control over compromised systems. The rule excludes known legitimate processes and paths to minimize false positives, focusing on anomalous registry modifications.\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 escalates privileges to gain administrative access, allowing them to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker directly modifies the \u003ccode\u003eHKLM\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL\u003c/code\u003e or \u003ccode\u003eHKLM\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath\u003c/code\u003e registry keys to point to a malicious DLL or executable.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s malicious DLL or executable is configured to run as a service, ensuring persistence across system reboots.\u003c/li\u003e\n\u003cli\u003eThe compromised service starts automatically during system startup or manually when triggered by the attacker.\u003c/li\u003e\n\u003cli\u003eThe malicious service executes arbitrary code, providing the attacker with persistent control over the system.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the compromised service to perform further malicious activities, such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to achieve persistence on the compromised system, maintaining access even after reboots or user logoffs. This can lead to long-term control over the system, enabling attackers to perform various malicious activities, including data theft, deployment of ransomware, or use of the system as a foothold for further attacks within the network. The severity is further amplified if critical services are targeted, potentially leading to system instability or denial of service.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture the necessary data for this detection (Data Source: Sysmon).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM to detect unusual service registry modifications (Sigma rules).\u003c/li\u003e\n\u003cli\u003eTune the Sigma rules by adding exceptions for legitimate software installations or updates that modify service registry keys directly (Sigma rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on processes modifying the \u003ccode\u003eServiceDLL\u003c/code\u003e or \u003ccode\u003eImagePath\u003c/code\u003e registry values (Sigma rules).\u003c/li\u003e\n\u003cli\u003eReview endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future (Response and remediation).\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-unusual-registry-persistence/","summary":"Detection of processes modifying the Windows services registry key directly, potentially indicating stealthy persistence attempts via abnormal service creation or modification.","title":"Unusual Persistence via Services Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-unusual-registry-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel","CrowdStrike FDR","Sysmon"],"_cs_severities":["medium"],"_cs_tags":["persistence","defense-evasion","registry-modification","ssp"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers can abuse the Windows Security Support Provider (SSP) mechanism to establish persistence on a compromised system. SSPs are DLLs loaded into the Local Security Authority Subsystem Service (LSASS) process, which handles authentication in Windows. By modifying specific registry keys related to SSP configuration, attackers can force LSASS to load malicious DLLs at startup, effectively creating a persistent backdoor. This technique is often used to maintain unauthorized access to a system even after a reboot. The registry keys of interest are \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\Security Packages\u003c/code\u003e and \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages\u003c/code\u003e. Successful exploitation allows the attacker to intercept and manipulate authentication credentials.\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 an exploit or compromised credentials (not detailed in source).\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to gain administrative rights on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry key \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\Security Packages\u003c/code\u003e to include a path to a malicious DLL.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker modifies the registry key \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages\u003c/code\u003e to include a path to a malicious DLL.\u003c/li\u003e\n\u003cli\u003eThe attacker triggers a system reboot, or restarts the LSASS process, causing the malicious SSP DLL to be loaded.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL intercepts authentication credentials and exfiltrates them or performs other malicious actions.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the system, even after reboots.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to achieve persistence and potentially compromise sensitive credentials handled by LSASS. This can lead to lateral movement within the network, data exfiltration, and further system compromise. The impact is significant as it bypasses standard security measures and provides a persistent foothold for malicious activities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious SSP Registry Modification\u0026rdquo; to your SIEM to detect unauthorized modifications to SSP registry keys.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to provide the necessary data for the Sigma rule to function.\u003c/li\u003e\n\u003cli\u003eContinuously monitor for unexpected processes writing to the \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\Security Packages\u003c/code\u003e and \u003ccode\u003eHKLM\\SYSTEM\\*\\ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages\u003c/code\u003e registry keys.\u003c/li\u003e\n\u003cli\u003eReview and whitelist legitimate software installers that frequently modify these registry entries to reduce false positives as mentioned in the brief.\u003c/li\u003e\n\u003cli\u003eEnsure access controls and permissions are strictly enforced to limit unauthorized modification of critical registry paths related to Security Support Providers.\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-ssp-registry-modification/","summary":"Adversaries may modify the Windows Security Support Provider (SSP) configuration in the registry to establish persistence or evade defenses.","title":"Suspicious Modifications to Windows Security Support Provider (SSP) Registry","url":"https://feed.craftedsignal.io/briefs/2024-01-ssp-registry-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["solarwinds","defense-evasion","registry-modification","supply-chain"],"_cs_type":"advisory","_cs_vendors":["SolarWinds","Microsoft","SentinelOne","Crowdstrike","Elastic"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of SolarWinds processes attempting to disable services by modifying their registry start type. This activity is associated with defense evasion tactics, potentially linked to initial access via supply chain compromise, similar to the SUNBURST campaign. The behavior involves SolarWinds binaries, such as \u003ccode\u003eSolarWinds.BusinessLayerHost*.exe\u003c/code\u003e and \u003ccode\u003eNetFlowService*.exe\u003c/code\u003e, manipulating registry entries related to service start configurations. This technique can be used to impair or disable security tools and services, allowing attackers to operate more freely within a compromised environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of the SolarWinds Orion platform, potentially through a supply chain attack.\u003c/li\u003e\n\u003cli\u003eDeployment of a malicious module or payload within the SolarWinds environment.\u003c/li\u003e\n\u003cli\u003eExecution of a SolarWinds process, such as \u003ccode\u003eSolarWinds.BusinessLayerHost*.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe SolarWinds process modifies the registry to change the start type of a service.\u003c/li\u003e\n\u003cli\u003eThe registry modification targets the \u003ccode\u003eHKLM\\SYSTEM\\ControlSet*\\Services\\*\\Start\u003c/code\u003e path.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eStart\u003c/code\u003e value is set to \u0026ldquo;4\u0026rdquo; or \u0026ldquo;0x00000004\u0026rdquo;, which disables the targeted service.\u003c/li\u003e\n\u003cli\u003eDisabling critical security services allows the attacker to evade detection and further compromise the system.\u003c/li\u003e\n\u003cli\u003eAttacker achieves persistence and performs lateral movement, exfiltrating data or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to the disabling of critical security services, such as antivirus, endpoint detection and response (EDR) agents, or other monitoring tools. This can significantly reduce the visibility of malicious activity within the network, potentially leading to data breaches, ransomware deployment, or other severe security incidents. The SolarWinds supply chain compromise affected numerous organizations globally, underscoring the potential impact of this type of attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSolarWinds Process Disabling Services via Registry\u003c/code\u003e to your SIEM to detect registry modifications by SolarWinds processes aimed at disabling services.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to provide the necessary data for the Sigma rule to function effectively.\u003c/li\u003e\n\u003cli\u003eReview and harden access controls for SolarWinds processes to restrict their ability to modify critical system settings.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the affected service and the timeline of events surrounding the registry modification.\u003c/li\u003e\n\u003cli\u003eUtilize threat intelligence platforms to stay informed about known SolarWinds-related attack patterns and indicators of compromise (IOCs).\u003c/li\u003e\n\u003cli\u003eMonitor endpoints for unusual behavior by SolarWinds processes, including network connections, file modifications, and process creations.\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-solarwinds-service-disable/","summary":"A SolarWinds binary is modifying the start type of a service to be disabled via registry modification, potentially to disable or impair security services.","title":"SolarWinds Process Disabling Services via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-solarwinds-service-disable/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["lateral-movement","defense-evasion","rdp","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eAttackers may enable Remote Desktop Protocol (RDP) to facilitate lateral movement within a compromised network. By modifying the \u003ccode\u003efDenyTSConnections\u003c/code\u003e registry key to a value of \u003ccode\u003e0\u003c/code\u003e, attackers can enable remote desktop connections, allowing them to access systems remotely. This technique can be employed using remote registry manipulation or tools like PsExec. The modification of the registry key is a common tactic used by ransomware operators and other threat actors to gain unauthorized access to victim servers. This activity can be performed to enable remote access for initial access or to regain access after persistence mechanisms have failed.\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 via an exploit or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a tool like PsExec or leverages remote registry modification capabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003efDenyTSConnections\u003c/code\u003e registry key, setting its value to \u003ccode\u003e0\u003c/code\u003e. This key is typically located in \u003ccode\u003eHKLM\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe system\u0026rsquo;s RDP service is enabled or re-enabled as a result of the registry change.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to connect to the now-enabled RDP service using valid or brute-forced credentials.\u003c/li\u003e\n\u003cli\u003eUpon successful authentication, the attacker gains interactive access to the system via RDP.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance, elevates privileges, and moves laterally to other systems.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys ransomware, exfiltrates data, or achieves other objectives.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the \u003ccode\u003efDenyTSConnections\u003c/code\u003e registry key allows unauthorized remote access to systems, potentially leading to lateral movement, data theft, or ransomware deployment. Organizations could suffer significant financial losses, reputational damage, and operational disruption. The scope of the impact depends on the attacker\u0026rsquo;s objectives and the level of access they gain within the environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;RDP Enabled via Registry\u0026rdquo; to detect modifications to the \u003ccode\u003efDenyTSConnections\u003c/code\u003e registry key (rules).\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for suspicious use of \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell to modify registry keys related to RDP (rules).\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and firewall rules to restrict RDP traffic to authorized hosts (overview).\u003c/li\u003e\n\u003cli\u003eReview the privileges assigned to users and ensure the principle of least privilege is enforced (overview).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture registry modifications (setup).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts related to registry modifications on critical systems (overview).\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-registry-enabled/","summary":"An adversary may enable Remote Desktop Protocol (RDP) access by modifying the `fDenyTSConnections` registry key, potentially indicating lateral movement preparation or defense evasion.","title":"RDP Enabled via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-rdp-registry-enabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["M365 Defender","Elastic Defend","SentinelOne Cloud Funnel","Sysmon"],"_cs_severities":["medium"],"_cs_tags":["lateral-movement","defense-evasion","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft","SentinelOne","Crowdstrike","Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies modifications to the \u003ccode\u003eNullSessionPipe\u003c/code\u003e registry setting in Windows. This setting defines named pipes that can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to enable lateral movement, allowing unauthorized access to network resources. By adding specific pipes to the \u003ccode\u003eNullSessionPipes\u003c/code\u003e registry key, an attacker can make services accessible without requiring authentication. This rule focuses on flagging modifications that introduce new accessible pipes, which could indicate malicious intent. The targeted configuration is located under \u003ccode\u003eHKLM\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters\u003c/code\u003e. The registry key \u003ccode\u003eNullSessionPipes\u003c/code\u003e is of particular interest when its values change.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of a system within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker gains elevated privileges on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the Windows Registry, specifically the \u003ccode\u003eHKLM\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters\\NullSessionPipes\u003c/code\u003e key. They add a new pipe name to this key, which will allow unauthenticated access to that named pipe.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell to modify the registry, potentially using commands like \u003ccode\u003ereg add\u003c/code\u003e or \u003ccode\u003eSet-ItemProperty\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eA remote system attempts to connect to the newly accessible named pipe on the compromised system without authenticating.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the now-accessible service or application associated with the named pipe to execute commands or transfer data.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages this access to move laterally within the network, compromising additional systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the \u003ccode\u003eNullSessionPipes\u003c/code\u003e registry setting can lead to unauthorized access to sensitive resources and lateral movement within the network. By enabling anonymous access to named pipes, attackers can potentially bypass authentication mechanisms and gain control over critical systems. While the direct number of victims is not specified, the impact can be significant, particularly in organizations where shared resources and services rely on secure authentication protocols.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Windows Registry auditing to capture changes to the \u003ccode\u003eNullSessionPipes\u003c/code\u003e registry key. This will allow you to detect unauthorized modifications as described in the overview.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;NullSessionPipe Registry Modification\u0026rdquo; to your SIEM and tune for your environment to identify malicious activity related to named pipe modifications.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the specific named pipes being added or modified in the registry event details, as detailed in the rule\u0026rsquo;s description.\u003c/li\u003e\n\u003cli\u003eRegularly review and validate the legitimacy of existing entries in the \u003ccode\u003eNullSessionPipes\u003c/code\u003e registry key to identify and remove any unauthorized pipes.\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-nullsessionpipe-modification/","summary":"Attackers modify the NullSessionPipe registry setting in Windows to enable anonymous access to named pipes, potentially facilitating lateral movement and unauthorized access to network resources.","title":"NullSessionPipe Registry Modification for Lateral Movement","url":"https://feed.craftedsignal.io/briefs/2024-01-nullsessionpipe-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defender XDR","ICA Client","SARemediation","Endpoint Connect"],"_cs_severities":["medium"],"_cs_tags":["credential-access","persistence","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Citrix","Dell","CheckPoint"],"content_html":"\u003cp\u003eAttackers may modify the network logon provider registry to gain persistence or access credentials. This involves registering a rogue network logon provider module that intercepts authentication credentials in clear text during user logon. The modification of the ProviderPath key under the NetworkProvider service registry path can be indicative of this malicious activity. The registry modification is often performed by non-system accounts and the adversary will attempt to hide the malicious DLL by placing it in common directories. This technique allows adversaries to steal user credentials or maintain persistent access to the compromised system.\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 exploiting a vulnerability or using compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker elevates privileges to obtain the necessary permissions to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker locates the registry key related to network logon providers: \u003ccode\u003eHKLM\\SYSTEM\\CurrentControlSet\\Services\\*\\NetworkProvider\\ProviderPath\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003eProviderPath\u003c/code\u003e registry value to point to a malicious DLL.\u003c/li\u003e\n\u003cli\u003eThe system loads the malicious DLL during the logon process.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL intercepts user credentials in clear text.\u003c/li\u003e\n\u003cli\u003eThe attacker harvests the intercepted credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the harvested credentials for lateral movement or further exploitation of the network.\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 user credentials, allowing attackers to gain unauthorized access to sensitive systems and data. Modification of the network logon provider registry enables attackers to maintain persistent access to the compromised system, even after a reboot. This can result in data breaches, financial losses, and reputational damage. The severity depends on the level of access granted to the compromised accounts 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\u003eMonitor registry modifications to the \u003ccode\u003eHKLM\\SYSTEM\\CurrentControlSet\\Services\\*\\NetworkProvider\\ProviderPath\u003c/code\u003e key, using the provided Sigma rule to detect suspicious changes.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture registry modifications.\u003c/li\u003e\n\u003cli\u003eRegularly audit network logon providers and verify the integrity and authenticity of the registered DLLs.\u003c/li\u003e\n\u003cli\u003eInvestigate processes modifying the registry and their associated file creation events for unknown or suspicious processes.\u003c/li\u003e\n\u003cli\u003eBlock execution of unsigned or untrusted DLLs in the network logon provider path.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Network Logon Provider Registry Modification\u0026rdquo; to your SIEM and tune for your environment.\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-network-logon-provider-modification/","summary":"Adversaries may modify the network logon provider registry to register a rogue network logon provider module for persistence and credential access by intercepting authentication credentials in clear text during user logon.","title":"Network Logon Provider Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-network-logon-provider-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Microsoft Defender","Elastic Defend","Elastic Endgame","Trend Micro Security Agent"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","registry-modification","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Trend Micro","Elastic","CrowdStrike","SentinelOne"],"content_html":"\u003cp\u003eAttackers commonly disable or tamper with Microsoft Defender features to evade detection and conceal malicious behavior within compromised Windows environments. This is often achieved by modifying specific registry keys that control the behavior and functionality of Defender components, such as real-time monitoring, exploit protection, and tamper protection itself. Such actions can significantly reduce the effectiveness of endpoint security, allowing malicious activities to proceed undetected. The references point to techniques that disable PUA protection, tamper protection, memory integrity, and real-time protection. This behavior is observed across various attack scenarios, including ransomware deployment and cryptocurrency mining campaigns.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained through an unspecified vector (e.g., phishing, exploitation of a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker obtains elevated privileges on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses an administrative tool like \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker disables real-time monitoring by setting \u003ccode\u003eHKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableRealtimeMonitoring\u003c/code\u003e to 1.\u003c/li\u003e\n\u003cli\u003eThe attacker disables tamper protection by setting \u003ccode\u003eHKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Features\\TamperProtection\u003c/code\u003e to 0.\u003c/li\u003e\n\u003cli\u003eThe attacker disables PUA Protection by setting \u003ccode\u003eHKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\PUAProtection\u003c/code\u003e to 0.\u003c/li\u003e\n\u003cli\u003eWith Defender weakened, the attacker executes malicious payloads, such as ransomware or cryptocurrency miners.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful tampering with Microsoft Defender can lead to a significant degradation of endpoint security posture. This can result in undetected malware infections, data breaches, and system compromise. Disabling Defender features can allow attackers to establish persistence, escalate privileges, and deploy malicious payloads without triggering alerts. The impact can range from individual system compromise to widespread network infection, depending on the attacker\u0026rsquo;s objectives and the extent of the tampering.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Microsoft Windows Defender Tampering - Disable Realtime Monitoring\u0026rdquo; to your SIEM to detect modifications to the \u003ccode\u003eDisableRealtimeMonitoring\u003c/code\u003e registry value.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Microsoft Windows Defender Tampering - Disable Tamper Protection\u0026rdquo; to detect modifications to the \u003ccode\u003eTamperProtection\u003c/code\u003e registry value.\u003c/li\u003e\n\u003cli\u003eMonitor registry modification events, specifically targeting keys associated with Microsoft Defender settings as described in the rule query.\u003c/li\u003e\n\u003cli\u003eInvestigate any process modifying Windows Defender registry settings that are not explicitly authorized, referencing the process exclusions in the rule query.\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-defender-tampering/","summary":"Adversaries may disable or tamper with Microsoft Defender features via registry modifications to evade detection and conceal malicious behavior on Windows systems.","title":"Microsoft Defender Tampering via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-defender-tampering/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Edge","Chrome","Firefox"],"_cs_severities":["low"],"_cs_tags":["defense-evasion","dns-over-https","registry-modification"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Google","Mozilla"],"content_html":"\u003cp\u003eThe use of DNS-over-HTTPS (DoH) can obscure network activity, potentially allowing malicious actors to bypass traditional DNS monitoring and conceal data exfiltration. When DoH is enabled, visibility into DNS query types, responses, and originating IPs is lost, hindering the detection of malicious activity. This behavior is detected by monitoring registry modifications associated with enabling DoH in popular browsers such as Microsoft Edge, Google Chrome, and Mozilla Firefox. The registry keys targeted are associated with settings that force the browsers to use secure DNS resolution, potentially circumventing organizational security policies.\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 initial access to a Windows system through various means, such as phishing or exploiting a software vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (if necessary):\u003c/strong\u003e The attacker may need to escalate privileges to modify registry settings.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker modifies the Windows registry to enable DNS-over-HTTPS (DoH) in web browsers like Edge, Chrome, or Firefox. This is achieved by modifying specific registry keys such as \u003ccode\u003eHKLM\\SOFTWARE\\Policies\\Microsoft\\Edge\\BuiltInDnsClientEnabled\u003c/code\u003e, \u003ccode\u003eHKLM\\SOFTWARE\\Google\\Chrome\\DnsOverHttpsMode\u003c/code\u003e, or \u003ccode\u003eHKLM\\SOFTWARE\\Policies\\Mozilla\\Firefox\\DNSOverHTTPS\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eObfuscation:\u003c/strong\u003e By enabling DoH, the attacker encrypts DNS queries, making it difficult for network monitoring tools to inspect DNS traffic.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCommand and Control:\u003c/strong\u003e The attacker establishes command and control (C2) communication with a remote server over encrypted DNS traffic, evading traditional network-based detection methods.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker uses the encrypted DNS channel to exfiltrate sensitive data, bypassing network security controls that rely on DNS inspection.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence (Optional):\u003c/strong\u003e The attacker might establish persistence by ensuring the DoH settings remain enabled across system reboots.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation leads to a loss of visibility into DNS traffic, hindering incident response and threat hunting efforts. Attackers can effectively hide command-and-control communications and data exfiltration activities. Although this activity by itself isn\u0026rsquo;t inherently malicious, it removes a layer of defense, increasing the risk that malicious activities will go undetected.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules provided in this brief to your SIEM to detect the enabling of DNS-over-HTTPS via registry modifications.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture the necessary events for the provided Sigma rules to function effectively.\u003c/li\u003e\n\u003cli\u003eReview and update security policies to ensure DNS-over-HTTPS is only enabled through approved channels and for legitimate purposes, reducing the risk of misuse, and create exceptions in the detection rule for systems where this is a known requirement.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on identifying the user account, process, and associated network activity (reference the investigation guide in the source URL).\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-dns-over-https-enabled/","summary":"Detection of DNS-over-HTTPS (DoH) being enabled via registry modifications on Windows systems, potentially indicating defense evasion and obfuscation of network activity by masking DNS queries.","title":"DNS-over-HTTPS Enabled via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-dns-over-https-enabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows","Elastic Defend","Microsoft Defender XDR"],"_cs_severities":["high"],"_cs_tags":["credential-access","registry-modification","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eThe WDigest security provider is a legacy authentication protocol that, when enabled, stores user passwords in cleartext within LSASS memory. Modern Windows versions (8.1+ and Server 2012 R2+) disable this behavior by default. Attackers can modify the \u003ccode\u003eUseLogonCredential\u003c/code\u003e registry value under the WDigest configuration to re-enable plaintext credential caching. This manipulation is a common precursor to credential dumping attacks, where tools like Mimikatz are used to extract sensitive information from LSASS. Defenders should monitor for unauthorized modifications to the WDigest configuration to prevent credential theft. The rule provided by Elastic aims to detect these modifications.\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 via compromised credentials or exploiting a vulnerability (e.g., phishing or RDP).\u003c/li\u003e\n\u003cli\u003eThe attacker executes code (e.g., PowerShell script or executable) with sufficient privileges to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe malicious code modifies the \u003ccode\u003eUseLogonCredential\u003c/code\u003e registry value under \u003ccode\u003eHKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\WDigest\u003c/code\u003e or a similar path.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the \u003ccode\u003eUseLogonCredential\u003c/code\u003e value to 1 (or 0x00000001), enabling plaintext storage of credentials.\u003c/li\u003e\n\u003cli\u003eA user logs on to the system, causing their credentials to be stored in cleartext in LSASS memory.\u003c/li\u003e\n\u003cli\u003eThe attacker uses credential dumping tools like Mimikatz to extract the cleartext passwords from LSASS.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials for lateral movement or to access sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the WDigest security provider can lead to widespread credential compromise. Attackers can harvest credentials for privileged accounts, enabling them to move laterally within the network, access sensitive resources, and potentially achieve domain dominance. This can 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\u003eDeploy the Sigma rule \u0026ldquo;Modification of WDigest Security Provider\u0026rdquo; to your SIEM to detect malicious registry modifications (rule \u003ccode\u003ed703a5af-d5b0-43bd-8ddb-7a5d500b7da5\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture the necessary data for the provided Sigma rule to function.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for unexpected processes modifying registry keys related to WDigest.\u003c/li\u003e\n\u003cli\u003eReview and restrict access control lists (ACLs) on the WDigest registry keys to prevent unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the process that made the modification, the user context, and any subsequent activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-wdigest-modification/","summary":"The rule detects attempts to modify the WDigest security provider in the registry to force the user's password to be stored in clear text in memory, which could lead to credential dumping.","title":"Modification of WDigest Security Provider","url":"https://feed.craftedsignal.io/briefs/2024-01-wdigest-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","registry-modification","code-signing"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eAttackers can modify the \u003ccode\u003eBehaviorOnFailedVerify\u003c/code\u003e registry key to disable code signing enforcement, allowing the execution of unsigned or self-signed code. This subverts trust controls and enables attackers to load and execute malicious drivers or other executables without proper validation. The targeted registry value controls how the system behaves when a driver\u0026rsquo;s signature verification fails, and altering this value can weaken system security. This technique is a common method to bypass security measures that rely on code signing to ensure the integrity and authenticity of software. This activity has been observed across various environments where endpoint detection and response solutions are deployed. The rule identifies registry modifications that can disable DSE.\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 target system through methods such as phishing, exploiting vulnerabilities, or social engineering.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to obtain administrative rights, which are required to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a command-line tool, such as \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell, to modify the \u003ccode\u003eBehaviorOnFailedVerify\u003c/code\u003e registry value.\u003c/li\u003e\n\u003cli\u003eThe registry value is changed to either \u0026ldquo;0\u0026rdquo; or \u0026ldquo;1\u0026rdquo;, effectively disabling or weakening code signing enforcement.\u003c/li\u003e\n\u003cli\u003eThe attacker loads an unsigned or self-signed malicious driver or executable.\u003c/li\u003e\n\u003cli\u003eThe malicious code executes without proper validation, allowing the attacker to perform malicious activities on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker may then establish persistence, move laterally within the network, or exfiltrate sensitive data.\u003c/li\u003e\n\u003cli\u003eThe final objective could be data theft, ransomware deployment, or establishing a long-term foothold within the compromised environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the code signing policy can lead to the execution of arbitrary code without proper validation, potentially compromising the entire system. Attackers can use this technique to install rootkits, bypass security software, and perform other malicious activities. Depending on the attacker\u0026rsquo;s objectives, this can result in data theft, system instability, or complete system compromise. While no specific victim count or sector is mentioned, any Windows system where code signing is relied upon for security is potentially at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eCode Signing Policy Modification Through Registry\u003c/code\u003e to your SIEM to detect suspicious registry modifications (rule.name). Tune the rule to exclude legitimate software installers or system administration tools that may temporarily modify these settings.\u003c/li\u003e\n\u003cli\u003eMonitor registry events, specifically changes to the \u003ccode\u003eBehaviorOnFailedVerify\u003c/code\u003e value, to identify potential attempts to disable code signing policy (event.type, registry.value, registry.data.strings).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the detection rule, focusing on the process execution chain and the legitimacy of the user account performing the action (rule.note).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to gain better visibility into registry modifications (setup).\u003c/li\u003e\n\u003cli\u003eEnsure that Driver Signature Enforcement (DSE) is enabled on all systems to prevent the loading of unsigned drivers (rule.description).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious Process Modifying Code Signing Policy Registry\u003c/code\u003e to identify potentially malicious processes attempting to disable code signing (rule.name).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-code-signing-policy-modification/","summary":"Attackers may modify the Windows registry to disable code signing policy, allowing the execution of unsigned or self-signed malicious code, thereby bypassing security controls and enabling defense evasion.","title":"Code Signing Policy Modification Through Registry","url":"https://feed.craftedsignal.io/briefs/2024-01-code-signing-policy-modification/"}],"language":"en","title":"CraftedSignal Threat Feed — Registry-Modification","version":"https://jsonfeed.org/version/1.1"}