Powershell — 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 Windows PowerShell Arguments Detected

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

This detection rule identifies the execution of PowerShell with suspicious argument values on Windows systems. This behavior is frequently associated with malware installation and other malicious activities. PowerShell is a powerful scripting language, and adversaries often exploit its capabilities to execute malicious scripts, download payloads, and obfuscate commands. The rule focuses on detecting patterns such as encoded commands, suspicious downloads (e.g., using WebClient or Invoke-WebRequest), and various obfuscation techniques used to evade detection. The rule is designed to work with various data sources, including Elastic Defend, Windows Security Event Logs, Sysmon, and third-party EDR solutions like CrowdStrike, Microsoft Defender XDR, and SentinelOne, enhancing its applicability across different environments.

Attack Chain

An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
The attacker uses PowerShell to download a malicious payload from a remote server using commands like DownloadFile or DownloadString.
The downloaded payload is often encoded or obfuscated to evade detection. Common techniques include Base64 encoding, character manipulation, and compression.
PowerShell is then used to decode or deobfuscate the payload using methods like [Convert]::FromBase64String or [char[]](...) -join ''.
The deobfuscated payload is executed directly in memory using techniques like iex (Invoke-Expression) or Reflection.Assembly.Load.
The executed payload performs malicious actions, such as installing malware, establishing persistence, or exfiltrating data.
The attacker may use techniques like WebClient to download files from a remote URL.
Commands like nslookup -q=txt are used for command and control.

Impact

Successful exploitation can lead to malware installation, data theft, system compromise, and further propagation of the attack within the network. The detection of suspicious PowerShell arguments helps to identify and prevent these malicious activities before significant damage can occur. Without proper detection, attackers can maintain persistence, escalate privileges, and compromise sensitive data. The rule helps defenders identify and respond to these threats quickly, minimizing the impact of potential attacks.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious PowerShell activity.
Enable Sysmon process creation logging with command line arguments to ensure the necessary data is captured for the Sigma rules to function effectively.
Investigate any alerts generated by the Sigma rules to determine the legitimacy of the PowerShell activity and take appropriate remediation steps.
Continuously tune the Sigma rules based on your environment to reduce false positives and improve detection accuracy.

Microsoft PowerShell Improper Input Validation Vulnerability (CVE-2026-26143)

hello@craftedsignal.io — Wed, 15 Apr 2026 12:00:00 +0000

CVE-2026-26143 describes a vulnerability in Microsoft PowerShell stemming from improper input validation. This flaw could allow a local, unauthorized attacker to bypass security features implemented within PowerShell. The vulnerability has a CVSS v3.1 score of 7.8, indicating a high severity. Successful exploitation could lead to significant compromise of the affected system. The vulnerability was reported to Microsoft and assigned CVE-2026-26143. Defenders should prioritize patching affected systems to mitigate the risk. The affected versions of PowerShell are not explicitly stated in the source material, therefore all installations of PowerShell on Windows should be considered potentially vulnerable.

Attack Chain

Attacker gains local access to a Windows system. This could be through existing malware, physical access, or other initial access vectors.
Attacker crafts a malicious PowerShell command or script designed to exploit the input validation vulnerability (CVE-2026-26143).
The attacker executes the malicious PowerShell command, bypassing intended security controls due to the input validation flaw.
PowerShell processes the crafted input, failing to properly sanitize or validate it.
The bypassed security feature allows the attacker to perform actions that would normally be restricted, such as elevated privileges.
Attacker leverages the bypassed security feature to execute unauthorized code or modify system configurations.
The attacker can now maintain persistence via registry keys (T1547.001) or scheduled tasks (T1053.005).
The attacker achieves their objective, which could include data exfiltration, system compromise, or further lateral movement within the network.

Impact

Successful exploitation of CVE-2026-26143 can allow a local attacker to bypass security features within Microsoft PowerShell, potentially leading to arbitrary code execution with elevated privileges. This vulnerability could lead to a full system compromise. The number of potential victims is substantial, as PowerShell is a standard component of Windows operating systems. Systems lacking the security patch are vulnerable.

Recommendation

Apply the security update provided by Microsoft for CVE-2026-26143 to remediate the improper input validation vulnerability.
Implement the Sigma rule “Detect Suspicious PowerShell Input Validation Bypass” to identify potential exploitation attempts in your environment.
Monitor PowerShell execution logs for suspicious command-line arguments and script content, which could indicate an attempt to exploit this vulnerability.
Restrict local user access to reduce the attack surface and limit the potential for local exploitation.
Enable PowerShell logging and auditing to capture detailed information about PowerShell activity, which can aid in detecting and investigating suspicious behavior.

Powercat PowerShell Implementation Detection

hello@craftedsignal.io — Mon, 04 Nov 2024 14:27:00 +0000

Powercat is a PowerShell script that functions similarly to the traditional Netcat utility, allowing for network communication using TCP and UDP. Attackers can use Powercat to establish reverse shells, transfer files, and perform port scanning within a compromised environment. This activity is often employed during post-exploitation phases to maintain access and propagate further into the network. Defenders should be aware of PowerShell scripts invoking Powercat, especially in environments…

Detecting Potential PowerShell Pass-the-Hash/Relay Scripts

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

This detection identifies PowerShell scripts containing artifacts indicative of NTLM relay or pass-the-hash (PtH) attacks. These techniques allow attackers to authenticate to systems without needing plaintext passwords, enabling lateral movement and privilege escalation. The rule focuses on identifying specific byte sequences and strings within PowerShell script blocks that suggest NTLM/SMB negotiation and credential access attempts. This detection helps defenders identify and respond to potential credential theft and abuse within their Windows environments. The rule is based on observed techniques used in various publicly available tools such as Invoke-TheHash, Check-LocalAdminHash, and PoshC2.

Attack Chain

An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
The attacker executes a PowerShell script on the compromised system. This script could be directly executed or obfuscated to evade initial detection.
The PowerShell script attempts to perform NTLM relay or pass-the-hash attacks by utilizing specific byte sequences related to NTLM/SMB negotiation, such as NTLMSSPNegotiate or 0x4e,0x54,0x4c,0x4d,0x53,0x53,0x50.
The script may utilize tools like Invoke-WMIExec or Invoke-SMBExec to execute commands on remote systems using the stolen credentials.
The attacker attempts to authenticate to other systems on the network using the relayed credentials or password hashes.
Successful authentication allows the attacker to move laterally, accessing sensitive data or escalating privileges on other systems.
The attacker may deploy additional payloads or establish persistence mechanisms for continued access.

Impact

A successful pass-the-hash or NTLM relay attack can grant an attacker unauthorized access to sensitive systems and data within the network. This can lead to data breaches, financial loss, or disruption of critical services. The impact could range from compromising a few systems to gaining domain administrator privileges, depending on the attacker’s goals and the network’s security posture. Organizations can experience significant financial and reputational damage due to data breaches and service disruptions.

Recommendation

Enable PowerShell Script Block Logging to capture the necessary data for this detection. Refer to the setup instructions in the rule documentation for configuration details.
Deploy the Sigma rule Detecting Potential PowerShell Pass-the-Hash/Relay Scripts to your SIEM and tune it based on your environment.
Investigate any alerts generated by this rule to determine the scope and impact of the potential attack. Refer to the triage and analysis section in the rule documentation for guidance on investigation steps.
Implement network segmentation and access controls to limit the impact of lateral movement.
Monitor authentication events (event codes 4624, 4625, 4648) for suspicious activity, such as NTLM authentication from unexpected source IPs or to unusual target systems, as described in the rule’s investigation notes.

Veeam Backup Library Loaded by Unusual Process

hello@craftedsignal.io — Fri, 03 May 2024 14:22:00 +0000

This detection identifies potential credential compromise attempts targeting Veeam Backup software. Attackers may attempt to load the Veeam.Backup.Common.dll library through unauthorized processes, such as PowerShell or unsigned executables, to decrypt and misuse stored credentials. These credentials can then be used to target backups, potentially leading to destructive operations like ransomware attacks. The rule focuses on flagging untrusted or unsigned processes loading the Veeam library, providing an indicator of possible malicious activity. The detection logic specifically looks for scenarios where PowerShell or other unusual processes load the Veeam backup library, which deviates from typical administrative or backup-related operations. This activity warrants further investigation to determine if it’s part of a credential access attempt.

Attack Chain

An attacker gains initial access to a Windows system through unspecified means.
The attacker uses PowerShell (powershell.exe, pwsh.exe, powershell_ise.exe) or another unsigned process to execute malicious commands.
The malicious process attempts to load the Veeam.Backup.Common.dll library.
The Veeam.Backup.Common.dll library is loaded into the process memory.
The attacker leverages the loaded library to decrypt stored Veeam credentials.
Using the decrypted credentials, the attacker gains access to Veeam backups.
The attacker may then encrypt, delete, or exfiltrate the backups, leading to data loss or ransomware attacks.
The attacker pivots to other systems using the compromised credentials, further expanding the attack.

Impact

Successful exploitation allows attackers to gain access to sensitive Veeam backup data. This can lead to data exfiltration, data encryption, or complete data loss. The impact includes potential ransomware attacks, significant business disruption, and financial losses due to recovery efforts and downtime. The compromise of Veeam backups can severely impact an organization’s ability to recover from incidents, making it a critical target for attackers.

Recommendation

Deploy the Sigma rule “Veeam Backup Library Loaded by Unusual Process” to your SIEM to detect suspicious DLL loads (rule.name).
Investigate any alerts generated by the Sigma rule, focusing on the process details and execution history to determine legitimacy (rule.description).
Enable process creation and library load logging to capture the necessary events for the Sigma rule to function correctly.
Review and enforce code signing policies to prevent unsigned processes from loading critical libraries like Veeam.Backup.Common.dll.
Implement multi-factor authentication for Veeam accounts to mitigate the impact of credential compromise.

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.

PowerShell Kerberos Ticket Dumping via LSA Authentication Package Access

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

