Registry-Modification — CraftedSignal Threat Feed

Windows Port Forwarding Rule Addition via Registry Modification

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

Attackers may configure port forwarding rules to bypass network segmentation restrictions, effectively using the compromised host as a jump box to access previously unreachable systems. This involves modifying the registry to redirect incoming TCP connections from a local port to another port or a remote computer. The technique is typically employed post-compromise to facilitate lateral movement and maintain unauthorized access within the network. This activity is detected by monitoring changes to the HKLM\SYSTEM\*ControlSet*\Services\PortProxy\v4tov4\ registry subkeys.

Attack Chain

The attacker gains initial access to the target system through an exploit or compromised credentials.
The attacker executes a command-line interface (e.g., cmd.exe or powershell.exe) with administrative privileges.
The attacker uses reg.exe or PowerShell’s Set-ItemProperty cmdlet to modify the HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\ registry key.
The attacker configures a new port forwarding rule by creating a new subkey under v4tov4\ with specific settings for the local port, remote address, and remote port.
The attacker sets the ListenAddress, ListenPort, ConnectAddress, and ConnectPort values within the new subkey.
The attacker verifies the successful creation and activation of the port forwarding rule using netsh interface portproxy show v4tov4.
The attacker leverages the newly created port forwarding rule to tunnel traffic through the compromised host, bypassing network segmentation.
The attacker uses the proxied connection to access internal resources and conduct further attacks, such as lateral movement or data exfiltration.

Impact

Successful exploitation enables attackers to bypass network segmentation restrictions, leading to unauthorized access to internal systems and data. This can facilitate lateral movement, data exfiltration, and further compromise of the network. The severity of the impact depends on the sensitivity of the accessible resources and the extent of the attacker’s lateral movement.

Recommendation

Enable Sysmon registry event logging to capture modifications to the HKLM\SYSTEM\*ControlSet*\Services\PortProxy\v4tov4\ registry subkeys, enabling detection of malicious port forwarding rule additions.
Deploy the Sigma rule “Port Forwarding Rule Addition via Registry Modification” to your SIEM to detect suspicious registry modifications related to port forwarding.
Investigate any alerts generated by the Sigma rule, focusing on identifying the process execution chain and the user account that performed the action.
Regularly review and audit existing port forwarding rules to identify and remove any unauthorized or suspicious configurations.

SIP Provider Modification for Defense Evasion

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This detection rule identifies modifications to Subject Interface Package (SIP) providers, a critical component of the Windows cryptographic system responsible for validating file signatures. Attackers may attempt to subvert trust controls by modifying SIP providers, allowing them to bypass signature validation checks and potentially inject malicious code into trusted processes. This activity is a form of defense evasion, allowing unauthorized code execution. The rule focuses on detecting suspicious registry changes associated with SIP providers, while excluding known benign processes to minimize false positives. The rule is designed for data generated by Elastic Defend, but also supports third-party data sources like CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon. This activity is related to MITRE ATT&CK technique T1553.003 (SIP and Trust Provider Hijacking).

Attack Chain

The attacker gains initial access to the system through various means (e.g., phishing, exploitation of vulnerabilities).
The attacker escalates privileges to gain necessary permissions to modify the registry.
The attacker modifies the registry keys associated with SIP providers, specifically targeting CryptSIPDllPutSignedDataMsg and Trust\\FinalPolicy locations.
The attacker changes the Dll value within these registry keys to point to a malicious DLL.
The system, upon attempting to validate a file signature, loads the malicious DLL instead of the legitimate SIP provider.
The malicious DLL executes arbitrary code, potentially injecting it into other processes.
The attacker uses the injected code to further compromise the system or network.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or establishing persistence.

Impact

Successful modification of SIP providers allows attackers to bypass signature validation checks, leading to the execution of unsigned or malicious code. This can compromise the integrity of the system, leading to data breaches, system instability, or further propagation of malware within the network. The impact can range from individual workstation compromise to widespread organizational damage, depending on the scope of the attack.

Recommendation

Deploy the Sigma rule Detect SIP Provider Modification via Registry to your SIEM and tune it for your environment to detect suspicious registry modifications related to SIP providers.
Enable Sysmon registry event logging to collect the necessary data for the Sigma rules above.
Investigate any alerts generated by the rules, focusing on the process responsible for the registry change and the DLL being loaded, as described in the rule’s triage section.
Implement application control policies to restrict the execution of unsigned or untrusted code.
Monitor the registry paths listed in the Sigma rules for unexpected changes.

Potential NetNTLMv1 Downgrade Attack via Registry Modification

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This rule detects a specific defense evasion technique where an attacker modifies the Windows registry to force a system to use the less secure NTLMv1 authentication protocol. This is known as a NetNTLMv1 downgrade attack. The registry modification involves changing the LmCompatibilityLevel value, which controls the authentication level. Attackers with local administrator privileges can perform this modification to weaken the authentication mechanism, making it easier to intercept and crack credentials. The rule is designed to detect this activity by monitoring registry events from various sources, including Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Crowdstrike. It is important to monitor for this activity as it can lead to credential theft and further compromise of the system.

Attack Chain

