CrowdStrike FDR — CraftedSignal Threat Feed

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.

WDAC Policy File Creation by Unusual Process

hello@craftedsignal.io — Sat, 02 Nov 2024 12:00:00 +0000

Attackers are increasingly targeting Windows Defender Application Control (WDAC) to disable or weaken endpoint defenses. By crafting malicious WDAC policies, adversaries can block legitimate security software and evade detection. This technique involves creating WDAC policy files (.p7b or .cip) in protected system directories using unauthorized processes. The activity often occurs when attackers have already gained a foothold in the system and are attempting to solidify their position. Successful deployment of a malicious WDAC policy can significantly hinder incident response and allow malware to operate undetected. This tactic has gained traction since late 2024, with offensive tools like Krueger demonstrating the potential for weaponizing WDAC against EDR solutions.

Attack Chain

Initial Access: The attacker gains initial access to the system through methods such as phishing or exploiting a software vulnerability.
Privilege Escalation: The attacker escalates privileges to gain administrative access, which is required to modify WDAC policies.
Policy Creation: The attacker crafts a malicious WDAC policy using tools or scripts. This policy is designed to block specific security products or processes.
Staging: The malicious policy is staged in a temporary location on the system, often within user-writable directories.
Policy Placement: The attacker moves the malicious WDAC policy file (.p7b or .cip) to a protected system directory, such as C:\Windows\System32\CodeIntegrity\ or C:\Windows\System32\CodeIntegrity\CiPolicies\Active\. The tool used may be a Living-off-the-Land Binary (LOLBin) or a custom .NET assembly.
Activation: The attacker triggers the activation of the new WDAC policy, which often requires a system reboot or the use of a service control utility.
Defense Evasion: Once the policy is active, the targeted security products are blocked, allowing the attacker to operate with reduced risk of detection.
Lateral Movement/Objectives: With defenses weakened, the attacker can move laterally within the network, exfiltrate data, or achieve other objectives.

Impact

A successful attack targeting WDAC can severely impair an organization’s ability to detect and respond to threats. By blocking security software, attackers can operate with impunity, leading to data breaches, financial losses, and reputational damage. Observed damage includes disabled endpoint detection and response (EDR) solutions, allowing ransomware and other malware to execute without interference. The scope of impact can range from individual workstations to entire domains, depending on the breadth of the WDAC policy deployment.

Recommendation

Deploy the “WDAC Policy File by an Unusual Process” Sigma rule to your SIEM to detect unauthorized WDAC policy modifications.
Monitor file creation events with extensions .p7b and .cip in C:\Windows\System32\CodeIntegrity\ and C:\Windows\System32\CodeIntegrity\CiPolicies\Active\ directories, specifically filtering for processes other than poqexec.exe, TiWorker.exe, and omadmclient.exe.
Enable Sysmon Event ID 11 (File Create) logging to capture file creation events and provide the necessary data for the Sigma rule to function effectively.
Implement strict access control policies on WDAC policy directories to prevent unauthorized modification.

NTDS Dump via Wbadmin

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

This detection identifies the execution of wbadmin.exe with arguments indicative of an attempt to access and dump the NTDS.dit file from a Windows domain controller. Attackers with sufficient privileges, specifically those belonging to groups like Backup Operators, can abuse the legitimate wbadmin.exe utility to create a backup of the Active Directory database (NTDS.dit). This file contains sensitive credential information, and once obtained, attackers can extract password hashes and compromise the entire domain. This activity is often part of a larger attack aimed at gaining persistent access and control over the network. The Elastic detection rule was published on 2024-06-05 and last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to a system within the target network. This may be achieved through phishing, exploiting vulnerabilities, or compromised credentials.
The attacker escalates privileges to obtain membership in the Backup Operators group or a similar privileged group capable of running backups.
The attacker executes wbadmin.exe with the recovery argument, targeting the NTDS.dit file. The command line includes parameters to create a system state backup.
Wbadmin creates a backup of the system state, including the NTDS.dit file, in a specified location.
The attacker copies the NTDS.dit file from the backup location to a separate location for offline analysis.
The attacker uses tools such as ntdsutil.exe or secretsdump.py to extract password hashes from the NTDS.dit file.
The attacker cracks the password hashes or uses them in pass-the-hash attacks to gain access to other systems and resources within the domain.
The attacker achieves domain dominance and persistence, allowing them to control critical systems and data.

