Masquerading — CraftedSignal Threat Feed

Potential Data Exfiltration via Rclone

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

Attackers are leveraging Rclone, a legitimate command-line program to manage files on cloud storage, for malicious purposes. The primary abuse case involves renaming Rclone (e.g., to TrendFileSecurityCheck.exe) to evade detection based on process name. Once renamed, attackers use Rclone’s copy/sync functionalities with cloud backends like S3 or HTTP endpoints. They often employ --include filters to target specific sensitive file types for exfiltration. This activity is frequently blended with regular administrative traffic to further obfuscate the malicious intent. Defenders should be aware of this tactic, particularly when unusual processes are observed interacting with cloud storage services.

Attack Chain

The attacker gains initial access to the system through an undisclosed method.
Rclone is downloaded or transferred to the victim machine.
The rclone executable is renamed to a benign-sounding name (e.g., TrendFileSecurityCheck.exe) to masquerade as a legitimate system utility.
The attacker configures rclone to connect to a cloud storage backend (e.g., an S3 bucket or HTTP endpoint) controlled by the attacker.
A command is executed using the renamed rclone executable, specifying the copy or sync command.
The command includes --include flags to filter and select specific file types (e.g., documents, source code, databases) for exfiltration.
Rclone transfers the targeted files from the victim machine to the attacker’s cloud storage backend, potentially using the --transfers option for faster exfiltration.
The attacker accesses the exfiltrated data from their cloud storage.

Impact

Successful exploitation can lead to the exfiltration of sensitive data, including proprietary information, customer data, financial records, or intellectual property. The impact can range from reputational damage and financial losses to legal and regulatory repercussions. The scope of damage depends on the sensitivity and volume of the exfiltrated data, the number of affected systems, and the effectiveness of the attacker’s filtering criteria.

Recommendation

Deploy the Sigma rule Suspicious Rclone Usage to detect renamed rclone executables executing copy/sync commands.
Enable Sysmon process creation logging (Event ID 1) to collect the necessary process execution data for the Sigma rules.
Investigate any process identified by the Sigma rule Suspicious Rclone Usage by examining command-line arguments for cloud backend destinations and --include filters.
Monitor network connections for unusual outbound traffic to cloud storage providers (AWS S3, Azure Blob Storage, Google Cloud Storage) from processes other than approved backup solutions.
Implement application control policies to restrict the execution of unauthorized or renamed executables.

Program Files Directory Masquerading

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

This detection identifies processes executing from directories that masquerade as the legitimate Windows Program Files directories. Attackers may create directories with similar names (e.g., “C:\Program Files Bad” or “C:\Program Files(x86) Malicious”) to host and execute malicious executables, bypassing security measures that trust the standard Program Files locations. This technique is particularly effective when combined with low-privilege accounts, as it allows attackers to evade detections that whitelist only the standard, trusted Program Files paths. The timeframe for this rule is the last 9 months. This matters to defenders because it highlights a common tactic used to bypass established trust relationships within the Windows operating system, requiring more granular inspection of process execution paths.

Attack Chain

An attacker gains initial access to a system, potentially through phishing or exploiting a vulnerability.
The attacker creates a new directory that mimics the “Program Files” or “Program Files (x86)” directory (e.g., “C:\Program Files Bad”).
The attacker copies or downloads malicious executable files into the newly created masquerading directory.
The attacker executes the malicious executable from the masquerading directory.
The operating system loads the executable and begins its execution, potentially bypassing any allowlisting rules that only check the standard “Program Files” locations.
The malicious executable performs its intended actions, such as installing malware, establishing persistence, or exfiltrating data.
The attacker leverages the compromised system to move laterally within the network, repeating the masquerading technique on other systems.

Impact

A successful attack can lead to malware infection, data theft, or complete system compromise. The impact is significant, as it undermines the trust placed in the “Program Files” directory and allows attackers to operate undetected for extended periods. While no specific victim counts are given, the technique is broadly applicable to any Windows environment, especially those relying on simple path-based allowlisting for security.

Recommendation

Deploy the Sigma rule Program Files Directory Masquerading Detection to your SIEM to detect suspicious process executions from masquerading directories.
Enable Sysmon process creation logging (Event ID 1) to collect the necessary process execution data for the Sigma rule.
Regularly review and update allowlisting rules to include more specific criteria beyond just the “Program Files” directory, such as file hashes or digital signatures.
Investigate any alerts generated by the Sigma rule, focusing on the parent processes and user accounts associated with the suspicious executions.
Monitor file creation events in the root directory to detect suspicious folders being created (file_event category)

