Registry — CraftedSignal Threat Feed

RegPwnBOF Registry Symlink Race Condition Exploit

hello@craftedsignal.io — Thu, 19 Mar 2026 05:23:44 +0000

RegPwnBOF 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’s accessibility to non-administrator users makes it particularly dangerous in environments where least-privilege principles are not strictly enforced.

Attack Chain

An unprivileged user initiates the ATConfig mechanism within the Windows Accessibility features.
The exploit creates a registry symlink pointing to a protected HKLM key.
A race condition is triggered during the ATConfig process, allowing the exploit to bypass security checks.
The attacker leverages this race condition to overwrite the target HKLM registry key with arbitrary data.
The modified registry key is used to establish persistence, for example, by creating a Run key.
Upon system restart or user login, the malicious payload associated with the modified Run key is executed.
The attacker gains elevated privileges by executing code within the context of a privileged process.

Impact

Successful 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.

Recommendation

Monitor registry modifications targeting HKLM keys, especially those related to Accessibility features, using a process_creation log source and the provided Sigma rules.
Implement strict access controls and least-privilege principles to limit the ability of unprivileged users to interact with system-level configurations.
Investigate any unusual registry symlink creation events using file_event logs, particularly those involving the ATConfig mechanism, to identify potential RegPwnBOF exploitation attempts.

Netsh Helper DLL Persistence

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

The netsh.exe 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 netsh.exe 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 netsh.exe. 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 HKLM\Software\Microsoft\netsh\.

Attack Chain

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

Impact

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

Recommendation

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

AMSI Enable Registry Key Modification for Defense Evasion

hello@craftedsignal.io — Sat, 27 Jan 2024 18:23:00 +0000

Attackers can disable the Antimalware Scan Interface (AMSI) to evade detection by modifying the AmsiEnable 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 AmsiEnable 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.

Attack Chain

An attacker gains initial access to the target system, possibly through phishing or exploiting a vulnerability.
The attacker executes a script or binary that attempts to modify the AmsiEnable registry key.
The script or binary uses reg.exe, PowerShell, or another tool to set the AmsiEnable registry value to 0. The registry key location is typically HKEY_USERS\\Software\Microsoft\Windows Script\Settings\AmsiEnable.
After successfully disabling AMSI, the attacker proceeds to execute malicious scripts or code. These scripts may use powershell.exe, wscript.exe, or cscript.exe.
The malicious scripts download and execute additional payloads, such as malware or remote access tools (RATs).
The attacker performs lateral movement within the network using the compromised system as a pivot.
The attacker attempts to establish persistence, ensuring continued access to the system even after reboots.
The attacker exfiltrates sensitive data or deploys ransomware to achieve their objectives.

Impact

Successful modification of the AmsiEnable 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’s objectives and the organization’s security posture.

Recommendation

Deploy the Sigma rule Detect AmsiEnable Registry Modification via Registry Events to your SIEM to detect modifications to the AmsiEnable registry key.
Enable Sysmon registry event logging to provide the necessary data for the Sigma rule to function.
Monitor process creation events for processes modifying registry keys, especially reg.exe and PowerShell, using the rule Detect AmsiEnable Registry Modification via Process Creation.
Investigate any alerts generated by these rules promptly to determine if the activity is malicious or legitimate.
Implement application control policies to restrict the execution of unsigned or untrusted scripts and binaries.
Harden systems by restricting user permissions to modify critical registry keys.

Microsoft Office 'Office Test' Registry Persistence Abuse

hello@craftedsignal.io — Sat, 27 Jan 2024 17:30:00 +0000

The “Office Test” registry key, located under HKCU\Software\Microsoft\Office Test\Special\Perf, 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.

Attack Chain

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

Impact

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

Recommendation

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

PowerShell Script Block Logging Disabled via Registry Modification

hello@craftedsignal.io — Tue, 09 Jan 2024 10:00:00 +0000

Attackers frequently disable PowerShell Script Block Logging to evade detection and hide malicious activities on compromised systems. By modifying the EnableScriptBlockLogging registry value to ‘0’ or ‘0x00000000’, 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.

Attack Chain

Initial Access: An attacker gains initial access to a Windows system, possibly through phishing or exploitation of a vulnerability.
Privilege Escalation: The attacker may attempt to escalate privileges to gain necessary permissions to modify the registry.
Defense Evasion: The attacker modifies the registry to disable PowerShell Script Block Logging by setting HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging to 0 or 0x00000000 using reg.exe or PowerShell itself.
Execution: 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.
Persistence: The attacker establishes persistence using various techniques, such as creating scheduled tasks or modifying registry keys to ensure continued access to the system.
Command and Control: The attacker establishes a command and control channel to communicate with the compromised system and issue further instructions.
Lateral Movement: The attacker moves laterally to other systems on the network, compromising additional assets.
Impact: The attacker achieves their final objective, such as data theft, ransomware deployment, or disruption of services.

Impact