This threat brief focuses on detecting PowerShell scripts designed to extract Kerberos tickets from memory. Attackers use these scripts to gain unauthorized access to credentials, which can then be leveraged for lateral movement within a network. The scripts achieve this by interacting with the Local Security Authority (LSA) and accessing Kerberos authentication packages. The observed PowerShell scripts utilize specific Kerberos ticket message types or dynamic Kerberos package lookup to enumerate and retrieve tickets. This behavior is often associated with post-exploitation activity, where attackers are attempting to escalate privileges or move laterally within a compromised environment. Defenders should monitor PowerShell activity for these patterns, as successful Kerberos ticket dumping can lead to significant security breaches. The scripts are not associated with any specific campaign or version.

Attack Chain

An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
The attacker executes a PowerShell script.
The PowerShell script uses LsaCallAuthenticationPackage to interact with the LSA.
The script attempts to retrieve Kerberos tickets by using functions like KerbRetrieveEncodedTicketMessage, KerbQueryTicketCacheMessage, KerbQueryTicketCacheExMessage, or KerbRetrieveTicketMessage.
Alternatively, the script uses LsaLookupAuthenticationPackage to dynamically locate the Kerberos package.
The script may then decrypt the ticket data using KerbDecryptDataMessage.
The script may attempt to serialize or export the extracted tickets to a file.
The attacker uses the dumped Kerberos tickets to impersonate users or services, gaining unauthorized access to resources and facilitating lateral movement.

Impact

Successful exploitation allows attackers to steal Kerberos tickets from memory. The attacker can then use these tickets to impersonate legitimate users or services, enabling them to move laterally within the network, access sensitive data, and potentially compromise critical systems. The impact includes unauthorized access to resources, data breaches, and potentially a complete compromise of the targeted Windows domain.

Recommendation

Enable PowerShell Script Block Logging to capture the malicious script content (as mentioned in the “Setup” section).
Deploy the Sigma rule “PowerShell Kerberos Ticket Dump” to detect scripts exhibiting Kerberos ticket dumping behavior.
Investigate any alerts triggered by the Sigma rule, focusing on the reconstructed script block content and process lineage as outlined in the “Triage and analysis” section.
Monitor for file creation events related to ticket material exports (e.g., “.kirbi” files) to identify potential ticket dumping activity.
Review authentication events (event codes 4624, 4625, 4648) to identify suspicious logins originating from compromised systems.

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.

Potential Antimalware Scan Interface Bypass via PowerShell

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

This detection identifies PowerShell scripts that attempt to circumvent the Antimalware Scan Interface (AMSI), a security feature in Windows designed to prevent the execution of malicious scripts and code. Attackers use AMSI bypass techniques to disable real-time scanning and execute malicious PowerShell code without detection. The bypasses often involve manipulating AMSI’s internal state or patching its scanning routines. This allows attackers to deliver and execute payloads undetected, leading to potential system compromise. This technique is actively used by various threat actors to evade defenses.

Attack Chain

An attacker gains initial access to the system, typically through phishing or exploiting a vulnerability.
The attacker executes a PowerShell script.
The PowerShell script contains code designed to bypass AMSI, such as manipulating the AmsiScanBuffer function or unmanaged code injection.
The AMSI bypass is executed, disabling real-time scanning of PowerShell scripts.
The attacker then executes a malicious payload within the same PowerShell session, which is no longer subject to AMSI scanning.
The malicious payload performs actions such as downloading additional malware, establishing persistence, or exfiltrating data.
The attacker leverages the compromised system for further lateral movement or to achieve their objectives, such as data theft or ransomware deployment.

Impact

Successful AMSI bypass can lead to the execution of arbitrary code on the affected system, potentially resulting in data breaches, system compromise, and the installation of malware. Because AMSI is a core component of Windows security, its bypass represents a significant security risk.

Recommendation

Enable PowerShell Script Block Logging to capture the contents of PowerShell scripts, which is essential for this detection to function effectively (reference: Setup section).
Deploy the Sigma rule “Potential Antimalware Scan Interface Bypass via PowerShell” to detect scripts containing known AMSI bypass techniques (reference: rules section below).
Investigate alerts generated by the Sigma rule, focusing on the script content and the context in which it was executed to identify potential malicious activity (reference: note section).

PowerShell Share Enumeration via ShareFinder or Native APIs

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

This detection identifies PowerShell scripts utilizing ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or native Windows API calls for share enumeration. These techniques are commonly used by attackers to map accessible network shares within an environment. This reconnaissance is often a precursor to data collection, lateral movement, or the deployment of ransomware. The activity is detected via script block logging, and focuses on identifying specific function calls and API usage within the PowerShell script content. Defenders should be aware of this activity, particularly when performed by unexpected users or on unusual systems, as it may indicate malicious reconnaissance within the network. The references indicate that this activity can lead to corporate insurance policy exfiltration or Conti ransomware deployment.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or compromised credentials.
The attacker executes a PowerShell script, either directly or through a fileless execution method.
The PowerShell script utilizes ShareFinder functions (Invoke-ShareFinder, Invoke-ShareFinderThreaded) or Windows share enumeration APIs (NetShareEnum, NetApiBufferFree) to discover network shares.
The script identifies accessible network shares by leveraging API calls and parsing the results for share names (shi1_netname) and remarks (shi1_remark).
The attacker analyzes the identified shares to determine those that are accessible and contain valuable data.
The attacker may then attempt to access these shares using compromised credentials or exploiting existing vulnerabilities.
Once access is gained, the attacker may collect sensitive data from the shares, move laterally to other systems, or deploy ransomware.
The ultimate goal is data exfiltration, system compromise, or financial gain through ransomware.

Impact

Successful exploitation of this reconnaissance technique can lead to significant data breaches, lateral movement within the network, and potential ransomware deployment. Organizations that fail to detect and prevent share enumeration may suffer financial losses, reputational damage, and operational disruption. The referenced “Stolen Images” campaign led to Conti ransomware deployment, and the “Hunting for corporate insurance policies” post highlights data exfiltration.

Recommendation

Enable PowerShell script block logging to capture the necessary events for detection (as referenced in the rule setup).
Deploy the Sigma rule “PowerShell Share Enumeration Script via Invoke-ShareFinder” to your SIEM and tune for your environment.
Deploy the Sigma rule “PowerShell Share Enumeration via NetShareEnum API” to detect share enumeration using native Windows APIs.
Investigate any alerts generated by these rules, focusing on the PowerShell launch context and the scope of the share discovery (see triage steps in the original rule).
Review and restrict PowerShell execution policies to prevent unauthorized script execution, especially from user-writable locations.

PowerShell Invoke-NinjaCopy Script Detection

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

Invoke-NinjaCopy is a PowerShell script used to perform direct volume file access, enabling attackers to bypass traditional file access controls. This technique allows reading locked system files, such as the NTDS.dit or registry hives, which are essential for credential dumping. The script, often incorporated into post-exploitation frameworks like Empire, leverages stealth functions to minimize detection. Defenders need to monitor PowerShell script block content for the presence of Invoke-NinjaCopy or related “Stealth*” functions to identify potential credential access attempts. This activity is typically observed in Windows environments where attackers attempt to escalate privileges or move laterally within a network. The use of NinjaCopy allows attackers to grab sensitive data without being blocked by standard security measures.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
The attacker executes a PowerShell script, either directly or through a command-line interface.
The PowerShell script contains the Invoke-NinjaCopy function or related StealthReadFile, StealthOpenFile functions.
The script utilizes the StealthOpenFile function to directly access the volume where the target file resides (e.g., NTDS.dit).
StealthReadFile is used to read the contents of the target file, bypassing standard file access controls.
The script copies the contents of the NTDS.dit or registry hives to a temporary location.
The attacker dumps credentials from the copied NTDS.dit file using tools like secretsdump.py or other credential harvesting tools.
The attacker uses the harvested credentials to escalate privileges or move laterally within the network.

Impact

Successful exploitation can lead to the compromise of domain credentials, granting the attacker access to sensitive information and systems. Credential dumping from NTDS.dit or registry hives can expose user accounts, service accounts, and other privileged credentials. The impact ranges from data breaches and financial losses to complete network compromise and disruption of services. If successful, attackers may gain persistent access and control over critical infrastructure, potentially affecting thousands of users and systems.

Recommendation

Enable PowerShell Script Block Logging and monitor event ID 4104 for script content containing Invoke-NinjaCopy, StealthReadFile, StealthOpenFile, StealthCloseFileDelegate as described in the Overview.
Deploy the Sigma rule “PowerShell Invoke-NinjaCopy script” to your SIEM and tune the rule for false positives in your environment.
Investigate any PowerShell processes with command-line arguments that contain the identified keywords to identify potential attacker activity as outlined in the Attack Chain.
Implement strict access controls on sensitive files like NTDS.dit and registry hives to limit the impact of successful credential access attempts.
Review PowerShell execution policies to prevent the execution of unsigned or untrusted scripts.

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).

Disabling Windows Defender Security Settings via PowerShell

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

Attackers commonly attempt to disable or weaken Windows Defender to evade detection and facilitate malicious activities. This involves using PowerShell commands like Set-MpPreference or Add-MpPreference to modify Defender’s configuration. Adversaries may also utilize base64 encoding to obfuscate these commands, bypassing simple command-line inspection. This activity typically occurs post-compromise, as part of a broader attack chain, and allows for the deployment of malware or other malicious tools without interference from the built-in antivirus. Detection of these techniques is crucial for maintaining the integrity of the system and preventing further damage. The scope of this threat includes any Windows environment where PowerShell is enabled and Windows Defender is used as the primary antivirus solution.

Attack Chain

Initial access is achieved through an existing compromise (e.g., phishing, exploit).
The attacker gains a foothold on the system and escalates privileges if necessary.
PowerShell is launched, either directly or through a parent process like cmd.exe.
The attacker uses Set-MpPreference or Add-MpPreference with parameters like -DisableRealtimeMonitoring, -DisableIOAVProtection, -DisableBehaviorMonitoring, or -DisableBlockAtFirstSeen to weaken Defender.
Alternatively, the attacker crafts a base64-encoded PowerShell command that performs the same actions.
The encoded command is executed using the -EncodedCommand or -enc parameter.
Windows Defender’s security settings are modified, reducing its effectiveness.
The attacker proceeds with deploying malware, exfiltrating data, or other malicious objectives.