Executable File Creation with Multiple Extensions

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

Adversaries may use masquerading techniques to evade defenses and blend into the environment by manipulating the name or location of a file, tricking users into executing malicious code disguised as a benign file type. This rule detects the creation of executable files with multiple extensions, a common method of masquerading. The rule focuses on identifying suspicious file creations that use misleading extensions, specifically targeting files with an “.exe” extension preceded by common benign extensions. It excludes known legitimate processes to minimize false positives. This activity is relevant for defenders to identify potential threats where adversaries attempt to bypass security measures by disguising malicious files.

Attack Chain

An attacker crafts a malicious executable file with a double extension (e.g., “document.pdf.exe”).
The attacker delivers the malicious file to the target system via phishing or other means.
The user downloads or receives the file and attempts to open it.
Windows displays the file with the first extension (“document.pdf”) by default, misleading the user.
Upon execution, Windows recognizes the “.exe” extension and executes the file.
The malicious executable runs, potentially deploying malware or performing other unauthorized actions.
The malware establishes persistence or attempts lateral movement within the network.
The attacker achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation can lead to malware infection, data breaches, and system compromise. This technique bypasses common file type restrictions and user awareness, potentially affecting a wide range of users and systems. While the number of victims is not specified, the impact can be significant, particularly in organizations where users handle sensitive data. The affected sectors are broad, encompassing any organization where users are susceptible to social engineering attacks.

Recommendation

Deploy the Sigma rule “Executable File Creation with Multiple Extensions” to your SIEM and tune for your environment to detect the creation of suspicious files with multiple extensions.
Enable Sysmon Event ID 11 (File Create) for comprehensive file creation monitoring to improve the effectiveness of the detection rule.
Implement enhanced monitoring and logging for similar file creation activities to improve detection and response capabilities.
Educate users on the risks associated with double file extensions and encourage caution when opening attachments from unknown sources.
Review and whitelist legitimate software installations that may create executables with multiple extensions to reduce false positives, as described in the rule’s triage notes.

Renamed Automation Script Interpreter

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

Malware operators often rename legitimate system and scripting tools to blend in with normal system processes and bypass security measures. This rule specifically detects instances where automation script interpreters like AutoIt, AutoHotkey, and KIX32 have been renamed. By comparing the process name against the original file name embedded in the executable, this detection identifies potential attempts to masquerade malicious scripts as legitimate software. This technique is employed to bypass application whitelisting and other security controls that rely on file names or process names for identification and authorization. This detection is relevant for any Windows environment where these scripting tools are used, as it can highlight potentially malicious activity masked by a common evasion technique.

Attack Chain

An attacker gains initial access to the system, often through phishing or exploiting a software vulnerability.
The attacker uploads or drops a malicious script (e.g., AutoIt, AutoHotkey, or KIX32 script) onto the target machine.
The attacker renames the legitimate AutoIt, AutoHotkey, or KIX32 interpreter executable to a non-standard name (e.g., “svchost.exe” or “wininit.exe”) to masquerade as a legitimate process.
The attacker executes the renamed interpreter, which in turn executes the malicious script.
The script performs malicious actions, such as downloading additional malware, modifying system settings, or establishing persistence.
The attacker uses the compromised system for lateral movement within the network or for data exfiltration.
The attacker attempts to maintain persistence on the system to ensure continued access.

Impact

Successful renaming of script interpreters allows attackers to execute malicious scripts undetected, potentially leading to data theft, system compromise, or further propagation within the network. The impact can range from minor disruption to significant financial loss and reputational damage, depending on the attacker’s objectives and the sensitivity of the compromised data.

Recommendation

Deploy the Sigma rule “Renamed AutoIt Interpreter” to your SIEM to detect when AutoIt executables are renamed, focusing on process.pe.original_file_name and process.name.
Deploy the Sigma rule “Renamed AutoHotkey Interpreter” to your SIEM to detect when AutoHotkey executables are renamed, focusing on process.pe.original_file_name and process.name.
Enable Sysmon process creation logging to capture the necessary process metadata, as referenced in the rule logsource.
Investigate any alerts generated by these rules to determine the legitimacy of the renamed executable and its associated activity as described in the note section.

