Defender XDR — CraftedSignal Threat Feed

Wireless Credential Dumping via Netsh

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

Attackers often target wireless credentials to gain unauthorized network access. This involves using the legitimate Windows command-line tool netsh.exe to extract Wi-Fi passwords stored on a compromised system. By leveraging netsh, attackers can bypass traditional security measures and retrieve sensitive information without deploying custom malware. The technique involves specific command-line arguments that instruct netsh to display wireless keys in cleartext, exposing the network passwords. Defenders must monitor netsh command-line activity to identify potential credential access attempts. This activity can lead to lateral movement within the network.

Attack Chain

The attacker gains initial access to a Windows system (e.g., via phishing or exploiting a software vulnerability).
The attacker executes netsh.exe with specific arguments to list available wireless profiles.
The attacker identifies a target wireless profile from the list.
The attacker executes netsh.exe again, this time specifying the target profile and requesting the key to be displayed in cleartext using the key=clear argument.
Netsh.exe retrieves the Wi-Fi password from the Windows Wireless LAN service.
The password is displayed in the command output, which the attacker captures.
The attacker uses the obtained Wi-Fi password to connect to the wireless network.
The attacker can now perform lateral movement and access internal resources.

Impact

Successful credential dumping allows attackers to gain unauthorized access to wireless networks. This can lead to lateral movement within the organization’s network, access to sensitive data, and further compromise of systems and resources. The impact includes potential data breaches, financial losses, and reputational damage. This technique allows attackers to bypass traditional network access controls.

Recommendation

Deploy the Sigma rule Detect Wireless Credential Dumping via Netsh to identify suspicious netsh.exe commands in your environment.
Enable Sysmon process creation logging to capture the netsh.exe command-line arguments.
Investigate any alerts triggered by the Sigma rule, focusing on the process lineage and user context as outlined in the “Triage and analysis” section of the source.
Implement strong password policies for Wi-Fi networks, including the use of WPA2 or WPA3 encryption.
Review and restrict the use of netsh.exe on systems where it is not required, using application control solutions.
Monitor for related alerts indicating lateral movement, staging, remote access, or persistence, as mentioned in the “Triage and analysis” section of the source.

Persistence via BITS Job Notify Cmdline

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

The Background Intelligent Transfer Service (BITS) is a Windows service used for asynchronous, prioritized, and throttled file transfers. Attackers can abuse BITS to establish persistence by using the SetNotifyCmdLine method to execute a program after a BITS job completes or enters a specific state. This technique allows adversaries to run arbitrary code with elevated privileges, bypassing traditional security measures. The detection rule identifies suspicious processes initiated by BITS, excluding known legitimate executables like WerFaultSecure.exe, WerFault.exe, wermgr.exe, and directxdatabaseupdater.exe. This behavior can be employed to maintain access to a compromised system, even after a reboot or user logout. Defenders need to monitor BITS activity for unusual command-line executions to detect and prevent potential persistence attempts.

Attack Chain

An attacker gains initial access to a system through other means (e.g., phishing, exploitation of a vulnerability).
The attacker uses the BITSAdmin tool or PowerShell cmdlets to create a new BITS job.
The attacker configures the BITS job to download a malicious payload or execute a malicious script.
The attacker utilizes the SetNotifyCmdLine method to set a command that will be executed upon job completion or a specified state change.
The BITS service executes the specified command, which can be a script interpreter (e.g., powershell.exe, cmd.exe) or a malicious executable.
The malicious command downloads or executes further payloads, establishing persistence on the system.
The attacker maintains persistent access, allowing them to execute commands, steal data, or perform other malicious activities.

Impact

Successful exploitation allows attackers to maintain persistent access to compromised systems. This can lead to data theft, further malware deployment, or complete system compromise. The BITS service runs with elevated privileges, so any command executed via SetNotifyCmdLine will also run with those privileges. This persistence mechanism is difficult to detect because BITS is a legitimate Windows service, and its activity can be easily masked as normal system operations.

Recommendation

Monitor process creation events for processes spawned by svchost.exe with arguments containing “BITS” but not in the exclusion list (WerFaultSecure.exe, WerFault.exe, wermgr.exe, directxdatabaseupdater.exe) using the “Persistence via BITS Job Notify Cmdline” rule.
Implement the Sigma rule “Detect Suspicious BITS Job Creation” to identify unusual BITS job creation activities.
Review BITS job configurations on systems to identify and remove any unauthorized or suspicious jobs.
Enable Sysmon process creation logging to capture detailed information about process execution, including parent-child relationships and command-line arguments.

PowerShell Script Block Logging Disabled via Registry Modification

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

Attackers frequently disable PowerShell Script Block Logging to evade detection and hide malicious activities on compromised systems. By modifying the EnableScriptBlockLogging registry value to ‘0’ or ‘0x00000000’, adversaries can significantly reduce the visibility into their PowerShell-based attacks. This technique is particularly effective when followed by script-driven activity, making it harder for security teams to identify and respond to threats. This behavior has been observed across multiple environments, including those utilizing endpoint detection and response solutions such as Elastic Defend, Microsoft Defender XDR, SentinelOne, and CrowdStrike. The rule was last updated on 2026-05-04 and is designed to detect these specific registry modifications.

