When you first get access to a host, oftentimes all you’re given is a prompt for a shell. And this is great if all you’re looking for is proof that you can compromise a single host.
But, more often than not, an attacker isn’t going to stop there. They’re going to take over other user accounts and pivot to other targets on the network so that they can steal as much information as possible.
Ethical hackers need to go beyond initial access too, in order to expose methods attackers may use in the future. And the first step in that journey is situational awareness.
Situational awareness is the act of gathering the context behind the machine you gained access to. I like to break it down into four simple questions:
- Who – What user are you logged in as? What level of access do they have? What is their role?
- What – What machine did you compromise? What role does it play in the network?
- Where – What position is the machine in the network? What other machines can it communicate with?
- Why – What is the purpose of this machine or what is it used for? How critical is it?
These four questions are what I use to help me think about the purpose of the commands I’m about to show you. I’m not just going to list them all one-by-one willy-nilly. You’re going to learn how to think like an attacker.
With a better mindset and understanding of the context of your initial access, it will make it easier for you to move on to further compromise. Knowledge is power. Situational awareness is also vital for pentesters especially, as it’s important to stay in scope and not do anything that could damage a business-critical machine.
It’s worth noting that this can all be automated (and has been automated). Even so, it’s important to know how to use these commands because
- You may not always be able to upload or use scripts
- You would be able to write your own scripts that get you the information that works best for you
Enough yapping from me. Let’s dive in!
User information (The who)
Probably the most basic (and important) question we can answer is “Who are we logged in as?” An equally basic command can answer that question for us:
C:\Users\sales01>whoami
samsec\sales01You’ll notice that the username was slightly given in the prompt because I was given a shell in the user’s home directory. But, that’s not always the case.
The whoami command also reveals that the sales01 user is a domain user part of the samsec domain. An important insight because this user may have access to other machines part of the samsec domain (I smell a pivot!).
Now that I know the logged-in user’s name, I can use the net user command for more context:
C:\Users\sales01>net user /domain sales01
The request will be processed at a domain controller for domain samsec.local.
User name sales01
...
Local Group Memberships
Global Group memberships *Domain Users *Sales
The command completed successfully.Since the user is a domain user, I used the /domain flag. Without it, no results are returned since the user is not a local user and is not part of any local groups.
C:\Users\sales01>net user sales01
The user name could not be found.
More help is available by typing NET HELPMSG 2221.Based on these results, the sales01 user does not seem to be a high privilege user (they’re not part of any built-in admin accounts). More exploration \is needed to determine what access they have to this machine and others on the network.
For now, we’re at a good starting point with just a few basic commands!
System information (The what)
We now know a little bit about who we’re logged in as. Now, we need more information about what system we are logged into.
Basic info with systeminfo
The powerful systeminfo command can shed some light for us:
C:\Users\sales01>systeminfo
Host Name: WORKSTATION01
OS Name: Microsoft Windows 10 Education
OS Version: 10.0.19045 N/A Build 19045
...
System Model: VirtualBox
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: AMD64 Family 25 Model 117 Stepping 2 AuthenticAMD ~3294 Mhz
BIOS Version: innotek GmbH VirtualBox, 12/1/2006
...
Time Zone: (UTC-08:00) Pacific Time (US & Canada)
...
Domain: samsec.local
Logon Server: \\DC01
Hotfix(s): 6 Hotfix(s) Installed.
[01]: KB5017022
[02]: KB5015684
[03]: KB5026037
[04]: KB5017308
[05]: KB5014032
[06]: KB5016705
Network Card(s): 1 NIC(s) Installed.
[01]: Intel(R) PRO/1000 MT Desktop Adapter
Connection Name: Ethernet
DHCP Enabled: No
IP address(es)
[01]: 192.168.56.21
[02]: fe80::8e2:71b5:af0e:9dc2This command gave me a lot of useful information. Including:
- The hostname
- OS name/version
- Architecture details
- Domain and domain controller’s hostname
- IP address
A pentester (or attacker) could have many uses for this information. For example, the OS details and processor information could be used to determine which payloads can be used on the system. It is also given that this system is a Virtualbox machine, so it could be a sandboxed environment or a honeypot. Given the hostname of the domain controller, an attacker could build the domain name of the DC and (dc01.samsec.local) start targeting it.
Using hostname to get our hostname
Another command useful for gleaning information about the system is the hostname command:
C:\Users\sales01>hostname
Workstation01This simple command is easy to overlook. Often, system admins will name computers that accurately describe their role on the network. This is helpful for them to quickly find out what computer is used for what. It also helps attackers get more context.
For example, we saw from the systeminfo command that the domain controller was appropriately named DC01. Another example would be a SQL server called MYSQL_SVR_01, which would reveal that the system is likely running MYSQL. Keep in mind, however, that not all hostnames are going to be this helpful.
In my case, it seems like the computer I have access to is just a workstation. While it may not be super critical to the overall network (like a database or domain controller), it can still be an important compromise. As a member or the Sales group, there may be confidential financial information stored somewhere on computer the sales01 user has access to. This could potentially be devastating towards a company in the wrong hands.
Remember: demonstrate risk that pertains to the company you are pentesting. It’s not always about getting Domain Admin.
Network Information (The where)
The next question we need to ask ourselves is where we’ve landed on the network. In other words, we need our IP address.
Get the IP with ipconfig
The right tool for the job is ipconfig:
C:\Users\sales01>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : Workstation01
Primary Dns Suffix . . . . . . . : samsec.local
Ethernet adapter Ethernet:
IPv4 Address. . . . . . . . . . . : 192.168.56.21(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.56.1
DNS Servers . . . . . . . . . . . : 192.168.56.10
8.8.8.8I tacked on the /all option to get a little more information. Here, we can see our IP address and the subnet mask of the network. An attacker can leverage this to scan for other targets this system could potentially have access to.
I’m also given the default gateway and DNS server. These are good to note down for potential Man-In-the-Middle attacks. We can also use the DNS server to query guessable names as a form of target discovery (ex: querying for workstation02.samsec.local).
I’m now aware of an address space of potential targets but what about systems that are already communicating with the compromised host? These would be easier to leverage than risking conducting a scan from the victim.
Displaying connections with netstat
Active connections can be displayed with the netstat command:
C:\Users\sales01>netstat -an | findstr "ESTABLISHED"
I used the a option to display all connections and n to display port numbers instead of names. Unfortunately there were no active connections to other systems.
It might be worth taking a look at listening ports however:
C:\Users\sales01>netstat -an | findstr "LISTENING"
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49669 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49670 0.0.0.0:0 LISTENING
TCP 192.168.56.21:139 0.0.0.0:0 LISTENINGThere are quite a few open ports. These would be worth cross-referencing with scan results and seeing if any of the ports host interesting services.
Exploring previous connections with arp
I may not have found any active connections to other systems with netstat, but we can take a look at connections the victim has made previously. These are found in the ARP cache and are revealed with the arp command:
C:\Users\sales01>arp -a
Interface: 192.168.56.21 --- 0xd
Internet Address Physical Address Type
192.168.56.1 0a-00-27-00-00-09 dynamic
192.168.56.10 08-00-27-6f-39-a3 dynamic
192.168.56.255 ff-ff-ff-ff-ff-ff staticIt’s no surprise that this system has talked to the gateway before. I also know that the 10 system is the DNS server from the ipconfig output.
Using route to show the routing table
Another area worth exploring is the victim’s routing table. In other words, where else can the victim send and receive traffic to?
The route command is the best tool for the job:
C:\Users\sales01> route print
===========================================================================
IPv4 Route Table
===========================================================================
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.10.10.1 10.10.10.5 10
192.168.1.0 255.255.255.0 On-link 192.168.1.100 20
172.16.0.0 255.255.0.0 10.10.10.1 10.10.10.5 10
192.168.5.0 255.255.255.0 10.10.10.1 10.10.10.5 10The route command shows me that there is a 100 system on its subnet that it may have access to. This could be an interesting pivot opportunity.
Moreover, there are two additional subnets the victim has access to: 172.16.0.0 and 192.168.5.0. These could be sensitive internal network that may host a slew of new targets!
Programs, Processes and Services (The why)
It was revealed earlier that the compromised host is most likely a simple workstation (from the hostname Workstation01) and may be used by an employee(s) working in the Sales department (net user output).
But we need more context. What exactly is the computer being used for? What is its purpose? How critical is it to the organization?
Why is it on the network?
Listing running processes with tasklist
To help answer these questions, we can look towards the tasklist command:
C:\Users\sales01>tasklist
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
...
VBoxService.exe 1512 Services 0 6,136 K
Memory Compression 1620 Services 0 29,664 K
...
MpDefenderCoreService.exe 2076 Services 0 16,008 K
...
SkypeBackgroundHost.exe 4336 Console 1 1,164 K
VBoxTray.exe 5092 Console 1 10,912 K
OneDrive.exe 936 Console 1 33,500 K
...
SgrmBroker.exe 5900 Services 0 6,472 K
svchost.exe 5980 Services 0 10,180 K
WMIADAP.exe 2696 Services 0 8,260 K
WmiPrvSE.exe 6036 Services 0 8,896 KThe tasklist command lists active processes.
From here we can see that the machine uses OneDrive, which is pretty standard in Windows. Maybe we can look for confidential files?
Windows Defender is active. As the default antivirus of windows (with seemingly no other defenses or VPNs being installed) maybe this is a low-priority system?
Interestingly, the system is running a VBoxService. Could this be sandboxed environment or honeypot? We certainly wouldn’t want to risk making too much noise on this system as it could raise some unwanted attention.
As you can see, the tasklist command can help us piece together the story behind this system.
Displaying startup processes with net start
We’re not going to stop there. Running similar commands for cross-referencing is always a good idea. Let’s see what net start shows us:
C:\Users\sales01>net start
These Windows services are started:
Microsoft Account Sign-in Assistant
Microsoft Defender Antivirus Network Inspection Service
Microsoft Defender Antivirus Service
Microsoft Defender Core Service
Microsoft Store Install Service
Netlogon
Network Connection Broker
Network List Service
Network Location Awareness
Network Store Interface Service
Power
Print Spooler
Radio Management Service
Remote Access Connection Manager
Remote Procedure Call (RPC)
RPC Endpoint Mapper
Secure Socket Tunneling Protocol Service
Security Accounts Manager
Security Center
Server
Task Scheduler
VirtualBox Guest Additions Service
The command completed successfully.In the list of startup apps/services, we see more or less the same output as tasklist. The presence of the VirtualBox Guest Additions Service pretty much confirms our suspicions that this is a virtual machine (which is entirely right because this is my lab network 😀 ).
Taking a look at scheduled tasks with schtasks
It’s also a good idea to look at scheduled tasks using the schtasks command:
C:\Users\sales01>schtasks
Folder: \
TaskName Next Run Time Status
======================================== ====================== ===============
OneDrive Standalone Update Task-S-1-5-21 9/15/2024 1:14:16 AM Running
Folder: \Microsoft\Windows\Windows Defender
TaskName Next Run Time Status
======================================== ====================== ===============
Windows Defender Cache Maintenance N/A Ready
Windows Defender Cleanup N/A Ready
Windows Defender Scheduled Scan N/A Ready
Windows Defender Verification N/A Ready
Folder: \Microsoft\Windows\Windows Error ReportingScheduled tasks are good to jot down for privilege escalation attacks, but that’s another rabbit hole for another day.
We also need to know how well this machine is protected. Using the previous commands, we could gauge this by taking note of the security software and services that are running.
Using netsh to display firewall rules
Firewall rules are important to check as well. We can list these with netsh:
C:\Users\sales01>netsh advfirewall show allprofiles
Domain, Private, Public Profiles:
--------------------------------------------------------
State ON
Firewall Policy BlockInbound,AllowOutbound
InboundUserNotification Enable
RemoteManagement Disable
UnicastResponseToMulticast Enable
Logging:
LogAllowedConnections Disable
LogDroppedConnections DisableNothing too special about these options. It’s nice to know that our connection isn’t being logged, though.
Conclusion
You learned how to gain more context after the initial compromise with some basic (but powerful) Windows commands.
As a penetration tester it is vital you know what system you have gained access to. You wouldn’t want to do anything risky on a business-critical machine or wander outside the scope of the test. That could spell some big legal trouble for you…
Besides exercising caution, the situational awareness stage is a major step in gaining more access to users and other hosts. So, don’t sleep on it.
And don’t sleep on these basic command either! It’s always good to know how to handle yourself without the use of 3rd party scripts. You never know when (and it is not a matter of “if” but “when“) these skills will come in handy.
I hope you had as much fun learning as I did putting this little article together. All the best to you and your cybersecurity journey!