Impact

Successful execution of these commands results in a weakened or disabled Windows Defender, leaving the system vulnerable to malware infections and other threats. This can lead to data breaches, system compromise, and financial loss. The impact is especially significant in environments where Windows Defender is the primary security solution. While the number of victims is unknown, the technique is widely applicable across Windows environments.

Recommendation

Monitor process creation events for PowerShell executions (powershell.exe, pwsh.exe) with command-line arguments related to disabling Windows Defender using the Sigma rule “Detect Suspicious PowerShell Encoded Commands”.
Enable PowerShell script block logging to capture the full content of executed scripts, which can reveal base64-encoded commands (reference: references - https://docs.microsoft.com/en-us/powershell/module/defender/set-mppreference?view=windowsserver2019-ps).
Deploy the Sigma rule “Disabling Windows Defender Security Settings via PowerShell” to your SIEM and tune for your environment.
Investigate any instances of Set-MpPreference or Add-MpPreference commands with arguments disabling real-time monitoring, IOAV protection, behavior monitoring, or block-at-first-seen features.

Incoming Execution via PowerShell Remoting

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

This detection identifies potential lateral movement through the exploitation of Windows PowerShell remoting. PowerShell remoting is a feature that enables administrators and attackers to execute commands on remote Windows systems. The detection focuses on identifying incoming network connections on ports 5985 (HTTP) and 5986 (HTTPS), the default ports used for PowerShell Remoting, followed by the execution of processes spawned by wsmprovhost.exe, the Windows Remote Management process host. This activity, when originating from unexpected sources, may indicate unauthorized access and lateral movement within a network. The rule is designed to detect suspicious activity by monitoring network traffic and process execution, flagging potential unauthorized remote executions, and enabling security teams to respond swiftly.

Attack Chain

An attacker gains initial access to a network, possibly through phishing or exploiting a vulnerability on an internet-facing system.
The attacker leverages PowerShell remoting to initiate a connection to a target system on ports 5985 or 5986.
The target system accepts the incoming PowerShell Remoting connection.
The wsmprovhost.exe process is launched on the target system to facilitate the remote PowerShell session.
The attacker executes commands remotely, spawning child processes from wsmprovhost.exe.
The attacker attempts to escalate privileges or move laterally to other systems within the network using the remote PowerShell session.
The attacker uses tools such as net.exe or PsExec over the remote PowerShell session to further propagate.
The attacker achieves their objective, such as data exfiltration or deploying ransomware, by leveraging the established remote session.

Impact

Successful exploitation of PowerShell Remoting for lateral movement can lead to widespread compromise within an organization. An attacker could gain control over multiple systems, potentially leading to data breaches, system outages, or ransomware deployment. The number of affected systems could range from a few critical servers to a significant portion of the network, depending on the attacker’s objectives and the organization’s security posture. The impact could include financial losses, reputational damage, and disruption of business operations.

Recommendation

Deploy the Sigma rule Incoming Execution via PowerShell Remoting to your SIEM to detect suspicious PowerShell remoting activity and tune for your environment.
Monitor network connections to ports 5985 and 5986, and investigate any unauthorized or unexpected traffic using the network_connection log source.
Investigate processes spawned by wsmprovhost.exe for unusual or malicious activity using the process_creation log source.
Whitelist authorized administrative IP addresses or user accounts that frequently perform remote management tasks, as mentioned in the false positives analysis.
Review and document automated scripts or scheduled tasks that use PowerShell Remoting for system maintenance, then create exceptions for their specific process names or execution paths.

PowerShell P/Invoke Process Injection API Chain Detection

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

This detection identifies PowerShell scripts leveraging the P/Invoke (Platform Invoke) technology to perform process injection. P/Invoke allows managed code (like PowerShell) to call unmanaged functions exported from DLLs, including critical Windows API functions. Attackers use this to inject malicious code into legitimate processes for evasion and persistence. The detection focuses on identifying specific API chains commonly used in process injection techniques, such as allocating memory in a target process (VirtualAlloc), writing malicious code into the allocated memory (WriteProcessMemory), and executing the injected code (CreateRemoteThread). This activity is often associated with malware deployment, privilege escalation, and defense evasion. The detection logic is designed to identify these API chains either at the compile phase using Add-Type or during the execution phase, alerting on suspicious PowerShell behavior.

Attack Chain

Attacker gains initial access to the system, potentially through phishing or exploiting a vulnerability.
PowerShell is invoked to execute a malicious script.
The PowerShell script uses Add-Type and DllImport to declare external functions from Windows DLLs, including kernel32.dll and ntdll.dll.
The script uses functions such as OpenProcess to gain a handle to a target process.
VirtualAllocEx is called to allocate memory within the target process.
WriteProcessMemory is used to write malicious code into the allocated memory region of the target process.
CreateRemoteThread is called 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, achieving code execution and potential privilege escalation.

Impact

Successful process injection allows attackers to execute arbitrary code within the context of a trusted process, bypassing security controls and potentially gaining elevated privileges. This can lead to data theft, system compromise, or further propagation within the network. The use of PowerShell and P/Invoke makes detection more challenging, as the activity can blend in with legitimate system administration tasks. A successful attack could lead to the deployment of a VIP Keylogger or other malware, as noted in the provided references.

Recommendation

Enable PowerShell Script Block Logging (Event ID 4104) to provide the necessary data for detection (data_source).
Deploy the Sigma rule PowerShell PInvoke Process Injection to your SIEM and tune the rule to your environment (rules).
Investigate any alerts generated by the Sigma rule, focusing on the specific API chains identified in the detection section of the rule.
Review PowerShell execution policies and restrict the execution of unsigned scripts to reduce the attack surface.

Suspicious PowerShell Script Using Cryptography Namespace

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

This threat brief focuses on detecting suspicious PowerShell activity involving the System.Security.Cryptography namespace, excluding common hashing algorithms like SHA and MD5. The detection leverages Windows PowerShell Script Block Logging (EventCode 4104) to identify scripts using cryptographic functions. This is significant because malware often uses cryptography to decrypt or decode additional malicious payloads, which can lead to further code execution, privilege escalation, or persistence within the compromised environment. The technique is commonly used by malware families like AsyncRAT, XWorm, and VIP Keylogger. Defenders should investigate the parent process of such scripts, the decrypted data, network connections established by the script, and the user context in which the script is executed.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.
The attacker executes a PowerShell script on the compromised system.
The PowerShell script utilizes the System.Security.Cryptography namespace to perform cryptographic operations.
The script decrypts or decodes a malicious payload (e.g., a second-stage executable or configuration file).
The decrypted payload is written to disk or loaded directly into memory.
The attacker executes the decrypted payload, potentially establishing persistence via registry keys or scheduled tasks.
The malware leverages the established persistence mechanism for long-term access.
The attacker performs malicious actions such as data exfiltration, lateral movement, or remote command execution.

Impact

Successful exploitation allows attackers to bypass security measures by hiding malicious code within encrypted payloads. This can lead to data theft, system compromise, and further propagation within the network. Malware families like AsyncRAT, XWorm, and VIP Keylogger use this technique to maintain persistence and perform malicious activities undetected. The impact can range from individual workstation compromise to large-scale data breaches depending on the attacker’s objectives and the compromised system’s role within the organization.

Recommendation

Enable PowerShell Script Block Logging on all endpoints to generate the necessary logs (EventCode 4104) for detection.
Deploy the Sigma rule Detect Suspicious PowerShell Cryptography Namespace Usage to your SIEM to detect the described activity.
Investigate any alerts generated by the Sigma rule by examining the parent process, decrypted data, network connections, and the user executing the script.
Review and tune the Sigma rule Detect Suspicious PowerShell Cryptography Namespace Usage based on your environment’s specific needs and known-good PowerShell usage to reduce false positives.
Implement application control policies to restrict the execution of unsigned or untrusted PowerShell scripts.

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.

Detection of Invoke-Obfuscation via Standard Input

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

Invoke-Obfuscation is a PowerShell obfuscation framework used to evade detection by security products. Attackers employ this technique to disguise malicious PowerShell code, making it harder to identify through static analysis or signature-based detection. This particular technique involves passing obfuscated PowerShell code via standard input (stdin) to the PowerShell interpreter. This method is often employed during the execution of scripts, where malicious code is dynamically constructed and executed, leaving a reduced footprint on the file system. Defenders should be aware of this technique because it is frequently used by threat actors in conjunction with other tactics to compromise systems and execute malicious payloads. This brief provides actionable detection strategies focused on identifying this specific obfuscation pattern.

Attack Chain

An attacker gains initial access through a vulnerability or other means (not covered in this brief).
The attacker uploads a small, initial-stage script or binary to the target system.
This script prepares the environment for PowerShell execution, potentially setting environment variables or disabling security features.
The script then calls powershell.exe with parameters designed to accept input from stdin.
Obfuscated PowerShell code generated by Invoke-Obfuscation is piped into the powershell.exe process via stdin. This code often contains commands to download, execute, or further obfuscate malicious payloads.
The powershell.exe process executes the obfuscated code from stdin, bypassing some common detection rules.
The deobfuscated code performs malicious actions such as lateral movement, data exfiltration, or persistence.
The attacker achieves their final objective, which may include data theft, system compromise, or deployment of ransomware.

Impact

Successful exploitation can lead to a full compromise of the targeted system, potentially impacting other systems within the network. Obfuscation makes incident response more difficult, as identifying and analyzing the malicious code requires additional effort. Affected systems could suffer data loss, service disruption, or financial damage. The use of Invoke-Obfuscation also indicates a deliberate attempt to evade security controls, suggesting a sophisticated attacker.

Recommendation

Deploy the Sigma rule Detect Invoke-Obfuscation Via Stdin to your SIEM to detect obfuscated PowerShell execution via standard input based on command-line patterns.
Enable process creation logging on Windows endpoints, ensuring that command-line arguments are captured to facilitate detection of obfuscated commands.
Investigate any process creation events where powershell.exe is executed with parameters that suggest input from stdin along with obfuscated code patterns.
Implement application control policies to restrict the execution of unauthorized PowerShell scripts, reducing the attack surface for Invoke-Obfuscation techniques.
Continuously update and refine detection rules to adapt to new obfuscation methods and variations of the Invoke-Obfuscation framework.

Remote File Download via PowerShell

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

Attackers frequently use PowerShell, a legitimate administration tool, to download malicious payloads into compromised systems. This technique allows them to bypass traditional security measures by leveraging a trusted tool. This activity often occurs during the command and control phase, where attackers introduce additional tooling or malware for further exploitation. This rule identifies instances where PowerShell downloads executable and script files from untrusted remote destinations. It does this by correlating network and file events, specifically looking for PowerShell processes initiating network connections to non-whitelisted domains followed by the creation of executable or script files. The rule helps defenders identify and respond to potential command and control activity and malware deployment attempts.

Attack Chain

An attacker gains initial access to a Windows system, possibly through phishing or exploiting a vulnerability.
The attacker uses PowerShell (powershell.exe, pwsh.exe, or powershell_ise.exe) to initiate a network connection to a remote domain.
The DNS request is made to a domain not in the allowed list (e.g., not *.microsoft.com, *.azureedge.net, etc.).
PowerShell downloads a file with an executable extension (e.g., .exe, .dll, .ps1, .bat) or a file with a MZ header.
The downloaded file is saved to disk.
The file is saved to a location that is not excluded by the rule, filtering out commonly used temporary directories.
The downloaded executable or script is then executed, leading to further malicious activities.
The attacker achieves persistence, lateral movement, or data exfiltration depending on the downloaded payload.

Impact

A successful attack can lead to the introduction of malware, backdoors, or other malicious tools into the compromised system. This can enable attackers to perform a wide range of malicious activities, including data theft, system compromise, and further propagation within the network. The compromised system can become a beachhead for further attacks, potentially impacting numerous systems and leading to significant financial and reputational damage.

Recommendation

Deploy the Sigma rule PowerShell Remote File Download to detect PowerShell processes downloading executable files from untrusted remote destinations by correlating network and file creation events.
Enable Elastic Defend to provide the necessary network and file event data for the rule to function correctly as noted in the setup instructions.
Investigate any alerts generated by the Sigma rule, focusing on the parent process of the PowerShell process, the reputation of the downloaded file, and any other suspicious activities on the affected host, as per the investigation guide in the rule’s note field.
Review and customize the whitelisted domains in the Sigma rule to match your organization’s specific environment and trusted external resources, as described in the query field.
Block the identified malicious domains or IP addresses at the network perimeter to prevent further downloads.

PowerShell Obfuscation via Concatenated Dynamic Command Invocation

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

This detection rule identifies PowerShell scripts employing concatenated string literals within dynamic invocation constructs like &() or .(). This obfuscation technique allows attackers to construct commands dynamically, making it harder to detect their malicious intent based on static analysis or keyword matching. By breaking commands into smaller, concatenated strings, attackers aim to bypass traditional signature-based detections and evade AMSI (Anti-Malware Scan Interface). This technique has been observed in various campaigns where threat actors attempt to execute malicious code while minimizing the chances of detection. This activity is particularly concerning for defenders, as it highlights a common method to bypass security measures.

Attack Chain

An attacker gains initial access to a system (e.g., through phishing or exploiting a vulnerability).
The attacker executes a PowerShell script on the compromised system.
The PowerShell script uses string concatenation to build malicious commands dynamically.
Dynamic invocation constructs like &() or .() are used to execute the concatenated commands.
The obfuscated commands bypass keyword-based detections and AMSI.
The attacker performs malicious activities, such as downloading additional payloads.
The attacker executes the downloaded payloads to establish persistence or exfiltrate data.
The attacker achieves their final objective, such as stealing sensitive information or deploying ransomware.

Impact

Successful exploitation can lead to complete system compromise, data theft, and potential ransomware deployment. Attackers can leverage this technique to evade security controls and execute malicious commands undetected. The impact is high because it allows attackers to bypass common defenses and maintain persistence on the system, affecting potentially hundreds or thousands of systems across an organization.

Recommendation

Enable PowerShell Script Block Logging to capture the events necessary for this detection, as indicated in the setup instructions linked in the source material.
Deploy the Sigma rule Detect PowerShell Obfuscation via String Concatenation to your SIEM and tune for your environment to detect the use of concatenated strings in PowerShell commands.
Investigate alerts generated by the Sigma rule, focusing on the reconstructed PowerShell commands and the processes that launched them, as outlined in the triage and analysis section of the source material.
Monitor for follow-on activities, such as child processes, file modifications, and network connections originating from PowerShell processes exhibiting obfuscation techniques.

Suspicious PowerShell Execution via Windows Script Host

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

This detection identifies PowerShell execution initiated by Windows Script Host processes (cscript.exe or wscript.exe). Attackers often use Windows Script Host (WSH) to execute malicious scripts as an initial access method. These scripts can act as droppers for second-stage payloads or download tools and utilities necessary for further compromise. The rule focuses on the parent-child process relationship between WSH and PowerShell, highlighting a common technique used to bypass security controls and execute arbitrary commands on a compromised system. This activity is relevant to defenders as it represents a potential entry point for various attacks, including malware deployment and data exfiltration. The detection logic is based on process execution events observed in Windows environments and is designed to work with data from Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.

Attack Chain

The user receives a phishing email with a malicious attachment (e.g., a .vbs or .js file).
The user opens the attachment, which is processed by either wscript.exe or cscript.exe.
The scripting engine executes the embedded malicious code.
The script downloads a PowerShell script from a remote server or contains an embedded, obfuscated PowerShell command.
The script uses wscript.exe or cscript.exe to launch powershell.exe to execute the downloaded or embedded PowerShell script.
PowerShell executes, performing malicious actions such as downloading additional payloads, modifying system settings, or establishing persistence.
PowerShell attempts to connect to external command-and-control servers to receive further instructions.
The attacker gains initial access to the system and can proceed with lateral movement, data exfiltration, or other malicious activities.

Impact

Successful exploitation can lead to initial access, allowing attackers to deploy malware, steal sensitive information, or perform other malicious activities. The impact can range from data breaches and financial losses to reputational damage. The severity depends on the attacker’s objectives and the level of access they gain. The number of affected systems depends on the scope of the phishing campaign or other initial access methods used to deliver the malicious script.

Recommendation

Enable Sysmon process creation logging to capture the necessary event data for the rules below.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
Investigate process execution chains where cscript.exe or wscript.exe spawn powershell.exe using the provided Sigma rules.
Implement email security measures to block phishing emails with script attachments.
Monitor network connections originating from PowerShell processes for suspicious outbound traffic.

Suspicious PowerShell Engine ImageLoad

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

Attackers can leverage the PowerShell engine without directly executing powershell.exe. This technique, often referred to as “PowerShell without PowerShell,” involves using the underlying System.Management.Automation namespace. This approach allows attackers to bypass application allowlisting and PowerShell security features, operating more stealthily within a compromised environment. This technique makes detection more challenging, as standard PowerShell execution logs might not capture the activity. The activity is detected by monitoring which processes load the System.Management.Automation.dll or System.Management.Automation.ni.dll libraries. This activity can legitimately happen where vendors have their own PowerShell implementations that are shipped with some products.

Attack Chain

An attacker gains initial access to a Windows system through various means, such as exploiting a vulnerability or using compromised credentials.
The attacker deploys a custom tool or script on the target system. This tool is designed to interact with the System.Management.Automation namespace directly.
The custom tool loads the System.Management.Automation.dll or System.Management.Automation.ni.dll library into its process space.
The tool uses the loaded PowerShell engine to execute malicious commands or scripts without invoking powershell.exe.
The attacker performs reconnaissance activities, such as gathering system information or network configurations, using PowerShell commands.
The attacker attempts to move laterally within the network, leveraging the PowerShell engine to execute commands on other systems.
The attacker installs malware or backdoors using the PowerShell engine to maintain persistence within the compromised environment.
The attacker exfiltrates sensitive data or causes damage to the system, completing the objectives of the attack.

Impact

A successful attack leveraging “PowerShell without PowerShell” can lead to significant compromise of Windows systems. Attackers can bypass traditional security measures, potentially leading to data theft, system disruption, or the installation of persistent malware. The technique’s stealthy nature can prolong the time to detection, increasing the potential for widespread damage.

Recommendation

Deploy the Sigma rule Suspicious PowerShell Engine ImageLoad to your SIEM to detect when the System.Management.Automation.dll or System.Management.Automation.ni.dll libraries are loaded by unexpected processes.
Investigate any alerts generated by the Sigma rule, focusing on the process execution chain (parent process tree) for unknown processes.
Implement endpoint detection and response (EDR) solutions like Elastic Defend to provide visibility into process behavior and library loading events, activating the process_creation and image_load log sources.
Review and tune exclusions to the Sigma rule based on legitimate vendor applications to reduce false positives.

Windows Firewall Disabled via PowerShell

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

Attackers often attempt to disable or modify system firewalls to evade network restrictions and facilitate lateral movement within a compromised environment. The Windows Firewall, a built-in component, provides host-based traffic filtering. Disabling it allows unrestricted communication, aiding command and control activities and hindering detection efforts. This activity is commonly achieved through PowerShell, leveraging cmdlets like Set-NetFirewallProfile. The rule focuses on detecting the use of this specific cmdlet to disable the Windows Firewall, alerting defenders to potential defense evasion attempts. This technique is valuable to attackers across various attack vectors, especially after initial access has been established.

Attack Chain

Initial Access: An attacker gains initial access through methods such as phishing or exploiting a vulnerability in a network-facing application.
Privilege Escalation (if necessary): The attacker escalates privileges to gain the necessary permissions to modify firewall settings.
PowerShell Execution: The attacker executes PowerShell, either through an interactive session or a script.
Disable Firewall Profile: The attacker uses the Set-NetFirewallProfile cmdlet with parameters such as -Enabled False to disable the firewall for all, public, domain, or private profiles.
Network Reconnaissance: With the firewall disabled, the attacker performs network reconnaissance to identify valuable assets and potential lateral movement paths.
Lateral Movement: The attacker moves laterally to other systems on the network, exploiting trust relationships or vulnerabilities.
Command and Control: The attacker establishes command and control channels to communicate with compromised systems and exfiltrate sensitive data.
Data Exfiltration or Further Exploitation: The attacker exfiltrates sensitive data or continues to exploit the environment based on their objectives.

Impact

Successful disabling of the Windows Firewall can lead to unrestricted lateral movement within a network, allowing attackers to compromise additional systems and exfiltrate sensitive data. This can result in data breaches, financial losses, and reputational damage. While the source does not specify the number of affected organizations, any environment relying on Windows Firewall for network segmentation is at risk.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the use of Set-NetFirewallProfile with the -Enabled False parameter (see Sigma rule below).
Enable process creation logging on Windows endpoints to capture PowerShell executions (reference the logsource in the Sigma rule).
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the firewall modification activity.
Review and enforce the principle of least privilege to limit the number of users with permissions to modify firewall settings.
Consider implementing additional network segmentation and monitoring controls to detect and prevent lateral movement even if the Windows Firewall is disabled.

Windows Defender Exclusions Added via PowerShell

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

Attackers may attempt to evade detection by modifying Windows Defender’s configuration to exclude specific files, folders, or processes from scanning. This is often achieved by using PowerShell commands to add exclusions. The tactic allows malware to operate without being detected by the built-in antivirus solution. Observed as early as 2018 with Trickbot disabling Windows Defender, this technique remains relevant today. This activity can be performed using Add-MpPreference or Set-MpPreference commands in PowerShell, specifying exclusions by path or process name. Detecting these modifications is critical for maintaining the integrity of endpoint security. The scope of targeting ranges from individual workstations to entire networks.

Attack Chain

The attacker gains initial access to the system via an undisclosed method.
The attacker executes PowerShell with administrative privileges.
The attacker uses the Add-MpPreference or Set-MpPreference cmdlet to add an exclusion.
The exclusion specifies a file path, folder, or process that should be ignored by Windows Defender.
Windows Defender is reconfigured to ignore the specified item.
The attacker deploys or executes malware in the excluded location.
The malware operates without interference from Windows Defender.
The attacker achieves their final objective, such as data theft or lateral movement.

Impact

Successful exploitation allows attackers to operate undetected on compromised systems, leading to potential data breaches, lateral movement within the network, and deployment of ransomware. While the exact number of victims is unknown, this technique is widely used by various threat actors, impacting organizations across various sectors. The lack of detection can lead to prolonged periods of compromise, increasing the potential damage.

Recommendation

Deploy the Sigma rule “Windows Defender Exclusions Added via PowerShell” to your SIEM to detect suspicious PowerShell commands used to add exclusions.
Enable Sysmon process creation logging with command line auditing to capture the necessary event data for the Sigma rule.
Regularly review Windows Defender exclusion lists to identify any unauthorized or suspicious entries.
Investigate any PowerShell process that uses Add-MpPreference or Set-MpPreference with exclusion parameters, as identified by the provided Sigma rule.
Monitor for processes and file modifications within excluded directories.
Configure alerts to notify security teams when new Windows Defender exclusions are added.

PowerShell Token Obfuscation via Process Creation

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

Attackers are increasingly using PowerShell token obfuscation techniques to bypass security measures. This involves manipulating PowerShell command syntax to make it harder for security tools to identify malicious code. This technique leverages Invoke-Obfuscation, a known framework for obfuscating PowerShell scripts. This method allows malicious actors to disguise commands, such as downloading and executing arbitrary code, making traditional signature-based detections less effective. The use of token obfuscation highlights the need for more sophisticated detection strategies that focus on identifying anomalous behavior rather than relying solely on static code analysis. The scope of this threat is broad, as it can be incorporated into various attack vectors, from initial access to lateral movement.

Attack Chain

Initial Access: The attacker gains initial access through an undisclosed method (e.g., phishing, exploit).
PowerShell Execution: The attacker initiates a PowerShell process (powershell.exe).
Token Obfuscation: The attacker employs token obfuscation techniques, such as inserting backticks (), using string concatenation, or manipulating environment variables, to disguise malicious commands. Examples from the source include INVoKe-eXpResSIOnand${eNv:pATh}.
Command Obfuscation: The obfuscated PowerShell command is executed, masking the intent of the command.
Payload Download: The obfuscated command may download a malicious payload from a remote server using methods such as (New-Object Net.WebClient).DownloadString.
Code Execution: The downloaded payload is executed, potentially leading to further compromise of the system.
Persistence: The attacker may establish persistence through various methods.
Lateral Movement/Exfiltration: Depending on the attacker’s objectives, they may move laterally within the network or exfiltrate sensitive data.

Impact

Successful exploitation using PowerShell token obfuscation can lead to complete system compromise, data theft, and disruption of services. The obfuscation techniques make it difficult for traditional security tools to detect and prevent the attack. The number of victims and sectors targeted is currently unknown, but the potential impact is significant due to the widespread use of PowerShell in enterprise environments.

Recommendation

Deploy the Sigma rule “Detect Powershell Token Obfuscation with Backticks” to identify PowerShell commands containing backtick-obfuscated tokens in process_creation logs.
Deploy the Sigma rule “Detect Powershell Token Obfuscation with String Concatenation” to identify PowerShell commands using string concatenation to obfuscate tokens in process_creation logs.
Monitor process_creation logs for PowerShell processes executing commands with environment variable manipulation, as described in the Sigma rules provided.
Investigate any PowerShell processes that exhibit obfuscation techniques to determine if they are malicious.

PowerShell Script with Encryption/Decryption Capabilities

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

This threat brief focuses on the detection of PowerShell scripts utilizing .NET cryptography APIs for file encryption or decryption. Attackers often leverage these capabilities to encrypt data for impact, potentially leading to data exfiltration or ransomware deployment, or to decrypt staged payloads, circumventing traditional security measures. Defenders should be aware of PowerShell scripts employing symmetric cryptography classes (AES/Rijndael, SymmetricAlgorithm), key derivation helpers (PasswordDeriveBytes, Rfc2898DeriveBytes), explicit cipher configurations (CipherMode, PaddingMode), and functions that generate encryptors/decryptors. Identifying such scripts is crucial for preventing both data compromise and the execution of malicious payloads. This detection specifically targets Windows systems where PowerShell is commonly used for both legitimate administration and malicious activities.

Attack Chain

Attacker gains initial access to the target system (e.g., via compromised credentials or a phishing attack).
Attacker uploads or stages a PowerShell script containing encryption/decryption capabilities.
The PowerShell script utilizes .NET cryptography APIs (e.g., AESManaged, RijndaelManaged, PasswordDeriveBytes, Rfc2898DeriveBytes).
The script configures the cipher using CipherMode and PaddingMode.
The script invokes .CreateEncryptor() or .CreateDecryptor() methods to initialize the cryptographic operation.
If encrypting, the script iterates through target files, encrypting their content and potentially renaming or deleting originals.
If decrypting, the script processes an encrypted payload, converting it to executable form or writing it to a new artifact.
The attacker executes the decrypted payload or exfiltrates the encrypted data, completing their objective.

Impact

Successful exploitation can lead to significant data loss, system downtime, and financial damage. Data encryption for impact can render systems unusable, while the decryption of staged payloads can introduce malware into the environment. The number of victims can vary widely depending on the scope of the attack, ranging from individual workstations to entire networks. Targeted sectors may include any organization reliant on Windows-based systems, with potential consequences including operational disruption, reputational damage, and regulatory fines.

Recommendation

Enable PowerShell Script Block Logging to capture the events required for detection, specifically event ID 4104, as detailed in the Elastic PowerShell logging setup guide.
Deploy the Sigma rule PowerShell Script with Encryption/Decryption Capabilities to your SIEM to detect suspicious PowerShell scripts utilizing .NET cryptography APIs.
Investigate alerts triggered by the Sigma rule, focusing on powershell.file.script_block_text to understand the cryptographic intent and data flow.
Tune the Sigma rule by adding exceptions for legitimate PowerShell scripts that use encryption, referencing the “False positive analysis” section in this brief.

PowerShell P/Invoke API Chain for Process Injection

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

This brief focuses on the detection of PowerShell scripts utilizing Platform Invoke (P/Invoke) to perform process injection. P/Invoke allows managed code (PowerShell) to call native, unmanaged code (Windows API functions). Adversaries leverage this capability to inject malicious code into other processes, bypassing traditional defenses. This activity is identified through PowerShell script block logging (Event ID 4104). The detection strategy covers both the compile phase (detecting inline .NET class definitions with DllImport declarations) and the execution phase (detecting static method invocation patterns using ::MethodName syntax with execution context indicators). This ensures broad coverage, even when pre-compiled assemblies are loaded. The techniques detected cover a wide range of process injection methods, increasing the likelihood of detection against various attack vectors.

Attack Chain

The attacker executes a PowerShell script containing malicious code designed for process injection.
The script uses Add-Type -TypeDefinition to define a .NET class inline, embedding C# source code that includes [DllImport] declarations for Windows API functions.
The DllImport attribute specifies the native DLL (e.g., kernel32.dll, ntdll.dll) and the function name to import.
The script declares external functions like VirtualAlloc, WriteProcessMemory, CreateRemoteThread, NtCreateSection, and NtMapViewOfSection using extern .
The script uses static method invocation (e.g., [IntPtr]::Zero, [Marshal]::Copy) to call the declared functions.
The script allocates memory in the target process using VirtualAllocEx or NtAllocateVirtualMemory.
The malicious code (shellcode or DLL) is written to the allocated memory using WriteProcessMemory.
A new thread is created in the target process to execute the injected code using CreateRemoteThread or RtlCreateUserThread. Alternatively, APC injection uses QueueUserAPC to queue an Asynchronous Procedure Call in the target process.

Impact

Successful process injection allows attackers to execute arbitrary code within the context of a legitimate process. This can lead to privilege escalation, credential theft, and persistence. Process injection can also be used to bypass security software and gain unauthorized access to sensitive data. This technique has been observed in malware campaigns associated with VIP Keylogger and similar threats, leading to data exfiltration and system compromise.

Recommendation

Enable PowerShell script block logging (Event ID 4104) to capture the necessary data for detection.
Deploy the provided Sigma rules to your SIEM to detect malicious PowerShell scripts using P/Invoke for process injection.
Investigate any alerts generated by the Sigma rules, focusing on processes that exhibit suspicious API call patterns.
Review and tune the Sigma rules based on your environment to minimize false positives and ensure accurate detection.

PowerShell Obfuscation via String Concatenation

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

This detection identifies PowerShell scripts that repeatedly concatenate quoted string literals using the + operator. Attackers use this technique to obfuscate malicious commands, URLs, or tokens, thereby evading static analysis and Anti-Malware Scan Interface (AMSI). The rule focuses on scripts with a script block length greater than 500 characters to reduce false positives. Successful exploitation allows attackers to execute malicious code without detection. This behavior matters for defenders as it bypasses traditional security measures that rely on static code analysis. This rule has been in production since 2025 and was updated in April 2026.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., phishing, exploit).
The attacker uploads or introduces a PowerShell script containing obfuscated code via string concatenation.
The script is executed using powershell.exe, potentially with arguments to bypass execution policies.
PowerShell interprets the script, which dynamically assembles commands by concatenating multiple string literals.
The dynamically assembled commands execute malicious actions, such as downloading a payload from a remote server.
The downloaded payload is saved to disk or executed directly in memory.
The payload establishes persistence using registry keys or scheduled tasks.
The attacker achieves their objective, such as data exfiltration or deploying ransomware.