Suspicious WerFault Child Process Abuse

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

This detection identifies suspicious child processes spawned by WerFault.exe, the Windows Error Reporting tool. Attackers can abuse WerFault by manipulating the SilentProcessExit registry key to execute malicious processes. This technique allows for defense evasion, persistence, and privilege escalation. The detection focuses on WerFault processes with specific command-line arguments (-s, -t, and -c) known to be used in SilentProcessExit exploitation, while excluding legitimate executables like Initcrypt.exe and Heimdal.Guard.exe. The rule helps defenders identify potential attempts to hijack the error reporting mechanism for malicious purposes. The monitored data sources include Windows Event Logs, Sysmon, Elastic Defend, Microsoft Defender XDR, and SentinelOne.

Attack Chain

An attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker modifies the SilentProcessExit registry key to specify a malicious process to be executed when a target application crashes. This involves setting the ReportingMode and Debugger values under the SilentProcessExit key for the target application.
The attacker triggers a crash in the target application or waits for a legitimate crash to occur.
WerFault.exe is invoked to handle the application crash.
Due to the registry modification, WerFault.exe spawns the attacker-controlled process, passing command-line arguments such as -s, -t, and -c.
The attacker-controlled process executes with the privileges of WerFault.exe, potentially achieving privilege escalation.
The malicious process performs actions such as injecting code into other processes, establishing persistence, or exfiltrating data.
The attacker achieves their objectives, such as maintaining persistence, escalating privileges, or evading detection.

Impact

A successful attack can lead to persistence, privilege escalation, and defense evasion. Attackers can use this technique to execute malicious code with elevated privileges, potentially bypassing security controls and gaining unauthorized access to sensitive data and system resources. The number of victims and affected sectors can vary depending on the attacker’s objectives and the scope of the initial compromise.

Recommendation

Enable Sysmon process creation logging to capture WerFault.exe child processes (Data Source: Sysmon).
Deploy the Sigma rule “WerFault Child Process Masquerading” to your SIEM and tune for your environment.
Review the SilentProcessExit registry key for unauthorized modifications (registry_set event).
Investigate any WerFault.exe processes with command-line arguments -s, -t, and -c (process_creation event).

Process Execution from Suspicious Windows Directories

hello@craftedsignal.io — Thu, 04 Jan 2024 12:00:00 +0000

This detection identifies process execution from suspicious default Windows directories. Attackers may hide malware in trusted paths to evade defenses, making it difficult for analysts to distinguish between legitimate and malicious activity. The detection focuses on identifying processes running from directories like C:\PerfLogs, C:\Users\Public, and various Windows subdirectories (e.g., C:\Windows\Tasks, C:\Windows\AppReadiness), where executable files are not typically expected to reside. The detection excludes known legitimate processes like SpeechUXWiz.exe, SystemSettings.exe, TrustedInstaller.exe and other Intel and IBM executables to reduce false positives. This technique is often used to bypass security controls or take advantage of existing exceptions applied to these directories. This activity was observed being used by threat actors in the Siestagraph campaign.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker drops a malicious executable into a suspicious directory like C:\Users\Public or C:\Windows\Tasks.
The attacker executes the malware from the unusual directory. This might be achieved using cmd.exe or powershell.exe.
The executed malware establishes persistence by creating a scheduled task or modifying registry keys.
The malware connects to a command-and-control (C2) server to receive further instructions.
The C2 server instructs the malware to perform reconnaissance on the network.
The malware attempts to move laterally to other systems on the network using techniques like pass-the-hash or exploiting vulnerabilities.
The attacker achieves their objective, such as data exfiltration, ransomware deployment, or establishing long-term access to the network.

Impact

Successful exploitation can lead to the execution of arbitrary code, persistence on the system, and further compromise of the network. Attackers can use this technique to bypass security controls and evade detection, potentially leading to data breaches, financial loss, or disruption of services. While the rule itself has a medium severity, the impact of a successful attack using this technique can be severe, depending on the attacker’s objectives and the compromised data.

Recommendation

Deploy the Sigma rule “Process Execution from Unusual Directory” to your SIEM and tune for your environment to detect suspicious process execution.
Investigate any alerts generated by the Sigma rule to determine if the process execution is legitimate or malicious.
Enable process creation logging, specifically Event ID 4688 with command line process auditing, to ensure the Sigma rule has the necessary data to function effectively.
Review and harden permissions on the listed suspicious directories to prevent unauthorized file creation and execution.
Block execution of unsigned or untrusted executables from these directories using application control solutions.

