R&E #03: Host Enumeration

What types of information do we need to gather from the target system?

Today’s post will be about host enumeration. It is a crucial step in providing a good foundation for getting to know our environment. Learning the environment and getting a general feel for our surroundings is beneficial to both sides of the aisle, benefitting the Offensive and the Defensive team. Those seated on the Offensive team (Penetration Testers, Red Team Operators, hackers, etc.) will find value in being able to scan their hosts and the environment to learn what vulnerable services and machines can be exploited. Whereas the Defensive team (System Administrators, SOC Analysts, etc.) can use the information to diagnose issues, secure hosts and services, and ensure integrity across the network. 

Once we have initial access to the system through some command shell, just knowing where to begin searching the system for information can be difficult.  Starting to search manually without any clear guidance or specific goals about what information you’re looking for will waste a lot of time during this phase. You may even feel overwhelmed or end up collecting only a tiny amount of useful data. Trust me — in my early days learning cybersecurity, I went through exactly this situation. After gaining control of a Windows host, I wandered around the system aimlessly, blindly trying to “find something” without knowing what questions I was supposed to answer. It cost me a huge amount of time before I could even move on to the post-exploitation stage. 

So, the goal of host enumeration is to provide an overall picture of the target host, its environment, and how it interacts with other systems across the network. Keeping this in mind, the first question that we might find ourselves coming to is: “How do we know what to look for?”

To answer this question, we need to have a basic understanding of all the different types of information available to us on a system. Okay, I’ll use an example based on a Windows host just like I did before. (The example below focuses specifically on Windows, so it may not be applicable to other types of systems. Also, the examples here only cover a small portion of what you can find on a Windows system — they’re meant to help you understand the concept, not serve as a full checklist). The types of information that we would be looking for can be broken down into the following categories:

  • General System Information: Contains information about the overall target system like hostname, OS-specific details (name, version, configuration,…), installed hotfixes/patches for the system.
  • Networking Information: Contains networking and connection information for the target system and system(s) to which the target is connected over the network. For instance, host IP address, available network interfaces, accessible subnets, DNS server(s), known hosts, and network resources.
  • Basic Domain Information: Contains Active Directory information regarding the domain to which the target system is connected.
  • User Information: Contains information regarding local users and groups on the target system such as environment variables, currently running tasks, scheduled tasks, and known services.

As I mentioned above, this is only a small portion — it is not a complete list of everything on a system. These small sections simply give us a starting point to build a solid enumeration methodology. After reading the example above, you should now have a clearer picture of what you need to look for on a host, right? To keep ourselves on target during enumeration, we want to try and ask ourselves some of the following questions:

  • What system information can we gather from the machine we’ve compromised?
  • Is this host interacting with or connected to any other systems within the organization’s network?
  • For the user account we’ve gained access to — what can we do with this user, and what is this user allowed to do on the system?

Think of these questions as a way to provide structure to help us develop a sense of situational awareness and a methodology for testing. Doing so gives us a clearer idea of what we are looking for and what information needs to be filtered out or prioritized during a real-life engagement.

Why do we even need these system information?

In the previous section, we discussed what information can be gathered from a system during enumeration and what we should be aware of during our search. I know some of you may ask yourselves why we even need this information (you’re not alone — I used to ask myself the exact same thing). 
As stated beforehand, our goal with host enumeration here is to use the information gained from the target to provide us with a starting point and guide for how we wish to attack the system. Ok, I’ll continue with an example: you’ve gained control of a user account named rick, and this account is a low-privileged user. Our next task is to escalate our privileges, right?
To do that, we need to understand the surrounding environment — this is where we start answering questions such as:

  • Which groups does this user belong to? Maybe we’re lucky and the user is in the local admin group?
  • What permissions does this user currently have? Did someone accidentally assign overly high privileges?
  • What resources within the company or organization can this user access?
  • Are there any tasks or services running under this rick user account?

Remember that this only partially encompasses all the questions we can ask ourselves to reach our intended goal but simply a tiny subset of possibilities. Without thinking things through and failing to follow any guided structure while performing enumeration, we will struggle to know if we have all the required information to reach our goal.

I’ve been in a situation where I kept looking for vulnerabilities on a machine that was almost fully patched. I spent hours trying to exploit Windows host vulnerabilities, running scripts and payloads, yet everything kept failing. It wasn’t until I accidentally noticed a misconfiguration in a service path (an unquoted service path) that everything clicked. 

 

Hands-on

We’ve been talking non-stop for a while, so let’s jump into some hands-on practice. I’ll start with a few Windows techniques first. These are just some of the methods used in this post — I’ll continue adding more steps to my GitHub. And if you want to explore Linux techniques as well, well… just keep an eye on my GitHub. That’s where I store commonly used commands. I’ll be updating it continuously, so if you ever need a place to look up commands, feel free to check it out. (Well, my GitHub hasn’t been updated much yet — it’s still pretty rough because the last months of the year I often get extremely lazy. There aren’t many ideas popping into my head; I just keep wishing for the holidays :v. But it’s fine — once this period passes, my brain will get back to normal. I’ll be much more active with the GitHub then, so stay tuned!)

