M365 Defender — CraftedSignal Threat Feed

Remote Desktop File Opened from Suspicious Path

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

Attackers are increasingly using malicious Remote Desktop Protocol (RDP) files to gain initial access to systems. These RDP files, often delivered via spearphishing attachments, contain connection settings that, when opened, can compromise a system. This technique allows adversaries to bypass traditional security measures by leveraging a legitimate tool (mstsc.exe) with a malicious configuration file. The observed activity involves opening RDP files from suspicious locations like Downloads, temporary folders (AppData\Local\Temp), and Outlook content cache (INetCache\Content.Outlook). This campaign has been observed as recently as October 2024, where Midnight Blizzard conducted large-scale spear-phishing using RDP files. Defenders should monitor for the execution of mstsc.exe with RDP files from untrusted locations.

Attack Chain

The attacker crafts a spearphishing email containing a malicious RDP file as an attachment.
The victim receives the email and, lured by social engineering, downloads the attached RDP file to a local directory, often the Downloads folder.
The victim double-clicks the RDP file, initiating the execution of mstsc.exe.
mstsc.exe reads the connection settings from the RDP file, which may include malicious configurations such as altered gateway settings or credential theft mechanisms.
mstsc.exe attempts to establish a remote desktop connection based on the RDP file’s settings.
If the connection is successful, the attacker gains unauthorized access to the remote system.
The attacker may then perform reconnaissance, move laterally, and escalate privileges within the compromised network.
The final objective could be data exfiltration, ransomware deployment, or establishing persistent access.

Impact

A successful attack using malicious RDP files can lead to unauthorized access to sensitive systems and data. The consequences range from data breaches and financial loss to complete system compromise and disruption of operations. The Microsoft Security blog reported a large-scale spear-phishing campaign utilizing RDP files as recently as October 2024. The targets may be across various sectors, with potentially widespread impact depending on the attacker’s objectives and the scope of the compromised network.

Recommendation

Deploy the Sigma rule Remote Desktop File Opened from Suspicious Path to your SIEM and tune for your environment, focusing on the specified file paths and mstsc.exe execution.
Enable process creation logging with command-line arguments to capture the execution of mstsc.exe and the paths of the RDP files being opened.
Educate users on the risks associated with opening RDP files from untrusted sources, particularly those received as email attachments.
Implement strict email filtering to block or quarantine emails with RDP attachments from external sources.
Monitor network connections for unusual RDP traffic originating from systems where suspicious RDP files were executed.

Command Shell Activity Started via RunDLL32

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

Attackers commonly abuse RunDLL32, a legitimate Windows utility, to execute malicious code by hosting it within DLLs. This technique allows adversaries to launch command shells like cmd.exe or PowerShell, effectively bypassing traditional security controls. Defenders should be aware of this technique because it provides a stealthy way for attackers to execute arbitrary commands, potentially leading to further compromise of the system. This activity is detected by monitoring for command shells initiated by RunDLL32, while excluding known benign patterns to reduce false positives. The detection rule was last updated on 2026/05/04 and supports multiple data sources, including Elastic Defend, Microsoft Defender XDR, and Sysmon.

Attack Chain

The attacker gains initial access to the system through an exploit or social engineering.
The attacker uses RunDLL32.exe to execute a malicious DLL.
RunDLL32.exe loads the specified DLL into memory.
The malicious DLL contains code to execute a command shell (cmd.exe or powershell.exe).
RunDLL32.exe spawns a command shell process.
The attacker uses the command shell to execute commands for reconnaissance.
The attacker may use the command shell to download additional payloads.
The attacker leverages the command shell to perform lateral movement.

Impact

Successful exploitation allows attackers to execute arbitrary commands on the compromised system. While the rule is rated “low” severity, this initial access can lead to credential access (T1552) and further lateral movement within the network. Attackers can potentially gain full control of the system, leading to data theft, system disruption, or other malicious activities.

Recommendation

