Windows Defender Advanced Threat Protection — CraftedSignal Threat Feed

Potential PowerShell Obfuscated Script via High Entropy

hello@craftedsignal.io — Mon, 04 May 2026 14:49:36 +0000

Attackers frequently employ PowerShell obfuscation techniques to evade detection and hinder analysis. These techniques involve encoding, encrypting, or compressing PowerShell scripts to mask their true intent. This detection identifies PowerShell script blocks exhibiting high entropy and non-uniform character distributions, statistical characteristics often associated with obfuscated content. The rule specifically targets script blocks longer than 1000 characters with entropy bits >= 5.5 and surprisal standard deviation > 0.7. This detection is designed to highlight potentially malicious PowerShell activity that warrants further investigation by security analysts and incident responders. This rule was created by Elastic and last updated on May 4, 2026.

Attack Chain

An attacker gains initial access to a system (e.g., via phishing or exploit).
The attacker leverages PowerShell, a built-in Windows scripting language, to execute malicious commands.
The attacker uses obfuscation techniques (encoding, encryption, compression) to disguise the PowerShell script’s true intent.
The obfuscated script is executed, bypassing basic signature-based detections.
The script may download and execute additional payloads or establish persistence.
The script performs malicious actions such as data exfiltration, lateral movement, or system compromise.

Impact

A successful attack using obfuscated PowerShell can lead to various negative impacts, including data breaches, system compromise, and disruption of services. The low severity reflects the need for further analysis to confirm malicious intent, given potential false positives from legitimate encoded scripts. While the exact number of affected systems and sectors is unknown, the widespread use of PowerShell makes this a potentially significant threat across many organizations.

Recommendation

Enable PowerShell Script Block Logging to generate the necessary events (4104) as outlined in the setup instructions: https://ela.st/powershell-logging-setup.
Deploy the provided Sigma rule to your SIEM and tune the thresholds (powershell.file.script_block_length, powershell.file.script_block_entropy_bits, powershell.file.script_block_surprisal_stdev) based on your environment’s baseline.
Investigate alerts generated by the Sigma rule, focusing on execution context (user.name, host.name), script provenance (file.path), and reconstructed script content (powershell.file.script_block_text).
Review the investigation guide within the rule’s note section for detailed triage and analysis steps.

Suspicious Registry Hive Access via RegBack

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

This detection identifies suspicious attempts to access registry backup hives (SAM, SECURITY, and SYSTEM) located in the RegBack folder on Windows systems. These hives contain sensitive credential material, making them attractive targets for attackers seeking to compromise system security. The detection logic focuses on file access events, specifically successful file opens, while excluding known benign processes such as taskhostw.exe and various AV/EDR solutions (SophosScanCoordinator.exe, MsSense.exe, ccSvcHst.exe, etc.) to minimize false positives. The rule is designed to provide defenders with high-fidelity alerts when unauthorized access to these critical registry hives is detected. The scope includes any Windows system where endpoint file access logging is enabled.

Attack Chain

An attacker gains initial access to the system through various means.
The attacker attempts to access the SAM, SECURITY, or SYSTEM registry hives located in the C:\\Windows\\System32\\config\\RegBack\\ directory.
The attacker leverages a tool or script to open one or more of these registry hives. This could involve using built-in Windows utilities, scripting languages, or custom-developed tools.
If the attacker successfully opens the SAM and SYSTEM hives, they can extract user account credentials, including usernames, password hashes, and other sensitive information. The SECURITY hive is also useful.
The attacker may stage the registry hive files by copying them to a different location on the system for further analysis or exfiltration.
The attacker uses credential dumping tools (e.g., Mimikatz, secretsdump.py) or custom scripts to extract credentials from the staged registry hives.
The attacker leverages the extracted credentials to escalate privileges, move laterally within the network, or access sensitive data.
The final objective is typically to gain unauthorized access to critical systems, steal sensitive data, or establish long-term persistence within the compromised environment.

Impact

Successful exploitation of this technique can lead to the compromise of user account credentials, enabling attackers to escalate privileges, move laterally within the network, and gain unauthorized access to sensitive data. The impact can range from data breaches and financial losses to reputational damage and disruption of critical business operations. The number of victims can vary depending on the scope of the attacker’s activities and the security posture of the targeted organization. Sectors commonly targeted include finance, healthcare, government, and critical infrastructure.

Recommendation

Enable file access monitoring for the C:\\Windows\\System32\\config\\RegBack\\ directory to capture file open events.
Deploy the Sigma rule Registry Hive Access via RegBack to your SIEM and tune the exclusions based on your environment.
Monitor process_creation events for unusual processes accessing files in C:\\Windows\\System32\\config\\RegBack\\, using the rule Suspicious Process Accessing RegBack Hives.
Enable Sysmon process creation logging and file creation to activate the rules above.

Potential Process Injection via PowerShell

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

This detection focuses on identifying PowerShell scripts that combine specific Win32 API calls, often used in process injection and in-memory payload execution techniques. Attackers use PowerShell, a ubiquitous scripting language in Windows environments, to inject malicious code into other processes, bypassing traditional security controls. The rule specifically targets API combinations related to memory allocation (VirtualAlloc, VirtualAllocEx), memory protection (VirtualProtect), process access (OpenProcess), dynamic library loading (LdrLoadDll, LoadLibrary), and thread manipulation (CreateRemoteThread, NtCreateThreadEx). The rule excludes script activity originating from within Microsoft Defender Advanced Threat Protection directories, reducing false positives. This technique is valuable to attackers seeking to evade detection and execute malicious code stealthily. The detection logic is based on observing specific API combinations, commonly seen in tools like Empire.

Attack Chain