Suspicious Windows Process Cluster Detection via Machine Learning

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

This detection identifies suspicious Windows processes exhibiting high malicious probability scores. The rule leverages machine learning to detect clusters of processes that may be indicative of defense evasion tactics, such as masquerading or the use of LOLbins (Living Off The Land Binaries). Specifically, a supervised ML model (ProblemChild) predicts whether a process is malicious, and an unsupervised ML model assesses the aggregate score of process clusters on a single host. The rule focuses on identifying unusual process clusters on a single host, indicating potential masquerading tactics for defense evasion. The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. It was last updated on 2026/04/01 and requires Elastic Stack version 9.4.0 or later.

Attack Chain

Initial Access: The attacker gains initial access to the Windows host through various methods, such as exploiting vulnerabilities or using compromised credentials (not detailed in source).
Execution: The attacker executes a LOLBin (e.g., PowerShell, cmd.exe, mshta.exe) on the compromised host.
Masquerading: The attacker attempts to masquerade the malicious activity by naming or placing the LOLBin within a legitimate system folder.
Defense Evasion: The attacker utilizes the LOLBin with specific command-line arguments designed to evade detection by traditional signature-based security solutions.
Privilege Escalation (Optional): The attacker may attempt to escalate privileges using further LOLBINS or other techniques.
Lateral Movement (Optional): The attacker may use the compromised host to move laterally to other systems within the network.
Command and Control (Optional): The attacker may establish command and control (C2) communication with an external server to receive further instructions.
Impact: The attacker achieves their objective, such as data exfiltration, ransomware deployment, or system disruption.

Impact

A successful attack can lead to various negative impacts, including data breaches, financial loss, and reputational damage. The rule is assigned a low severity, due to it likely being a supplemental detection to other rules. Lateral movement and exfiltration can also be accomplished. There is no information available on the number of victims and specific sectors targeted.

Recommendation

Ensure the Living off the Land (LotL) Attack Detection integration is installed and configured correctly, along with either Elastic Defend or Winlogbeat, to collect Windows process events as outlined in the setup instructions.
Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts as suggested in the investigation guide.
Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading, per the investigation guide.
Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future, as advised in the remediation steps.
Tune the anomaly threshold of the machine learning job (problem_child_high_sum_by_host_ea) to reduce false positives based on your environment’s specific characteristics and activity patterns.

Signed Proxy Execution via MS Work Folders

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

Windows Work Folders is a Microsoft file server role that allows users to sync work files between their PCs and a central server. The WorkFolders.exe process, when called, will automatically execute any Portable Executable (PE) named control.exe as an argument before accessing the synced share. Attackers can abuse this functionality by placing a malicious executable renamed to control.exe in a location synced by Work Folders, and then triggering WorkFolders.exe. This can lead to the execution of arbitrary code in a manner that bypasses application control policies, as WorkFolders.exe is a signed Microsoft binary. This technique has been observed in the wild and documented by security researchers. This allows attackers to execute code from locations outside the standard Windows directories, evading traditional detection mechanisms.

Attack Chain

An attacker gains initial access to the target system through an unspecified means (e.g., phishing, exploiting a vulnerability).
The attacker places a malicious executable and renames it to control.exe in a directory accessible to Work Folders.
The attacker configures Windows Work Folders to synchronize the directory containing the malicious control.exe.
The victim system synchronizes with the Work Folders server, copying the malicious control.exe to the local machine.
The attacker triggers the WorkFolders.exe process.
WorkFolders.exe executes the control.exe binary from the synced folder.
The malicious control.exe executes, performing attacker-defined actions such as establishing persistence, escalating privileges, or deploying additional malware.
The attacker achieves code execution in a potentially elevated context, leveraging a signed Microsoft binary (WorkFolders.exe) to bypass security controls.

Impact

Successful exploitation allows attackers to execute arbitrary code on a victim’s machine, potentially bypassing application control and other security measures. This can lead to a range of malicious activities, including data theft, system compromise, and lateral movement within the network. Given the legitimate use of Work Folders, identifying malicious executions can be challenging, potentially allowing attackers to maintain a persistent foothold. The lack of specific victim counts or industry targeting details in the source material limits a complete assessment of impact scope.