The attacker gains local administrator privileges on a Windows system.
The attacker uses a registry editor or command-line tool (e.g., reg.exe, PowerShell) to modify the LmCompatibilityLevel value in the registry.
The attacker navigates to one of the following registry paths: HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel or HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
The attacker sets the LmCompatibilityLevel value to “0”, “1”, or “2” (or their hexadecimal equivalents “0x00000000”, “0x00000001”, “0x00000002”). These values force the system to use NTLMv1.
The system now uses NTLMv1 for authentication attempts.
The attacker initiates a man-in-the-middle attack to capture NTLMv1 authentication traffic using tools like Responder or Inveigh.
The captured NTLMv1 hashes are cracked using brute-force or dictionary attacks, revealing the user’s credentials.
The attacker uses the compromised credentials to gain unauthorized access to network resources or other systems.

Impact

A successful NetNTLMv1 downgrade attack can lead to the compromise of user credentials, enabling attackers to move laterally within the network, access sensitive data, and potentially escalate privileges. The impact can range from data breaches to complete system compromise, depending on the attacker’s objectives and the compromised user’s privileges.

Recommendation

Deploy the Sigma rule “Potential NetNTLMv1 Downgrade Attack” to detect registry modifications setting LmCompatibilityLevel to insecure values (0, 1, 2) within the specified registry paths.
Enable Sysmon registry event logging to ensure the necessary data is available for the Sigma rule to function correctly.
Review registry event logs for unauthorized modifications of LmCompatibilityLevel to confirm legitimate administrative actions.
Implement strict access control policies to limit local administrator privileges and reduce the attack surface.
Monitor the references URL for updates on recommended security configurations related to NTLM authentication.

Local Account TokenFilter Policy Modification for Defense Evasion and Lateral Movement

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

The LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled (set to 1), allows remote connections from local members of the Administrators group to be granted full high-integrity tokens during negotiation. This bypasses User Account Control (UAC) restrictions, allowing for elevated privileges remotely. Attackers may modify this registry setting to facilitate lateral movement within a network. This rule detects modifications to this specific registry setting, alerting on potential unauthorized changes that could lead to defense evasion and privilege escalation. The modification of this policy has been observed being leveraged in conjunction with pass-the-hash attacks.

Attack Chain

The attacker gains initial access to a system through an exploit, such as phishing or exploiting a vulnerability.
The attacker obtains local administrator credentials on the compromised system.
The attacker modifies the LocalAccountTokenFilterPolicy registry key to a value of 1. This is done to allow remote connections from local administrator accounts to receive high-integrity tokens. The registry key is typically located at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy.
The attacker leverages a “pass the hash” attack (T1550.002) using the compromised local administrator credentials.
The attacker attempts to move laterally to other systems within the network using the “pass the hash” technique and the modified LocalAccountTokenFilterPolicy.
Due to the LocalAccountTokenFilterPolicy being enabled, the remote connection from the local administrator account receives a full high-integrity token.
The attacker bypasses UAC on the remote system, gaining elevated privileges.
The attacker performs malicious activities on the remote system, such as data exfiltration or deploying ransomware.

Impact

Successful modification of the LocalAccountTokenFilterPolicy allows attackers to bypass User Account Control (UAC) and gain elevated privileges on remote systems, potentially leading to unauthorized access to sensitive data, lateral movement across the network, and the deployment of ransomware. The overall impact can include data breaches, financial loss, and reputational damage.

Recommendation

Deploy the Sigma rule Local Account TokenFilter Policy Enabled to your SIEM and tune for your environment to detect unauthorized modifications to the LocalAccountTokenFilterPolicy registry key.
Enable Sysmon registry event logging to capture modifications to the registry, which is required for the Local Account TokenFilter Policy Enabled Sigma rule.
Review the processes excluded in the rule query and ensure they are legitimate and necessary to prevent false positives.
Monitor registry events for changes to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy path, specifically looking for changes to the value data.

Suspicious Registry Modifications by Scripting Engines

hello@craftedsignal.io — Tue, 14 Apr 2026 12:50:16 +0000

This brief covers suspicious registry modifications made by scripting engine processes like WScript, CScript, and MSHTA. These processes are often abused by attackers to modify the registry without using standard tools like regedit.exe or reg.exe, potentially for evasion and persistence. Legitimate use of these scripting engines to modify the registry is uncommon, making this behavior a good indicator of potential malicious activity. Defenders should monitor for these processes interacting with sensitive registry keys. This activity was observed as of 2025 and continues to be a relevant technique for persistence and defense evasion in 2026.

Attack Chain

An attacker gains initial access to a system via an exploit or social engineering.
The attacker uses MSHTA.exe to execute malicious HTML Application code.
MSHTA.exe is used to launch a PowerShell script.
The PowerShell script uses the Registry module to add a new registry key.
The registry key is configured to execute a payload upon system startup.
The attacker uses wscript.exe or cscript.exe to execute VBScript or JScript.
The script modifies registry values to disable security features.
The compromised system restarts, executing the payload defined in the registry, granting the attacker persistent access.

Impact

Successful exploitation allows attackers to establish persistence on the targeted system, enabling them to maintain access even after a reboot. This can lead to data theft, further malware deployment, or complete system compromise. The impact ranges from minor data breaches to significant operational disruptions. The scope of the impact depends on the attacker’s objectives and the compromised system’s role within the organization.