Attack Chain

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

Impact

Successful disabling of PowerShell Script Block Logging can severely hinder incident response efforts, allowing attackers to operate undetected for extended periods. Organizations may experience data breaches, financial losses, and reputational damage. The impact can be widespread as attackers leverage compromised systems for lateral movement and further exploitation. The loss of PowerShell logging can blind security teams, making it difficult to reconstruct attacker actions and contain the breach.

Recommendation

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

UAC Bypass via DiskCleanup Scheduled Task Hijack

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

This rule identifies User Account Control (UAC) bypass attempts via hijacking the DiskCleanup Scheduled Task. Attackers exploit this method to execute code with elevated privileges, bypassing standard security controls. The technique involves leveraging the cleanmgr.exe or taskhostw.exe executables with specific arguments (/autoclean and /d) outside of their expected paths. This allows attackers to run malicious code under the guise of a legitimate system process, making detection more challenging. This technique is used to gain elevated privileges on a compromised system, allowing for further malicious activities.

Attack Chain

An attacker gains initial access to the system (e.g., via phishing or exploiting a software vulnerability).
The attacker modifies or creates a scheduled task to execute cleanmgr.exe or taskhostw.exe with the /autoclean and /d arguments.
The modified scheduled task is triggered, executing the specified executable with the supplied arguments.
The executable, such as cleanmgr.exe, attempts to run Disk Cleanup.
If the executable path is outside the standard locations (e.g., C:\\Windows\\System32 or C:\\Windows\\SysWOW64), it indicates a potential hijack.
Malicious code is executed with elevated privileges due to the UAC bypass.
The attacker uses these elevated privileges to install malware, modify system settings, or perform other malicious activities.

Impact

Successful exploitation allows attackers to bypass User Account Control (UAC) and execute code with elevated privileges. This can lead to the installation of malware, modification of system settings, data theft, and other malicious activities. While the exact number of victims is unknown, this technique is effective on systems where UAC is enabled but misconfigured or vulnerable.

Recommendation

Deploy the Sigma rule “UAC Bypass via DiskCleanup with Suspicious Path” to your SIEM and tune for your environment to detect UAC bypass attempts.
Deploy the Sigma rule “UAC Bypass via DiskCleanup and Taskhostw” to your SIEM to detect UAC bypass attempts.
Monitor process creation events for cleanmgr.exe and taskhostw.exe with the /autoclean and /d arguments, focusing on executions outside the standard system directories.
Review and harden scheduled tasks to prevent unauthorized modifications.
Ensure that UAC settings are properly configured and enforced across the organization.

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.

Potential Defense Evasion via Filter Manager (fltMC.exe)

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

The Filter Manager Control Program (fltMC.exe) is a Windows utility used to manage filter drivers, also known as minifilters. These minifilters are leveraged by various security products, including EDR, antivirus solutions, and data loss prevention tools, to intercept and modify I/O requests. Attackers can abuse fltMC.exe to unload these minifilters, effectively disabling or circumventing the security measures they provide. This allows malicious actors to operate without detection, potentially leading to data breaches, malware infections, or other harmful activities. This technique has been observed being used to disable security products such as Bitdefender, SentinelOne and ManageEngine Endpoint Central.

Attack Chain

Attacker gains initial access to the target system (e.g., via compromised credentials or exploit).
Attacker executes fltMC.exe with administrative privileges.
fltMC.exe attempts to unload a specific filter driver (minifilter).
The operating system processes the request to unload the specified filter driver.
If successful, the targeted minifilter is removed from the active filter stack.
Security software relying on the unloaded minifilter ceases to function correctly, leaving a security gap.
Attacker performs malicious actions, such as deploying malware or exfiltrating sensitive data, without the protection of the disabled filter driver.
Attacker achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation allows attackers to disable or circumvent security controls, increasing the likelihood of successful malware infections, data breaches, and other malicious activities. The scope of impact depends on the specific filter driver unloaded and the security products it supports. Disabling a critical EDR minifilter could leave the entire system vulnerable, while disabling a less critical filter might only impact a subset of security features.

Recommendation

Monitor process creation events for the execution of fltMC.exe with the unload argument to identify potential evasion attempts (see Sigma rule “Potential Evasion via Filter Manager”).
Investigate any instances of fltMC.exe execution where the parent process is not a known and trusted system management tool.
Implement strict access controls to limit the ability of users to execute fltMC.exe or modify filter driver configurations.
Review the list of exclusions in the provided EQL query to identify any legitimate software that may be generating false positives.
Ensure that endpoint security solutions are properly configured and monitored to detect and prevent unauthorized filter driver modifications.
Enable Sysmon process creation logging to activate the rules above.

Network Logon Provider Registry Modification

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

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