Impact

Successful exploitation allows attackers to dump credentials from the NTDS.dit file, leading to complete compromise of the Active Directory domain. This enables them to move laterally, access sensitive data, and establish persistent control over the environment. The impact can include data breaches, ransomware deployment, and long-term disruption of business operations. The medium risk score indicates that while the attack requires specific privileges, the consequences are significant if successful.

Recommendation

Enable process creation logging with command line arguments to detect wbadmin.exe execution as described in the Attack Chain (Data Source: Windows Security Event Logs, Sysmon).
Implement the provided Sigma rule to detect suspicious wbadmin.exe execution with NTDS.dit related arguments in your SIEM (Rule: NTDS Dump via Wbadmin).
Monitor and restrict membership in privileged groups like Backup Operators to minimize the risk of abuse (Reference: https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960).
Review and whitelist legitimate backup schedules or disaster recovery processes to reduce false positives (False positive analysis).

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.

Windows Sandbox Abuse with Sensitive Configuration

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

Attackers may abuse the Windows Sandbox feature to evade detection by running malicious code within the isolated environment. This involves configuring the sandbox with sensitive options such as granting write access to the host file system, enabling network connections, and setting up automatic command execution via logon. By running within the sandbox with these configurations, malware can potentially interact with the host system, while making detection more difficult. This technique is used for defense evasion, hiding artifacts, and executing malicious activities within a virtualized environment to avoid direct exposure on the host. The rule identifies the start of a new container with sensitive configurations like write access to the host file system, network connection and automatic execution via logon command.

Attack Chain

An attacker gains initial access to the system through an exploit or social engineering.
The attacker leverages Windows Sandbox by executing wsb.exe or WindowsSandboxClient.exe.
The attacker configures the sandbox to enable networking using Enable or true.
The attacker grants the sandbox write access to the host file system using C:\\false.
The attacker sets up a logon command to automatically execute malicious code when the sandbox starts using .
The sandbox initializes and executes the configured logon command.
The malicious code interacts with the host file system and network, performing actions such as data exfiltration or lateral movement.
The attacker achieves their objective, such as deploying ransomware or stealing sensitive information, while operating from within the isolated sandbox environment.

Impact

A successful attack using Windows Sandbox abuse can lead to a range of negative impacts. Attackers may gain unauthorized access to sensitive data, compromise system integrity, or disrupt business operations. The use of the sandbox environment helps to conceal malicious activity, making detection and remediation more challenging. The damage can include data breaches, financial losses, reputational damage, and regulatory penalties. Successful exploitation allows malware to interact with the host system, potentially affecting multiple systems on the network.

Recommendation

Deploy the “Windows Sandbox with Sensitive Configuration” detection rule to your SIEM to identify potential sandbox abuse attempts.
Monitor process creation events for wsb.exe and WindowsSandboxClient.exe with command-line arguments that enable networking (Enable, true).
Monitor process creation events for wsb.exe and WindowsSandboxClient.exe with command-line arguments that enable write access to the host file system (C:\\false).
Monitor process creation events for wsb.exe and WindowsSandboxClient.exe with command-line arguments that define logon commands ().
Enable Sysmon process creation logging (Event ID 1) to capture the necessary command-line arguments.

Windows Subsystem for Linux Distribution Installed via Registry Modification

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

Attackers may leverage the Windows Subsystem for Linux (WSL) to evade detection by operating within a Linux environment on a Windows host. The installation of a new WSL distribution involves specific registry modifications. This rule identifies such modifications, providing an alert when a new WSL distribution is installed. This is important for defenders as it could signal an attacker setting up a persistent and potentially hidden environment for malicious activities. WSL allows attackers to utilize Linux tools and techniques on a Windows system, potentially bypassing traditional Windows-based security measures.