Recommendation

Deploy the Sigma rule “Registry Tampering by Potentially Suspicious Processes” to your SIEM to detect this specific activity, and tune for your environment (rules).
Investigate any instances of wscript.exe, cscript.exe or mshta.exe modifying registry keys outside of known-good paths (rules).
Monitor registry events for unexpected modifications by scripting engines, focusing on persistence-related keys (rules).

DNS Global Query Block List Modified or Disabled

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

The DNS Global Query Block List (GQBL) is a Windows security feature designed to prevent the resolution of specific DNS names, commonly exploited in attacks like WPAD spoofing. Attackers who have obtained elevated privileges, such as DNSAdmin, can modify or disable this list to bypass security controls. This allows exploitation of hosts running WPAD with default settings. The modification of the GQBL can be used for privilege escalation and lateral movement within a network. This rule detects changes to the registry values associated with the GQBL, specifically “EnableGlobalQueryBlockList” and “GlobalQueryBlockList.” This activity could indicate an attacker attempting to weaken defenses to facilitate further malicious activities.

Attack Chain

An attacker gains initial access to a system, possibly through compromised credentials or exploiting a vulnerability.
The attacker escalates privileges to obtain DNSAdmin rights.
The attacker modifies the “EnableGlobalQueryBlockList” registry value to “0” or “0x00000000,” effectively disabling the GQBL.
Alternatively, the attacker modifies the “GlobalQueryBlockList” registry value to remove “wpad” from the list.
The attacker leverages the disabled GQBL to conduct WPAD spoofing attacks, redirecting network traffic to attacker-controlled servers.
The attacker captures user credentials transmitted during WPAD authentication.
The attacker uses the captured credentials to move laterally to other systems on the network.
The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

Successful modification or disabling of the DNS Global Query Block List can lead to WPAD spoofing attacks, credential theft, lateral movement, and ultimately, complete compromise of the network. Attackers can leverage this technique to gain unauthorized access to sensitive data or systems. The impact includes potential data breaches, financial loss, and reputational damage.

Recommendation

Deploy the Sigma rule Registry Modification of DNS Global Query Block List to your SIEM to detect unauthorized changes to the GQBL configuration.
Enable Sysmon registry event logging to capture the necessary events for the Sigma rule to function (reference the logsource in the rule).
Review and restrict DNSAdmin privileges to only necessary accounts to minimize the attack surface (reference: Overview section).
Monitor network traffic for unusual DNS queries or WPAD-related activity, correlating with registry modification events (reference: Attack Chain step 5).
Regularly audit registry settings related to DNS configuration, including the GQBL, to identify unauthorized modifications (reference: Attack Chain steps 3 & 4).
Update security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List (reference: Impact section).

Network-Level Authentication (NLA) Disabled via Registry Modification

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

Network Level Authentication (NLA) is a security feature in Windows that requires users to authenticate before establishing a full RDP session, adding an extra layer of protection against unauthorized access. Attackers might attempt to disable NLA to gain access to the Windows sign-in screen without proper authentication. This tactic can facilitate the deployment of persistence mechanisms, such as leveraging Accessibility Features like Sticky Keys, or enable unauthorized remote access. This brief addresses the registry modifications associated with disabling NLA and provides detection strategies to identify such attempts. The references indicate that this technique is used in conjunction with other attacks for lateral movement within a compromised network.

Attack Chain

Initial access to the system is gained (potentially via compromised credentials or vulnerability exploitation).
The attacker elevates privileges to modify system-level settings.
The attacker modifies the registry key HKLM\SYSTEM\ControlSet*\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication to disable NLA.
The UserAuthentication value is set to “0” or “0x00000000”.
The attacker attempts to establish an RDP connection to the compromised system.
Due to the disabled NLA, the attacker bypasses the initial authentication screen.
The attacker leverages accessibility features (e.g., Sticky Keys) for persistence or further exploitation.
The attacker gains unauthorized access to the system.

Impact

Successful disabling of NLA allows attackers to bypass authentication and gain unauthorized access to systems via RDP. This can lead to data theft, malware installation, or further lateral movement within the network. While the exact number of victims and sectors targeted are unspecified, the potential impact includes significant data breaches and system compromise.

Recommendation

Enable Sysmon process-creation and registry event logging to detect the registry modifications (Elastic Defend, Elastic Endgame, Microsoft Defender XDR, SentinelOne, Sysmon).
Deploy the Sigma rule provided to detect attempts to modify the UserAuthentication registry key (Sysmon Registry Events).
Review and harden RDP configurations across the environment to prevent unauthorized access (Microsoft documentation).
Monitor endpoint security policies to detect unauthorized registry modifications (Endpoint Security Policies).

Suspicious Registry Modifications by Scripting Engines

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

Attackers may leverage scripting engines, such as wscript.exe and cscript.exe, to directly modify the Windows Registry. These scripting engines are often abused for malicious purposes, including establishing persistence, escalating privileges, or disabling security controls. These scripting engines can modify the registry without using standard tools like regedit.exe or reg.exe, making it harder to detect malicious registry changes. Defenders should be aware of processes using these engines to modify the registry, as this behavior is uncommon in legitimate software installations or administrative tasks.