Impact

Successful obfuscation can lead to the execution of arbitrary code, bypassing security measures, and potentially leading to system compromise. Consequences include data theft, system disruption, or ransomware deployment. The number of potential victims is broad, encompassing any Windows system running PowerShell. This technique can affect any sector.

Recommendation

Enable PowerShell Script Block Logging to capture the full script content (referenced in the rule’s Data Source: PowerShell Logs tag and the setup section of the source).
Deploy the provided Sigma rule to your SIEM and tune the Esql.script_block_pattern_count threshold based on your environment (see rules section below).
Investigate alerts generated by this rule, focusing on the reconstructed PowerShell script and its execution context (see note section of the source).

PowerShell Obfuscation via Character Array Reconstruction

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

This detection identifies PowerShell scripts employing character array reconstruction to obfuscate their contents. This technique involves building strings from char[] arrays, index lookups, or repeated ([char]NN)+ concatenation/join operations. Threat actors leverage this method to conceal malicious commands, URLs, or payloads, making them difficult to detect through static analysis and AMSI (Anti-Malware Scan Interface). The rule focuses on identifying scripts containing these character array manipulation patterns, enabling security teams to uncover potentially malicious PowerShell activity that would otherwise be missed. This technique is especially useful for attackers to evade detection in environments where PowerShell logging is enabled but not actively monitored for obfuscated code.