Deploy the Sigma rule “Command Shell Activity Started via RunDLL32” to your SIEM and tune for your environment.
Enable Sysmon process creation logging (Event ID 1) to provide the necessary data for this detection.
Review the process details of RunDLL32.exe to confirm the parent-child relationship with the command shell, helping to reduce false positives.
Implement enhanced monitoring for rundll32.exe and related processes to detect similar activities in the future and improve response times.

Code Signing Policy Modification Through Built-in Tools

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

Attackers may attempt to subvert trust controls by disabling or modifying the code signing policy. This allows them to execute unsigned or self-signed malicious code. This can be achieved by modifying boot configuration data (BCD) settings using the built-in bcdedit.exe utility on Windows. Disabling Driver Signature Enforcement (DSE) allows the loading of untrusted drivers, which can compromise system integrity. The rule identifies commands that can disable the Driver Signature Enforcement feature. The scope of the targeting is broad, as it can affect any Windows system where an attacker gains sufficient privileges to modify the BCD settings. This activity is detected by analyzing process execution events for specific command-line arguments used with bcdedit.exe. The detection rule was last updated on 2026-05-04.

Attack Chain

The attacker gains administrative privileges on a Windows system.
The attacker executes bcdedit.exe with arguments to disable driver signature enforcement. Example: bcdedit.exe /set testsigning on or bcdedit.exe /set nointegritychecks on.
The bcdedit.exe modifies the Boot Configuration Data (BCD) store.
The system is restarted to apply the changes made to the BCD.
The attacker loads an unsigned or self-signed malicious driver.
The malicious driver executes with kernel-level privileges.
The attacker performs malicious activities such as installing rootkits, bypassing security controls, or stealing sensitive data.
The attacker maintains persistence by ensuring the malicious driver is loaded on subsequent system reboots.

Impact

Successful modification of the code signing policy can lead to the execution of unsigned or self-signed malicious code, which can compromise the integrity and security of the system. Attackers can install rootkits, bypass security controls, or steal sensitive data. The impact can range from individual system compromise to broader network-wide attacks, depending on the attacker’s objectives.

Recommendation

Deploy the Sigma rule “Code Signing Policy Modification Through Built-in Tools” to your SIEM to detect the execution of bcdedit.exe with arguments used to disable code signing (process.args).
Enable process creation logging with command line arguments on Windows systems to ensure the Sigma rule can capture the relevant events (logsource).
Investigate any detected instances of code signing policy modification, as this activity is typically not legitimate and can indicate malicious activity. The rule First Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9 can be used to detect suspicious drivers loaded into the system after the command was executed.
Ensure that Driver Signature Enforcement is enabled on all systems.

Windows Console History Clearing

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

Attackers can try to cover their tracks by clearing the PowerShell console history on Windows systems. PowerShell offers multiple ways to log commands, including the built-in history and the command history managed by the PSReadLine module. This activity is often part of post-compromise behavior aimed at evading detection and forensic analysis. This rule detects the execution of specific commands that clear the built-in PowerShell logs or delete the ConsoleHost_history.txt file. The rule focuses on PowerShell activity and covers scenarios where commands like Clear-History, Remove-Item, rm, and Set-PSReadlineOption are used to manipulate command history.

Attack Chain

Initial access is gained through an unspecified method, potentially exploiting a vulnerability or using stolen credentials.
The attacker executes PowerShell (powershell.exe, pwsh.exe, or powershell_ise.exe) to perform reconnaissance and other malicious activities.
The attacker attempts to clear the PowerShell command history using the Clear-History cmdlet.
Alternatively, the attacker attempts to remove the ConsoleHost_history.txt file using Remove-Item or rm, which stores the PSReadLine command history.
Another method involves using the Set-PSReadlineOption cmdlet with the SaveNothing parameter to prevent the saving of future command history.
The attacker may leverage other tools and techniques to further obscure their activities and maintain persistence on the compromised system.
The attacker attempts to move laterally to other systems within the network to increase their impact.
The final objective is data exfiltration, deployment of ransomware, or other malicious activities, all while attempting to evade detection by clearing logs and command history.