Recommendation

Monitor process creations where WorkFolders.exe is the parent process and control.exe is the child process, but control.exe is not located in a standard Windows system directory (Sigma rule: “Detect Suspicious WorkFolders Control Execution”).
Investigate any instances where control.exe is executed from unusual or user-writable locations, especially if WorkFolders.exe is involved (see Attack Chain step 6).
Enable Sysmon process creation logging (Event ID 1) on Windows systems to capture the necessary data for the provided Sigma rules.
Review the Microsoft documentation on Windows Information Protection (WIP) and consider implementing it to encrypt data on PCs using Work Folders.
Implement application control policies that restrict the execution of control.exe to authorized locations (e.g., C:\Windows\System32).

Renamed Utility Executed with Short Program Name

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

This detection identifies the execution of a process with a single-character process name that differs from the original file name. Adversaries often employ this technique during staging, to execute temporary utilities, or to bypass security detections relying on process names. This behavior is typically observed in Windows environments where attackers attempt to masquerade their activities by renaming legitimate utilities to short, less conspicuous names, making it harder to identify malicious processes based on their name alone. The detection leverages process creation events from Elastic Defend, Microsoft Defender XDR, Crowdstrike, and Sysmon to identify such anomalies. The rule was initially created on 2020-11-15 and last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., phishing, exploitation of vulnerabilities).
The attacker renames a legitimate utility (e.g., cmd.exe, powershell.exe) to a single-character name such as a.exe.
The renamed utility a.exe is executed, potentially without parameters initially, to test execution.
The attacker uses the renamed utility a.exe to execute commands, download additional payloads, or perform reconnaissance.
The commands executed by a.exe might involve further obfuscation techniques to evade detection, such as base64 encoding or encryption.
The attacker leverages the renamed utility to establish persistence by creating scheduled tasks or modifying registry keys.
The attacker moves laterally within the network, using the compromised host as a staging point.
The attacker achieves their final objective, such as data exfiltration or ransomware deployment.

Impact

A successful attack using this technique can lead to significant compromise of the target system. By renaming legitimate utilities, attackers can bypass standard security measures that rely on process names for detection. This can result in delayed detection, allowing the attacker to perform further malicious activities such as data theft, installation of malware, or lateral movement within the network. While specific numbers are unavailable, this technique has been observed across various organizations, making it a relevant threat for defenders.

Recommendation

Enable process creation logging via Sysmon or Elastic Defend to provide the necessary data for detection.
Deploy the Sigma rule “Suspicious Renamed Utility Execution” to your SIEM and tune it based on your environment.
Investigate any alerts generated by the Sigma rule by examining the parent process and command-line arguments.
Review the osquery queries in the brief for additional context gathering during incident response.

Potential Windows Error Manager Masquerading

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

Attackers may attempt to evade defenses by masquerading malicious processes as legitimate Windows Error Reporting (WER) executables, specifically WerFault.exe or Wermgr.exe. These executables are responsible for handling application crashes and reporting errors to Microsoft. This technique involves launching these executables without command-line arguments and then establishing outgoing network connections. By mimicking the behavior of legitimate WER processes, adversaries can potentially bypass detections that focus on suspicious child process activity or command-line arguments, effectively blending their malicious network activity with normal system operations. This technique has been observed in conjunction with malware campaigns, highlighting the importance of detecting deviations from the expected behavior of WER processes.

Attack Chain

An attacker gains initial access to the system through an unspecified method.
The attacker deploys a malicious payload onto the compromised system.
The attacker executes WerFault.exe or Wermgr.exe without any command-line arguments. This is an attempt to mimic legitimate WER process behavior.
The masquerading WER process initiates an outgoing network connection to a command-and-control (C2) server. The specific protocol used is not specified.
The C2 server issues commands to the compromised system through the masquerading WER process.
The attacker executes malicious commands on the system, potentially including data exfiltration, lateral movement, or further payload deployment.
The attacker attempts to maintain persistence on the compromised system, potentially through registry modifications or scheduled tasks.
The attacker achieves their final objective, such as data theft, system disruption, or establishing a foothold for future attacks.

Impact

