National Cyber Warfare Foundation (NCWF)

Use built-in AD modules and Invoke-Command to run focused queries remotely, staying under the radar while exploring the environment.

The post PowerShell for Hackers: Survival Edition, Part 2 first appeared on Hackers Arise.

Welcome back, aspiring hackers!

Today we’re continuing the survival sequence and taking a closer look at PowerShell as your main tool. The beauty of PowerShell is that you don’t need to memorize a massive list of commands, it’s both a toolbox and a guide. It’s designed to help you figure things out as you go, so instead of wasting time searching online you can experiment and learn directly in the shell. If you let PowerShell handle the heavy lifting, you’ll work faster and stay under the radar. The integrated survival kit that not only has the tools you need, but also shows you how to use them step by step.

We will also cover Active Directory modules and dsquery which are incredibly useful during pentests. You will learn what to run, why it matters, and what to watch for if your goal is to stay quiet and keep access.

Remember, recon comes first, actions later. If you map the terrain carefully, you minimize surprises and reduce the chance of getting kicked out. Let’s dive in!

Dsquery

dsquery is a classic Windows tool, which is simple, fast, and present on domain-managing machines or admin workstations. At a high level, dsquery talks LDAP to AD, applies filters, and returns object lists like users, computers, OUs, groups, and whatever you ask for.

On well-configured domains, dsquery runs quickly and gives structured output that’s easy to parse. It’s also convenient when you don’t want to load or rely on larger modules or tools.

It is a system binary in the sense that it’s part of the Windows AD tooling set so it is legitimate for endpoint monitoring. Defenders may not immediately flag a dsquery invocation, but broad or repetitive queries against AD can still generate logs and attract attention. Large domain enumerations, wildcard queries that return thousands of objects, or repeated use from an unusual host are all detectable. Since stealth is the goal, favor targeted queries and avoid blasting the directory with exhaustive requests. Also note, that not every machine has dsquery installed, but it’s often present on domain controllers and admin workstations. On locked-down hosts it may be absent.

Find Users

This returns user accounts both active and inactive. Useful to get the initial scope of identities to investigate. Mainly we prioritize service and admin accounts first. Common name patterns like svc, adm, and others may give them away.

PS > dsquery user

Find Computers

Computer objects reveal server names, DEV hosts, backups, SQL, EXCH, etc. This variety gives you potential vectors of compromise. Well-managed environments place servers in OUs, which can tell you where critical infrastructure lives and help you refine your scope quickly.

PS > dsquery computer

Find groups

Inspect groups like Domain Admins, Enterprise Admins, Backup Operators and other potentially valuable. They point you to high-value targets and to people who matter inside the organization.

PS > dsquery * "CN=Users,DC=DOMAIN,DC=LOCAL"

Password-not-required accounts

This searches for users with the PASSWORD_NOT_REQUIRED flag. It’s uncommon on privileged accounts, but every once in a while you’ll find legacy or misconfigured accounts that are worth investigating.

PS > dsquery * -filter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))" -attr distinguishedName userAccountControl

finding password not required accounts with dsquery

An account that looks unprivileged at first can still own or be granted rights that make it a pivot to more interesting objects. Low-profile privilege pathways that are laterally exploitable. Tools like BloodHound help visualize those relationships if you’re collecting data to analyze later.

Domain Controllers

Knowing DC names and their IPs is important. They’re the gatekeepers. LDAP, Kerberos, and replication insights come from them, and they host the crown jewels of domain authentication.

PS > dsquery * -filter "(userAccountControl:1.2.840.113556.1.4.804:=8192)" -limit 5 -attr sAMAccountName

User-related data

We won’t rehash registry or user history investigations here, since that has been covered in PowerShell for Hackers: Basics. This chapter is focused on directory and module-based recon. If you need detailed user-artifact techniques, refer back to that article.

Remote Command Execution With PowerShell

There are many ways to execute commands remotely. Some require installing third-party binaries, others use native capabilities. Malicious third-party tools are noisy and signatured, while native execution can be quieter. Here’s the canonical PowerShell remote execution pattern:

PS > Invoke-Command -ComputerName DC -ScriptBlock { hostname }

remote command execution with Invoke-Command of one command

You can also run several commands at once. Here is how you would import a module and run an AD query:

PS > Invoke-Command -ComputerName DC -ScriptBlock { Import-Module ActiveDirectory; Get-ADUser -Filter * }

remote command execution with Invoke-Command of multiple commands

Now you can run modules on remote hosts and pull back results without leaving large traces.

Active Directory Modules and Documentation

Active Directory modules are incredibly convenient for both defenders and pentesters. They expose AD query and management commands in a readable, scriptable way. Importing the module is a legitimate action, which makes it less suspicious. Many teams don’t actively monitor every module load. That said, module use is logged, and the patterns of use matter. If you import ActiveDirectory and immediately run a large enumeration from a workstation that never runs those commands, defenders may notice.

Imagine you’re on a physical pentest and you find a machine with PowerShell but no internet access. Memorizing every command helps, but there are too many across different operating systems to rely on memory alone. In this case, PowerShell’s built-in help and a module’s own documentation have your back. Microsoft provided a solid help system that you can learn from.

Available modules

List what’s on the system before importing anything:

PS > Get-Module -ListAvailable

Check whether the Active Directory module is present:

PS > Get-Module ActiveDirectory

If it’s available, import it:

PS > Import-Module ActiveDirectory

checking if a powershell module is available and importing it

Once imported, list the commands available in the module. There are a lot. Don’t attempt to memorize them all, but focus on those that return identity, group, and computer information, and the ones that let you scope queries efficiently.

PS > Get-Command -Module ActiveDirectory

Get-Help is one of the useful survival tools you’ll have when offline. It shows command syntax, parameters, examples, and deeper usage notes, right in the session you’re running. Two flags we commonly use are -Examples and -Full:

See examples:

PS > Get-Help Enable-ADAccount -Example

using get-help to get help on a command in powershell to show examples of use

See full documentation:

PS > Get-Help Enable-ADAccount -Full

using get-help to get help on a command in powershell to show full command info

Help can also be updated, when the computer is connected to the internet:

PS > Update-Help

Take some time to explore the other commands PowerShell has in the Active Directory module. Doing this will prepare you for the variety of environments you’ll encounter during your pentests.

Summary

PowerShell is both your tool and your guide. It lets you learn about the environment in the shell, as you can get information without relying on external resources. Tools like dsquery and the Active Directory module help you map users, computers, and groups. These built-in binaries let you work from the host itself, even without internet access, which is good for keeping a lower profile. Careful and targeted recon reduces the risk of detection. Although everything can be detected, it really depends where the defender is looking at. Normally, detecting every possible move a hacker can make is unreal. By using the tools the defenders and system administrators use for legitimate purposes, you blend in with the environment so well.

In the next chapter we’ll cover how defenders spot suspicious activity and offer high-level recommendations for maintaining operational security and minimizing unnecessary noise.