Impact

Successful clearing of console history hinders forensic investigations and incident response efforts. If command history is cleared, administrators will have difficulty reconstructing the attacker’s actions and identifying the extent of the compromise. This can lead to prolonged incident response times, increased damage, and potential for further exploitation of the compromised systems.

Recommendation

Deploy the Sigma rule Detect Clearing PowerShell History to your SIEM to detect the use of Clear-History cmdlet, potentially indicating an attempt to remove command history.
Deploy the Sigma rule Detect Removal of PowerShell History File to detect the use of Remove-Item or rm command against the PowerShell history file.
Enable PowerShell logging and auditing policies to ensure adequate visibility into PowerShell activity as described in the setup instructions to improve detection capabilities.

Suspicious Managed Code Hosting Process

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

This detection identifies suspicious managed code hosting processes on Windows systems. Attackers may leverage processes like wscript.exe, cscript.exe, mshta.exe, wmic.exe, svchost.exe, dllhost.exe, cmstp.exe, and regsvr32.exe to execute malicious code, often bypassing traditional security controls. These processes can be abused to load and execute .NET assemblies or other managed code components. The detection focuses on identifying unusual file creation events associated with these processes which could indicate an attacker is attempting to leverage these processes for malicious purposes. This activity might be indicative of code injection, defense evasion, or other suspicious code execution techniques. The rule uses EQL to search for file events associated with specific processes.

Attack Chain

An attacker gains initial access to the system through a phishing email or compromised software.
The attacker uses a LOLBin such as mshta.exe or regsvr32.exe to bypass application control.
The LOLBin executes a malicious script or loads a malicious DLL from a user-writable location.
The malicious script or DLL performs reconnaissance activities, such as gathering system information or enumerating network resources.
The attacker then attempts to escalate privileges by exploiting a vulnerability or using stolen credentials.
The attacker uses the compromised process to download and execute additional malware.
The malware establishes persistence on the system through scheduled tasks or registry modifications.
The attacker performs lateral movement within the network, compromising additional systems and exfiltrating sensitive data.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to compromise systems, steal sensitive data, and establish persistence. The use of LOLBins can bypass application control, making detection more challenging. Depending on the scope of the attack, this could result in significant financial losses, reputational damage, and disruption of business operations. This is a high-severity finding due to the potential for attackers to gain full control over affected systems.

Recommendation

Enable Sysmon file creation logging (Event ID 11) to collect the necessary data for this detection.
Deploy the Sigma rule “Suspicious Managed Code Hosting Process” to your SIEM and tune for your environment.
Investigate any alerts generated by this rule, focusing on the file paths, process command lines, and parent processes involved.
Monitor for unexpected file creation events associated with processes like wscript.exe, cscript.exe, and mshta.exe in user-writable directories.
Implement application control policies to restrict the execution of LOLBins and other potentially malicious processes.
Correlate the detection with other security events to identify related malicious activity.

Suspicious Alternate Data Stream (ADS) File Creation

hello@craftedsignal.io — Fri, 26 Jan 2024 18:00:00 +0000

This detection focuses on identifying the creation of Alternate Data Streams (ADS) on Windows systems, a technique often employed by adversaries to conceal malicious code or data within seemingly benign files. Attackers leverage scripting engines and command interpreters to write ADS to various file types, including executables, documents, and media files. This activity is uncommon in legitimate workflows, making it a valuable indicator of potential compromise. The rule is designed to trigger on file creation events where the process creating the file is a known script or command interpreter (cmd.exe, powershell.exe, etc.) and the target file has a suspicious extension. The detection excludes common legitimate ADS usage patterns. This technique is used for defense evasion, allowing malware to persist without being easily detected by traditional security measures.

Attack Chain