Windows CMD provides a one-stop shop for information via the systeminfo command. It is excellent for finding relevant information about the host, such as hostname, IP address(es), if it belongs to a domain, what hotfixes have been installed, and much more. This information is super valuable for a sysadmin when trying to diagnose issues.

But remember: on professional systems, commands like these are always on the monitoring list. If you keep running them over and over, it’s basically like telling the defender team, “Hey, I’ve already compromised your system.” So try to do everything within just a few commands, and save the results right away so you can use them later.

In addition to the host information provided above, let us quickly look at some basic network information for our target. A thorough understanding of how our target is connected and what devices it can access across the network is an invaluable tool in our arsenal as an attacker. To gather this information quickly and in one simple-to-use command, Command Prompt offers the ipconfig utility. The ipconfig utility displays all current TCP/IP network configurations for the machine.

Ipconfig is a highly versatile command for gathering information about the network connectivity of the target host; however, if we need to quickly see what hosts our target has come into contact with, look no further than the arp /a command. The arp utility effectively displays the contents and entries contained within the Address Resolution Protocol (ARP) cache. We can also use this command to modify the table entries effectively.

Now that we have some basic host information to get us started, we should further understand our current compromised user account. One of the best command line utilities to do so is whoami

Whoami allows us to display the user, group, and privilege information for the user that is currently logged in. In this case, we should run it without any parameters first and see what kind of output we end up with.

As previously mentioned, we can also use whoami to view our current user’s security privileges on the system. By understanding what privileges are enabled for our current user, we can determine our capabilities on our target host. Let us try running whoami /priv from our compromised user account.

From the output below, we only seem to have access to a basic permission set, and most of our options are disabled. This falls within the limitations of a standard user account provisioned on the domain. However, if there were any misconfigurations in these settings or the user was provided any additional privileges, we could potentially use this to our advantage in trying to escalate the privileges of our current user.

On top of having a thorough understanding of our current user’s privileges, we should also take some time to see what groups our account is a member of. This can provide insight into other groups our current user is a part of, including any default groups (built-ins) and, more importantly, any custom groups to which our user was explicitly granted access. To view the groups our current user is a part of, we can issue the following command: whoami /groups.

After investigating our current compromised user account, we need to branch out a bit and see if we can get access to other accounts. In most environments, machines on a network are domain-joined. 

Net user allows us to display a list of all users on a host, information about a specific user, and to create or delete users.

In addition to user accounts, we should also take a quick look into what groups exist across the network. In the previous section, we discussed very heavily into groups that our user is a member of; however, we also have the capability from our current host to view all groups that exist on our host and from the domain. We can achieve this by utilizing the net group and net localgroup commands.

Net Group will display any groups that exist on the host from which we issued the command, create and delete groups, and add or remove users from groups. It will also display domain group information if the host is joined to the domain. Keep in mind, net group must be run against a domain server such as the DC, while net localgroup can be run against any host to show us the groups it contains.

Previously, we honed in on what our current user has access to in terms of the host locally. However, in a domain environment, users are typically required to store any work-related material on a share located on the network versus storing files locally on their machine. These shares are usually found on a server away from the physical access of a run-of-the-mill employee. Typically, standard users will have the necessary permissions to read, write, and execute files from a share, provided they have valid credentials. 

One way of doing so involves using the net share command. Net Share allows us to display info about shared resources on the host and to create new shared resources as well.

 Ideally, if we were to find an open share like this while on an engagement, we would need to keep track of the following:

  • Do we have the proper permissions to access this share?
  • Can we read, write, and execute files on the share?
  • Is there any valuable data on the share?

Using all the information and examples provided above, we have extracted a significant amount of information from our host and its’ surroundings. From here, depending on our access, we can elevate our privileges or continue to move towards our goal.

This is just a quick look at how CMD can be used to gain access and continue an assessment with limited resources. Keep in mind that this route is quite noisy, and we will be noticed eventually by even a semi-competent blue team. As it stands, we are writing tons of logs, leaving traces across multiple hosts, and have little to no insight into what their EDR and NIDS was able to see.

There’s one more note for you: in a real-world environment, it’s very unusual for a client machine in an organization—especially one not belonging to the IT department—to be using CMD. For IT staff, this might look normal, but for users in other departments like HR, there’s no reason for them to use CMD commands at all. This is often a red flag for the defender team to intervene and investigate. In many organizations, within a domain environment, they even disable CMD and PowerShell on client machines.

However, security isn’t really a major concern for many small and medium-sized businesses. I used to work at a mid-sized organization where all computers joined the domain, but the way they managed policies and hardened their environment was extremely weak. They even added several users to the local admin group on their machines just so certain software could run — cracked software… :v. It’s hard to blame them, because the IT in charge back then was just a help desk technician. I had to rebuild the policies and procedures, and it was difficult to get the help desk team to agree with the new workflow, since they only cared about getting things done quickly. That was a real example from the place I used to work. If at that time you happened to compromise an account that the help desk added to the local admin group, wouldn’t everything become much easier?

Alright, we’ll wrap up this section for now. If you need the commands, check out my GitHub — I’ll try to update the repo to make it more polished and professional, maybe after the holidays are over 🙂