Attack Chain

An attacker gains initial access to the system, potentially through social engineering or exploiting a software vulnerability.
The attacker executes a script (VBScript, JScript) via wscript.exe or cscript.exe.
The script contains commands to modify specific registry keys, such as the Run key for persistence (T1547.001).
The scripting engine process (e.g., wscript.exe) directly interacts with the Windows Registry to set the new values.
Upon system restart or user logon, the modified registry key triggers the execution of a malicious payload.
The attacker achieves persistence on the compromised system, allowing for continued access and control.
The attacker leverages the persistent access to perform lateral movement or data exfiltration.

Impact

Successful exploitation can lead to persistent access on compromised systems, enabling attackers to execute malicious code, steal sensitive information, or disrupt critical services. The registry modifications performed by scripting engines can bypass traditional security measures and make it difficult to detect and remediate the attack. This can result in significant data loss, financial damage, and reputational harm to affected organizations.

Recommendation

Deploy the Sigma rule “Registry Tampering by Potentially Suspicious Processes” to your SIEM to detect suspicious registry modifications made by scripting engines.
Investigate any alerts generated by the Sigma rule “Registry Tampering by Potentially Suspicious Processes” for unusual or unauthorized registry changes.
Monitor registry events for modifications made by processes such as wscript.exe and cscript.exe (logsource: registry_event).

Windows Defender Disabled via Registry Modification

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

Attackers commonly disable Windows Defender to evade detection and facilitate malicious activities. This involves modifying specific registry settings to either disable the service entirely or prevent it from starting automatically. The rule specifically identifies modifications to the DisableAntiSpyware and WinDefend\\Start registry keys. The DFIR Report has documented this technique in real-world incidents, highlighting its effectiveness in bypassing built-in security measures. This allows threat actors to operate with reduced risk of detection, enabling them to deploy malware, exfiltrate data, or perform other malicious actions without immediate interference from the endpoint security solution.

Attack Chain

An attacker gains initial access to the target system, potentially through phishing or exploiting a software vulnerability.
The attacker elevates privileges to obtain the necessary permissions to modify the registry.
The attacker modifies the HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware registry key to disable Windows Defender, setting its value to “1” or “0x00000001”.
Alternatively, the attacker modifies the HKLM\\System\\*ControlSet*\\Services\\WinDefend\\Start registry key to prevent the Windows Defender service from starting automatically. The attacker sets the value to “3” or “4” (or their hexadecimal equivalents “0x00000003”, “0x00000004”).
The attacker verifies that Windows Defender is disabled by checking the Security Center or attempting to run a scan.
With Windows Defender disabled, the attacker proceeds to deploy malware or execute malicious commands without interference from the antivirus software.
The attacker may further disable security settings and block security-related indicators.

Impact

If successful, this attack can lead to a complete compromise of the affected system. With Windows Defender disabled, the system becomes vulnerable to malware infections, data exfiltration, and other malicious activities. This can result in financial losses, data breaches, and reputational damage for the targeted organization. The lack of immediate detection allows attackers to establish persistence and expand their foothold within the network.

Recommendation

Deploy the Sigma rule “Registry Modification to Disable Windows Defender” to your SIEM and tune for your environment to detect unauthorized changes to Windows Defender registry settings.
Monitor registry events for changes to the HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware and HKLM\\System\\*ControlSet*\\Services\\WinDefend\\Start registry keys using the provided log sources.
Investigate any alerts generated by the Sigma rule, focusing on identifying the process and user account responsible for the registry modifications.
Enable Sysmon registry event logging to capture the necessary data for the Sigma rule to function effectively.

Unusual Persistence via Services Registry Modification

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

This detection identifies processes that modify the Windows services registry key directly, bypassing the standard Windows APIs. This behavior can signify an adversary’s attempt to establish persistence stealthily by creating new services or altering existing ones in an unexpected manner. The detection logic focuses on changes to the ServiceDLL and ImagePath values within specific registry paths associated with service configurations. This rule is designed for data generated by Elastic Defend and also supports Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon Registry Events. The rule helps security analysts identify potentially malicious activity related to service manipulation, which can lead to persistent access and control over compromised systems. The rule excludes known legitimate processes and paths to minimize false positives, focusing on anomalous registry modifications.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., phishing, exploitation of a vulnerability).
The attacker escalates privileges to gain administrative access, allowing them to modify the registry.
The attacker directly modifies the HKLM\SYSTEM\ControlSet*\Services\*\ServiceDLL or HKLM\SYSTEM\ControlSet*\Services\*\ImagePath registry keys to point to a malicious DLL or executable.
The attacker’s malicious DLL or executable is configured to run as a service, ensuring persistence across system reboots.
The compromised service starts automatically during system startup or manually when triggered by the attacker.
The malicious service executes arbitrary code, providing the attacker with persistent control over the system.
The attacker may use the compromised service to perform further malicious activities, such as data exfiltration or lateral movement.

Impact

Successful exploitation allows attackers to achieve persistence on the compromised system, maintaining access even after reboots or user logoffs. This can lead to long-term control over the system, enabling attackers to perform various malicious activities, including data theft, deployment of ransomware, or use of the system as a foothold for further attacks within the network. The severity is further amplified if critical services are targeted, potentially leading to system instability or denial of service.