Attack Chain

Initial Access: The attacker gains initial access through various means, such as phishing emails, compromised credentials, or exploiting software vulnerabilities.
Payload Delivery: The attacker delivers a PowerShell script containing obfuscated code using character array reconstruction.
Obfuscation: The PowerShell script utilizes character array manipulation to construct malicious commands, URLs, or payloads dynamically.
Defense Evasion: The character array reconstruction technique bypasses static analysis and AMSI, hindering traditional security measures.
Execution: The script executes the reconstructed commands, potentially downloading and executing additional payloads or performing malicious actions on the system.
Persistence: The attacker may establish persistence by creating scheduled tasks or modifying registry keys to ensure the script runs automatically.
Command and Control: The script communicates with a command and control (C2) server to receive further instructions and exfiltrate sensitive data.
Impact: The attacker achieves their objective, which could include data theft, system compromise, or ransomware deployment.

Impact

Successful exploitation allows attackers to execute arbitrary code on the compromised system, potentially leading to data theft, system compromise, or ransomware deployment. The use of character array reconstruction significantly increases the likelihood of bypassing traditional security measures and successfully executing malicious actions. The severity of the impact depends on the attacker’s objectives and the level of access they gain on the compromised system.

Recommendation

Enable PowerShell script block logging to capture the necessary events for detection. Refer to the setup instructions in the rule details.
Deploy the provided Sigma rule to your SIEM and tune it for your environment to minimize false positives.
Investigate alerts generated by the Sigma rule to identify potentially malicious PowerShell scripts using character array reconstruction. Focus on analyzing the reconstructed strings and the script’s overall behavior.
Implement strict PowerShell execution policies to restrict the execution of unsigned or untrusted scripts.
Monitor for suspicious process creations originating from PowerShell, such as spawning command-line interpreters or executing system utilities.
Block known malicious domains and IP addresses associated with command and control servers.