Successful 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.

Recommendation

Deploy the Sigma rule PowerShell_Script_Block_Logging_Disabled to your SIEM to detect registry modifications that disable PowerShell Script Block Logging.
Monitor registry events for changes to the EnableScriptBlockLogging value, focusing on events with registry.data.strings set to “0” or “0x00000000” (see rule PowerShell_Script_Block_Logging_Disabled).
Enable Sysmon registry event logging to capture the necessary data for the Sigma rules to function effectively (see references).
Review and harden PowerShell execution policies to prevent unauthorized script execution (related to tactic TA0005).
Implement strict access controls to limit who can modify registry settings related to PowerShell logging (related to tactic TA0005).

Uncommon Registry Persistence Change Detection

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This 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 HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell and HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Run. 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.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker executes code on the system, potentially using a dropper or exploit.
The attacker identifies uncommon registry keys suitable for persistence.
The 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.
The system restarts, or the user logs in, triggering the execution of the malicious code through the modified registry key.
The malicious code executes with the privileges of the user or system, depending on the registry key modified.
The attacker achieves persistence, allowing them to maintain access to the system even after restarts.
The attacker performs malicious activities such as data exfiltration, lateral movement, or deploying ransomware.

Impact

A 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’s objectives and the scope of the initial compromise.

Recommendation

Deploy the “Uncommon Registry Persistence Change” Sigma rule to your SIEM to detect modifications to uncommon registry persistence keys and tune for your environment.
Enable Sysmon registry event logging to ensure the visibility required for the Sigma rule to function effectively (see references).
Review and tune the filter conditions in the Sigma rule to reduce false positives, specifically excluding legitimate software installations, system maintenance processes, and administrative scripts.
Investigate any alerts generated by the Sigma rule, focusing on identifying the process responsible for the registry modification and correlating it with other suspicious activities.
Block execution of known malicious executables and scripts identified during the investigation to prevent further compromise.

Startup or Run Key Registry Modification

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Attackers 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.

Attack Chain

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

Impact

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

Recommendation

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

Registry Persistence via AppInit DLL Modification

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The 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.

Attack Chain

An attacker gains initial access to the system through a vulnerability, phishing, or other means.
The attacker identifies the AppInit DLLs registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows.
The attacker modifies the AppInit_DLLs registry value to include the path to their malicious DLL.
The attacker’s DLL is placed on the filesystem, typically in a location where it will persist across reboots.
Any new process that loads user32.dll will automatically load the attacker’s malicious DLL.
The malicious DLL executes arbitrary code within the context of the newly created process.
The attacker can use this code execution to perform further actions, such as installing backdoors or escalating privileges.
The attacker maintains persistent access to the system through the malicious DLL loaded into every user interface process.

Impact

Successful exploitation allows attackers to execute arbitrary code within the context of any process that loads user32.dll. 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.

Recommendation

Monitor registry modifications to the AppInit_DLLs value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows using the “Registry Persistence via AppInit DLL Modification” Sigma rule.
Enable Sysmon registry event logging to provide the data required for the Sigma rule to function correctly.
Deploy the “Registry Persistence via AppInit DLL Modification” Sigma rule to your SIEM and tune the filter to exclude known-good DLL paths in your environment.
Investigate any alerts triggered by the Sigma rule, focusing on the parent process and the DLL being loaded.

Encoded Executable Stored in the Registry

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This 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.

Attack Chain

An attacker gains initial access to the system (e.g., through compromised credentials or exploiting a vulnerability).
The attacker uses a command-line tool, such as PowerShell or cmd.exe, to interact with the registry.
The attacker encodes a malicious executable using tools like certutil or custom encoding scripts.
The attacker creates or modifies a registry key using reg.exe or PowerShell’s Set-ItemProperty cmdlet.
The encoded executable is written to the registry key’s data value. The data string often starts with “TVqQAAMAAAAEAAAA*”.
The attacker uses another script or command to decode the executable from the registry.
The decoded executable is then executed in memory or written to disk for execution.
The attacker achieves their final objective, such as establishing persistence, escalating privileges, or deploying ransomware.

Impact

Successful 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.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect encoded executables stored in the registry.
Enable Sysmon registry event logging to provide the necessary data for the provided Sigma rules.
Investigate any alerts triggered by the Sigma rules to determine if the registry modification is malicious.
Use endpoint detection and response (EDR) tools to further analyze suspicious processes associated with the registry modifications.
Implement application control policies to prevent the execution of unauthorized executables, even if they are decoded from the registry.

Disabling LSA Protection via Registry Modification

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Local 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 RunAsPPL registry key that weaken LSA protection. This involves monitoring changes to the registry path *\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL and alerting when the registry data does not contain values that enable protected LSASS modes (“1”, “0x00000001”, “2”, “0x00000002”).

Attack Chain

