A Threat Hunter’s Guide to Unmasking Attacks in PowerShell Event Logs

PowerShell is a powerful administration tool baked into every modern version of Windows. While system administrators love it for automation, attackers love it for the very same reason. Its ability to access deep parts of the operating system and execute fileless attacks makes it a prime vector for malicious activity.

But what if I told you that Windows is already watching? By default, PowerShell leaves a trail of breadcrumbs perfect for threat hunting. You just need to know where to look and what to look for.

Today, we’re diving into the native PowerShell event logs—a rich, built-in data source that can help you detect and dissect cybersecurity threats without any expensive third-party tools. The best part? They are enabled by default.

Finding the Treasure: Where Are PowerShell Logs?

First things first, let’s locate these logs. You can find them within the standard Windows Event Viewer under:

Application and Service Logs > Windows PowerShell

The fact that these are on by default is a huge win for defenders. While other advanced logs require configuration, you can often jump right into a system and find valuable historical data about PowerShell activity.

The Lifecycle of a PowerShell Script: From Birth to Death

To hunt effectively, you need to understand the lifecycle of a PowerShell script. Every time a script runs, it follows a predictable pattern, generating key events along the way. Think of it as a short story with a beginning, a middle, and an end, all chronicled by specific Event IDs.

The three most important Event IDs in this story are:

• Event ID 400: The engine starts. (The script is born).

• Event ID 600: A provider is loaded. (The script learns a new skill).

• Event ID 403: The engine stops. (The script’s work is done).

Let’s break down each one.

The Beginning: Event ID 400 – Engine Start

When any PowerShell script or command begins, it generates an Event ID 400. This log is your starting pistol, signaling that a new process has kicked off.

When you examine a 400 event, a few fields are critical for your investigation:

• HostApplication: This shows what process initiated the PowerShell command. You can see the exact command line arguments used. This is your first clue to what the script intends to do.

• HostID & RunspaceID: Think of these as unique identifiers. As you collect more logs, you can use these IDs to connect all the related events (like provider loading and the final shutdown) to this single script execution. It’s the thread that ties the entire story together.

• Timestamp: The exact time the script started.

Pro Tip for Investigators: Attackers know you’re looking at the HostApplication field. A common obfuscation technique is to encode the commands in Base64. This makes the text look like a meaningless jumble, breaking simple text-based searches. When you see what looks like gibberish, try decoding it from Base64 to reveal the true command.

The Middle: Event ID 600 – Providers Loading

Once a script is running, it often needs to interact with different parts of the operating system. To do this, it loads Providers. An Event ID 600 is logged every time a script loads a provider.

Think of providers as PowerShell’s version of DLLs or imports. They grant the script specific capabilities. For example, if a script needs to edit the Windows Registry, it must first load the Registry provider.

Here are some common built-in providers you’ll see:

• Registry: Accessing and modifying registry keys.

• FileSystem: Creating, reading, or modifying files and directories.

• Environment: Accessing environment variables.

• Function: Accessing PowerShell functions.

By monitoring Event ID 600, you can profile a script’s behavior. You don’t even need to see the full code to understand its capabilities. A script loading the Registry provider immediately tells you it’s interacting with the registry. If you suspect an unauthorized registry change was made via PowerShell, you can hunt for all scripts that loaded that specific provider.

The End: Event ID 403 – Engine Stop

Finally, when the script finishes its execution, the PowerShell engine stops, generating an Event ID 403. This log confirms that the process has concluded.

Like the 400 event, it contains the HostID and RunspaceID, allowing you to definitively tie it back to the script that started it all.

An Interesting forensic Clue: Pay close attention to the fields in the 403 event and compare them to the initial 400 event. Sometimes, more advanced malware will try to modify its own process in memory during execution. This can cause discrepancies where the command line or other data in the 403 “stop” event looks different from the 400 “start” event. A simple diff between the two can sometimes reveal that something suspicious happened mid-flight.

Putting It All Together for the Hunt

By themselves, these events are useful. Together, they are a powerful narrative. Your threat hunt workflow can look like this:

1. Scan for Starters (ID 400): Look for suspicious HostApplication commands. Is PowerShell being called in a strange way? Is the command obfuscated with Base64?

2. Correlate the IDs: Once you find a suspicious 400 event, grab its HostID and RunspaceID.

3. Find the Capabilities (ID 600): Pivot to find all 600 events with the same HostID/RunspaceID. This tells you exactly what the script did: Did it touch the file system? The registry? Both?

4. Confirm the End (ID 403): Locate the corresponding 403 event to see when it stopped and if anything changed upon exit.

This lifecycle approach gives you a complete picture of a script’s actions on a host, using only the logs Windows provides for free.

Start Digging Today

PowerShell isn’t going away, and neither are the attackers who abuse it. The good news is that you have a powerful, built-in detection mechanism at your fingertips. By understanding and correlating event logs 400, 600, and 403, you can turn a black box of potential threats into a clear story of what happened on your network.

So go ahead, open up Event Viewer and start exploring. You might be surprised what you find.