PowerShell PSReflect Script Detection

This detection rule identifies PowerShell scripts that utilize PSReflect techniques to dynamically invoke Win32 APIs. PSReflect allows PowerShell scripts to interact with native Windows APIs, potentially enabling malicious activities such as memory manipulation, privilege escalation, and bypassing security controls. The rule focuses on detecting specific keywords and patterns within PowerShell script block content, including “New-InMemoryModule”, “Add-Win32Type”, “DllImportAttribute”, and others indicative of PSReflect usage. The rule aims to catch scripts that might be used for malicious purposes by leveraging the power of native API calls within the PowerShell environment. It’s important for defenders as it helps identify potentially harmful scripts that may be attempting to perform unauthorized actions on a Windows system. The rule was last updated in May 2026.

Attack Chain

1. An attacker gains initial access to a Windows system, potentially through phishing or other means.
2. The attacker executes a PowerShell script, either file-based or fileless, on the compromised system.
3. The PowerShell script contains code that utilizes PSReflect techniques to dynamically load and call Win32 APIs.
4. The script uses functions like Add-Win32Type or New-InMemoryModule to create in-memory modules and import necessary Win32 API functions.
5. The attacker leverages DllImportAttribute to define the imported API functions and their corresponding DLLs.
6. The script then calls the imported Win32 APIs to perform malicious actions, such as memory manipulation, process injection, or privilege escalation.
7. The malicious actions may include injecting code into other processes, modifying system settings, or establishing persistence.
8. The attacker achieves their objective, such as gaining control of the system, stealing sensitive data, or causing damage.

Impact

Successful exploitation via PSReflect can lead to a wide range of malicious activities, including privilege escalation, code injection, and system compromise. An attacker could potentially gain complete control over the affected system, steal sensitive information, or use the system as a launchpad for further attacks. The impact can be severe, especially if the compromised system is a critical server or workstation within the organization. The rule helps to identify potential threats before they can cause significant damage.

Recommendation

• Enable PowerShell Script Block Logging to generate the necessary events for detection, as detailed in the setup instructions referenced in the original rule.
• Deploy the Sigma rules provided below to your SIEM to detect suspicious PowerShell scripts utilizing PSReflect techniques. Tune the rules for your specific environment to minimize false positives.
• Investigate any alerts generated by these rules by reconstructing the full script block using powershell.file.script_block_id, powershell.sequence, and powershell.total fields.
• Review the process execution telemetry (host.id + process.pid) to understand how PowerShell was launched and identify any suspicious parent processes.
• Consider implementing restrictions on PowerShell interop and unsigned script execution to reduce the attack surface.