Recommendation

Enable Sysmon registry event logging to capture the necessary data for this detection (Data Source: Sysmon).
Deploy the provided Sigma rules to your SIEM to detect unusual service registry modifications (Sigma rules).
Tune the Sigma rules by adding exceptions for legitimate software installations or updates that modify service registry keys directly (Sigma rules).
Investigate any alerts generated by the Sigma rules, focusing on processes modifying the ServiceDLL or ImagePath registry values (Sigma rules).
Review endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future (Response and remediation).

Suspicious Modifications to Windows Security Support Provider (SSP) Registry

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

Attackers can abuse the Windows Security Support Provider (SSP) mechanism to establish persistence on a compromised system. SSPs are DLLs loaded into the Local Security Authority Subsystem Service (LSASS) process, which handles authentication in Windows. By modifying specific registry keys related to SSP configuration, attackers can force LSASS to load malicious DLLs at startup, effectively creating a persistent backdoor. This technique is often used to maintain unauthorized access to a system even after a reboot. The registry keys of interest are HKLM\SYSTEM\*\ControlSet*\Control\Lsa\Security Packages and HKLM\SYSTEM\*\ControlSet*\Control\Lsa\OSConfig\Security Packages. Successful exploitation allows the attacker to intercept and manipulate authentication credentials.

Attack Chain

An attacker gains initial access to a Windows system through an exploit or compromised credentials (not detailed in source).
The attacker escalates privileges to gain administrative rights on the system.
The attacker modifies the registry key HKLM\SYSTEM\*\ControlSet*\Control\Lsa\Security Packages to include a path to a malicious DLL.
Alternatively, the attacker modifies the registry key HKLM\SYSTEM\*\ControlSet*\Control\Lsa\OSConfig\Security Packages to include a path to a malicious DLL.
The attacker triggers a system reboot, or restarts the LSASS process, causing the malicious SSP DLL to be loaded.
The malicious DLL intercepts authentication credentials and exfiltrates them or performs other malicious actions.
The attacker maintains persistent access to the system, even after reboots.

Impact

Successful exploitation allows attackers to achieve persistence and potentially compromise sensitive credentials handled by LSASS. This can lead to lateral movement within the network, data exfiltration, and further system compromise. The impact is significant as it bypasses standard security measures and provides a persistent foothold for malicious activities.

Recommendation

Deploy the Sigma rule “Suspicious SSP Registry Modification” to your SIEM to detect unauthorized modifications to SSP registry keys.
Enable Sysmon registry event logging to provide the necessary data for the Sigma rule to function.
Continuously monitor for unexpected processes writing to the HKLM\SYSTEM\*\ControlSet*\Control\Lsa\Security Packages and HKLM\SYSTEM\*\ControlSet*\Control\Lsa\OSConfig\Security Packages registry keys.
Review and whitelist legitimate software installers that frequently modify these registry entries to reduce false positives as mentioned in the brief.
Ensure access controls and permissions are strictly enforced to limit unauthorized modification of critical registry paths related to Security Support Providers.

SolarWinds Process Disabling Services via Registry Modification

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

This threat brief focuses on the detection of SolarWinds processes attempting to disable services by modifying their registry start type. This activity is associated with defense evasion tactics, potentially linked to initial access via supply chain compromise, similar to the SUNBURST campaign. The behavior involves SolarWinds binaries, such as SolarWinds.BusinessLayerHost*.exe and NetFlowService*.exe, manipulating registry entries related to service start configurations. This technique can be used to impair or disable security tools and services, allowing attackers to operate more freely within a compromised environment.

Attack Chain

Initial compromise of the SolarWinds Orion platform, potentially through a supply chain attack.
Deployment of a malicious module or payload within the SolarWinds environment.
Execution of a SolarWinds process, such as SolarWinds.BusinessLayerHost*.exe.
The SolarWinds process modifies the registry to change the start type of a service.
The registry modification targets the HKLM\SYSTEM\ControlSet*\Services\*\Start path.
The Start value is set to “4” or “0x00000004”, which disables the targeted service.
Disabling critical security services allows the attacker to evade detection and further compromise the system.
Attacker achieves persistence and performs lateral movement, exfiltrating data or deploying ransomware.

Impact

Successful exploitation can lead to the disabling of critical security services, such as antivirus, endpoint detection and response (EDR) agents, or other monitoring tools. This can significantly reduce the visibility of malicious activity within the network, potentially leading to data breaches, ransomware deployment, or other severe security incidents. The SolarWinds supply chain compromise affected numerous organizations globally, underscoring the potential impact of this type of attack.

Recommendation

Deploy the Sigma rule SolarWinds Process Disabling Services via Registry to your SIEM to detect registry modifications by SolarWinds processes aimed at disabling services.
Enable Sysmon registry event logging to provide the necessary data for the Sigma rule to function effectively.
Review and harden access controls for SolarWinds processes to restrict their ability to modify critical system settings.
Investigate any alerts generated by the Sigma rule, focusing on the affected service and the timeline of events surrounding the registry modification.
Utilize threat intelligence platforms to stay informed about known SolarWinds-related attack patterns and indicators of compromise (IOCs).
Monitor endpoints for unusual behavior by SolarWinds processes, including network connections, file modifications, and process creations.