PowerShell MiniDump Script Detection

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

This rule detects PowerShell scripts that contain references to MiniDumpWriteDump, MiniDumpWithFullMemory, or obfuscated versions of these strings (e.g., pmuDetirWpmuDiniM). Attackers can leverage these functions to create memory dumps of processes, including sensitive processes such as LSASS, which contains cached credentials. The dumping of LSASS memory allows attackers to extract credentials for lateral movement and privilege escalation within a compromised network. The rule is designed to detect scripts utilizing these techniques, providing an early warning sign of potential credential theft attempts. The rule leverages PowerShell script block logging (event ID 4104). The original rule was created in 2021 and updated in April 2026 according to the source.

Attack Chain

An attacker gains initial access to a Windows system through various means, such as phishing, exploiting a vulnerability, or using compromised credentials.
The attacker executes a PowerShell script on the target system. This script may be directly executed or injected into an existing PowerShell process.
The PowerShell script contains code that references MiniDumpWriteDump or MiniDumpWithFullMemory, or an obfuscated variant, indicating an intention to create a memory dump.
The script identifies a target process, often LSASS (lsass.exe), or iterates through running processes to select a target.
Using the MiniDumpWriteDump function, the script creates a memory dump of the targeted process.
The memory dump is saved to a file on the system, potentially in a location that is easily accessible to the attacker.
The attacker may then compress or encrypt the dump file to avoid detection and prepare it for exfiltration.
The attacker exfiltrates the memory dump from the compromised system for offline analysis and credential extraction.

Impact

Successful execution of this attack can lead to the compromise of sensitive credentials stored in memory, such as domain administrator accounts. This can enable attackers to move laterally within the network, escalate privileges, and gain access to critical systems and data. The impact could include data breaches, financial losses, and reputational damage. The number of victims can vary depending on the scope of the initial compromise and the effectiveness of the attacker’s lateral movement.

Recommendation

Enable PowerShell Script Block Logging (event ID 4104) to capture the necessary events for detection. Reference: https://atc-project.org/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md
Deploy the Sigma rule “PowerShell MiniDump Script” to your SIEM and tune for your environment to detect suspicious PowerShell scripts.
Investigate any alerts generated by the Sigma rule, focusing on the script content, target process, and output file. Use the investigation steps provided in the rule’s documentation.
Monitor for file creation events related to memory dumps (e.g., *.dmp files) and analyze these files for sensitive information.
Implement strict access controls and privilege management to limit the potential impact of credential theft.

Potential PowerShell Obfuscation via Special Character Overuse

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

This detection rule identifies PowerShell scripts that exhibit characteristics of obfuscation, specifically those heavily reliant on whitespace and special characters. Attackers employ these techniques to bypass security measures such as static analysis and the Antimalware Scan Interface (AMSI). The rule focuses on scripts that have a low diversity of symbols and a high ratio of whitespace and special characters, a common profile for obfuscated PowerShell code. The rule leverages PowerShell script block logging (event code 4104) to analyze script content and identify suspicious patterns, aiming to detect potentially malicious scripts attempting to conceal their true intent. This detection helps defenders identify and investigate potentially malicious PowerShell scripts before they can execute their payloads.

Attack Chain

An attacker gains initial access through a vulnerability or social engineering.
The attacker uploads or introduces an obfuscated PowerShell script to the target system.
The PowerShell script is executed, bypassing initial security checks due to the obfuscation.
The script leverages whitespace and special characters to hide malicious commands and logic.
At runtime, the script deobfuscates itself using PowerShell functions like Invoke-Expression or [char] casting.
The deobfuscated code executes malicious actions, such as downloading malware or modifying system settings.
The malware establishes persistence on the system.
The attacker achieves their objective, such as data exfiltration or establishing a backdoor.

Impact

Successful exploitation can lead to the execution of arbitrary code, malware installation, and potential compromise of the entire system. Obfuscation makes it difficult to detect malicious intent, allowing attackers to bypass traditional security measures. The widespread use of PowerShell in enterprise environments makes this a significant threat vector. The impact could range from minor system instability to a full-scale data breach, depending on the attacker’s objectives and the privileges of the compromised account.

Recommendation

Enable PowerShell Script Block Logging to generate the events used by this rule (e.g., 4104).
Deploy the Sigma rule Detect-Potential-PowerShell-Obfuscation to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule Detect-Potential-PowerShell-Obfuscation for potential malicious activity.

New ActiveSync Allowed Device Added via PowerShell

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

This detection identifies the use of the Exchange PowerShell cmdlet, Set-CASMailbox, to add a new ActiveSync allowed device. Attackers may target user email to collect sensitive information by adding unauthorized devices to a user’s allowed ActiveSync devices. The rule focuses on detecting suspicious PowerShell activity by monitoring for specific command patterns indicative of unauthorized device additions. This activity can lead to persistent access to sensitive email data, bypassing normal authentication controls. The original Elastic detection rule was created on 2020/12/15 and updated on 2026/05/04. This matters for defenders because it highlights a persistence mechanism that can be difficult to detect through traditional means.

Attack Chain

