{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/registry/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["registry","symlink","race-condition","accessibility","privilege-escalation","persistence","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eRegPwnBOF is an exploit leveraging a registry symlink race condition within the Windows Accessibility ATConfig mechanism. This vulnerability allows an unprivileged user to manipulate protected areas of the registry, specifically HKLM, which are typically reserved for administrators or system processes. By exploiting this race condition, an attacker can write arbitrary values to these protected keys. The initial report surfaced around March 2026, highlighting the potential for unauthorized persistence and privilege escalation. This circumvents standard Windows security controls, posing a significant risk to system integrity and confidentiality. The exploit\u0026rsquo;s accessibility to non-administrator users makes it particularly dangerous in environments where least-privilege principles are not strictly enforced.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unprivileged user initiates the ATConfig mechanism within the Windows Accessibility features.\u003c/li\u003e\n\u003cli\u003eThe exploit creates a registry symlink pointing to a protected HKLM key.\u003c/li\u003e\n\u003cli\u003eA race condition is triggered during the ATConfig process, allowing the exploit to bypass security checks.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages this race condition to overwrite the target HKLM registry key with arbitrary data.\u003c/li\u003e\n\u003cli\u003eThe modified registry key is used to establish persistence, for example, by creating a Run key.\u003c/li\u003e\n\u003cli\u003eUpon system restart or user login, the malicious payload associated with the modified Run key is executed.\u003c/li\u003e\n\u003cli\u003eThe attacker gains elevated privileges by executing code within the context of a privileged process.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of RegPwnBOF allows an attacker to gain persistent access to a compromised system and escalate their privileges to administrator level. This can lead to complete system compromise, data theft, and the installation of malware. The impact is magnified by the fact that this exploit can be triggered by a normal user, bypassing traditional access controls. The number of potential victims is considerable, as the vulnerability exists within the Windows Accessibility features, which are enabled by default on many systems.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor registry modifications targeting HKLM keys, especially those related to Accessibility features, using a process_creation log source and the provided Sigma rules.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and least-privilege principles to limit the ability of unprivileged users to interact with system-level configurations.\u003c/li\u003e\n\u003cli\u003eInvestigate any unusual registry symlink creation events using file_event logs, particularly those involving the ATConfig mechanism, to identify potential RegPwnBOF exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-19T05:23:44Z","date_published":"2026-03-19T05:23:44Z","id":"/briefs/2024-01-regpwnbof/","summary":"RegPwnBOF exploits a registry symlink race condition in the Windows Accessibility ATConfig mechanism, enabling a normal user to write arbitrary values to protected HKLM registry keys for persistence and privilege escalation.","title":"RegPwnBOF Registry Symlink Race Condition Exploit","url":"https://feed.craftedsignal.io/briefs/2024-01-regpwnbof/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","CrowdStrike Falcon","SentinelOne Cloud Funnel"],"_cs_severities":["low"],"_cs_tags":["persistence","windows","netsh","registry"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eThe \u003ccode\u003enetsh.exe\u003c/code\u003e utility in Windows supports the addition of Helper DLLs to extend its functionality. An attacker can abuse this mechanism to establish persistence by adding a malicious DLL. When \u003ccode\u003enetsh.exe\u003c/code\u003e is executed, the malicious DLL is loaded and executed, allowing the attacker to run arbitrary code with the privileges of the user or process that initiated \u003ccode\u003enetsh.exe\u003c/code\u003e. This can be done by administrators or scheduled tasks, making it a stealthy and effective persistence technique. The registry key targeted by this technique is \u003ccode\u003eHKLM\\Software\\Microsoft\\netsh\\\u003c/code\u003e.\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 through unspecified means.\u003c/li\u003e\n\u003cli\u003eAttacker creates a malicious DLL to be used as a Netsh Helper DLL.\u003c/li\u003e\n\u003cli\u003eAttacker modifies the Windows Registry to add the malicious DLL as a Netsh Helper DLL under \u003ccode\u003eHKLM\\Software\\Microsoft\\netsh\\\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe system administrator or a scheduled task executes \u003ccode\u003enetsh.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003enetsh.exe\u003c/code\u003e loads and executes the malicious DLL, granting the attacker code execution.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL performs its intended actions, such as establishing a reverse shell or deploying additional malware.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence on the system through the malicious Netsh Helper DLL.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to establish persistent access to a compromised system. This can lead to data theft, system compromise, and further malicious activities. While the risk score is low, the persistence mechanism can allow attackers to maintain a foothold for extended periods, increasing the potential for significant damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor registry modifications under the \u003ccode\u003eHKLM\\Software\\Microsoft\\netsh\\\u003c/code\u003e path for suspicious DLL additions using the \u0026ldquo;Netsh Helper DLL Registry Modification\u0026rdquo; Sigma rule.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to collect the necessary data for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by reviewing the DLL file properties, timestamps, and related processes.\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-netsh-helper-dll/","summary":"Attackers may abuse the Netsh Helper DLL functionality by adding malicious DLLs to execute payloads every time the netsh utility is executed via administrators or scheduled tasks, achieving persistence.","title":"Netsh Helper DLL Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-netsh-helper-dll/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Endpoint Security","SentinelOne Cloud Funnel","Crowdstrike FDR","Sysmon"],"_cs_severities":["high"],"_cs_tags":["defense-evasion","amsi","registry","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers can disable the Antimalware Scan Interface (AMSI) to evade detection by modifying the \u003ccode\u003eAmsiEnable\u003c/code\u003e registry key. This technique is commonly employed to execute malicious scripts without triggering security warnings or blocks. The AMSI, a Windows feature, allows applications and services to request the scanning of potentially malicious content (e.g., PowerShell scripts, JScript) before execution. By setting the \u003ccode\u003eAmsiEnable\u003c/code\u003e value to 0, an attacker can disable AMSI for the current user, effectively bypassing real-time script scanning. This action is often a precursor to deploying further malicious payloads or establishing persistence on a compromised system. This behavior has been observed since at least 2019 and continues to be a relevant defense evasion technique.\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, possibly through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a script or binary that attempts to modify the \u003ccode\u003eAmsiEnable\u003c/code\u003e registry key.\u003c/li\u003e\n\u003cli\u003eThe script or binary uses \u003ccode\u003ereg.exe\u003c/code\u003e, PowerShell, or another tool to set the \u003ccode\u003eAmsiEnable\u003c/code\u003e registry value to 0. The registry key location is typically \u003ccode\u003eHKEY_USERS\\\u0026lt;SID\u0026gt;\\Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAfter successfully disabling AMSI, the attacker proceeds to execute malicious scripts or code. These scripts may use \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003ewscript.exe\u003c/code\u003e, or \u003ccode\u003ecscript.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe malicious scripts download and execute additional payloads, such as malware or remote access tools (RATs).\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement within the network using the compromised system as a pivot.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to establish persistence, ensuring continued access to the system even after reboots.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data or deploys ransomware to achieve their objectives.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the \u003ccode\u003eAmsiEnable\u003c/code\u003e registry key allows attackers to execute malicious scripts without triggering AMSI alerts, leading to potential malware infections, data breaches, and system compromise. Disabling AMSI significantly reduces the effectiveness of endpoint security solutions, making the system more vulnerable to attack. The impact can range from individual workstation compromise to widespread network infections, depending on the attacker\u0026rsquo;s objectives and 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\u003eDetect AmsiEnable Registry Modification via Registry Events\u003c/code\u003e to your SIEM to detect modifications to the \u003ccode\u003eAmsiEnable\u003c/code\u003e registry key.\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\u003eMonitor process creation events for processes modifying registry keys, especially \u003ccode\u003ereg.exe\u003c/code\u003e and PowerShell, using the rule \u003ccode\u003eDetect AmsiEnable Registry Modification via Process Creation\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by these rules promptly to determine if the activity is malicious or legitimate.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unsigned or untrusted scripts and binaries.\u003c/li\u003e\n\u003cli\u003eHarden systems by restricting user permissions to modify critical registry keys.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-27T18:23:00Z","date_published":"2024-01-27T18:23:00Z","id":"/briefs/2024-01-amsi-registry-disable/","summary":"Adversaries modify the AmsiEnable registry key to 0 to disable Windows Script AMSI scanning, bypassing AMSI protections for Windows Script Host or JScript execution.","title":"AMSI Enable Registry Key Modification for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-amsi-registry-disable/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Office","Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Crowdstrike"],"_cs_severities":["low"],"_cs_tags":["persistence","registry","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThe \u0026ldquo;Office Test\u0026rdquo; registry key, located under \u003ccode\u003eHKCU\\Software\\Microsoft\\Office Test\\Special\\Perf\u003c/code\u003e, is a legitimate feature that allows specifying a DLL to be executed every time an MS Office application is started. Attackers can abuse this functionality by modifying the registry to point to a malicious DLL, achieving persistence on a compromised host. This allows for continued malicious activity even after a system restart or user logout. Elastic has published a rule to detect this behavior. The modification of this registry key, excluding deletions, is a strong indicator of potential abuse, and can be detected via endpoint detection and response (EDR) solutions as well as traditional Sysmon logging.\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, often through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes a foothold and escalates privileges to make necessary registry modifications.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003eHKCU\\Software\\Microsoft\\Office Test\\Special\\Perf\u003c/code\u003e registry key, adding a new entry or modifying an existing one to point to a malicious DLL.\u003c/li\u003e\n\u003cli\u003eThe attacker ensures the malicious DLL is present on the system, either by dropping it directly or using existing system tools to download it.\u003c/li\u003e\n\u003cli\u003eA user launches a Microsoft Office application (e.g., Word, Excel, PowerPoint).\u003c/li\u003e\n\u003cli\u003eThe Office application loads the DLL specified in the \u0026ldquo;Office Test\u0026rdquo; registry key during startup.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL executes its payload, which could include establishing a reverse shell, installing malware, or exfiltrating data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence, allowing them to regain access to the system each time an Office application is started.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to maintain persistent access to a compromised system. The injected DLL can be used to execute arbitrary code, potentially leading to data theft, malware installation, or further compromise of the network. The relatively low risk score suggests a common technique, but the potential for persistent access makes it a significant threat.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM and tune for your environment to detect unauthorized modifications to the \u0026ldquo;Office Test\u0026rdquo; registry key (\u003ccode\u003eHKCU\\Software\\Microsoft\\Office Test\\Special\\Perf\\*\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon Registry event logging to capture registry modifications and activate the Sigma rule above.\u003c/li\u003e\n\u003cli\u003eMonitor process execution logs for Office applications to detect if a suspicious DLL has been loaded or executed, as described in the investigation guide.\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and alerting for similar registry modifications across the network, as described in the remediation steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-27T17:30:00Z","date_published":"2024-01-27T17:30:00Z","id":"/briefs/2024-01-office-test-registry-persistence/","summary":"Attackers modify the Microsoft Office 'Office Test' Registry key to achieve persistence by specifying a malicious DLL that executes upon application startup.","title":"Microsoft Office 'Office Test' Registry Persistence Abuse","url":"https://feed.craftedsignal.io/briefs/2024-01-office-test-registry-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defender XDR","Cloud Endpoint","AutomationManagerAgent"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","powershell","registry"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Trend Micro","N-able"],"content_html":"\u003cp\u003eAttackers frequently disable PowerShell Script Block Logging to evade detection and hide malicious activities on compromised systems. By modifying the \u003ccode\u003eEnableScriptBlockLogging\u003c/code\u003e registry value to \u0026lsquo;0\u0026rsquo; or \u0026lsquo;0x00000000\u0026rsquo;, adversaries can significantly reduce the visibility into their PowerShell-based attacks. This technique is particularly effective when followed by script-driven activity, making it harder for security teams to identify and respond to threats. This behavior has been observed across multiple environments, including those utilizing endpoint detection and response solutions such as Elastic Defend, Microsoft Defender XDR, SentinelOne, and CrowdStrike. The rule was last updated on 2026-05-04 and is designed to detect these specific registry modifications.\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, possibly through phishing or exploitation of a vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker may attempt to escalate privileges to gain necessary permissions to modify the registry.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker modifies the registry to disable PowerShell Script Block Logging by setting \u003ccode\u003eHKEY_LOCAL_MACHINE\\Software\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\\EnableScriptBlockLogging\u003c/code\u003e to 0 or 0x00000000 using \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell itself.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExecution:\u003c/strong\u003e The attacker executes malicious PowerShell scripts, leveraging the disabled logging to avoid detection. These scripts may be used for reconnaissance, lateral movement, or data exfiltration.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence using various techniques, such as creating scheduled tasks or modifying registry keys to ensure continued access to the system.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCommand and Control:\u003c/strong\u003e The attacker establishes a command and control channel to communicate with the compromised system and issue further instructions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally to other systems on the network, compromising additional assets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their final objective, such as data theft, ransomware deployment, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful disabling of PowerShell Script Block Logging can severely hinder incident response efforts, allowing attackers to operate undetected for extended periods. Organizations may experience data breaches, financial losses, and reputational damage. The impact can be widespread as attackers leverage compromised systems for lateral movement and further exploitation. The loss of PowerShell logging can blind security teams, making it difficult to reconstruct attacker actions and contain the breach.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003ePowerShell_Script_Block_Logging_Disabled\u003c/code\u003e to your SIEM to detect registry modifications that disable PowerShell Script Block Logging.\u003c/li\u003e\n\u003cli\u003eMonitor registry events for changes to the \u003ccode\u003eEnableScriptBlockLogging\u003c/code\u003e value, focusing on events with \u003ccode\u003eregistry.data.strings\u003c/code\u003e set to \u0026ldquo;0\u0026rdquo; or \u0026ldquo;0x00000000\u0026rdquo; (see rule \u003ccode\u003ePowerShell_Script_Block_Logging_Disabled\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to capture the necessary data for the Sigma rules to function effectively (see references).\u003c/li\u003e\n\u003cli\u003eReview and harden PowerShell execution policies to prevent unauthorized script execution (related to tactic TA0005).\u003c/li\u003e\n\u003cli\u003eImplement strict access controls to limit who can modify registry settings related to PowerShell logging (related to tactic TA0005).\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-09-disable-powershell-scriptblock-logging/","summary":"Attackers may disable PowerShell Script Block Logging by modifying the registry to conceal their activities on the host and evade detection by setting the `EnableScriptBlockLogging` registry value to 0, impacting security monitoring and incident response capabilities.","title":"PowerShell Script Block Logging Disabled via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-09-disable-powershell-scriptblock-logging/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["persistence","registry","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies unusual modifications to less commonly altered registry keys, which may indicate stealthy persistence attempts on Windows systems. Adversaries exploit registry keys for persistence, ensuring malicious code executes on startup or during specific events. The rule filters out benign changes by excluding known legitimate processes and paths, focusing on suspicious alterations. The rule focuses on changes to registry keys such as \u003ccode\u003eHKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Winlogon\\\\Shell\u003c/code\u003e and \u003ccode\u003eHKEY_USERS\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Windows\\\\Run\u003c/code\u003e. This rule is designed for data generated by Elastic Defend and also supports third-party data sources such as Sysmon. The rule was 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 the system (e.g., through phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes code on the system, potentially using a dropper or exploit.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies uncommon registry keys suitable for persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry key to point to a malicious executable or script. This may involve adding a new entry or modifying an existing one.\u003c/li\u003e\n\u003cli\u003eThe system restarts, or the user logs in, triggering the execution of the malicious code through the modified registry key.\u003c/li\u003e\n\u003cli\u003eThe malicious code executes with the privileges of the user or system, depending on the registry key modified.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence, allowing them to maintain access to the system even after restarts.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious activities such as data exfiltration, lateral movement, or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to persistent access to the compromised system, allowing the attacker to maintain control and execute malicious activities. This can lead to data theft, system disruption, or further compromise of the network. The impact can range from a single workstation being compromised to a widespread enterprise-level breach, depending on the attacker\u0026rsquo;s objectives and the scope of the initial compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Uncommon Registry Persistence Change\u0026rdquo; Sigma rule to your SIEM to detect modifications to uncommon registry persistence keys and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to ensure the visibility required for the Sigma rule to function effectively (see references).\u003c/li\u003e\n\u003cli\u003eReview and tune the filter conditions in the Sigma rule to reduce false positives, specifically excluding legitimate software installations, system maintenance processes, and administrative scripts.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the process responsible for the registry modification and correlating it with other suspicious activities.\u003c/li\u003e\n\u003cli\u003eBlock execution of known malicious executables and scripts identified during the investigation to prevent further compromise.\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-uncommon-registry-persistence/","summary":"This rule detects changes to uncommon registry persistence keys on Windows systems that are not commonly used or modified by legitimate programs, which could indicate an adversary's attempt to persist in a stealthy manner by modifying registry keys for persistence, ensuring malicious code executes on startup or during specific events.","title":"Uncommon Registry Persistence Change Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-uncommon-registry-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Edge","Cisco Spark","Admin By Request","Cloud Signature Update Agent","Vantage","Adobe Reader and Acrobat Manager"],"_cs_severities":["low"],"_cs_tags":["persistence","registry","runkey"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Cisco","FastTrack Software","Exclaimer Ltd","Lenovo","Adobe"],"content_html":"\u003cp\u003eAttackers often modify registry run keys to achieve persistence on a system. By adding entries to these keys, they ensure that a malicious program executes automatically whenever a user logs in. This technique allows the attacker to maintain access to the compromised system even after reboots or other interruptions. The programs added to these run keys execute under the context of the user account, inheriting its permissions. This activity is often difficult to distinguish from legitimate software installations or updates, requiring careful analysis to identify malicious intent. Elastic has observed this activity and created a detection rule to identify this 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 target system.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies registry run key locations for persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies a registry run key (e.g., \u003ccode\u003eHKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\u003c/code\u003e) using tools such as \u003ccode\u003ereg.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker adds a malicious executable path to the registry key.\u003c/li\u003e\n\u003cli\u003eThe system is restarted, or a user logs in.\u003c/li\u003e\n\u003cli\u003eThe malicious executable is launched automatically as part of the logon process.\u003c/li\u003e\n\u003cli\u003eThe malicious executable establishes a connection to a command-and-control server.\u003c/li\u003e\n\u003cli\u003eThe attacker gains remote access to the compromised system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to maintain persistent access to compromised systems, enabling them to perform unauthorized activities such as data theft, lateral movement, and deployment of ransomware. While each instance may not cause immediate critical damage, the cumulative effect of multiple persistent infections across an environment can lead to significant data breaches and operational disruption. The Elastic rule attempts to minimize false positives with built-in filters for common legitimate applications and processes like \u003ccode\u003ectfmon.exe\u003c/code\u003e, but tuning is required.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to detect suspicious modifications to registry run keys and tune it to filter out legitimate application updates.\u003c/li\u003e\n\u003cli\u003eEnable registry event logging to capture modifications made to the registry, ensuring that the Sigma rule can function correctly.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, examining the parent process of the process modifying the registry for suspicious activity.\u003c/li\u003e\n\u003cli\u003eBlock known malicious executables and domains identified during triage to prevent further infection.\u003c/li\u003e\n\u003cli\u003eUse endpoint detection and response (EDR) solutions like Elastic Defend to gain enhanced visibility into endpoint activity and detect malicious behavior associated with persistence mechanisms.\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-run-key-registry-modification/","summary":"Attackers modify registry run keys or startup keys to achieve persistence by referencing a program that executes when a user logs in or the system boots.","title":"Startup or Run Key Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-run-key-registry-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Windows","Microsoft Defender XDR","Commvault","Nvidia Display Driver","Elastic Defend","SentinelOne Cloud Funnel","CrowdStrike FDR"],"_cs_severities":["medium"],"_cs_tags":["persistence","defense-evasion","appinit-dlls","registry","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Commvault","Nvidia","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eThe AppInit DLLs mechanism allows dynamic-link libraries (DLLs) to be loaded into every process that creates a user interface (loads user32.dll) on Microsoft Windows operating systems. This mechanism is intended for customization of the user interface and behavior of Windows-based applications. However, attackers can abuse this by adding malicious DLLs to the registry locations associated with AppInit DLLs. This enables them to execute code with elevated privileges, similar to process injection, and maintain a persistent presence on the compromised machine. This technique is often used to maintain access after initial compromise. Detection focuses on registry modifications to the relevant keys, excluding known legitimate processes to minimize false positives. The referenced Elastic rule was 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 the system through a vulnerability, phishing, or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the AppInit DLLs registry keys: \u003ccode\u003eHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\u003c/code\u003e or \u003ccode\u003eHKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Windows\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003eAppInit_DLLs\u003c/code\u003e registry value to include the path to their malicious DLL.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s DLL is placed on the filesystem, typically in a location where it will persist across reboots.\u003c/li\u003e\n\u003cli\u003eAny new process that loads user32.dll will automatically load the attacker\u0026rsquo;s malicious DLL.\u003c/li\u003e\n\u003cli\u003eThe malicious DLL executes arbitrary code within the context of the newly created process.\u003c/li\u003e\n\u003cli\u003eThe attacker can use this code execution to perform further actions, such as installing backdoors or escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the system through the malicious DLL loaded into every user interface process.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to execute arbitrary code within the context of any process that loads \u003ccode\u003euser32.dll\u003c/code\u003e. This provides a persistent mechanism for maintaining access to the compromised system. The attacker gains code execution with elevated privileges, similar to process injection. This can lead to data theft, system compromise, or further lateral movement within the network. While no specific victim counts are mentioned, the widespread use of Windows makes this a potentially high-impact vulnerability.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor registry modifications to the \u003ccode\u003eAppInit_DLLs\u003c/code\u003e value in \u003ccode\u003eHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\u003c/code\u003e and \u003ccode\u003eHKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Windows\u003c/code\u003e using the \u0026ldquo;Registry Persistence via AppInit DLL Modification\u0026rdquo; Sigma rule.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to provide the data required for the Sigma rule to function correctly.\u003c/li\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Registry Persistence via AppInit DLL Modification\u0026rdquo; Sigma rule to your SIEM and tune the filter to exclude known-good DLL paths in your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the parent process and the DLL being loaded.\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-appinit-dll-persistence/","summary":"Modification of the AppInit DLLs registry keys on Windows systems allows attackers to execute code in every process that loads user32.dll, establishing persistence and potentially escalating privileges.","title":"Registry Persistence via AppInit DLL Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-appinit-dll-persistence/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Crowdstrike"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","registry","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThis detection identifies Windows Registry modifications used to conceal encoded portable executables, a tactic employed by adversaries to evade traditional disk-based detection mechanisms. The rule focuses on detecting registry entries with data strings that match known encoded executable patterns. This technique allows attackers to store malicious code within the registry, making it more difficult to detect using standard file-based scanning methods. The rule is designed to work with Elastic Defend, but also supports data from third-party EDR solutions, including CrowdStrike, Microsoft Defender XDR, and SentinelOne. The detection logic focuses on identifying registry entries with data resembling encoded executables.\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 (e.g., through compromised credentials or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker uses a command-line tool, such as PowerShell or cmd.exe, to interact with the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker encodes a malicious executable using tools like \u003ccode\u003ecertutil\u003c/code\u003e or custom encoding scripts.\u003c/li\u003e\n\u003cli\u003eThe attacker creates or modifies a registry key using \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell\u0026rsquo;s \u003ccode\u003eSet-ItemProperty\u003c/code\u003e cmdlet.\u003c/li\u003e\n\u003cli\u003eThe encoded executable is written to the registry key\u0026rsquo;s data value. The data string often starts with \u0026ldquo;TVqQAAMAAAAEAAAA*\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker uses another script or command to decode the executable from the registry.\u003c/li\u003e\n\u003cli\u003eThe decoded executable is then executed in memory or written to disk for execution.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as establishing persistence, escalating privileges, or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to evade traditional disk-based security measures, enabling them to execute malicious code undetected. Attackers can use this technique to establish persistence, escalate privileges, or deploy malware, including ransomware. The rule helps defenders identify systems where this defense evasion technique is being employed.\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 encoded executables stored in the registry.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to provide the necessary data for the provided Sigma rules.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rules to determine if the registry modification is malicious.\u003c/li\u003e\n\u003cli\u003eUse endpoint detection and response (EDR) tools to further analyze suspicious processes associated with the registry modifications.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to prevent the execution of unauthorized executables, even if they are decoded from the registry.\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-encoded-executable-registry/","summary":"This rule detects registry write modifications hiding encoded portable executables, indicative of adversary defense evasion by avoiding storing malicious content directly on disk.","title":"Encoded Executable Stored in the Registry","url":"https://feed.craftedsignal.io/briefs/2024-01-encoded-executable-registry/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","Crowdstrike"],"_cs_severities":["high"],"_cs_tags":["defense-evasion","windows","registry"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eLocal Security Authority (LSA) protection is a security feature in Windows that prevents unauthorized processes from accessing sensitive information stored in LSASS memory. This protection is enabled through the RunAsPPL registry key. Adversaries may attempt to disable LSA protection by modifying this registry key, allowing them to more easily access credentials stored in LSASS. This technique can be used as part of a broader attack to escalate privileges and move laterally within a network. The rule detects modifications to the \u003ccode\u003eRunAsPPL\u003c/code\u003e registry key that weaken LSA protection. This involves monitoring changes to the registry path \u003ccode\u003e*\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\RunAsPPL\u003c/code\u003e and alerting when the registry data does not contain values that enable protected LSASS modes (\u0026ldquo;1\u0026rdquo;, \u0026ldquo;0x00000001\u0026rdquo;, \u0026ldquo;2\u0026rdquo;, \u0026ldquo;0x00000002\u0026rdquo;).\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, potentially through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to an administrator account, if necessary, to gain the required permissions to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003eRunAsPPL\u003c/code\u003e registry key located at \u003ccode\u003eHKLM\\System\\CurrentControlSet\\Control\\Lsa\u003c/code\u003e (or similar path under \u003ccode\u003eControlSet00x\u003c/code\u003e) to a value that disables LSA protection (e.g., setting it to 0). This is often achieved using tools like \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell.\u003c/li\u003e\n\u003cli\u003eThe attacker may stage the system for a reboot to apply the registry change.\u003c/li\u003e\n\u003cli\u003eAfter the system reboots, LSASS starts without Protected Process Light (PPL) protection, allowing the attacker to access its memory.\u003c/li\u003e\n\u003cli\u003eThe attacker uses credential dumping tools like \u003ccode\u003eMimikatz\u003c/code\u003e to extract credentials from the unprotected LSASS process.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen 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, ransomware deployment, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful disabling of LSA protection allows attackers to easily extract credentials from LSASS memory. This can lead to widespread compromise of user and service accounts, enabling lateral movement and privilege escalation within the network. The impact could range from data breaches and financial loss to complete system compromise and disruption of critical services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon registry event logging to detect changes to the \u003ccode\u003eRunAsPPL\u003c/code\u003e registry key (Data Source: Sysmon).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Disabling Lsa Protection via Registry Modification\u0026rdquo; to your SIEM to detect malicious modifications to the \u003ccode\u003eRunAsPPL\u003c/code\u003e registry key.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the process making the change, the user account, and any associated processes (see the \u0026ldquo;investigation_fields\u0026rdquo; in the source).\u003c/li\u003e\n\u003cli\u003eMonitor for unusual process activity after registry modifications, such as the execution of credential dumping tools (e.g., Mimikatz).\u003c/li\u003e\n\u003cli\u003eRegularly review and enforce the principle of least privilege to minimize the number of accounts with permissions to modify sensitive registry keys.\u003c/li\u003e\n\u003cli\u003eUse host isolation when unauthorized LSA-protection weakening is detected and confirmed.\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-lsass-ppl-disable/","summary":"Adversaries may modify the RunAsPPL registry key to disable LSA protection, which prevents nonprotected processes from reading memory and injecting code, potentially leading to credential access.","title":"Disabling LSA Protection via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-lsass-ppl-disable/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","OneDrive.exe","OneDriveSetup.exe","FileSyncConfig.exe","Teams.exe","MicrosoftEdgeUpdate.exe","msrdcw.exe","MicrosoftEdgeUpdateComRegisterShell64.exe","setup.exe","PowerToys.PowerLauncher.exe"],"_cs_severities":["low"],"_cs_tags":["persistence","com-hijacking","windows","registry","defense-evasion","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Elastic","Island Technology Inc.","Google LLC","Grammarly, Inc.","Dropbox, Inc.","REFINITIV US LLC","HP Inc.","Adobe Inc.","Citrix Systems, Inc.","Veeam Software Group GmbH","Zhuhai Kingsoft Office Software Co., Ltd.","Oracle America, Inc.","Brave Software, Inc.","DeepL SE","Opera Norway AS","Slack Technologies, LLC","Spotify AB","Vivaldi Technologies AS","Microsoft"],"content_html":"\u003cp\u003eComponent Object Model (COM) hijacking is a persistence and privilege escalation technique used by adversaries to execute malicious code by hijacking references to COM objects. This involves modifying specific registry keys to redirect COM object instantiation to attacker-controlled DLLs or executables. The technique is difficult to detect due to the legitimate use of COM objects by various applications and the operating system itself. This brief focuses on identifying suspicious registry modifications indicative of COM hijacking, while excluding known legitimate processes to minimize false positives. The original Elastic detection rule was published in November 2020 and last updated in May 2026, showcasing its continued relevance. This activity matters to defenders because successful COM hijacking allows attackers to execute arbitrary code with the privileges of the user or service that instantiates the hijacked COM object.\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 identifies a target COM object to hijack by enumerating COM object entries in the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u003ccode\u003eInprocServer32\u003c/code\u003e or \u003ccode\u003eLocalServer32\u003c/code\u003e registry keys associated with the target COM object to point to a malicious DLL or executable.\u003c/li\u003e\n\u003cli\u003eThe attacker may also modify the \u003ccode\u003eDelegateExecute\u003c/code\u003e registry key to control how the COM object is executed.\u003c/li\u003e\n\u003cli\u003eA legitimate application or service attempts to instantiate the original COM object.\u003c/li\u003e\n\u003cli\u003eDue to the registry modifications, the malicious DLL or executable is loaded and executed instead.\u003c/li\u003e\n\u003cli\u003eThe malicious code performs its intended actions, such as establishing persistence, escalating privileges, or executing arbitrary commands.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the system and potentially gains elevated privileges through the hijacked COM object.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful COM hijacking enables attackers to establish persistent access to compromised systems and potentially escalate privileges. The impact can range from executing arbitrary code with user privileges to gaining system-level access, depending on the context in which the hijacked COM object is used. The Elastic detection rule aims to identify and prevent such attacks by detecting suspicious registry modifications, but the overall number of affected systems or specific sectors targeted by this technique are not specified in the original source.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Windows Registry auditing to capture registry modification events and activate the Sigma rule \u003ccode\u003eSuspicious COM Hijack Registry Modification\u003c/code\u003e to detect potential COM hijacking attempts.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on processes modifying COM-related registry keys and their associated executables.\u003c/li\u003e\n\u003cli\u003eImplement code signing validation and monitor for unsigned or unexpected DLLs being loaded by legitimate processes, as indicated in the rule\u0026rsquo;s description.\u003c/li\u003e\n\u003cli\u003eRegularly review and update the list of excluded processes and trusted code signers in the Sigma rule to minimize false positives.\u003c/li\u003e\n\u003cli\u003eDeploy the EQL rule provided by Elastic, adjusting the \u003ccode\u003efrom\u003c/code\u003e and \u003ccode\u003eindex\u003c/code\u003e fields to match your environment, and tune the process and signature exclusions for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor for registry changes in \u003ccode\u003eHKEY_USERS\u003c/code\u003e hive related to COM objects, as these are considered less common and potentially malicious.\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-com-hijacking/","summary":"Adversaries may establish persistence by executing malicious content triggered by hijacked references to COM objects through Component Object Model (COM) hijacking via registry modification on Windows systems.","title":"Component Object Model (COM) Hijacking via Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-com-hijacking/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","CrowdStrike FDR"],"_cs_severities":["medium"],"_cs_tags":["persistence","defense-evasion","registry","ifeo","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eImage File Execution Options (IFEO) injection is a Windows feature that allows developers to debug applications by specifying an alternative executable to run. Attackers abuse this feature by modifying the Debugger and SilentProcessExit registry keys, setting a debugger to execute malicious code instead of the intended application. This technique is used to establish persistence or evade defenses. The attack involves modifying registry keys under \u003ccode\u003eHKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Image File Execution Options\u003c/code\u003e, \u003ccode\u003eHKLM\\\\SOFTWARE\\\\WOW6432Node\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Image File Execution Options\u003c/code\u003e, \u003ccode\u003eHKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\SilentProcessExit\u003c/code\u003e, and \u003ccode\u003eHKLM\\\\SOFTWARE\\\\WOW6432Node\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\SilentProcessExit\u003c/code\u003e. This matters to defenders because successful IFEO injection can allow attackers to maintain persistent access to a system and execute malicious code without detection.\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 unspecified means (e.g., exploiting a vulnerability or using stolen credentials).\u003c/li\u003e\n\u003cli\u003eThe attacker elevates privileges to gain administrative access, allowing modification of sensitive registry keys.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry, specifically the \u003ccode\u003eDebugger\u003c/code\u003e or \u003ccode\u003eMonitorProcess\u003c/code\u003e values within the IFEO or SilentProcessExit keys for a target executable (e.g., \u003ccode\u003enotepad.exe\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eDebugger\u003c/code\u003e or \u003ccode\u003eMonitorProcess\u003c/code\u003e value is set to point to a malicious executable.\u003c/li\u003e\n\u003cli\u003eWhen the target executable is launched by a user or system process, the malicious executable is launched instead.\u003c/li\u003e\n\u003cli\u003eThe malicious executable performs its intended actions, such as installing malware, stealing credentials, or establishing a reverse shell.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence through the IFEO injection, as the malicious executable will continue to be launched whenever the target executable is run.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful IFEO injection can allow attackers to maintain persistent access to a system, execute malicious code without detection, and potentially compromise sensitive data. IFEO injection can lead to a full compromise of the affected system, potentially impacting all users and applications on the system. This technique is often used in conjunction with other attack methods to achieve broader objectives, such as data exfiltration or ransomware deployment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Windows Registry auditing to monitor changes to the IFEO and SilentProcessExit registry keys, enabling detection of unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM to detect suspicious registry modifications related to IFEO injection.\u003c/li\u003e\n\u003cli\u003eReview and update the exceptions list in the Sigma rules to account for legitimate uses of the Debugger and MonitorProcess registry keys, reducing false positives.\u003c/li\u003e\n\u003cli\u003eMonitor process execution and correlate with registry modifications to identify potentially malicious processes launched via IFEO injection.\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and logging for registry changes related to IFEO to detect and respond to similar threats in the future.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T10:00:00Z","date_published":"2024-01-03T10:00:00Z","id":"/briefs/2024-01-ifeo-injection/","summary":"Attackers can establish persistence and evade defenses by modifying the Debugger and SilentProcessExit registry keys to perform Image File Execution Options (IFEO) injection, allowing them to intercept file executions and run malicious code.","title":"Image File Execution Options (IFEO) Injection for Persistence and Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-ifeo-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["low"],"_cs_tags":["initial-access","exfiltration","windows","registry","usb"],"_cs_type":"advisory","_cs_vendors":["Microsoft","SentinelOne","Elastic"],"content_html":"\u003cp\u003eThis detection identifies the first-time appearance of removable devices on a Windows system by monitoring registry modifications. While not inherently malicious, the activity can indicate potential data exfiltration over removable media or initial access attempts using malware delivered via USB. The rule specifically looks for registry events with the \u0026ldquo;FriendlyName\u0026rdquo; value associated with USB storage devices (\u0026ldquo;USBSTOR\u0026rdquo;). This helps in identifying potentially unauthorized devices connected to the system. The detection is designed to work with data from Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user connects a removable device (e.g., USB drive) to a Windows system.\u003c/li\u003e\n\u003cli\u003eThe operating system detects the new device and attempts to enumerate its properties.\u003c/li\u003e\n\u003cli\u003eThe system queries the registry for device-specific settings, including the \u0026ldquo;FriendlyName,\u0026rdquo; under the \u003ccode\u003eHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USBSTOR\u003c/code\u003e key.\u003c/li\u003e\n\u003cli\u003eIf the device is new to the system, the registry is modified to record the device\u0026rsquo;s information, including its friendly name.\u003c/li\u003e\n\u003cli\u003eThe event generates a registry modification event, which is logged by Sysmon, Elastic Defend, Microsoft Defender XDR, or SentinelOne.\u003c/li\u003e\n\u003cli\u003eAn attacker may use the USB device to deploy malware or exfiltrate sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker copies files to the USB device.\u003c/li\u003e\n\u003cli\u003eThe attacker removes the USB device, completing the exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation and data exfiltration via USB can lead to the loss of sensitive information, intellectual property theft, or the introduction of malware into the network. Although this alert is low severity, multiple alerts across the environment may indicate an active campaign. The detection focuses on registry modifications, which are early indicators of device connection, allowing for proactive monitoring and response.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon registry event logging to detect registry modifications related to USB devices and activate the Sigma rules below.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided to your SIEM to detect and monitor first-time seen USB devices.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, correlating with user activity and file access events.\u003c/li\u003e\n\u003cli\u003eMaintain a list of approved USB devices and create exceptions for them in the monitoring system to reduce false positives as described in the rule documentation.\u003c/li\u003e\n\u003cli\u003eMonitor for subsequent file access or transfer events involving the new device as described in the rule documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T14:00:00Z","date_published":"2024-01-02T14:00:00Z","id":"/briefs/2024-01-first-time-usb/","summary":"Detection of newly seen removable devices via Windows registry modification events can indicate data exfiltration attempts or initial access via malicious USB drives.","title":"First Time Seen Removable Device Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-first-time-usb/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Office"],"_cs_severities":["medium"],"_cs_tags":["office","macro","registry","defense-evasion","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eMicrosoft Office applications allow users and developers to manage macro security settings. Attackers can abuse these settings by modifying the registry to automatically trust macros or disable security warnings. This increases the likelihood of successful macro execution, potentially establishing persistence or enabling further malicious activities on the compromised system. The modifications specifically target the \u003ccode\u003eAccessVBOM\u003c/code\u003e and \u003ccode\u003eVbaWarnings\u003c/code\u003e registry values. This is a common tactic used to bypass security controls and execute malicious code within an organization, often as part of a phishing or spear phishing campaign.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker crafts a malicious Office document containing VBA macros.\u003c/li\u003e\n\u003cli\u003eThe victim receives the malicious document via email or other means (T1566).\u003c/li\u003e\n\u003cli\u003eThe victim opens the document, potentially triggering a prompt to enable macros.\u003c/li\u003e\n\u003cli\u003eIf macros are enabled or trusted due to existing settings, the malicious VBA code executes (T1204.002).\u003c/li\u003e\n\u003cli\u003eThe VBA code modifies the Windows Registry to disable macro security warnings by setting \u003ccode\u003eHKEY_CURRENT_USER\\Software\\Microsoft\\Office\\*\\Security\\VbaWarnings\u003c/code\u003e to 1 or modifying \u003ccode\u003eAccessVBOM\u003c/code\u003e (T1112).\u003c/li\u003e\n\u003cli\u003eThe attacker can then use the trusted macro environment to execute arbitrary code (T1059.005).\u003c/li\u003e\n\u003cli\u003eThe attacker may establish persistence by creating scheduled tasks or modifying startup entries (T1547.001).\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, which may include data exfiltration, lateral movement, or deploying ransomware (TA0005, TA0002).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to bypass Office macro security protections, potentially leading to arbitrary code execution and system compromise. Disabling macro security warnings increases the attack surface within an organization, as users are no longer prompted to approve macro execution, which can lead to further malware infection and data breaches. The rule is designed to detect registry changes that could enable this type of attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon registry event logging to detect the registry modifications described in this brief to trigger the detections (Sysmon Registry Events).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;MS Office Macro Security Registry Modifications\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eUse Group Policy Objects (GPOs) to centrally manage Office macro security settings and prevent users from modifying them (references).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by this rule to determine the source of the registry modification and whether malicious macros were subsequently executed (rule description).\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-office-macro-security-regmod/","summary":"Attackers may modify Microsoft Office registry settings related to macro security (AccessVBOM, VbaWarnings) to disable security warnings, enabling malicious macros for persistence and further compromise.","title":"MS Office Macro Security Registry Modifications","url":"https://feed.craftedsignal.io/briefs/2024-01-office-macro-security-regmod/"}],"language":"en","title":"CraftedSignal Threat Feed — Registry","version":"https://jsonfeed.org/version/1.1"}