A successful masquerading attack can lead to a prolonged period of undetected malicious activity. Victims may experience data breaches, system compromise, and potential financial losses. The targeted systems could be incorporated into a botnet, used for cryptocurrency mining, or further exploited for lateral movement within the network. The lack of command-line arguments makes detection more challenging, allowing attackers to operate with a lower risk of detection.

Recommendation

Monitor process creation events for instances of WerFault.exe or Wermgr.exe executed with a single argument and an unusual command line, using the “Potential Windows Error Manager Masquerading” Sigma rule to detect such events.
Investigate network connections originating from WerFault.exe or Wermgr.exe, especially when the process is launched without arguments.
Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging to provide the necessary data for the Sigma rule.
Correlate process creation and network connection events to identify suspicious sequences, as outlined in the attack chain.
Implement network segmentation to limit the potential impact of compromised systems and restrict lateral movement.

Potential Masquerading as Communication Apps

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

Attackers may attempt to evade defenses by masquerading malicious processes as legitimate communication applications. This involves using names and icons that resemble trusted applications like Slack, WebEx, Teams, Discord, RocketChat, Mattermost, WhatsApp, Zoom, Outlook and Thunderbird to trick users and bypass security measures. This technique can be used to conceal malicious activity, bypass allowlists, or trick users into executing malware. The detection rule identifies suspicious instances by checking for unsigned or improperly signed processes, ensuring they match known trusted signatures, which helps in flagging potential threats that mimic trusted communication tools.

Attack Chain

An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
The attacker deploys a malicious executable onto the compromised system.
The attacker renames the malicious executable to resemble a legitimate communication application, such as “slack.exe” or “Teams.exe”.
The attacker modifies or removes the code signature of the malicious executable to avoid detection based on trusted publishers.
The attacker executes the renamed and potentially unsigned malicious executable.
The masqueraded process performs malicious actions, such as establishing a reverse shell or downloading additional payloads.
The attacker uses the compromised system to move laterally within the network, escalating privileges and compromising additional systems.
The final objective is to exfiltrate sensitive data or deploy ransomware.

Impact

Successful masquerading attacks can lead to significant security breaches, including data theft, system compromise, and financial loss. By disguising malicious processes as legitimate communication apps, attackers can bypass security controls and operate undetected for extended periods. This can result in widespread damage and disruption, as well as reputational damage for the targeted organization. The impact can range from a few compromised systems to a complete network takeover, depending on the attacker’s objectives and the effectiveness of the masquerading technique.

Recommendation

Deploy the Sigma rule “Potential Masquerading as Communication Apps - Generic” to your SIEM and tune for your environment to detect unsigned or improperly signed communication applications.
Deploy the Sigma rule “Potential Masquerading as Communication Apps - Specific” to your SIEM and tune for your environment to detect unsigned or improperly signed instances of specific communication applications.
Enable process creation logging on Windows systems to capture the necessary events for the Sigma rules.
Review and validate the code signatures of all communication apps on your systems to ensure they are properly signed by trusted entities.
Implement application control policies to restrict the execution of unsigned or untrusted executables.

Microsoft Build Engine Executed After Renaming

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

Attackers may rename legitimate utilities, such as MSBuild, to evade detection, application allowlists, and other security protections. MSBuild, the Microsoft Build Engine, is a platform for building applications. Attackers can abuse MSBuild to proxy the execution of malicious code. The detection rule identifies instances where MSBuild is started after being renamed, indicating a potential attempt to evade detection. The rule focuses on identifying processes where the original file name is MSBuild.exe, but the process name is different, suggesting a renaming attempt.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker renames the legitimate MSBuild.exe executable to a different name (e.g., evil.exe) to evade detection.
The attacker executes the renamed MSBuild executable (evil.exe) with a malicious project file (.csproj or similar).
MSBuild processes the project file, which contains commands or scripts to be executed.
The malicious commands within the project file are executed by MSBuild, potentially downloading or executing further payloads.
The attacker may use MSBuild to execute PowerShell commands or other scripting languages for lateral movement or further exploitation.
MSBuild can be used to modify files, registry entries, or other system settings.
The attacker achieves their final objective, such as data exfiltration or establishing persistence.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to install malware, steal sensitive information, or compromise the entire system. The renaming of MSBuild can bypass standard application allowlisting and detection mechanisms.

Recommendation