RDP Enabled via Registry Modification

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

Attackers may enable Remote Desktop Protocol (RDP) to facilitate lateral movement within a compromised network. By modifying the fDenyTSConnections registry key to a value of 0, attackers can enable remote desktop connections, allowing them to access systems remotely. This technique can be employed using remote registry manipulation or tools like PsExec. The modification of the registry key is a common tactic used by ransomware operators and other threat actors to gain unauthorized access to victim servers. This activity can be performed to enable remote access for initial access or to regain access after persistence mechanisms have failed.

Attack Chain

An attacker gains initial access to a system via an exploit or compromised credentials.
The attacker uses a tool like PsExec or leverages remote registry modification capabilities.
The attacker modifies the fDenyTSConnections registry key, setting its value to 0. This key is typically located in HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server.
The system’s RDP service is enabled or re-enabled as a result of the registry change.
The attacker attempts to connect to the now-enabled RDP service using valid or brute-forced credentials.
Upon successful authentication, the attacker gains interactive access to the system via RDP.
The attacker performs reconnaissance, elevates privileges, and moves laterally to other systems.
The attacker deploys ransomware, exfiltrates data, or achieves other objectives.

Impact

Successful modification of the fDenyTSConnections registry key allows unauthorized remote access to systems, potentially leading to lateral movement, data theft, or ransomware deployment. Organizations could suffer significant financial losses, reputational damage, and operational disruption. The scope of the impact depends on the attacker’s objectives and the level of access they gain within the environment.

Recommendation

Deploy the Sigma rule “RDP Enabled via Registry” to detect modifications to the fDenyTSConnections registry key (rules).
Monitor process creation events for suspicious use of reg.exe or PowerShell to modify registry keys related to RDP (rules).
Implement network segmentation and firewall rules to restrict RDP traffic to authorized hosts (overview).
Review the privileges assigned to users and ensure the principle of least privilege is enforced (overview).
Enable Sysmon registry event logging to capture registry modifications (setup).
Investigate any alerts related to registry modifications on critical systems (overview).

NullSessionPipe Registry Modification for Lateral Movement

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

This detection rule identifies modifications to the NullSessionPipe registry setting in Windows. This setting defines named pipes that can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to enable lateral movement, allowing unauthorized access to network resources. By adding specific pipes to the NullSessionPipes registry key, an attacker can make services accessible without requiring authentication. This rule focuses on flagging modifications that introduce new accessible pipes, which could indicate malicious intent. The targeted configuration is located under HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. The registry key NullSessionPipes is of particular interest when its values change.

Attack Chain

Initial compromise of a system within the network.
The attacker gains elevated privileges on the compromised system.
The attacker modifies the Windows Registry, specifically the HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes key. They add a new pipe name to this key, which will allow unauthenticated access to that named pipe.
The attacker uses reg.exe or PowerShell to modify the registry, potentially using commands like reg add or Set-ItemProperty.
A remote system attempts to connect to the newly accessible named pipe on the compromised system without authenticating.
The attacker exploits the now-accessible service or application associated with the named pipe to execute commands or transfer data.
The attacker leverages this access to move laterally within the network, compromising additional systems.

Impact

Successful modification of the NullSessionPipes registry setting can lead to unauthorized access to sensitive resources and lateral movement within the network. By enabling anonymous access to named pipes, attackers can potentially bypass authentication mechanisms and gain control over critical systems. While the direct number of victims is not specified, the impact can be significant, particularly in organizations where shared resources and services rely on secure authentication protocols.

Recommendation

Enable Windows Registry auditing to capture changes to the NullSessionPipes registry key. This will allow you to detect unauthorized modifications as described in the overview.
Deploy the Sigma rule “NullSessionPipe Registry Modification” to your SIEM and tune for your environment to identify malicious activity related to named pipe modifications.
Investigate any alerts generated by the Sigma rule, focusing on the specific named pipes being added or modified in the registry event details, as detailed in the rule’s description.
Regularly review and validate the legitimacy of existing entries in the NullSessionPipes registry key to identify and remove any unauthorized pipes.

Network Logon Provider Registry Modification

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

Attackers may modify the network logon provider registry to gain persistence or access credentials. This involves registering a rogue network logon provider module that intercepts authentication credentials in clear text during user logon. The modification of the ProviderPath key under the NetworkProvider service registry path can be indicative of this malicious activity. The registry modification is often performed by non-system accounts and the adversary will attempt to hide the malicious DLL by placing it in common directories. This technique allows adversaries to steal user credentials or maintain persistent access to the compromised system.

Attack Chain

An attacker gains initial access to a Windows system, possibly through exploiting a vulnerability or using compromised credentials.
The attacker elevates privileges to obtain the necessary permissions to modify the registry.
The attacker locates the registry key related to network logon providers: HKLM\SYSTEM\CurrentControlSet\Services\*\NetworkProvider\ProviderPath.
The attacker modifies the ProviderPath registry value to point to a malicious DLL.
The system loads the malicious DLL during the logon process.
The malicious DLL intercepts user credentials in clear text.
The attacker harvests the intercepted credentials.
The attacker uses the harvested credentials for lateral movement or further exploitation of the network.