An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
The attacker uses a command interpreter (cmd.exe, powershell.exe, etc.) or scripting engine (wscript.exe, cscript.exe) to execute malicious code.
The malicious code creates an Alternate Data Stream (ADS) on a targeted file (e.g., an executable, document, or image). The targeted file’s extension could be pdf, dll, exe, dat, etc.
The attacker hides malicious code or data within the ADS, making it less visible to standard file system scans and security tools. The ADS is written to a file path using the C:\\*:\* syntax.
The attacker may rename or clean up any staging files to further conceal their activity.
The attacker can then execute the hidden code within the ADS, or use the ADS to store configuration data for later use.
The attacker maintains persistence by using the ADS to store and execute malicious code, bypassing typical file-based security measures.
The ultimate goal is to maintain unauthorized access to the system, potentially leading to data exfiltration, lateral movement, or other malicious activities.

Impact

Successful exploitation allows attackers to hide malicious code within legitimate files, evading detection by traditional security measures. This can lead to prolonged persistence on compromised systems, enabling data theft, ransomware deployment, or other malicious activities. While the specific number of victims is unknown, this technique is broadly applicable across Windows environments, potentially affecting a wide range of organizations.

Recommendation

Deploy the Sigma rule Suspicious ADS File Creation via Cmd to detect ADS creation events initiated by cmd.exe.
Deploy the Sigma rule Suspicious ADS File Creation via PowerShell to detect ADS creation events initiated by powershell.exe.
Enable Sysmon Event ID 15 (FileCreateStreamHash) to provide detailed information about ADS creation events, as referenced in the rule’s setup instructions.
Investigate any alerts generated by these rules, focusing on the file paths, creating processes, and command-line arguments involved, as detailed in the rule’s triage and analysis notes.

Group Policy Discovery via Microsoft GPResult Utility

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

Attackers may leverage the gpresult.exe utility, a built-in Windows tool, to gather information about Group Policy Objects (GPOs) within an Active Directory environment. This reconnaissance activity allows adversaries to understand the existing security policies, identify potential misconfigurations, and discover pathways for privilege escalation or lateral movement. The rule focuses on detecting the execution of gpresult.exe with specific command-line arguments (/z, /v, /r, /x) commonly associated with malicious reconnaissance. This behavior is typically observed after an initial compromise, where the attacker is attempting to map out the network and identify valuable targets. This activity matters for defenders as it provides an early indicator of post-compromise activity and can help prevent further damage.

Attack Chain

The attacker gains initial access to a Windows system through methods such as phishing, exploiting vulnerabilities, or using stolen credentials.
The attacker executes gpresult.exe from the command line or through a script.
The attacker uses command-line arguments such as /z, /v, /r, or /x to request detailed information about Group Policy settings.
gpresult.exe queries the Active Directory domain to retrieve GPO information applicable to the user or computer.
The attacker parses the output of gpresult.exe to identify security policies, user rights assignments, and other relevant configurations.
The attacker identifies potential weaknesses in the GPO configuration, such as overly permissive user rights or insecure password policies.
The attacker uses the gathered information to exploit identified weaknesses and escalate privileges or move laterally to other systems within the network.
The attacker achieves their objective, such as data exfiltration, system compromise, or deployment of ransomware.

Impact

Successful exploitation can lead to a comprehensive understanding of the target environment’s security posture, enabling attackers to identify and exploit weaknesses for privilege escalation and lateral movement. While the source does not specify a number of victims or sectors targeted, the impact of a successful attack can range from data breaches and financial losses to reputational damage and disruption of operations. The discovery of misconfigured group policies can open doors for attackers to compromise critical systems and data within the network.

Recommendation

Deploy the Sigma rule “Group Policy Discovery via GPResult” to your SIEM to detect the execution of gpresult.exe with suspicious parameters.
Enable Windows process creation logging to capture command-line arguments used with gpresult.exe and other executables.
Review and harden Group Policy configurations to minimize the risk of exploitation by attackers.
Investigate any alerts generated by the Sigma rule “Group Policy Discovery via GPResult” to determine the context and intent of the activity.

Windows Script Execution from Archive File

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

