PowerShell — CraftedSignal Threat Feed

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.

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.

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.

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

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