Impact

A successful attack can lead to the compromise of user credentials, allowing attackers to gain unauthorized access to sensitive systems and data. Modification of the network logon provider registry enables attackers to maintain persistent access to the compromised system, even after a reboot. This can result in data breaches, financial losses, and reputational damage. The severity depends on the level of access granted to the compromised accounts and the sensitivity of the data they can access.

Recommendation

Monitor registry modifications to the HKLM\SYSTEM\CurrentControlSet\Services\*\NetworkProvider\ProviderPath key, using the provided Sigma rule to detect suspicious changes.
Enable Sysmon registry event logging to capture registry modifications.
Regularly audit network logon providers and verify the integrity and authenticity of the registered DLLs.
Investigate processes modifying the registry and their associated file creation events for unknown or suspicious processes.
Block execution of unsigned or untrusted DLLs in the network logon provider path.
Deploy the Sigma rule “Network Logon Provider Registry Modification” to your SIEM and tune for your environment.

Microsoft Defender Tampering via Registry Modification

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

Attackers commonly disable or tamper with Microsoft Defender features to evade detection and conceal malicious behavior within compromised Windows environments. This is often achieved by modifying specific registry keys that control the behavior and functionality of Defender components, such as real-time monitoring, exploit protection, and tamper protection itself. Such actions can significantly reduce the effectiveness of endpoint security, allowing malicious activities to proceed undetected. The references point to techniques that disable PUA protection, tamper protection, memory integrity, and real-time protection. This behavior is observed across various attack scenarios, including ransomware deployment and cryptocurrency mining campaigns.

Attack Chain

Initial access is gained through an unspecified vector (e.g., phishing, exploitation of a vulnerability).
The attacker obtains elevated privileges on the system.
The attacker uses an administrative tool like reg.exe or PowerShell to modify the registry.
The attacker disables real-time monitoring by setting HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableRealtimeMonitoring to 1.
The attacker disables tamper protection by setting HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Features\TamperProtection to 0.
The attacker disables PUA Protection by setting HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\PUAProtection to 0.
With Defender weakened, the attacker executes malicious payloads, such as ransomware or cryptocurrency miners.

Impact

Successful tampering with Microsoft Defender can lead to a significant degradation of endpoint security posture. This can result in undetected malware infections, data breaches, and system compromise. Disabling Defender features can allow attackers to establish persistence, escalate privileges, and deploy malicious payloads without triggering alerts. The impact can range from individual system compromise to widespread network infection, depending on the attacker’s objectives and the extent of the tampering.

Recommendation

Deploy the Sigma rule “Microsoft Windows Defender Tampering - Disable Realtime Monitoring” to your SIEM to detect modifications to the DisableRealtimeMonitoring registry value.
Deploy the Sigma rule “Microsoft Windows Defender Tampering - Disable Tamper Protection” to detect modifications to the TamperProtection registry value.
Monitor registry modification events, specifically targeting keys associated with Microsoft Defender settings as described in the rule query.
Investigate any process modifying Windows Defender registry settings that are not explicitly authorized, referencing the process exclusions in the rule query.

DNS-over-HTTPS Enabled via Registry Modification

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

The use of DNS-over-HTTPS (DoH) can obscure network activity, potentially allowing malicious actors to bypass traditional DNS monitoring and conceal data exfiltration. When DoH is enabled, visibility into DNS query types, responses, and originating IPs is lost, hindering the detection of malicious activity. This behavior is detected by monitoring registry modifications associated with enabling DoH in popular browsers such as Microsoft Edge, Google Chrome, and Mozilla Firefox. The registry keys targeted are associated with settings that force the browsers to use secure DNS resolution, potentially circumventing organizational security policies.

Attack Chain

Initial Access: An attacker gains initial access to a Windows system through various means, such as phishing or exploiting a software vulnerability.
Privilege Escalation (if necessary): The attacker may need to escalate privileges to modify registry settings.
Defense Evasion: The attacker modifies the Windows registry to enable DNS-over-HTTPS (DoH) in web browsers like Edge, Chrome, or Firefox. This is achieved by modifying specific registry keys such as HKLM\SOFTWARE\Policies\Microsoft\Edge\BuiltInDnsClientEnabled, HKLM\SOFTWARE\Google\Chrome\DnsOverHttpsMode, or HKLM\SOFTWARE\Policies\Mozilla\Firefox\DNSOverHTTPS.
Obfuscation: By enabling DoH, the attacker encrypts DNS queries, making it difficult for network monitoring tools to inspect DNS traffic.
Command and Control: The attacker establishes command and control (C2) communication with a remote server over encrypted DNS traffic, evading traditional network-based detection methods.
Data Exfiltration: The attacker uses the encrypted DNS channel to exfiltrate sensitive data, bypassing network security controls that rely on DNS inspection.
Persistence (Optional): The attacker might establish persistence by ensuring the DoH settings remain enabled across system reboots.

Impact