Attackers commonly use archive files (ZIP, RAR, 7z) to deliver malicious scripts, such as JScript and VBScript, to Windows systems. This technique allows them to bypass some initial security checks and deliver payloads that can execute arbitrary code. The “Windows Script Execution from Archive” detection identifies instances where Windows Script Host (wscript.exe) is launched from temporary directories containing extracted archive contents. This activity can indicate a user has opened a malicious archive, leading to potential malware execution. This detection focuses on the parent-child process relationship, where explorer.exe, winrar.exe, or 7zFM.exe spawns wscript.exe to execute scripts from the temp directory.

Attack Chain

A user receives a malicious archive file (e.g., ZIP, RAR, 7z) via email or downloads it from a website.
The user opens the archive file using a file archiver tool like Explorer, WinRAR, or 7-Zip.
The archiver extracts the contents, including a malicious JScript (.js) or VBScript (.vbs) file, to a temporary directory, such as \Users\*\AppData\Local\Temp\7z*\.
The user (or the archiver tool) inadvertently executes the extracted script using Windows Script Host (wscript.exe).
Wscript.exe executes the malicious script, which may perform a variety of actions, such as downloading and executing additional payloads.
The script establishes persistence via registry modification, adding a run key to execute upon system startup.
The script connects to a command-and-control server to receive further instructions.
The attacker gains control of the compromised system and begins lateral movement.

Impact

A successful attack of this nature can lead to arbitrary code execution on the victim’s machine, potentially resulting in data theft, malware installation, or complete system compromise. While the number of affected organizations is not specified, the technique is broadly applicable to any Windows environment where users handle archive files, potentially affecting numerous individuals and organizations across various sectors.

Recommendation

Enable process creation logging with command line arguments to capture the execution of wscript.exe and its arguments.
Deploy the Sigma rule “Detect Script Execution from Archive” to your SIEM to identify suspicious script execution patterns.
Monitor process activity for wscript.exe and other scripting engines executing from temporary directories.
Configure endpoint security solutions to block execution of scripts from common temporary directories.

Windows Account Discovery of Administrator Accounts

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

Attackers often perform reconnaissance activities within a compromised environment to understand the available resources and potential targets. This reconnaissance helps them plan subsequent actions, such as privilege escalation and lateral movement. This activity involves using built-in Windows utilities like net.exe and wmic.exe to enumerate administrator-related user accounts and groups. This information can reveal potential targets for credential compromise or other post-exploitation activities. Lower privileged accounts commonly perform this enumeration.

Attack Chain

The attacker gains initial access to a Windows system.
The attacker executes net.exe with arguments to list users and groups.
The attacker filters the output for administrator-related keywords like “admin”, “Domain Admins”, “Enterprise Admins”, “Remote Desktop Users”, or “Organization Management”.
Alternatively, the attacker executes wmic.exe to query user accounts.
The attacker parses the output from wmic.exe to identify administrator accounts.
The attacker identifies privileged accounts to target for credential theft or privilege escalation.
The attacker uses the identified accounts to perform lateral movement or access sensitive data.

Impact

Successful enumeration of administrator accounts allows an attacker to identify high-value targets within the environment. This can lead to credential theft, privilege escalation, lateral movement, and ultimately, unauthorized access to sensitive data or systems. While the risk score is low, this activity serves as a precursor to more serious compromises.

Recommendation

Monitor process creation events for net.exe and wmic.exe commands with arguments related to user and group enumeration using the Sigma rules provided.
Investigate any instances of lower-privileged accounts executing these commands and filter out authorized administrative accounts performing the same actions.
Enable Windows process creation logging to capture the necessary events.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.

Proxy Execution via Windows OpenSSH Client

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