Attack Chain

Initial Access: The attacker gains initial access to the Windows system through existing vulnerabilities or compromised credentials.
Privilege Escalation: The attacker elevates their privileges to perform system-level changes, including registry modifications.
WSL Installation: The attacker initiates the installation of a WSL distribution. This may involve downloading and executing a WSL installer package.
Registry Modification: During installation, the system modifies the registry to configure and register the new WSL distribution. Specifically, keys under HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Lxss\\ are created/modified.
WSL Environment Setup: The attacker configures the installed WSL distribution, potentially installing additional tools and software needed for their objectives.
Execution of Malicious Activities: The attacker executes malicious commands and scripts within the WSL environment, leveraging Linux tools to perform actions such as lateral movement, data exfiltration, or persistence.
Defense Evasion: The attacker utilizes WSL to evade detection, as traditional Windows-based security tools may not effectively monitor or analyze activity within the Linux subsystem.
Persistence: The attacker establishes persistence within the WSL environment, ensuring continued access to the compromised system even after reboots or security updates.

Impact

Successful exploitation allows attackers to establish a hidden and persistent environment within the compromised Windows system. This can lead to data theft, system compromise, and further propagation of the attack within the network. The number of victims and affected sectors depends on the scope and objectives of the attacker. The use of WSL for malicious purposes can significantly complicate incident response and remediation efforts.

Recommendation

Deploy the Sigma rule “Detect WSL Installation via Registry Modification” to your SIEM to detect new WSL installations by monitoring registry changes.
Enable Sysmon registry event logging to capture the necessary data for the Sigma rule to function correctly (see setup instructions in the rule description).
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the WSL installation and identify potential malicious activities.
Monitor for execution of suspicious processes within WSL environments, as described in “Execution via Windows Subsystem for Linux - db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd”.

Suspicious Antimalware Scan Interface DLL Creation

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

The Antimalware Scan Interface (AMSI) is a Windows interface that allows applications and services to integrate with antimalware products. Attackers may attempt to bypass AMSI to execute malicious code without detection. This detection identifies the creation of the AMSI DLL (amsi.dll) in unusual locations, which is a common technique used to load a rogue AMSI module instead of the legitimate one. This technique can be used to evade detection by security products that rely on AMSI for scanning potentially malicious scripts and code. The rule is designed to work with data from Winlogbeat, Elastic Endpoint, Sysmon, Endgame, SentinelOne Cloud Funnel, Microsoft Defender XDR, and Crowdstrike.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., phishing, exploit).
The attacker determines the location of the legitimate amsi.dll file.
The attacker identifies a writable directory where a malicious amsi.dll can be placed. This location must be in the search order of applications that use AMSI, such as PowerShell or other scripting hosts.
The attacker copies or creates a malicious amsi.dll in the identified location. This rogue DLL is designed to bypass or disable AMSI functionality.
A process like PowerShell or another scripting host is launched. Because the malicious amsi.dll is in a higher-priority directory, it is loaded instead of the legitimate AMSI library.
The launched process executes malicious code (e.g., PowerShell script).
Because the rogue amsi.dll is loaded, AMSI scans are bypassed, allowing the malicious code to execute without detection.

Impact

A successful AMSI bypass can allow attackers to execute malicious code, such as malware, scripts, or exploits, without detection by antimalware products. This can lead to system compromise, data theft, or other malicious activities. The impact can range from a single compromised endpoint to a wider breach of an organization’s network.

Recommendation

Enable file creation monitoring with Sysmon or Elastic Defend to detect the creation of files, specifically DLLs, in unusual locations.
Deploy the Sigma rule “Suspicious Antimalware Scan Interface DLL Creation” to your SIEM to detect the creation of amsi.dll in non-standard paths. Tune the rule for your environment.
Investigate any alerts generated by the Sigma rule by examining the parent process, file path, and user context to determine if the activity is malicious.

