Login
PowerShell for Hackers: Survival Edition, Part 1
Welcome back, cyberwarriors.
We’re continuing our look at how PowerShell can be used in offensive operations, but this time with survival in mind. When you’re operating in hostile territory, creativity and flexibility keep you alive. PowerShell is a powerful tool and how well it serves you depends on how cleverly you use it. The more tricks you know, the better you’ll be at adapting when things get tense. In today’s chapter we’re focusing on a core part of offensive work, which is surviving while you’re inside the target environment. These approaches have proven themselves in real operations. The longer you blend in and avoid attention, the more you can accomplish.
We’ll split this series into several parts. This first piece is about reconnaissance and learning the environment you’ve entered. If you map the perimeter and understand the scope of your target up front, you’ll be far better placed to move into exploitation without triggering traps defenders have set up. It takes patience. As OTW says, true compromises usually require time and persistence. Defenders often rely on predictable detection patterns, and that predictability is where many attackers get caught. Neglecting the basics is a common and costly mistake.
When the stakes are high, careless mistakes can ruin everything. You can lose access to a target full of valuable information and damage your reputation among other hackers. That’s why we made this guide to help you use PowerShell in ways that emphasize staying undetected and keeping access. Every move should be calculated. Risk is part of the job, but it should never be reckless. That’s also why getting comfortable with PowerShell matters, as it gives you the control and flexibility you need to act professionally.
If you read our earlier article PowerShell for Hackers: Basics, then some of the commands in Part 1 will look familiar. In this article we build on those fundamentals and show how to apply them with survival and stealth as the priority.
Basic Reconnaissance
Hostname
Once you have access to a host, perhaps after a compromise or phishing attack, the first step is to find out exactly which system you have landed on. That knowledge is the starting point for planning lateral movement and possible domain compromise:
PS > hostname
Sometimes the hostname is not very revealing, especially in networks that are poorly organized or where the domain setup is weak. On the other hand, when you break into a large company’s network, you’ll often see machines labeled with codes instead of plain names. That’s because IT staff need a way to keep track of thousands of systems without getting lost. Those codes aren’t random, they follow a logic. If you spend some time figuring out the pattern, you might uncover hints about how the company structures its network.
System Information
To go further, you can get detailed information about the machine itself. This includes whether it is domain-joined, its hardware resources, installed hotfixes, and other key attributes.
PS > systeminfo
This command is especially useful for discovering the domain name, identifying whether the machine is virtual, and assessing how powerful it is. A heavily provisioned machine is often important. Just as valuable is the operating system type. For instance, compromising a Windows server is a significant opportunity. Servers typically permit multiple RDP connections and are less likely to be personal workstations. This makes them more attractive for techniques such as LSASS and SAM harvesting. Servers also commonly host information that is valuable for reconnaissance, as well as shares that can be poisoned with malicious LNK files pointing back to your Responder.
Once poisoned, any user accessing those shares automatically leaks their NTLMv2 hashes to you, which you can capture and later crack using tools like Hashcat.
OS Version
If your shell is unstable or noninteractive and you cannot risk breaking it with systeminfo. Here is your alternative:
PS > Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption
Different versions of Windows expose different opportunities for abuse, so knowing the precise version is always beneficial.
Patches and Hotfixes
Determining patch levels is important. It tells you which vulnerabilities might still be available for exploitation. End-user systems tend to be updated more regularly, but servers and domain controllers often lag behind. Frequently they lack antivirus protection, still run legacy operating systems like Windows Server 2012 R2, and hold valuable data. This makes them highly attractive targets.
Many administrators mistakenly believe isolating domain controllers from the internet is sufficient security. The consequence is often unpatched systems. We once compromised an organization in under 15 minutes with the NoPac exploit, starting from a low-privileged account, purely because their DC was outdated.
To review installed hotfixes:
PS > wmic qfe get Caption,Description,HotFixID,InstalledOn
Remember, even if a system is unpatched, modern antivirus tools may still detect exploitation attempts. Most maintain current signature databases.
Defenses
Before proceeding with exploitation or lateral movement, always understand the defensive posture of the host.
Firewall Rules
Firewall configurations can reveal why certain connections succeed or fail and may contain clues about the broader network. You can find this out through passive reconnaissance:
PS > netsh advfirewall show allprofiles
The output may seem overwhelming, but the more time you spend analyzing rules, the more valuable the information becomes. As you can see above, firewalls can generate logs that are later collected by SIEM tools, so be careful before you initiate any connection.
Antivirus
Antivirus software is common on most systems. Since our objective here is to survive using PowerShell only, we won’t discuss techniques for abusing AV products or bypassing AMSI, which are routinely detected by those defenses. That said, if you have sufficient privileges you can query installed security products directly to learn what’s present and how they’re configured. You might be lucky to find a server with no antivirus at all, but you should treat that as the exception rather than the rule
PS > Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntivirusProduct
This method reliably identifies the product in use, not just Microsoft Defender. For more details, such as signature freshness and scan history run this:
PS > Get-MpComputerStatus
To maximize survivability, avoid using malware on these machines. Even if logging is not actively collected, you must treat survival mode as if every move is observed. The lack of endpoint protection does not let you do everything. We saw people install Gsocket on Linux boxes thinking it would secure access, but in reality network monitoring quickly spotted those sockets and defenders shut them down. Same applies to Windows.
Script Logging
Perhaps the most important check is determining whether script logging is enabled. This feature records every executed PowerShell command.
PS > Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
If EnableScriptBlockLogging is set to 1, all your activity is being stored in the PowerShell Operational log. Later we will show you strategies for operating under such conditions.
Users
Identifying who else is present on the system is another critical step.
The quser command is user-focused, showing logged-in users, idle times, and session details:
PS > quser
Meanwhile, qwinsta is session-focused, showing both active and inactive sessions. This is particularly useful when preparing to dump LSASS, as credentials from past sessions often remain in memory. It also shows the connection type whether console or RDP.
PS > qwinsta
Network Enumeration
Finding your way through a hostile network can be challenging. Sometimes you stay low and watch, sometimes you poke around to test the ground. Here are the essential commands to keep you alive.
ARP Cache
The ARP table records known hosts with which the machine has communicated. It is both a reconnaissance resource and an attack surface:
PS > arp -a
ARP entries can reveal subnets and active hosts. If you just landed on a host, this could be valuable.
Note: a common informal convention is that smaller organizations use the 192.168.x.x address space, mid-sized organizations use 172.16.x.x–172.31.x.x, and larger enterprises operate within 10.0.0.0/8. This is not a rule, but it is often true in practice.
Known Hosts
SSH is natively supported on modern Windows but less frequently used, since tools like PuTTY are more common. Still, it is worth checking for known hosts, as they might give you insights about the network segmentation and subnets:
PS > cat %USERPROFILE%\.ssh\known_hosts
Routes
The route table exposes which networks the host is aware of, including VLANs, VPNs, and static routes. This is invaluable for mapping internal topology and planning pivots:
PS > route print
Learning how to read the output can take some time, but it’s definitely worth it. We know many professional hackers that use this command as part of their recon toolbox.
Interfaces
Knowing the network interfaces installed on compromised machines helps you understand connectivity and plan next steps. Always record each host and its interfaces in your notes:
PS > ipconfig /all
Maintaining a record of interfaces across compromised hosts prevents redundant authentication attempts and gives a clearer mindmap of the environment.
Net Commands
The net family of commands remains highly useful, though they are often monitored. Later we will discuss bypass methods. For now, let’s review their reconnaissance value.
Password Policy
Knowing the password policy helps you see if brute force or spraying is possible. But keep in mind, these techniques are too noisy for survival mode:
PS > net accounts /domain
Groups and Memberships
Local groups, while rarely customized in domain environments, can still be useful:
PS > net localgroup
Domain groups are far more significant:
PS > net group /domain
Checking local Administrators can show privilege escalation opportunities:
PS > net localgroup Administrators
Investigating domain group memberships often reveals misconfigured privileges:
PS > net group <group_name> /domain
With sufficient rights, groups can be manipulated:
PS > net localgroup Administrators hacker /add
PS > net group "Marketing" user /add /domain
However, directly adding accounts to highly privileged groups like Domain Admins is reckless. These groups are closely monitored. Experienced hackers instead look for overlooked accounts, such as users with the “password not required” attribute or exposed credentials in LDAP fields.
Domain Computers and Controllers
Domain computer lists reveal scope, while controllers are critical to identify and study:
PS > net group "Domain Computers" /domain
PS > net group "Domain Controllers" /domain
Controllers in particular hold the keys to Active Directory. LDAP queries against them can return huge amounts of intelligence.
Domain Users
Enumerating users can give you useful account names. Administrators might include purpose-based prefixes such as “adm” or “svc” for service accounts, and descriptive fields sometimes contain role notes or credential hints.
PS > net user /domain
Shares
Shares are often overlooked by beginners, and that’s a common mistake. A share is basically a place where valuable items can be stored. At first glance it may look like a pile of junk full of unnecessary files and details. And that might be true, since these shares are usually filled with paperwork and bureaucratic documents. But among that clutter we often find useful IT data like passwords, VPN configurations, network maps and other items. Finding documents owned by assistants is just as important. Assistants usually manage things for their directors, so you’ll often find a lot of directors’ private information, passwords, emails, and similar items. Here is how you find local shares hosted on your computer:
PS > net share
Remote shares can also be listed:
PS > net view \\computer /ALL
Enumerating all domain shares creates a lot of noise, but it can be done if you don’t have a clear understanding of the hosts. We do not recommend doing this. If the host names already give you enough information about their purpose, for example, “DB” or “BACKUP”, then further enumeration isn’t necessary. Going deeper can get you caught, even on a small or poorly managed network. If you decide to do it, here is how you can enumerate all shares in the domain:
PS > net view /all /domain[:domainname]
Interesting shares can be mounted for detailed searching:
PS > net use x: \\computer\share
You can search through documents in a share using specific keywords:
PS > Get-ChildItem -Recurse | Select-String -Pattern "keyword" -SimpleMatch -CaseSensitive:$false
Summary
That’s it for Part 1 of the Survival Series. We’re excited to keep this going, showing you different ways to work with systems even when you’re limited in what you can do. Sure, the commands you have are restricted, but survival sometimes means taking risks. If you play it too safe, you might get stuck and have no way forward. Time can work against you, and making bold moves at the right moment can pay off.
The goal of this series is to help you get comfortable with the Windows tools you have at your disposal for recon and pentesting. There will be times when you don’t have much, and you’ll need to make the most of what’s available.
In Part 2, we’ll go deeper looking at host inspections, DC queries, and the Active Directory modules that can give you even more insight. Having these native tools makes it easier to stay under the radar, even when things are going smoothly. As you get more experience, you’ll find that relying on built-in tools is often the simplest, most reliable way to get the job done.
The post PowerShell for Hackers: Survival Edition, Part 1 first appeared on Hackers Arise.