An attacker gains initial access to a Windows system, possibly through phishing or exploiting a vulnerability.
The attacker uses PowerShell to execute a malicious script.
The PowerShell script uses OpenProcess to gain access to a target process.
The script then uses VirtualAllocEx to allocate memory within the target process.
WriteProcessMemory is used to write malicious code into the allocated memory.
The script uses CreateRemoteThread or NtCreateThreadEx to create a new thread within the target process, pointing to the injected code.
The injected code executes within the context of the target process.
The attacker achieves their objective, such as credential dumping or establishing persistence.

Impact

Successful process injection allows attackers to execute arbitrary code within the context of another process, often a legitimate one. This can lead to credential theft, privilege escalation, data exfiltration, or the deployment of ransomware. The impact is significant, as it allows attackers to bypass security controls and operate stealthily. While the number of victims is unknown, the widespread use of PowerShell makes this a potentially widespread threat. Successful attacks can compromise sensitive data, disrupt business operations, and damage an organization’s reputation.

Recommendation

Enable PowerShell Script Block Logging to capture the necessary events (4104) for this detection to function as described in the setup instructions https://ela.st/powershell-logging-setup.
Deploy the provided Sigma rules to your SIEM to detect suspicious PowerShell scripts indicative of process injection. Tune the rules based on your environment’s baseline activity.
Investigate any alerts generated by these rules, focusing on the reconstructed script content, target process, and execution context. Refer to the investigation guide section for triage steps.
Implement application control policies to restrict the execution of unauthorized PowerShell scripts.
Monitor PowerShell execution for suspicious API calls related to process injection, as described in the rule’s query.

Account Discovery Command via SYSTEM Account

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

This detection rule identifies instances where the SYSTEM account is used to execute account discovery utilities, such as whoami.exe and net1.exe. This behavior is commonly observed after an attacker has successfully achieved privilege escalation within a Windows environment, or after exploiting a web application. The rule is designed to detect post-exploitation discovery activity where an adversary attempts to gain situational awareness by enumerating accounts and system information using the elevated SYSTEM context. The rule leverages data from Elastic Defend and Sysmon Event ID 1 to identify these behaviors, helping defenders spot potential privilege escalation and lateral movement attempts. The original rule was created 2020/03/18 and updated 2026/05/04.

Attack Chain

An attacker gains initial access to a system, potentially through exploiting a vulnerability in a web application or through phishing.
The attacker escalates privileges to the SYSTEM account, possibly by exploiting a local privilege escalation vulnerability.
The attacker executes whoami.exe or net1.exe via the SYSTEM account to enumerate user accounts and gather system information.
The whoami.exe or net1.exe process is spawned by a parent process such as a web server process (e.g., w3wp.exe) or a service process.
The attacker uses the discovered account information to plan further actions, such as lateral movement or credential theft.
The attacker may use net1.exe to query domain information.
The attacker leverages the gained information to identify valuable targets within the network.
The final objective is often data exfiltration, deployment of ransomware, or further compromise of the network.

Impact

A successful attack can lead to unauthorized access to sensitive data, lateral movement within the network, and potential data exfiltration or ransomware deployment. Although this rule has low severity, the execution of discovery commands by the SYSTEM account can be a critical indicator of compromise. Early detection of such activity can prevent more severe damage.

Recommendation

Deploy the provided Sigma rules to detect account discovery commands executed via the SYSTEM account and tune for your environment.
Enable Sysmon process creation logging (Event ID 1) to ensure the necessary data is available for detection.
Investigate any alerts generated by these rules, focusing on the process execution chain to identify the source of the SYSTEM account usage.
If the process tree includes a web-application server process, investigate suspicious file creation or modification to assess for webshell backdoors.
Review and harden web application security to prevent initial access and privilege escalation.

PowerShell Suspicious Payload Encoded and Compressed

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

This detection identifies PowerShell scripts leveraging a combination of Base64 encoding and .NET compression techniques (Deflate/GZip) to conceal malicious payloads. Attackers employ this method to bypass security measures by deobfuscating and reconstructing the payload directly in memory. This technique allows adversaries to evade detection mechanisms that rely on static analysis of script content. The rule focuses on identifying script block content exhibiting this behavior, providing defenders with visibility into potential defense evasion attempts within their Windows environments. This rule was last updated on 2026-05-04, and its initial version was created on 2021/10/19.

Attack Chain

An attacker gains initial access through methods like phishing or exploiting a vulnerability.
A PowerShell script is executed on the target system, potentially through a compromised user account.
The PowerShell script contains a Base64 encoded string representing a compressed payload.
The script uses the FromBase64String function to decode the Base64 encoded string.
The script decompresses the decoded data using .NET compression classes like System.IO.Compression.DeflateStream or System.IO.Compression.GzipStream.
The decompressed data reveals a malicious payload, such as a reverse shell or credential theft tool.
The script executes the payload in memory, bypassing traditional file-based detection methods.
The attacker achieves their objective, such as gaining persistent access, stealing data, or deploying ransomware.

Impact

Successful exploitation can lead to complete system compromise, data theft, and deployment of malware such as ransomware. The obfuscation techniques make detection more difficult, increasing the dwell time of attackers within the network. Windows systems are primarily affected. If Windows Defender Advanced Threat Protection is being used, this can evade its protection.

Recommendation

Enable PowerShell Script Block Logging to capture the necessary events for detection (related to the logsource in the rules below).
Deploy the Sigma rule “PowerShell Suspicious Payload Encoded and Compressed” to your SIEM and tune it for your environment.
Investigate any alerts generated by the rule, focusing on the reconstructed script block content.
Review PowerShell execution policies to restrict the execution of unsigned or untrusted scripts.
Monitor process telemetry for PowerShell instances and their parent processes.
Restrict PowerShell execution to trusted administrative paths where feasible.