Script Execution via Microsoft HTML Application

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

This detection identifies the execution of scripts via HTML applications, leveraging Windows utilities like rundll32.exe or mshta.exe. Attackers often use this method to bypass process and signature-based defenses by proxying the execution of malicious content through legitimate, signed binaries. The detection focuses on specific command-line arguments and patterns associated with this technique, while also excluding known legitimate uses by applications such as Citrix System32 (wfshell.exe), Microsoft Access (MSACCESS.EXE), and Quokka.Works (GTInstaller.exe). This technique is used by attackers to execute malicious scripts without directly running them, thus evading traditional security measures. The detection rule analyzes process names, command-line arguments, parent processes, and file paths to identify potentially malicious activity indicative of defense evasion.

Attack Chain

An attacker gains initial access through various means (e.g., phishing, drive-by download).
The attacker leverages a malicious HTML application (HTA) file or a scriptlet (SCT) file.
The attacker uses mshta.exe or rundll32.exe to execute the malicious HTA or SCT file. The command line includes obfuscated or encoded script content.
mshta.exe or rundll32.exe process spawns a child process, such as cmd.exe or powershell.exe, to execute further commands.
The spawned process executes malicious code, such as downloading and executing a payload.
The attacker achieves persistence by modifying registry keys or creating scheduled tasks.
The attacker performs lateral movement by exploiting vulnerabilities or using stolen credentials.
The final objective is achieved, such as data exfiltration, ransomware deployment, or system compromise.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to compromise the system, steal sensitive data, deploy ransomware, or establish a persistent foothold. Due to the nature of the technique, it can bypass many traditional security measures. The wide adoption of Windows and the inherent trust placed in signed binaries makes this a potent evasion technique. Failure to detect and prevent this attack can lead to significant financial and reputational damage for the targeted organization.

Recommendation

Deploy the Sigma rule “Script Execution via Microsoft HTML Application” to your SIEM to detect suspicious mshta.exe and rundll32.exe executions. Tune the rule by adding exceptions for known legitimate uses in your environment.
Enable Sysmon process creation logging (Event ID 1) to ensure the visibility required for the Sigma rules to function correctly.
Monitor process command lines for suspicious arguments like “script:eval”, “WScript.Shell”, and “mshta http” which are indicative of this technique.
Implement application control policies to restrict the execution of mshta.exe and rundll32.exe where they are not required for legitimate business purposes.
Investigate and block any identified malicious HTA files or scriptlet URLs found in the command lines of detected processes.

Windows Scheduled Tasks AT Command Enabled via Registry Modification

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

The legacy Windows AT command allows scheduling tasks for execution. While deprecated since Windows 8 and Windows Server 2012, it remains present for backwards compatibility. Attackers may enable the AT command through registry modifications to achieve persistence or lateral movement within a network. This technique bypasses modern security controls and can be difficult to detect without specific monitoring. The detection rule monitors registry changes enabling this command, flagging potential misuse by checking specific registry paths and values indicative of enabling the AT command. The use of this command allows an attacker to execute commands with elevated privileges, potentially compromising the entire system.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.
The attacker attempts to enable the AT command by modifying the registry.
The registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration\EnableAt is modified to a value of “1” or “0x00000001”.
The attacker uses the AT command to schedule a malicious task.
The scheduled task executes a command or script, such as downloading and executing malware.
The malware establishes persistence on the system.
The attacker uses the compromised system as a pivot point for lateral movement.

Impact

Enabling the AT command can lead to unauthorized task scheduling, malware execution, persistence, and lateral movement within a network. Successful exploitation can compromise sensitive data, disrupt operations, and grant attackers persistent access to critical systems. The use of a deprecated command makes it harder to detect, increasing the impact.

Recommendation

Monitor registry events for modifications to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration\EnableAt as described in the rule overview.
Deploy the Sigma rule “Scheduled Tasks AT Command Enabled” to your SIEM and tune for your environment.
Enable Sysmon process creation and registry event logging to activate the rule.
Investigate any alerts triggered by the Sigma rule “Scheduled Tasks AT Command Enabled” for suspicious activity.

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.

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.

