Initial Enumeration
Before kicking off any pentest, it can be beneficial to perform external reconnaissance of your target. This can serve many different functions, such as:
Validating information provided to you in the scoping document from the client
Ensuring you are taking actions against the appropriate scope when working remotely
Looking for any information that is publicly accessible that can affect the outcome of your test, such as leaked credentials
What Are We Looking For?
The table below highlights the "What" in what we would be searching for during this phase of our engagement.
Data Point
Description
IP Space
Valid ASN for our target, netblocks in use for the organization's public-facing infrastructure, cloud presence and the hosting providers, DNS record entries, etc.
Domain Information
Based on IP data, DNS, and site registrations. Who administers the domain? Are there any subdomains tied to our target? Are there any publicly accessible domain services present? (Mailservers, DNS, Websites, VPN portals, etc.) Can we determine what kind of defenses are in place? (SIEM, AV, IPS/IDS in use, etc.)
Schema Format
Can we discover the organization's email accounts, AD usernames, and even password policies? Anything that will give us information we can use to build a valid username list to test external-facing services for password spraying, credential stuffing, brute forcing, etc.
Data Disclosures
For data disclosures we will be looking for publicly accessible files ( .pdf, .ppt, .docx, .xlsx, etc. ) for any information that helps shed light on the target. For example, any published files that contain intranet site listings, user metadata, shares, or other critical software or hardware in the environment (credentials pushed to a public GitHub repo, the internal AD username format in the metadata of a PDF, for example.)
Breach Data
Any publicly released usernames, passwords, or other critical information that can help an attacker gain a foothold.
Where Are We Looking?
Resource
Examples
ASN / IP registrars
Domain Registrars & DNS
Social Media
Searching Linkedin, Twitter, Facebook, your region's major social media sites, news articles, and any relevant info you can find about the organization.
Public-Facing Company Websites
Often, the public website for a corporation will have relevant info embedded. News articles, embedded documents, and the "About Us" and "Contact Us" pages can also be gold mines.
Cloud & Dev Storage Spaces
Breach Data Sources
Finding Address Spaces
The BGP-Toolkit hosted by Hurricane Electric is a fantastic resource for researching what address blocks are assigned to an organization and what ASN they reside within.
Understanding where that infrastructure resides is extremely important for our testing. We have to ensure we are not interacting with infrastructure out of our scope.
In some cases, your client may need to get written approval from a third-party hosting provider before you can test. Others, such as AWS, have specific guidelines for performing penetration tests and do not require prior approval for testing some of their services. Others, such as Oracle, ask you to submit a Cloud Security Testing Notification.
These types of steps should be handled by your company management, legal team, contracts team, etc. If you are in doubt, escalate before attacking any external-facing services you are unsure of during an assessment. It is our responsibility to ensure that we have explicit permission to attack any hosts (both internal and external), and stopping and clarifying the scope in writing never hurts.
DNS
DNS is a great way to validate our scope and find out about reachable hosts the customer did not disclose in their scoping document. Sites like domaintools, and viewdns.info are great spots to start.
Sometimes we may find additional hosts out of scope, but look interesting. In that case, we could bring this list to our client to see if any of them should indeed be included in the scope.
Public Data
Social media can be a treasure trove of interesting data that can clue us in to how the organization is structured, what kind of equipment they operate, potential software and security implementations, their schema, and more.
Don't discount public information such as job postings or social media. You can learn a lot about an organization just from what they post, and a well-intentioned post could disclose data relevant to us as penetration testers.
Websites hosted by the organization are also great places to dig for information. We can gather contact emails, phone numbers, organizational charts, published documents, etc.
With the growing use of sites such as GitHub, AWS cloud storage, and other web-hosted platforms, data can also be leaked unintentionally.
It could mean the difference between having to password spray and brute-force credentials for hours or days or gaining a quick foothold with developer credentials, which may also have elevated permissions. Tools like Trufflehog and sites like Greyhat Warfare are fantastic resources for finding these breadcrumbs.
Overarching Enumeration Principles
Keeping in mind that our goal is to understand our target better, we are looking for every possible avenue we can find that will provide us with a potential route to the inside. Enumeration itself is an iterative process we will repeat several times throughout a penetration test. Besides the customer's scoping document, this is our primary source of information, so we want to ensure we are leaving no stone unturned. When starting our enumeration, we will first use passive resources, starting wide in scope and narrowing down. Once we exhaust our initial run of passive enumeration, we will need to examine the results and then move into our active enumeration phase.
Example Enumeration Process
We will practice our enumeration tactics on the inlanefreight.com domain without performing any heavy scans (such as Nmap or vulnerability scans which are out of scope).
We will start first by checking our Netblocks data and seeing what we can find.
From this first look, we have already gleaned some interesting info. BGP.he is reporting:
IP Address: 134.209.24.248
Mail Server: mail1.inlanefreight.com
Nameservers: NS1.inlanefreight.com & NS2.inlanefreight.com
For now, this is what we care about from its output. Inlanefreight is not a large corporation, so we didn't expect to find that it had its own ASN. Now let's validate some of this information.
We utilized viewdns.info to validate the IP address of our target.
Now let's try another route to validate the two nameservers in our results.
We now have two new IP addresses to add to our list for validation and testing.
Before taking any further action with them, ensure they are in-scope for your test.
For our purposes, the actual IP addresses would not be in scope for scanning, but we could passively browse any websites to hunt for interesting data.
We would check sites like LinkedIn, Twitter, Instagram, and Facebook for helpful info if it were real.
Using filetype:pdf inurl:inlanefreight.com as a search, we are looking for PDFs.
It is always best to save files, screenshots, scan output, tool output, etc., as soon as we come across them or generate them.
Next, let's look for any email addresses we can find.
Using the dork intext:"@inlanefreight.com" inurl:inlanefreight.com, we are looking for any instance that appears similar to the end of an email address on the website.
E-mail Dork Results
Browsing the contact page, we can see several emails for staff in different offices around the globe. We now have an idea of their email naming convention (first.last) and where some people work in the organization.
This could be handy in later password spraying attacks or if social engineering/phishing were part of our engagement scope.
Username Harvesting
We can use a tool such as linkedin2username to scrape data from a company's LinkedIn page and create various mashups of usernames (flast, first.last, f.last, etc.) that can be added to our list of potential password spraying targets.
Credential Hunting
Dehashed is an excellent tool for hunting for cleartext credentials and password hashes in breach data. We can search either on the site or using a script that performs queries via the API. Typically we will find many old passwords for users that do not work on externally-facing portals that use AD auth (or internal), but we may get lucky! This is another tool that can be useful for creating a user list for external or internal password spraying.
Also see Breachdirectory, leakpeek, checkleaked, (paid) snusbase
Starting AD enumaration: TTPs
We will start with passive identification of any hosts in the network, followed by active validation of the results to find out more about each host (what services are running, names, potential vulnerabilities, etc.).
Once we know what hosts exist, we can proceed with probing those hosts, looking for any interesting data we can glean from them. After we have accomplished these tasks, we should stop and regroup and look at what info we have. At this time, we'll hopefully have a set of credentials or a user account to target for a foothold onto a domain-joined host or have the ability to begin credentialed enumeration from our Linux attack host.
Identifying Hosts
We can use Wireshark and TCPDump to "put our ear to the wire" and see what hosts and types of network traffic we can capture. This is particularly helpful if the assessment approach is "black box."
Example: We notice some ARP requests and replies, MDNS, and other basic layer two packets
If we are on a host without a GUI (which is typical), we can use tcpdump, net-creds, and NetMiner, etc., to perform the same functions. We can also use tcpdump to save a capture to a .pcap file, transfer it to another host, and open it in Wireshark.
Depending on the host you are on, you may already have a network monitoring tool built-in, such as pktmon.exe, which was added to all editions of Windows 10.
As a note for testing, it's always a good idea to save the PCAP traffic you capture. You can review it again later to look for more hints, and it makes for great additional information to include while writing your reports.
ow let's utilize a tool called Responder to analyze network traffic and determine if anything else in the domain pops up.
Responder is a tool built to listen, analyze, and poison LLMNR, NBT-NS, and MDNS requests and responses.
As we start Responder with passive analysis mode enabled, we will see requests flow in our session. Notice below that we found a few unique hosts not previously mentioned in our Wireshark captures. It's worth noting these down as we are starting to build a nice target list of IPs and DNS hostnames.
Our passive checks have given us a few hosts to note down for a more in-depth enumeration. Now let's perform some active checks starting with a quick ICMP sweep of the subnet using fping.
Fping provides us with a similar capability as the standard ping application in that it utilizes ICMP requests and replies to reach out and interact with a host.
FPing Active Checks
Here we'll start fping with a few flags: a to show targets that are alive, s to print stats at the end of the scan, g to generate a target list from the CIDR network, and q to not show per-target results.
The command above validates which hosts are active in the /23 network and does it quietly instead of spamming the terminal with results for each IP in the target list.
Nmap Scanning
Now that we have a list of active hosts within our network, we can enumerate those hosts further.
With our focus on AD, after doing a broad sweep, it would be wise of us to focus on standard protocols typically seen accompanying AD services, such as DNS, SMB, LDAP, and Kerberos name a few.
The -A (Aggressive scan options) scan will perform several functions.
For our hosts.txt file, some of our results from Responder and fping overlapped (we found the name and IP address), so to keep it simple, just the IP address was fed into hosts.txt for the scan.
Looking at our results, we found several servers that host domain services ( DC01, MX01, WS01, etc.). Now that we know what exists and what services are running, we can poll those servers and attempt to enumerate users. Be sure to use the -oA flag as a best practice when performing Nmap scans. This will ensure that we have our scan results in several formats for logging purposes and formats that can be manipulated and fed into other tools.
We will most likely return to these results later for further enumeration, so don't forget about them. We need to find our way to a domain user account or SYSTEM level access on a domain-joined host so we can gain a foothold and start the real fun. Let's dive into finding a user account.
Identifying Users
If our client does not provide us with a user to start testing with (which is often the case), we will need to find a way to establish a foothold in the domain by either obtaining clear text credentials or an NTLM password hash for a user, a SYSTEM shell on a domain-joined host, or a shell in the context of a domain user account.
Kerbrute - Internal AD Username Enumeration
Kerbrute can be a stealthier option for domain account enumeration. It takes advantage of the fact that Kerberos pre-authentication failures often will not trigger logs or alerts.
We will use Kerbrute in conjunction with the jsmith.txt or jsmith2.txt user lists from Insidetrust.
We can point Kerbrute at the DC we found earlier and feed it a wordlist. The tool is quick, and we will be provided with results letting us know if the accounts found are valid or not, which is a great starting point for launching attacks such as password spraying
To get started with Kerbrute, we can download precompiled binaries for the tool for testing from Linux, Windows, and Mac, or we can compile it ourselves:
The newly created dist directory will contain our compiled binaries.
Usage:
Identifying Potential Vulnerabilities
The local system account NT AUTHORITY\SYSTEM is a built-in account in Windows operating systems. It has the highest level of access in the OS
A SYSTEM account on a domain-joined host will be able to enumerate Active Directory by impersonating the computer account, which is essentially just another kind of user account. Having SYSTEM-level access within a domain environment is nearly equivalent to having a domain user account.
There are several ways to gain SYSTEM-level access on a host, including but not limited to:
Remote Windows exploits such as MS08-067, EternalBlue, or BlueKeep.
Abusing a service running in the context of the
SYSTEM account, or abusing the service accountSeImpersonateprivileges using Juicy Potato. This type of attack is possible on older Windows OS' but not always possible with Windows Server 2019.Local privilege escalation flaws in Windows operating systems such as the Windows 10 Task Scheduler 0-day.
Gaining admin access on a domain-joined host with a local account and using Psexec to launch a SYSTEM cmd window
By gaining SYSTEM-level access on a domain-joined host, you will be able to perform actions such as, but not limited to:
Enumerate the domain using built-in tools or offensive tools such as BloodHound and PowerView.
Perform Kerberoasting / ASREPRoasting attacks within the same domain.
Run tools such as Inveigh to gather Net-NTLMv2 hashes or perform SMB relay attacks.
Perform token impersonation to hijack a privileged domain user account.
Carry out ACL attacks.
A Word Of Caution
Keep the scope and style of the test in mind when choosing a tool for use. If you are performing a non-evasive penetration test, with everything out in the open and the customer's staff knowing you are there, it doesn't typically matter how much noise you make. However, during an evasive penetration test, adversarial assessment, or red team engagement, you are trying to mimic a potential attacker's Tools, Tactics, and Procedures. With that in mind, stealth is of concern. Throwing Nmap at an entire network is not exactly quiet, and many of the tools we commonly use on a penetration test will trigger alarms for an educated and prepared SOC or Blue Teamer. Always be sure to clarify the goal of your assessment with the client in writing before it begins.
Last updated