Successful exploitation leads to a loss of visibility into DNS traffic, hindering incident response and threat hunting efforts. Attackers can effectively hide command-and-control communications and data exfiltration activities. Although this activity by itself isn’t inherently malicious, it removes a layer of defense, increasing the risk that malicious activities will go undetected.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect the enabling of DNS-over-HTTPS via registry modifications.
Enable Sysmon registry event logging to capture the necessary events for the provided Sigma rules to function effectively.
Review and update security policies to ensure DNS-over-HTTPS is only enabled through approved channels and for legitimate purposes, reducing the risk of misuse, and create exceptions in the detection rule for systems where this is a known requirement.
Investigate any alerts generated by the Sigma rules, focusing on identifying the user account, process, and associated network activity (reference the investigation guide in the source URL).

Modification of WDigest Security Provider

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

The WDigest security provider is a legacy authentication protocol that, when enabled, stores user passwords in cleartext within LSASS memory. Modern Windows versions (8.1+ and Server 2012 R2+) disable this behavior by default. Attackers can modify the UseLogonCredential registry value under the WDigest configuration to re-enable plaintext credential caching. This manipulation is a common precursor to credential dumping attacks, where tools like Mimikatz are used to extract sensitive information from LSASS. Defenders should monitor for unauthorized modifications to the WDigest configuration to prevent credential theft. The rule provided by Elastic aims to detect these modifications.

Attack Chain

An attacker gains initial access to a Windows system via compromised credentials or exploiting a vulnerability (e.g., phishing or RDP).
The attacker executes code (e.g., PowerShell script or executable) with sufficient privileges to modify the registry.
The malicious code modifies the UseLogonCredential registry value under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest or a similar path.
The attacker sets the UseLogonCredential value to 1 (or 0x00000001), enabling plaintext storage of credentials.
A user logs on to the system, causing their credentials to be stored in cleartext in LSASS memory.
The attacker uses credential dumping tools like Mimikatz to extract the cleartext passwords from LSASS.
The attacker uses the stolen credentials for lateral movement or to access sensitive data.

Impact

Successful modification of the WDigest security provider can lead to widespread credential compromise. Attackers can harvest credentials for privileged accounts, enabling them to move laterally within the network, access sensitive resources, and potentially achieve domain dominance. This can result in data breaches, financial loss, and reputational damage.

Recommendation

Deploy the Sigma rule “Modification of WDigest Security Provider” to your SIEM to detect malicious registry modifications (rule d703a5af-d5b0-43bd-8ddb-7a5d500b7da5).
Enable Sysmon registry event logging to capture the necessary data for the provided Sigma rule to function.
Monitor process creation events for unexpected processes modifying registry keys related to WDigest.
Review and restrict access control lists (ACLs) on the WDigest registry keys to prevent unauthorized modifications.
Investigate any alerts generated by the Sigma rule, focusing on the process that made the modification, the user context, and any subsequent activity.

Code Signing Policy Modification Through Registry

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

Attackers can modify the BehaviorOnFailedVerify registry key to disable code signing enforcement, allowing the execution of unsigned or self-signed code. This subverts trust controls and enables attackers to load and execute malicious drivers or other executables without proper validation. The targeted registry value controls how the system behaves when a driver’s signature verification fails, and altering this value can weaken system security. This technique is a common method to bypass security measures that rely on code signing to ensure the integrity and authenticity of software. This activity has been observed across various environments where endpoint detection and response solutions are deployed. The rule identifies registry modifications that can disable DSE.

Attack Chain

The attacker gains initial access to the target system through methods such as phishing, exploiting vulnerabilities, or social engineering.
The attacker escalates privileges to obtain administrative rights, which are required to modify the registry.
The attacker uses a command-line tool, such as reg.exe or PowerShell, to modify the BehaviorOnFailedVerify registry value.
The registry value is changed to either “0” or “1”, effectively disabling or weakening code signing enforcement.
The attacker loads an unsigned or self-signed malicious driver or executable.
The malicious code executes without proper validation, allowing the attacker to perform malicious activities on the system.
The attacker may then establish persistence, move laterally within the network, or exfiltrate sensitive data.
The final objective could be data theft, ransomware deployment, or establishing a long-term foothold within the compromised environment.

Impact

Successful modification of the code signing policy can lead to the execution of arbitrary code without proper validation, potentially compromising the entire system. Attackers can use this technique to install rootkits, bypass security software, and perform other malicious activities. Depending on the attacker’s objectives, this can result in data theft, system instability, or complete system compromise. While no specific victim count or sector is mentioned, any Windows system where code signing is relied upon for security is potentially at risk.

Recommendation

Deploy the Sigma rule Code Signing Policy Modification Through Registry to your SIEM to detect suspicious registry modifications (rule.name). Tune the rule to exclude legitimate software installers or system administration tools that may temporarily modify these settings.
Monitor registry events, specifically changes to the BehaviorOnFailedVerify value, to identify potential attempts to disable code signing policy (event.type, registry.value, registry.data.strings).
Investigate any alerts generated by the detection rule, focusing on the process execution chain and the legitimacy of the user account performing the action (rule.note).
Enable Sysmon registry event logging to gain better visibility into registry modifications (setup).
Ensure that Driver Signature Enforcement (DSE) is enabled on all systems to prevent the loading of unsigned drivers (rule.description).
Deploy the Sigma rule Suspicious Process Modifying Code Signing Policy Registry to identify potentially malicious processes attempting to disable code signing (rule.name).