This detection identifies attempts to execute commands through a proxy using the Windows OpenSSH client (ssh.exe or sftp.exe). Attackers may abuse this behavior to evade application control policies by leveraging the trusted Windows OpenSSH binaries. The technique involves using the ProxyCommand or LocalCommand options with the OpenSSH client to execute arbitrary commands on the target system. The rule focuses on detecting command lines containing potentially malicious commands such as PowerShell, schtasks, mshta, msiexec, cmd, or script execution, indicating a possible attempt to bypass security measures. The detection logic is applicable to Windows systems.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker executes the Windows OpenSSH client (ssh.exe or sftp.exe) with either the ProxyCommand or LocalCommand option.
The ProxyCommand or LocalCommand parameter specifies a command to be executed locally on the system.
The command includes potentially malicious payloads such as PowerShell commands, scheduled tasks manipulation (schtasks), or execution of other LOLBINs (Living Off the Land Binaries) like mshta or msiexec.
The OpenSSH client executes the specified command.
The malicious command performs actions such as downloading and executing additional payloads, creating scheduled tasks for persistence, or executing arbitrary code.
The attacker achieves their objectives, such as gaining further access to the system, escalating privileges, or deploying malware.

Impact

Successful exploitation can lead to a complete compromise of the affected system. Attackers can bypass application control mechanisms, execute arbitrary code, and establish persistence. This can result in data theft, system disruption, or further propagation of the attack within the network. The severity of the impact depends on the privileges of the account running the OpenSSH client and the specific actions performed by the malicious commands.

Recommendation

Enable process creation logging with command line details to capture the execution of ssh.exe and sftp.exe with malicious parameters.
Deploy the Sigma rule Proxy Execution via Windows OpenSSH to your SIEM to detect suspicious OpenSSH client executions with malicious commands in the command line.
Monitor for the creation of child processes from ssh.exe or sftp.exe, as this can indicate the execution of malicious commands specified in the ProxyCommand or LocalCommand options.
Review and restrict the usage of PermitLocalCommand in OpenSSH server configurations to prevent attackers from executing commands locally on the system after a connection is established.

Potential DNS Tunneling via NsLookup

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

Attackers can abuse DNS protocol for command and control and/or data exfiltration by exploiting network rules that allow DNS communication with external resources. This technique, known as DNS tunneling, involves encoding data within DNS queries to transmit commands, malicious files, or exfiltrate sensitive information to attacker-controlled DNS servers. Detection focuses on identifying anomalous patterns of nslookup.exe usage, specifically a high volume of executions with explicit query types originating from a single host within a short timeframe. This activity may bypass traditional security controls that monitor standard network traffic, enabling covert communication channels.

Attack Chain

The attacker compromises a host within the network.
The attacker executes nslookup.exe to perform DNS queries with specific query types (e.g., -querytype=TXT, -qt=A).
The attacker encodes data (commands, files, or exfiltrated data) into the DNS query.
The compromised host sends multiple DNS requests to a rogue DNS server controlled by the attacker.
The attacker receives the DNS queries and decodes the data.
The attacker uses the tunneled command to further compromise the internal network.
The attacker exfiltrates data to the attacker-controlled server.

Impact

Successful DNS tunneling allows attackers to establish covert communication channels, bypassing traditional security measures. This can lead to command and control of compromised systems, exfiltration of sensitive data, and further propagation within the network. The impact includes potential data breaches, system compromise, and prolonged attacker presence due to the difficulty in detecting covert DNS traffic.

Recommendation

Deploy the Sigma rule “Suspicious Nslookup DNS Tunneling Activity” to your SIEM to detect potential DNS tunneling attempts.
Enable Sysmon process creation logging (Event ID 1) to capture nslookup.exe executions and their command-line arguments.
Inspect network traffic logs for unusually high volumes of DNS queries originating from individual hosts.
Monitor DNS query logs for encoded or unusual data patterns within DNS query names.

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.

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.

Adding Hidden File Attribute via Attrib.exe

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

Attackers can add the ‘hidden’ attribute to files to hide them from the user in an attempt to evade detection. This technique involves using the attrib.exe utility to modify file attributes. By setting the hidden attribute, adversaries can conceal tooling and malware to prevent administrators and users from finding it, even if they are looking specifically for it. This tactic is often employed post-compromise to maintain a stealthy presence within the target environment. Detection focuses on monitoring process executions that involve attrib.exe with command-line arguments indicating the modification of the hidden attribute. The rule is designed for data generated by Elastic Defend, CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs.