Execution via Local SxS Shared Module

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

This detection identifies potential abuse of the Windows Side-by-Side (SxS) feature to execute malicious code. Attackers can place a malicious DLL file within an application’s local SxS folder (application.exe.local) and trick the Windows module loader into prioritizing it over legitimate system DLLs. This technique, known as DLL hijacking or DLL redirection, allows adversaries to gain arbitrary code execution within the context of the targeted application. This technique may be used to bypass security controls, escalate privileges, or establish persistence. The detection focuses on file events related to DLLs within these specific SxS folders.

Attack Chain

The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker identifies a legitimate application with an associated SxS folder (application.exe.local).
The attacker creates or modifies a malicious DLL file.
The attacker places the malicious DLL file in the application’s SxS folder (application.exe.local).
A legitimate application attempts to load a DLL.
Due to the presence of the malicious DLL in the SxS folder, the Windows module loader prioritizes the attacker’s DLL.
The malicious DLL is loaded and executed by the application.
The attacker achieves code execution within the context of the application.

Impact

Successful exploitation can lead to arbitrary code execution within the targeted application’s context. This can result in privilege escalation, data theft, system compromise, or the establishment of persistence mechanisms. While the number of directly affected organizations is unknown, this technique can be used against a wide range of applications on Windows systems.

Recommendation

Monitor file creation events for DLL files in C:\*\*.exe.local\*.dll and \\Device\\HarddiskVolume*\\*\\*.exe.local\\*.dll using the provided Sigma rule to detect potential malicious DLL planting.
Enable Sysmon Event ID 11 (File Create) to improve visibility into file creation events, as noted in the setup instructions.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the DLL creation event and the involved application.

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.

Persistence via PowerShell Profile Modification

hello@craftedsignal.io — Tue, 02 Jan 2024 18:17:05 +0000

PowerShell profiles are scripts that run when PowerShell starts, customizing the user’s environment. Attackers can abuse this feature to gain persistence by modifying these profiles to execute malicious code each time a user launches PowerShell. The modification of PowerShell profiles allows the attacker to run arbitrary commands without requiring user interaction or explicit execution of malicious scripts. The targeted profile file names include profile.ps1 and Microsoft.Powershell_profile.ps1, and the attack affects Windows systems where PowerShell is commonly used.

Attack Chain

The attacker gains initial access to the system through unspecified means.
The attacker identifies the location of PowerShell profile scripts, typically found in C:\Users\\Documents\WindowsPowerShell\.
The attacker modifies an existing PowerShell profile (e.g., profile.ps1) or creates a new one if it doesn’t exist.
The attacker injects malicious code into the PowerShell profile. This code could download and execute additional payloads, establish a reverse shell, or perform other malicious activities.
The attacker ensures the malicious code runs when PowerShell is launched by modifying the profile content.
When a user opens PowerShell, the profile script executes automatically, running the injected malicious code.
The malicious code performs its intended actions, such as establishing persistence by creating scheduled tasks or modifying registry keys.

Impact

Successful exploitation allows attackers to maintain persistent access to compromised systems. This persistence can be used to perform various malicious activities, including data theft, lateral movement, and deployment of ransomware. The severity is medium as it requires local access or prior compromise, but can lead to significant impact if successful.

Recommendation

Deploy the Sigma rule “PowerShell Profile Modification” to detect unauthorized changes to PowerShell profile scripts.
Monitor file creation and modification events in the C:\Users\*\Documents\WindowsPowerShell\ and C:\Windows\System32\WindowsPowerShell\ directories for suspicious activity.
Enable PowerShell script block logging and transcription to gain visibility into the contents of PowerShell scripts being executed.
Restrict PowerShell usage to authorized personnel via Group Policy or other application control mechanisms.
Regularly audit PowerShell profiles for suspicious or unexpected code.