An attacker gains initial access to a privileged account with Exchange management permissions.
The attacker uses PowerShell to execute the Set-CASMailbox cmdlet.
The attacker modifies the ActiveSyncAllowedDeviceIDs attribute for a target user’s mailbox.
The attacker adds a rogue device ID to the list of allowed devices.
The attacker configures a mobile device with the rogue device ID to synchronize with the target mailbox.
The attacker gains persistent access to the target user’s email, calendar, and contacts.
The attacker exfiltrates sensitive data from the mailbox.
The attacker maintains persistence even after password changes by continuing to synchronize via the added device.

Impact

Successful exploitation could lead to unauthorized access to sensitive email data, including confidential communications, financial information, and personal data. This can result in data breaches, compliance violations, and reputational damage. The scope of the impact depends on the privileges of the compromised account and the sensitivity of the data contained in the targeted mailboxes.

Recommendation

Deploy the Sigma rule ActiveSyncAllowedDeviceID Added via PowerShell to your SIEM and tune for your environment to detect suspicious activity.
Enable Sysmon process-creation logging to capture PowerShell commands for the rule above.
Review Exchange audit logs for instances of Set-CASMailbox being used to modify ActiveSyncAllowedDeviceIDs.
Implement multi-factor authentication (MFA) for all accounts, especially those with Exchange management privileges.
Regularly audit ActiveSync device configurations to identify unauthorized devices.

Invoke-Obfuscation Obfuscated IEX Invocation via PowerShell

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

Attackers leverage Invoke-Obfuscation, a popular PowerShell obfuscation framework, to generate highly obfuscated IEX (Invoke-Expression) commands. This technique allows them to bypass traditional signature-based detections and execute malicious payloads on targeted systems. Invoke-Obfuscation is designed to make PowerShell code difficult to read and analyze, thus hindering security analysts and automated detection systems. The obfuscation techniques include string concatenation using environment variables, character code manipulation, and other methods to mask the true intent of the script. This activity has been observed across various campaigns, typically targeting Windows environments where PowerShell is widely used. Defenders should be aware of this technique and implement robust detection mechanisms to identify and block obfuscated PowerShell execution.

Attack Chain

Initial Access: An attacker gains initial access to the target system through methods such as phishing or exploiting a software vulnerability.
Payload Delivery: The attacker uploads a malicious PowerShell script or downloads it from a remote server.
Obfuscation: The attacker uses Invoke-Obfuscation to obfuscate the PowerShell script, making it difficult to analyze. This can involve techniques like string concatenation using $PSHome or $ShellId, or using complex variable manipulations.
Execution: The attacker executes the obfuscated PowerShell script using powershell.exe.
IEX Invocation: The obfuscated script leverages IEX (Invoke-Expression) to dynamically execute code, further hindering detection. The obfuscated strings are deobfuscated at runtime within the IEX context.
Persistence (Optional): The attacker may establish persistence by creating scheduled tasks or modifying registry keys.
Lateral Movement (Optional): The attacker may use the compromised system as a launching point for lateral movement within the network, using tools like PsExec or WinRM.
Objective: The ultimate objective could be data exfiltration, ransomware deployment, or establishing a long-term foothold for espionage.

Impact

Successful exploitation allows attackers to execute arbitrary code on the compromised system, leading to various malicious activities such as data theft, system compromise, and ransomware deployment. The use of Invoke-Obfuscation makes detection more challenging, potentially allowing attackers to remain undetected for extended periods. This can result in significant financial losses, reputational damage, and operational disruption.

Recommendation

Deploy the Sigma rule Invoke-Obfuscation Obfuscated IEX Invocation to your SIEM to detect obfuscated IEX commands generated by Invoke-Obfuscation.
Monitor PowerShell execution logs for suspicious command-line arguments that resemble obfuscation patterns described in the Sigma rule.
Implement PowerShell Constrained Language Mode to restrict the capabilities of PowerShell and limit the effectiveness of obfuscation techniques.
Enable and review PowerShell Script Block Logging to capture the content of executed scripts, allowing for more in-depth analysis of malicious activity.
Regularly update your endpoint detection and response (EDR) solutions to ensure they have the latest signatures and behavioral detection capabilities.
Educate users about the risks of phishing and other social engineering attacks that may be used to deliver malicious PowerShell scripts.

Exchange Mailbox Export via PowerShell

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

Attackers may target user email to collect sensitive information. The New-MailBoxExportRequest cmdlet is used to export the contents of a primary mailbox or archive to a .pst file. Note that this is done on a per-mailbox basis and this cmdlet is available only in on-premises Exchange. Attackers can abuse this functionality in preparation for exfiltrating contents, which is likely to contain sensitive and strategic data. This activity is typically performed using PowerShell or similar scripting tools and can be difficult to detect without specific monitoring in place. The activity may be part of a larger attack campaign targeting sensitive information.

Attack Chain

An attacker gains initial access to a compromised system with sufficient privileges to access Exchange PowerShell.
The attacker authenticates to the Exchange server using PowerShell.
The attacker uses the New-MailboxExportRequest cmdlet to initiate the export of a target mailbox to a .pst file. The command may include parameters to filter specific content.
The Exchange server processes the export request, creating a .pst file containing the mailbox data.
The attacker retrieves the exported .pst file from the designated file path.
The attacker may compress and archive the .pst file to reduce its size for exfiltration.
The attacker exfiltrates the .pst file to an external location controlled by the attacker.
The attacker analyzes the .pst file to extract sensitive information such as credentials, financial data, or intellectual property.

Impact

Successful exploitation allows the attacker to gain access to sensitive information contained within the exported mailboxes. This could lead to financial loss, reputational damage, or compromise of intellectual property. Depending on the scope of the export requests, multiple mailboxes may be compromised, impacting a large number of users. The impact is significant because email often contains highly sensitive business communications and data.

Recommendation

Enable Sysmon process creation logging to monitor PowerShell execution with command-line arguments (Data Source: Sysmon).
Implement the provided Sigma rule to detect the use of New-MailboxExportRequest cmdlet in PowerShell commands.
Review the privileges of users with the “Mailbox Import Export” privilege to ensure that the least privilege principle is being followed.
Monitor Windows Security Event Logs for PowerShell activity related to mailbox export requests (Data Source: Windows Security Event Logs).
Investigate any alerts generated by the Sigma rules to identify potential malicious activity.

PowerShell Loading .NET Assemblies via Reflection

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

This threat brief addresses the use of PowerShell to load .NET assemblies into memory using reflection, a technique frequently observed in advanced attacks. Threat actors, including those employing frameworks like Empire and Cobalt Strike, utilize this method to execute code directly in memory, evading traditional file-based security controls. The detection strategy focuses on PowerShell Script Block Logging (EventCode=4104), which captures the full commands executed, enabling analysis for specific reflection-related keywords. This behavior is a strong indicator of potential malicious activity, as it allows for unauthorized code execution, privilege escalation, and persistent access. Defenders should prioritize detection and response to such events to mitigate the risk of compromise. The technique allows attackers to bypass traditional defenses, execute code in memory, and potentially establish persistence within the targeted environment.

Attack Chain

Initial Access: The attacker gains initial access to the system, possibly through phishing or exploiting a vulnerability.
PowerShell Execution: The attacker executes PowerShell, often obfuscated or encoded, to avoid detection.
Reflection Assembly Loading: The PowerShell script uses reflection techniques, such as [System.Reflection.Assembly]::Load(), to load a .NET assembly directly into memory.
Bypassing Security Controls: The in-memory execution bypasses traditional security controls that scan files on disk.
Malicious Code Execution: The loaded assembly contains malicious code, which could be a payload for lateral movement, data exfiltration, or other malicious activities.
Privilege Escalation: The malicious code may attempt to escalate privileges to gain higher-level access to the system.
Persistence: The attacker establishes persistence by creating scheduled tasks or modifying registry keys.
Lateral Movement: The attacker uses the compromised system as a springboard to move laterally within the network, compromising additional systems.

Impact

Successful exploitation can lead to unauthorized code execution, privilege escalation, and persistent access within the environment. By loading .NET assemblies directly into memory, attackers can bypass traditional file-based security controls, making detection more challenging. This technique is often employed in advanced attacks, potentially affecting numerous systems across the network, leading to significant data breaches and system compromise. While specific victim counts are not available, the impact is considered high due to the potential for widespread damage and data loss.

Recommendation

Enable PowerShell Script Block Logging (EventCode=4104) on all endpoints to capture the full commands executed, as referenced in the description.
Deploy the provided Sigma rules to your SIEM to detect PowerShell scripts loading .NET assemblies into memory via reflection.
Investigate and remediate any alerts generated by the Sigma rules, prioritizing systems with high-value data or critical functions.
Regularly review and update PowerShell execution policies to restrict the execution of unsigned or untrusted scripts.
Monitor PowerShell logs for suspicious activity, such as the use of reflection techniques to load assemblies from unusual locations.
Consult the references provided, specifically the Microsoft .NET API documentation and the Palantir article on event tracing, to deepen your understanding of the attack techniques and potential mitigations.

PowerShell Execution via Environment Variables

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

Attackers are increasingly leveraging PowerShell to execute malicious code embedded within environment variables. This method involves storing commands or encoded content in environment variables and then using Invoke-Expression (or its alias iex) to dynamically construct and execute code at runtime. This tactic is employed to evade traditional static analysis techniques and conceal the true intent of the executed code. Observed in malware loaders and stagers, including those associated with the VIP Keylogger campaign, this technique is a significant threat. Defenders should be aware of this trend and implement appropriate detection mechanisms. The focus is on identifying PowerShell scripts that combine environment variable access ($env:) with Invoke-Expression or its aliases, based on PowerShell Script Block Logging (Event ID 4104).

Attack Chain

The attacker gains initial access to the system, possibly through phishing or exploiting a software vulnerability.
PowerShell is invoked, either directly or indirectly, via a script or another process.
The attacker sets an environment variable containing malicious code or a command. This might involve using [Environment]::SetEnvironmentVariable.
A PowerShell script is executed that reads the content of the environment variable using $env:.
The content read from the environment variable is passed to Invoke-Expression or its alias iex.
Invoke-Expression dynamically executes the code, effectively bypassing static analysis.
The executed code downloads and executes a secondary payload, such as a keylogger or a remote access tool.
The attacker achieves their objective, such as stealing credentials or establishing persistent access.