Attack Chain

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

Impact

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

Recommendation

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

Detection of Encrypted Archive Creation with WinRAR or 7-Zip

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

Attackers frequently compress and encrypt data before exfiltration to reduce the amount of data being sent over the network and to obfuscate the contents. This behavior often indicates a later stage of intrusion where the attacker has already collected sensitive data and is preparing to move it out of the environment. The use of archiving tools like WinRAR and 7-Zip with encryption flags can help attackers to hide their activities, making it more difficult for defenders to identify and respond to data theft. This technique has been observed in multiple threat actors including Turla as documented by WeLiveSecurity. This brief focuses on detecting command-line activity indicative of archive creation with encryption using WinRAR or 7-Zip on Windows systems.

Attack Chain

Initial Access: The attacker gains initial access to the system through methods such as phishing, exploiting vulnerabilities, or using stolen credentials.
Credential Access: The attacker attempts to obtain credentials using techniques such as Mimikatz or credential dumping.
Discovery: The attacker performs reconnaissance to identify sensitive data and systems of interest.
Data Collection: The attacker gathers sensitive data from various locations on the compromised system or network.
Archive Creation: The attacker uses WinRAR or 7-Zip to create an encrypted archive of the collected data using command-line arguments like -hp, -p, /hp, or /p with rar.exe or WinRAR.exe or -p* with 7z.exe or 7za.exe.
Data Staging: The encrypted archive is moved to a staging location, such as a temporary directory or removable media.
Exfiltration: The attacker exfiltrates the encrypted archive from the network using various methods, such as FTP, SCP, or cloud storage services.
Covering Tracks: The attacker deletes the archive from the staging location to remove evidence of the activity.

Impact

A successful attack can lead to the exfiltration of sensitive data, including personally identifiable information (PII), financial records, intellectual property, and other confidential information. This can result in significant financial losses, reputational damage, legal liabilities, and regulatory fines for the victim organization. The number of victims and specific sectors targeted will vary depending on the attacker’s objectives and the nature of the compromised data.

Recommendation

Deploy the Sigma rule “Detect Encrypting Files with WinRar or 7z - CommandLine” to your SIEM to detect the execution of WinRAR or 7-Zip with encryption parameters (rule:Detect Encrypting Files with WinRar or 7z - CommandLine).
Enable process creation logging with command line arguments in Sysmon to ensure the necessary data is available for detection (Data Source: Sysmon).
Investigate any alerts generated by the Sigma rules to determine the scope and impact of the potential data exfiltration attempt (rule:Detect Encrypting Files with WinRar or 7z - CommandLine).
Monitor network traffic for unusual outbound connections, particularly to cloud storage services or other external destinations, that may indicate data exfiltration.

Potential Protocol Tunneling via Yuze

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

This rule detects the execution of Yuze, an open-source tunneling tool written in C, which is commonly used for intranet penetration. Yuze supports both forward and reverse SOCKS5 proxy tunneling and is often executed using rundll32 to load yuze.dll with the RunYuze export. Threat actors can leverage Yuze to proxy command and control (C2) communications or to pivot within a network. The detection focuses on identifying processes with command-line arguments indicative of Yuze execution, specifically those involving “reverse,” “-c,” “proxy,” “fwd,” and “-l” parameters. This activity has been observed in real-world campaigns, increasing the importance of timely detection and response.

Attack Chain

The attacker gains initial access to a target system through various means (e.g., phishing, exploitation of vulnerabilities).
The attacker uploads or drops the yuze.dll file onto the compromised host.
The attacker uses rundll32.exe to execute yuze.dll, calling the RunYuze export.
The command line includes parameters to establish a reverse or forward SOCKS5 proxy tunnel (e.g., rundll32 yuze.dll,RunYuze reverse -c :).
Yuze establishes a tunnel to a remote server, allowing the attacker to proxy network traffic.
The attacker uses the established tunnel to pivot within the network and access internal resources.
The attacker may proxy C2 traffic through the tunnel, masking the true origin of the commands.
The attacker performs actions on the internal network, such as data exfiltration or lateral movement, using the tunnel as a covert channel.

Impact

Successful exploitation allows attackers to establish covert communication channels, bypass network security controls, and proxy malicious traffic, potentially leading to unauthorized access to sensitive data, lateral movement within the network, and data exfiltration. The use of Yuze can obscure the origin of attacks, making attribution more difficult and hindering incident response efforts.

Recommendation

Deploy the Sigma rule “Potential Yuze Tunneling via Rundll32” to your SIEM to detect the execution of yuze.dll via rundll32.exe with specific command-line arguments.
Enable process creation logging (Sysmon Event ID 1 or Windows Security Auditing) to capture the necessary command-line information for the Sigma rules.
Investigate any identified instances of rundll32.exe executing yuze.dll, focusing on the parent processes and network connections.
Block the C2/relay IP or domain found in the -c argument at DNS/firewall, as described in the Triage and Analysis section of the rule’s note.