Enable Sysmon process creation logging to capture the Image and OriginalFileName fields.
Deploy the Sigma rule “Microsoft Build Engine Using an Alternate Name” to your SIEM and tune for your environment to detect renamed MSBuild executables based on process metadata and command-line arguments.
Monitor process execution events for processes with OriginalFileName of “MSBuild.exe” and a different process.name.
Implement application control policies to restrict the execution of renamed executables, specifically those with an OriginalFileName of “MSBuild.exe.”

Unusual Parent-Child Relationship Detection

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

This detection identifies Windows programs executed with unexpected parent processes, which may indicate masquerading, process injection, or other anomalous behavior. The detection logic focuses on deviations from established parent-child process relationships within the Windows operating system. This rule leverages data from multiple sources, including Elastic Defend, CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs, to enhance detection coverage. This is important for defenders as unusual parent-child process relationships can be indicative of various malicious activities, including privilege escalation and defense evasion techniques employed by threat actors. The rule aims to provide early detection of potentially malicious activities by identifying deviations from the expected process execution patterns.

Attack Chain

The attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker executes a malicious payload that attempts to masquerade as a legitimate process.
The malicious process is launched with an unexpected parent process, deviating from normal Windows process relationships. For example, autochk.exe running without smss.exe as its parent.
The malicious process attempts to inject code into other processes for privilege escalation or defense evasion, leveraging techniques like process hollowing.
The injected code gains elevated privileges, allowing the attacker to perform sensitive actions on the system.
The attacker uses the elevated privileges to move laterally within the network, compromising additional systems.
The attacker attempts to maintain persistence by creating scheduled tasks or modifying registry keys.
The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

A successful attack exploiting unusual parent-child relationships can lead to privilege escalation, allowing attackers to gain control of the compromised system. This can result in data breaches, system downtime, and financial losses. The rule aims to mitigate these risks by detecting suspicious process executions early in the attack chain. While the exact number of potential victims and sectors targeted is not explicitly mentioned, the broad applicability of Windows systems makes this a widespread threat.

Recommendation

Deploy the provided Sigma rules to your SIEM and tune for your environment to detect unusual parent-child process relationships (see rules section).
Enable process creation logging with command line arguments in your Windows environment using Sysmon or Windows Security Event Logs to ensure the necessary data is available for detection.
Investigate and baseline common parent-child process relationships in your environment to reduce false positives.
Integrate your SIEM with threat intelligence feeds to identify known malicious processes and their associated parent processes.
Configure endpoint detection and response (EDR) solutions like Elastic Defend, CrowdStrike, Microsoft Defender XDR, and SentinelOne to collect and analyze process execution data (see setup section in the source URL).
Refer to the investigation guide linked in the source URL to triage alerts related to unusual parent-child process relationships.

Potential Masquerading as Svchost

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

Attackers may attempt to evade detection by masquerading as legitimate system processes, specifically svchost.exe. The svchost.exe process is a critical component of the Windows operating system, responsible for hosting multiple Windows services. By naming a malicious executable svchost.exe and placing it in a non-standard directory, attackers aim to blend in with normal system activity and bypass security controls that rely on process names or paths. This technique is particularly effective because svchost.exe is a common and trusted process, making it less likely to be scrutinized by users or security software. This detection focuses on identifying processes named svchost.exe that are not running from the legitimate Windows system directories.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.
The attacker uploads a malicious executable disguised as svchost.exe to a non-standard directory, such as C:\Users\Public\.
The attacker executes the malicious svchost.exe process from the non-standard location.
The masquerading process attempts to mimic legitimate svchost.exe behavior to avoid suspicion.
The malicious svchost.exe process may establish network connections to external command-and-control servers.
The process may execute malicious payloads, such as downloading additional malware or performing lateral movement.
The attacker leverages the compromised system to access sensitive data or perform other malicious activities.
The attacker attempts to maintain persistence on the system to ensure continued access.

Impact

A successful masquerading attack can lead to undetected execution of malicious code, allowing attackers to compromise systems, steal data, or establish persistent access. Because the malicious process is disguised as a legitimate system component, it may evade detection by traditional security measures. This can result in significant damage to the affected organization, including data breaches, financial loss, and reputational damage.

Recommendation

Enable process creation logging with command line details to capture the execution of processes, including their names and paths.
Deploy the Sigma rule “Potential Svchost Masquerading” to detect svchost.exe processes running from non-standard locations.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the svchost.exe process and its activities.
Implement file integrity monitoring to detect unauthorized modifications to system files, including the svchost.exe executable in the system directories.
Use application control lists (ACLs) to restrict the execution of executables from non-standard directories.