An attacker gains initial access to a system, potentially through phishing or exploiting a vulnerability.
The attacker escalates privileges to an administrator account, if necessary, to gain the required permissions to modify the registry.
The attacker modifies the RunAsPPL registry key located at HKLM\System\CurrentControlSet\Control\Lsa (or similar path under ControlSet00x) to a value that disables LSA protection (e.g., setting it to 0). This is often achieved using tools like reg.exe or PowerShell.
The attacker may stage the system for a reboot to apply the registry change.
After the system reboots, LSASS starts without Protected Process Light (PPL) protection, allowing the attacker to access its memory.
The attacker uses credential dumping tools like Mimikatz to extract credentials from the unprotected LSASS process.
The attacker uses the stolen credentials to move laterally to other systems on the network.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or disruption of services.

Impact

Successful 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.

Recommendation

Enable Sysmon registry event logging to detect changes to the RunAsPPL registry key (Data Source: Sysmon).
Deploy the Sigma rule “Disabling Lsa Protection via Registry Modification” to your SIEM to detect malicious modifications to the RunAsPPL registry key.
Investigate any alerts generated by the Sigma rule, focusing on the process making the change, the user account, and any associated processes (see the “investigation_fields” in the source).
Monitor for unusual process activity after registry modifications, such as the execution of credential dumping tools (e.g., Mimikatz).
Regularly review and enforce the principle of least privilege to minimize the number of accounts with permissions to modify sensitive registry keys.
Use host isolation when unauthorized LSA-protection weakening is detected and confirmed.

Component Object Model (COM) Hijacking via Registry Modification

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Component 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.

Attack Chain

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

Impact

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

Recommendation

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

Image File Execution Options (IFEO) Injection for Persistence and Defense Evasion

hello@craftedsignal.io — Wed, 03 Jan 2024 10:00:00 +0000

Image 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 HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options, HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options, HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit, and HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit. This matters to defenders because successful IFEO injection can allow attackers to maintain persistent access to a system and execute malicious code without detection.

Attack Chain

The attacker gains initial access to the system through unspecified means (e.g., exploiting a vulnerability or using stolen credentials).
The attacker elevates privileges to gain administrative access, allowing modification of sensitive registry keys.
The attacker modifies the registry, specifically the Debugger or MonitorProcess values within the IFEO or SilentProcessExit keys for a target executable (e.g., notepad.exe).
The Debugger or MonitorProcess value is set to point to a malicious executable.
When the target executable is launched by a user or system process, the malicious executable is launched instead.
The malicious executable performs its intended actions, such as installing malware, stealing credentials, or establishing a reverse shell.
The attacker maintains persistence through the IFEO injection, as the malicious executable will continue to be launched whenever the target executable is run.

Impact

Successful 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.

Recommendation

Enable Windows Registry auditing to monitor changes to the IFEO and SilentProcessExit registry keys, enabling detection of unauthorized modifications.
Deploy the Sigma rules in this brief to your SIEM to detect suspicious registry modifications related to IFEO injection.
Review and update the exceptions list in the Sigma rules to account for legitimate uses of the Debugger and MonitorProcess registry keys, reducing false positives.
Monitor process execution and correlate with registry modifications to identify potentially malicious processes launched via IFEO injection.
Implement enhanced monitoring and logging for registry changes related to IFEO to detect and respond to similar threats in the future.

First Time Seen Removable Device Registry Modification

hello@craftedsignal.io — Tue, 02 Jan 2024 14:00:00 +0000

This 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 “FriendlyName” value associated with USB storage devices (“USBSTOR”). 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.

Attack Chain

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

Impact

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

Recommendation

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

MS Office Macro Security Registry Modifications

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Microsoft 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 AccessVBOM and VbaWarnings 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.

Attack Chain

The attacker crafts a malicious Office document containing VBA macros.
The victim receives the malicious document via email or other means (T1566).
The victim opens the document, potentially triggering a prompt to enable macros.
If macros are enabled or trusted due to existing settings, the malicious VBA code executes (T1204.002).
The VBA code modifies the Windows Registry to disable macro security warnings by setting HKEY_CURRENT_USER\Software\Microsoft\Office\*\Security\VbaWarnings to 1 or modifying AccessVBOM (T1112).
The attacker can then use the trusted macro environment to execute arbitrary code (T1059.005).
The attacker may establish persistence by creating scheduled tasks or modifying startup entries (T1547.001).
The attacker achieves their final objective, which may include data exfiltration, lateral movement, or deploying ransomware (TA0005, TA0002).

Impact

Successful 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.

Recommendation

Enable Sysmon registry event logging to detect the registry modifications described in this brief to trigger the detections (Sysmon Registry Events).
Deploy the Sigma rule “MS Office Macro Security Registry Modifications” to your SIEM and tune for your environment.
Use Group Policy Objects (GPOs) to centrally manage Office macro security settings and prevent users from modifying them (references).
Investigate any alerts generated by this rule to determine the source of the registry modification and whether malicious macros were subsequently executed (rule description).