Attack Chain

Initial Access: An attacker gains initial access to a Windows system through various means such as exploiting a vulnerability or using stolen credentials.
Privilege Escalation: The attacker escalates privileges to gain the necessary permissions to execute system utilities.
Defense Evasion: The attacker uses attrib.exe to modify the hidden attribute of a malicious file or directory. For example, attrib.exe +h C:\path\to\malicious\file.exe.
Concealment: The malicious file or directory is now hidden from normal directory listings, making it harder for users and administrators to detect.
Persistence: The attacker establishes persistence by hiding malicious scripts or executables in startup directories or scheduled tasks.
Lateral Movement: The attacker uses the hidden files to move laterally within the network, potentially using them as part of a larger attack campaign.

Impact

The impact of this attack includes prolonged attacker presence, increased difficulty in detecting malicious activity, and potential data exfiltration or system compromise. While the risk score is relatively low, the technique contributes to a broader attack chain and can significantly hinder incident response efforts. A successful hiding of artifacts might lead to further compromise, data breaches, or ransomware deployment.

Recommendation

Deploy the Sigma rule “Adding Hidden File Attribute via Attrib” to your SIEM to detect suspicious usage of attrib.exe.
Enable process creation logging with command line monitoring in Windows environments to ensure the Sigma rule can capture relevant events.
Investigate any alerts generated by the Sigma rule, focusing on the parent processes and target files to determine if the activity is legitimate.
Correlate detections of attrib.exe with other suspicious activities or alerts on the same host.
Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden attribute.

Detecting Execution from Alternate Data Streams

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

Alternate Data Streams (ADS) are a feature of the NTFS file system that allows files to contain multiple data streams. Adversaries can exploit this feature to hide malicious code within legitimate files, making detection more difficult. This technique is often used for defense evasion, as security tools may not inspect ADS when scanning for malware. This detection focuses on identifying processes initiated from ADS by monitoring process execution paths and arguments, specifically looking for the pattern “?:\:”. This activity is uncommon for legitimate processes, making it a valuable indicator of potential malicious activity. The rule is designed for data generated by Elastic Defend, but also supports CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.

Attack Chain

An attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker creates an Alternate Data Stream (ADS) within a seemingly benign file (e.g., harmless.txt:malicious.exe).
The attacker copies or moves malicious executable code into the newly created ADS.
The attacker uses a method to execute the code within the ADS, often involving command-line arguments that specify the ADS path (e.g., harmless.txt:malicious.exe).
The operating system executes the code contained within the ADS as if it were a standard executable.
The malicious code performs its intended actions, such as installing malware, establishing persistence, or escalating privileges.
The attacker may attempt to further conceal their activity by deleting the original executable or modifying timestamps.
The final objective is to achieve persistence, exfiltrate data, or perform other malicious activities while evading traditional detection methods.

Impact

Successful exploitation allows attackers to hide and execute malicious code, bypassing standard security measures. This can lead to malware infections, data breaches, and system compromise. The number of victims and specific sectors targeted can vary, but the potential impact includes data loss, financial damage, and reputational harm.

Recommendation

Deploy the Sigma rule “Unusual Process Execution from Alternate Data Stream” to your SIEM and tune for your environment to detect processes executing from ADS.
Enable Sysmon process creation logging to capture process execution events necessary for the Sigma rule to function correctly.
Investigate any alerts generated by the Sigma rule, focusing on processes with command-line arguments matching the ?:\\*:\* pattern.
Review process details, including the process name and path, to determine if it is a known legitimate application or potentially malicious, as described in the rule’s investigation guide.
Correlate events with other security logs or alerts from data sources like Sysmon, Microsoft Defender XDR, or Crowdstrike to gather additional context.