Masquerading Business Application Installers

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

Attackers often attempt to trick users into downloading and executing malicious executables by disguising them as legitimate business applications. This tactic is used to bypass security measures and gain initial access to a system. These malicious executables, often distributed via malicious ads, forum posts, and tutorials, mimic the names of commonly used applications such as Slack, WebEx, Teams, Discord, and Zoom. The executables are typically unsigned or signed with invalid certificates to further evade detection. This allows the attacker to execute arbitrary code on the victim’s machine, potentially leading to further compromise. This campaign aims to target end-users who are less security-aware, and this makes social engineering attacks like this very effective.

Attack Chain

The user visits a compromised website or clicks on a malicious advertisement.
The user is prompted to download an installer file masquerading as a legitimate business application (e.g., Slack, Zoom, Teams) from a download directory.
The downloaded executable is placed in the user’s Downloads folder (e.g., C:\Users*\Downloads*).
The user executes the downloaded file.
The executable, lacking a valid code signature, begins execution.
The malicious installer may drop and execute additional malware components.
The malware establishes persistence, potentially using techniques such as registry key modification.
The malware performs malicious activities, such as data exfiltration or lateral movement.

Impact

Successful execution of a masqueraded business application installer can lead to a complete system compromise. The attacker gains initial access and can deploy various malware payloads, including ransomware, keyloggers, and data stealers. This can result in data breaches, financial loss, and reputational damage. Although the specific number of victims and sectors targeted are not detailed, the widespread use of the applications being spoofed (Slack, Zoom, etc.) suggests a broad potential impact.

Recommendation

Implement the Sigma rule Potential Masquerading as Business App Installer to detect unsigned executables resembling legitimate business applications in download directories.
Enable process creation logging to capture the execution of unsigned executables.
Educate users on the risks of downloading and executing files from untrusted sources.
Implement application whitelisting to restrict the execution of unauthorized applications.
Regularly update endpoint detection and response (EDR) tools to detect and prevent the execution of known malware.
Monitor process execution events for processes originating from the Downloads folder that lack valid code signatures.

File with Right-to-Left Override Character (RTLO) Created/Executed

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

The Right-to-Left Override (RTLO) character (U+202E) is a Unicode character that causes text to be displayed from right to left, instead of the usual left to right. This character can be exploited by attackers to disguise malicious file extensions, making a harmful file appear safe to unsuspecting users. For example, an executable file named “evil.exe” could be renamed to “evilU+202Eegp.txt.exe,” which, when displayed, would appear as “evil.exe.txt.ege,” tricking the user into thinking it’s a harmless text file. This detection rule identifies suspicious file or process activities on Windows systems by scanning for RTLO characters in file paths or process names, helping to uncover potential masquerading attempts. The detection is applicable to events from Elastic Defend, Microsoft Defender XDR, and SentinelOne Cloud Funnel.

Attack Chain

An attacker crafts a malicious file with an RTLO character embedded in its name. For example, badU+202Eexe.txt.
The attacker delivers the malicious file to the target system, possibly through phishing, web downloads, or other social engineering techniques.
The user receives the file and sees the file name as bad.txt.exe due to the RTLO character reversing the text display.
The user, believing the file is a harmless text file, executes the file.
The malicious file executes its intended payload, which could include installing malware, exfiltrating data, or performing other malicious actions.
The executed process may attempt to establish a command and control (C2) connection with an external server to receive further instructions.
The malware may attempt to escalate privileges or move laterally within the network to compromise additional systems.

Impact

Successful exploitation can lead to the execution of arbitrary code on the victim’s system. This can result in data theft, system compromise, and potential lateral movement within the network. The use of RTLO characters is a simple but effective defense evasion technique that can bypass standard security controls relying on file extension checks.

Recommendation

Deploy the Sigma rule Detect RTLO Character in Filename to your SIEM to detect suspicious file creations and executions involving the RTLO character (Data Source: Sysmon).
Enable process monitoring with command line auditing to capture the execution of processes with RTLO characters in their names (Logsource: process_creation).
Educate users about the dangers of RTLO characters and the importance of verifying file extensions before execution.
Implement file extension filtering policies to block the execution of certain file types, regardless of the displayed file name.