Windows PowerShell

Severity: High

Likelihood: High (commonly leveraged by attackers post-compromise; often overlooked as “legitimate” activity)

General Guidance

Restrict and monitor PowerShell usage, enforce logging, and apply least-privilege access controls. Where possible, limit PowerShell to authorized users and implement security features like Constrained Language Mode and script signing.

What is the concern?

PowerShell is a powerful administrative tool built into Windows that enables automation and remote command execution. Attackers frequently abuse PowerShell for “living off the land” techniques, allowing them to execute malicious commands, download payloads, and move laterally without introducing traditional malware—making detection significantly harder.

Business Impact

• Stealthy execution of malicious commands without dropping files

• Credential harvesting and privilege escalation

• Lateral movement across systems

• Data exfiltration and system manipulation

• Increased dwell time due to evasion of traditional security tools

How can this be resolved?

• Enable PowerShell logging (Script Block Logging, Module Logging, Transcription)

• Restrict PowerShell usage to authorized administrators only

• Enforce Constrained Language Mode where appropriate

• Require signed scripts and restrict execution policies

• Integrate with EDR tools for behavioral monitoring

• Disable PowerShell v2 (legacy, less secure version)

• Apply least privilege and monitor administrative activity

Windows PowerShell services should be hidden behind a firewall and/or VPN, or similar action taken, to prevent any unwanted access or intrusion which could later be used to access the internal network via any connecting devices or accidental connection onto the core network. If placing these services behind a firewall/VPN, only a narrow set of allow-listed services should be permitted to connect. If you do this, KYND will mark the issue as resolved.

If this isn’t possible, you should take alternative steps to mitigate the issue.

This could include adding extra layers of authentication, including MFA or PKI certificates to ensure that only authenticated users and services are able to connect.

If none of these are possible, then these services should be entirely separated from the rest of your organization's infrastructure, ensuring that there is no way an attacker could traverse from an attack on this service to gain access to sensitive data, services, networks or infrastructure.

Real-World Example

• Fileless malware campaigns (multiple): Attackers have widely used PowerShell to download and execute payloads directly in memory, avoiding disk-based detection. Campaigns involving Emotet, TrickBot, and Cobalt Strike commonly leveraged PowerShell for staging and persistence.

• Targeted enterprise breaches: In many incident response cases, attackers used PowerShell remoting (WinRM) to move laterally across environments, execute commands on remote systems, and extract sensitive data—all using legitimate administrative tooling.

• APT activity: Advanced threat groups (e.g., APT29) have used heavily obfuscated PowerShell scripts to maintain persistence and evade detection in high-value targets

Detection Opportunities

• Log monitoring:

  • PowerShell Script Block Logging (Event ID 4104)

  • Module Logging (Event ID 4103)

  • Process creation logs (Event ID 4688) for powershell.exe or pwsh.exe

• Behavioral indicators:

  • Encoded or obfuscated PowerShell commands (e.g., -EncodedCommand)

  • PowerShell spawning from unusual parent processes (e.g., Office apps)

• Network monitoring:

  • PowerShell downloading external content (e.g., via Invoke-WebRequest, IEX)

• Endpoint detection:

  • In-memory execution patterns or suspicious command-line usage

• Threat hunting:

  • Known malicious PowerShell patterns and frameworks (e.g., Empire, Cobalt Strike)