Impact

Successful exploitation can lead to the execution of arbitrary code on the compromised system, allowing attackers to install malware, steal sensitive data, or establish a persistent foothold. The VIP Keylogger campaign, for example, demonstrates how this technique can be used to harvest user credentials. Due to the obfuscated nature of this attack, it is difficult to detect and remediate, often leading to extended dwell time for the attacker. Compromised systems can be further used as a launchpad for attacks against other systems within the network.

Recommendation

Enable PowerShell Script Block Logging (Event ID 4104) on all Windows systems to capture the de-obfuscated script blocks before execution.
Deploy the provided Sigma rules to your SIEM to detect PowerShell scripts that access environment variables and use Invoke-Expression or its aliases. Tune these rules to your environment to reduce false positives.
Investigate any alerts generated by these rules to determine if malicious activity is occurring.
Monitor PowerShell execution for suspicious environment variable access and dynamic code execution.
Implement application control to prevent the execution of unauthorized PowerShell scripts.
Review and harden PowerShell execution policies to limit the attack surface.

Persistence via PowerShell Profile Modification

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious PowerShell Reconnaissance via WMI Queries

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

This brief focuses on detecting reconnaissance activities performed through PowerShell using WMI queries. Adversaries often use WMI to gather detailed information about a compromised system, including hardware specifications, operating system details, and installed software. This information can be used to plan further attacks, such as privilege escalation or lateral movement. This detection leverages PowerShell Script Block Logging (EventCode 4104) to identify specific WMI queries that target system information classes like Win32_Bios, Win32_OperatingSystem, Win32_Processor and others. Identifying this behavior early can help defenders disrupt attack chains before significant damage occurs. The analytic is based on the detection logic from the Splunk Security Content project as of April 2026.

Attack Chain

An attacker gains initial access to the target system, potentially through phishing or exploiting a software vulnerability.
The attacker executes a PowerShell script, either directly or via a command-line interpreter like cmd.exe.
The PowerShell script uses the Get-WmiObject cmdlet or a direct WMI query with SELECT to query system information.
Specific WMI classes are targeted, including Win32_Bios, Win32_OperatingSystem, Win32_Processor, Win32_ComputerSystem, Win32_PnPEntity, Win32_ShadowCopy, Win32_DiskDrive, Win32_PhysicalMemory, Win32_BaseBoard, and Win32_DisplayConfiguration.
The script collects the data returned by the WMI queries.
The gathered information is used to profile the system and identify potential vulnerabilities or weaknesses.
The attacker uses the gathered information to plan subsequent stages of the attack, like lateral movement or privilege escalation.
The attacker executes further commands based on the gathered information.

Impact

Successful reconnaissance can provide attackers with a comprehensive understanding of the target environment, enabling them to tailor their attacks for maximum impact. This can lead to successful privilege escalation, lateral movement, data exfiltration, or ransomware deployment. Organizations that fail to detect and prevent reconnaissance activities are at a higher risk of experiencing significant data breaches and financial losses. The Maze ransomware group, Industroyer2, and LockBit ransomware have been observed using similar reconnaissance techniques.

Recommendation

Enable PowerShell Script Block Logging on all endpoints to capture the necessary data for detection (PowerShell Script Block Logging 4104).
Deploy the Sigma rule Detect Suspicious WMI Reconnaissance via PowerShell to identify PowerShell scripts querying sensitive WMI classes.
Investigate any alerts generated by the Sigma rule, focusing on the user and process context to determine potential malicious intent.
Review and tune the Recon Using WMI Class detection filter (recon_using_wmi_class_filter) to reduce false positives in your environment.

Potential Invoke-Mimikatz PowerShell Script

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

This detection identifies PowerShell scripts containing Invoke-Mimikatz or Mimikatz commands, which are commonly used to extract sensitive information such as credentials, password stores, and certificates. The detection focuses on in-memory credential access, requiring thorough investigation and reconstruction of script context to assess the impact. The rule is designed to detect potential credential access attempts by identifying specific keywords and command patterns associated with Mimikatz usage within PowerShell script blocks. Defenders should prioritize investigations triggered by this rule due to the potential for significant compromise. The Elastic detection rule was last updated on 2026/04/24.

Attack Chain

An attacker gains initial access to the target system, potentially through phishing or exploiting a vulnerability.
The attacker executes a PowerShell script, either directly or through a payload.
The PowerShell script contains obfuscated or encoded Mimikatz commands.
The script leverages techniques to bypass AMSI (Anti-Malware Scan Interface) to avoid detection.
The script utilizes Invoke-Mimikatz or direct Mimikatz commands to dump credentials from memory (LSASS process).
The attacker extracts password hashes, plaintext passwords, and Kerberos tickets.
The attacker uses the stolen credentials to move laterally within the network.
The final objective is to gain access to sensitive data or critical systems, leading to data exfiltration or further compromise.

Impact

Successful exploitation can result in the compromise of user accounts, including privileged accounts. This can lead to lateral movement within the network, access to sensitive data, and potential data exfiltration. Credential dumping via Mimikatz is a common technique used in many attacks, often leading to widespread damage and significant financial loss. The rule’s high risk score of 99 reflects the severe potential impact of this activity.

Recommendation

Enable PowerShell Script Block Logging to capture the necessary events (4104) for this detection, as specified in the setup instructions.
Deploy the Sigma rule below to your SIEM and tune it for your environment to detect potential Mimikatz usage within PowerShell scripts.
Investigate any alerts generated by this rule by reconstructing the full PowerShell script block using powershell.file.script_block_id, powershell.sequence, and powershell.total as described in the rule’s notes.
Monitor for file creation events following the detection to identify potential credential dumps, archives, or exported certificates as highlighted in the rule’s notes.

Disabling Windows Defender Security Settings via PowerShell

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

Attackers frequently attempt to disable or weaken Windows Defender to facilitate the execution of malware and other malicious activities. This is often achieved through the use of PowerShell commands like Set-MpPreference and Add-MpPreference, which can modify various Defender settings. To evade detection, adversaries may encode these commands using Base64, making it more difficult for traditional command-line inspection techniques to identify the malicious intent. This activity is a common tactic in post-exploitation scenarios, allowing attackers to operate with reduced risk of being detected by the built-in antivirus solution. Detection of this behavior is critical for identifying and responding to potential intrusions. The Elastic detection rule aims to catch both standard and encoded PowerShell commands used for this purpose.

Attack Chain

An attacker gains initial access to a Windows system through methods such as phishing or exploiting a vulnerability.
The attacker elevates privileges to gain necessary permissions to modify Windows Defender settings.
The attacker uses the powershell.exe process to execute commands.
The attacker uses Set-MpPreference or Add-MpPreference to disable real-time monitoring.
The attacker may use Base64 encoding (e.g., using the -EncodedCommand parameter) to obfuscate the PowerShell commands.
The encoded command is executed, modifying Windows Defender settings.
Windows Defender’s real-time monitoring is disabled, allowing the attacker to execute malicious payloads without immediate detection.
The attacker proceeds with their objectives, such as deploying ransomware or exfiltrating data.

Impact

Successful disabling of Windows Defender can lead to a significant increase in the risk of malware infection and data breach. With real-time protection disabled, the system becomes vulnerable to various threats, including ransomware, Trojans, and other malicious software. This can result in data loss, system compromise, and potential financial damages. The impact can be severe, especially if the compromised system handles sensitive information or is critical to business operations.

Recommendation

Deploy the Sigma rule “Disabling Windows Defender Security Settings via PowerShell” to your SIEM and tune for your environment.
Enable PowerShell Script Block Logging to gain better visibility into the commands being executed (referenced in Sysmon setup instructions).
Monitor process creation events for PowerShell processes executing commands with -EncodedCommand or containing specific Base64 encoded strings to detect obfuscated attempts to disable Windows Defender.
Investigate any instances of Set-MpPreference or Add-MpPreference being used, especially if accompanied by unusual parent processes or command-line arguments.

PowerShell Obfuscation via Backtick-Escaped Variable Expansion

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

This rule detects PowerShell scripts employing backtick-escaped characters within ${} variable expansion, a technique used to reconstruct strings at runtime. Attackers leverage variable-expansion obfuscation to split keywords, conceal commands, and bypass static analysis and AMSI (Antimalware Scan Interface). This obfuscation method involves inserting multiple backticks between word characters inside ${} blocks. Detecting this behavior is crucial as it signifies attempts to evade security measures and potentially execute malicious code on compromised systems. The rule focuses on identifying scripts with a length exceeding 500 characters to minimize false positives and targets PowerShell event code 4104.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or exploiting a software vulnerability.
The attacker uploads or creates a PowerShell script on the target system.
The PowerShell script employs backtick-escaped variable expansion (e.g., $env:use``r``na``me) to obfuscate its contents.
The obfuscated script is executed using powershell.exe.
The script dynamically reconstructs commands and strings by evaluating the backtick-escaped variables.
The reconstructed commands perform malicious activities, such as downloading additional payloads or modifying system configurations.
The script attempts to evade detection by AMSI and other security tools.
The attacker achieves persistence and control over the compromised system, potentially leading to data exfiltration or further lateral movement.

Impact

Successful exploitation can lead to arbitrary code execution, system compromise, and data theft. While the number of victims is unknown, PowerShell is a common attack vector on Windows environments. The sectors most affected are organizations relying on Windows infrastructure without adequate PowerShell monitoring and security controls. Failure to detect and prevent this technique allows attackers to bypass security measures and gain unauthorized access to sensitive data.

Recommendation

Enable PowerShell Script Block Logging to generate event code 4104. (Reference: Setup section)
Deploy the Sigma rule Detect PowerShell Backtick Variable Obfuscation to identify scripts using backtick-escaped variable expansion.
Investigate any alerts generated by the Sigma rule, focusing on scripts with a high Esql.script_block_pattern_count value.
Monitor for process creation events where powershell.exe executes obfuscated commands as detected by the Sigma rule Detect Suspicious PowerShell Encoded Commands.
Review PowerShell logs for event code 4104 and examine powershell.file.script_block_text for suspicious patterns.