Initial Enumeration
Notes taken from the AD Enumeration & Attack module from HTB Academy
External Recon and Enumeration Principles
External reconnaissance can be useful at the beginning of an engagement or if get stuck with no foothold in the internal environment.
Basic OSINT can be useful in these particular cases:
Validating the scope of our engagement (making sure that all assets that we are about to target are not third-party).
Find credentials or others information that can be leverage to gain a foothold or perform a lateral movement into the internal network.
Here are some interesting information to collect when conducting external reconnaissance:
IP ownership;
Cloud infrastructures;
Security defense implemented such as AV/EDR/SIEMS, etc.;
Domain, subdomain & domain registrars;
Leaks credentials and secret keys, email & usernames patterns.
During an Penetration Testing engagement, all the assets included in the scope should be owned by our client, unless specified otherwise. Indeed, big companies might have their own DNS infrastructure, but it is more likely that smaller companies rely on third-parties services such as Google, Cloudflare, Azure, etc.
The BGP Toolkit is a nice online tool to identify who is the owner of an IP space.
Many tools and strategies can be leveraged to perform external recon:
Google Dorking;
Social media, companies websites and job posting inspection;
Github commit and source code inspection;
Information disclosure in document metadata;
Online tools such as GreyHatWarfare, ViewDNS.info, TruffleHog, grep.app, ARIN (or RIP for Europe), Dehashed, HaveIBeenPawned, etc.
Initial Enumeration of the Domain
Many set ups are possible to conduct an internal engagement. Depending of the will of the client, we might or not have credentials for a low privilege users in the domain. The client can also ask to start the engagement completely blinded from an external attacker perspective.
We might have to enumerate the domain from a Linux or Windows host depending of the set up chosen to perform the engagement. Being able to enumerate from both Windows and Linux is essential to conduct our activities.
Here are listed examples of many possible set up that we could encounter:
Physically at the client office with a workstation
A VM machine deployed in the client environment that call back to a jump server owned by the testers. Then, SSH into the jump server.
Use of a VPN and a Citrix instance.
A Linux VM from the cloud whose IP is whitelisted by the client.
VPN access to their internal network.
Physical device plugged into a ethernet port that connect back to the attacker host.
Hosts identification
This steps implies to sniff the traffic and inspect which hosts are alive and what communication protocols are in use (ex: MDNS, LLMNR, Net-Bios, etc). Many tools can be used to sniff traffic and look for the network traffic such as WireShark, net-creds, Responder, and TCPdump.
We can use Responder in Analyze mode (-A
) to only monitor LLMNR/NetBIOS traffic without sending poisoned packets. Indeed, some legacy protocols can be identified such as LLMNR, Net-Bios and MDNS.
Fping
Fping can also be used to identify live hosts in case ICMP packets are allowed. It is a way faster than traditional ping when it's time to send ICMP requests to multiple hosts.
Services identification
Once we have discovered a bunch of lived hosts, the next steps is to enumerate open ports and services hosted on these systems.
In my personal opinion, I prefer to use masscan before nmap to enumerate open ports in a subnet range since it is a way faster, than nmap. I am used to select specific ports to scan associated with most common services.
Nmap can be used later one to get the exact services type and version hosted on open ports identified by masscan. The objective is to limit the number of hosts and ports scanned by nmap since it is very slow and somewhat noisy.
Legacy OS
Nmap can point to assets with legacy OS. It worth checking if those assets are vulnerable to publicly known vulnerability such as Eternal Blue, MS-07, etc.
When scanning we have to be careful to not cause instability and put assets offline or unusable.
Identify Usernames
The first objective is to identify valid credentials to get access, at least, to a low privilege domain account. We can also gain a SYSTEM account by exploiting a potential vulnerability. Having SYSTEM on a domain-joined account give us the same abilities than having credentials of a domain users.
We can leverage Kerbrute and a list of statistically likely usernames (InsideTrust) with the information we collected through OSINT to identify valid usernames. A Kerbrute module is also integrated in CrackMapExec (see here).
The list of valid usernames can thus be used to perform a password spraying attack against one or multiple services. See here.
Last updated