100+ Enumeration Techniques for Penetration Testing: From OSCP Essentials to Advanced Offensive Security

Let me share at least 100 enumeration techniques relevant to OSCP, categorized by target type. I will include tools, commands, explanations, and real-world or OSCP-like challenge references where applicable. I'll also go beyond OSCP to include broader enumeration techniques for when you're... you know... stuck :)

Network & Infrastructure Enumeration

Network enumeration involves probing networks to discover hosts, open ports, services, and misconfigurations. It’s a critical first step in penetration testing to map the attack surface and find potential entry points. Major breaches like the 2017 Equifax incident were aided by aggressive network enumeration that revealed vulnerable services. Below are common network-level enumeration techniques and examples:

• Ping Sweep (ICMP Discovery) – Identifying live hosts by sending ICMP Echo requests across an IP range. For example, use nmap -sn 10.10.0.0/24 to ping a subnet and list responsive IPs. This helps map active machines in the target network. (In some environments, ping may be blocked, so alternative host discovery like ARP scanning may be used.)
• ARP Scanning – Enumerating hosts on a local network by sending ARP requests (useful when ICMP is filtered). For example, arp-scan -l will list all devices on the local LAN segment. This technique leverages the fact that ARP does not require routable traffic and can discover hosts that might not respond to ping.
• Traceroute Mapping – Mapping the route and hops to the target to identify intermediary devices or firewall rules. Using traceroute (Linux) or tracert (Windows) can reveal network infrastructure (routers, gateways) and may indicate filtering at certain hops. This can inform which network segments or devices might be reachable.
• Full TCP Port Scan – Scanning all 65,535 TCP ports on a host to find all listening services. For example, sudo nmap -Pn -p- -T4 -n 10.10.10.5 -oN full_tcp.txt does a full connect scan on all ports. This comprehensive scan ensures no open service is missed during enumeration. (On OSCP exams and real engagements, thorough port scanning often reveals services that standard scans might skip.)
• UDP Port Scan – Scanning common UDP ports, since some services (DNS, SNMP, TFTP, etc.) use UDP. For example, nmap -sU --top-ports 20 10.10.10.5 -oN udp_top20.txt checks the top 20 UDP ports. UDP scanning is slower and less reliable, but important for finding “hidden” UDP services (e.g. SNMP or NTP) that can yield useful info.
• Service Version Detection – After finding open ports, querying services to determine software/version. nmap -sV -p 80,443,22 10.10.10.5 -oN versions.txt will grab banners and service info on those ports. Knowing exact versions (e.g. “Apache httpd 2.4.49”) allows a tester to research known vulnerabilities or default credentials. Tools like Netcat or Telnet can also manually grab banners (e.g. nc -nv 10.10.10.5 21 to get an FTP banner).
• OS Fingerprinting – Inferring the target OS by analyzing network responses (TTL, window size, etc.). Nmap does this automatically (-O flag) to guess the OS (e.g. “Windows Server 2019 or 2022”). This helps tailor the enumeration (for instance, focusing on SMB for Windows targets or NFS for Unix).
• DNS Zone Transfer – Querying a DNS server for its zone records to dump hostnames. For example, using dig axfr @ns1.target.com target.com attempts a zone transfer. If misconfigured, this can retrieve all DNS entries (subdomains, IPs) for the domain, revealing a map of servers. (In OSCP-like labs, a successful zone transfer might unveil internal hostnames or hidden services.)
• DNS Brute-Forcing (Subdomain Enumeration) – Attempting to find subdomains by guessing names. Tools like dnsrecon or Gobuster (gobuster dns -d target.com -w subdomains.txt) try common subdomain names (admin, mail, dev, etc.). This often uncovers additional targets (e.g. dev.target.com) that might not be obvious but are in scope. For example, a company’s forgotten test.target.com subdomain could run an outdated app.
• Reverse DNS Lookup – Enumerating PTR records to map IP ranges to hostnames. For instance, using nmap -sL 10.10.10.0/24 will perform a reverse lookup on a range. This can identify naming patterns (like DC01.target.local for an IP, indicating an Active Directory domain controller) and uncover hosts that weren’t directly given.
• NetBIOS/LDAP Discovery – In internal networks, using NetBIOS or LDAP queries to list hosts. Running nmblookup -A 10.10.10.5 can return the NetBIOS name, workgroup/Domain, and logged-in user for a Windows host. Similarly, unauthenticated LDAP queries (if allowed) with tools like ldapsearch can reveal domain info. These methods enumerate hostnames and domain membership, guiding targeting for Windows networks.
• SNMP Enumeration – Querying SNMP (UDP 161) for system information. If a device has SNMP enabled with a default or known community string (e.g. “public”), an attacker can retrieve a wealth of data. For example, snmpwalk -v1 -c public 10.10.10.5 1.3.6.1.2.1.1 will dump system info (system description, uptime, contacts). Tools like onesixtyone can brute-force SNMP community strings. SNMP data often includes network device configurations, ARP tables, running processes, or even plaintext credentials. (Real-world example: SNMP enumeration has revealed router configs with embedded passwords.)
• SMTP User Enumeration – Using SMTP service commands to reveal valid email users on a mail server. Some SMTP servers respond differently to the VRFY or EXPN commands for valid vs. invalid usernames. For example, using smtp-user-enum tool or manual telnet: VRFY jdoe might confirm if “jdoe” is a valid user. This technique can harvest a list of usernames for use in password attacks. Example: smtp-user-enum -M VRFY -U users.txt -t mail.target.com will try a list of names and report which are valid. (In one OSCP-like challenge, enumerating SMTP revealed a valid user that later enabled an SSH brute-force with that username.)
• NFS Enumeration – If Network File System (NFS, port 2049) is open (common on Unix/Linux targets), listing NFS exports can reveal shared directories. Running showmount -e 10.10.10.5 shows exported file shares and which clients can mount them. An example outcome could be an export like /backup *(rw,no_root_squash), meaning it’s writable by any host and root on the client isn’t squashed – a potential vector to upload an exploit and execute as root. Enumerating NFS shares is crucial as misconfigurations can lead to easy access to sensitive files or remote code execution.
• RPC Services (Unix) – Enumerating RPC binders (port 111 on Unix). Using rpcinfo -p 10.10.10.5 lists RPC programs (NFS, NIS, mountd, etc.) and their port numbers. This can uncover services running on high ports that weren’t evident (for example, an older NIS (YP) service for directory information). Knowing RPC services helps target attacks (e.g., if an old NIS is running, one might attempt to grab password hashes from it).
• Brute-Force Default Credentials – While more of a password attack than pure enumeration, trying default or common credentials on services can be considered part of info gathering. For example, attempting an SSH login with default combos or an FTP login as “anonymous” (no password) can reveal access. In many OSCP scenarios, an FTP service might allow anonymous:anonymous login, yielding a file listing (and sometimes sensitive data or hints). Similarly, default creds on Tomcat (tomcat:tomcat) or MySQL (root with no password) would quickly enumerate access to those services. Always check for well-known defaults to enumerate accessible functionality (but ensure this is done under authorized conditions).

These network and infrastructure techniques lay the groundwork for deeper enumeration. For instance, the widespread WannaCry attack leveraged network scanning to identify Windows SMB shares and then propagated via the SMB vulnerability. By systematically enumerating ports and services, a penetration tester ensures no potential entry-point is overlooked before moving to exploitation.

Web Application Enumeration

Web app enumeration focuses on mapping out websites, web services, and application components to find hidden content or functionality. Many OSCP machines and real-world targets hide interesting clues in web servers, so thorough web enumeration is key. This includes discovering directories/files, identifying technologies, and enumerating users or parameters. Below are techniques specific to web applications:

• URL and Directory Brute-Forcing – Discovering hidden pages or directories by trying common names. Tools like Gobuster, DirBuster, or feroxbuster automate this. For example: gobuster dir -u https://10.10.10.5 -w wordlist.txt -x php,txt,html -o gobuster.txt will fuzz for directories and files with .php, .txt, or .html extensions. This often uncovers admin panels (e.g. /admin/), config files (e.g. config.php), backups (.bak files), or other functionality not linked on the main site. Case: A hidden /backup/ directory might contain old source code or database dumps – gold for an attacker.
• File Extension and Backup Hunting – Many web servers have backup files or old versions accessible. Enumerating common extensions like .bak, .old, .zip, or ~ files can yield results. For instance, after finding admin.php, one might try admin.php.bak or admin.old. A famous real-world example was finding config.php~ files in websites due to editors leaving backups – revealing database credentials. Using DirBuster/Dirsearch with an extended wordlist that includes such variants can automate this search.
• Subdomain Enumeration (Web) – Besides DNS brute forcing, some web apps host functionality on subdomains (e.g. api.target.com or dev.target.com). Using web tools or services (like Sublist3r, Amass) to enumerate subdomains can reveal additional web applications. For example, running amass enum -d target.com might find a staging.target.com site running a less secure version of the app. These findings broaden the scope of attack surface on the web front.
• Website Content Crawling – Automatically crawling a website to map all links and content. Tools like Burp Suite’s Spider or OWASP ZAP can enumerate all reachable pages. This can reveal hidden pages that directory brute-forcing might miss (especially if they’re only linked through forms or scripts). Crawling also helps identify parameters and inputs for later testing.
• Technology Stack Fingerprinting – Identifying the frameworks, languages, and technologies used by the web app. Knowing the stack helps tailor enumeration (and exploitation). Tools like WhatWeb or Wappalyzer can detect CMS (WordPress, Joomla), server (Apache, IIS), scripting languages (PHP, ASP.NET), JavaScript libraries, etc., by examining HTTP headers and page content. For example, whatweb https://10.10.10.5 might reveal “WordPress 5.8” – cue to run WordPress-specific enumeration next.
• CMS and Plugin Enumeration – If the site runs a CMS or well-known platform, use specialized tools. For WordPress, WPScan can enumerate users, plugins, and themes (wpscan --url https://site -e u,p). This might list usernames (for login brute force) and outdated plugins (with known exploits). Similarly, for Drupal or Joomla, tools and manual checks can list module versions. Enumerating these components is vital because a single outdated plugin (e.g. an old WordPress plugin) can be a foothold.
• Parameter and Fuzzing Enumeration – Many web apps have hidden parameters or API endpoints. Using Burp Intruder or ffuf to fuzz parameter names and values can uncover undisclosed functionality. For example, fuzzing an API endpoint with different parameters (?debug=1, ?test=true, etc.) might trigger debug pages or verbose errors. Another example is fuzzing numeric parameters (ID values) to see if data can be accessed sequentially (insecure direct object references). This process enumerates how the application handles inputs and identifies potential vulnerabilities.
• Error Message Analysis – Intentionally provoking errors to glean information. For instance, adding a single quote (') to a URL parameter may produce a SQL error revealing the database type or query structure. Similarly, visiting a non-existent page might show a stack trace with file paths. These errors can divulge server paths, database schemas, or code snippets. Enumerating these clues guides the tester toward likely vulnerabilities (e.g. if you see “SQLException” you know SQL injection testing is worthwhile).
• User Account Enumeration via Web Interfaces – Many web apps inadvertently reveal valid usernames through subtle differences in responses. For example, a login page might respond “Invalid username” vs. “Incorrect password” – allowing an attacker to enumerate which usernames exist. Similarly, a “Forgot Password” function might say “Email sent” for a valid account versus “Email not found” for an invalid one. By automating attempts with a list of common usernames or emails, testers can harvest a set of valid accounts. Example: An OSCP-like web challenge might have a registration page that prevents choosing an existing username – testing a few common names could reveal which are taken (valid). This list can then be used for credential stuffing or password guessing.
• Session and Cookie Inspection – Inspecting cookies and session tokens for clues. Sometimes cookies are named in revealing ways (e.g. SESSIONID vs AUTH_TOKEN vs JWT), indicating the mechanism in use. Decoding Base64 or JWT tokens can enumerate user info or configuration (for example, decoding a JWT might reveal the algorithm and claims, which could be manipulated if misconfigured). Even without vulnerabilities, understanding session implementation is key enumeration data for later potential exploitation (like forging cookies if the app is vulnerable).
• Robots.txt and Sitemap Discovery – Checking robots.txt for disallowed paths and any sitemap.xml files. These often enumerate sensitive or private paths that the site owner didn’t want search engines to crawl, such as /admin or /test/. While not intended for attackers, they provide a handy list of URLs to investigate. Example: robots.txt might list /backup/ or /old/ directories, which could contain old versions of the site or sensitive files.
• SSL/TLS Certificate Inspection – If the site uses HTTPS, examining the SSL certificate for domain names (SANs) can enumerate subdomains or internal hostnames. For instance, a certificate might be issued to *.target.com and also list internal.target.local in its Subject Alternative Names. This hints at an internal domain that could be targeted if reachable. Tools like openssl (openssl s_client -connect target.com:443) or sslscan can retrieve certificate details. Additionally, running sslscan or Nmap SSL scripts can enumerate supported ciphers and potential SSL vulnerabilities (like Heartbleed).
• Virtual Host Enumeration – Enumerating name-based virtual hosts configured on the same server. If a single IP hosts multiple websites, using a tool like Gobuster vhost mode or ffuf -H "Host: FUZZ.target.com" with a subdomain wordlist can identify other vhosts. For example, discovering that staging.target.com resolves to the same IP as www.target.com indicates a likely virtual host – visiting it might show a different site (like a dev version). This technique finds sites that DNS enumeration alone might miss (especially if the DNS records aren’t public).
• Web Server Information Disclosure – Sending specific requests to trigger server-info pages or default files. For example, Apache’s default mod_status page at /server-status (if enabled and not access-controlled) will display server performance data and request info. Visiting /server-status?full=true could list current requests including URLs being accessed by users. Similarly, checking for /phpinfo.php might yield a PHP configuration page exposing internal paths, usernames, and configuration. Enumerating these default endpoints (with tools or manually) can leak configuration details useful for later exploitation.
• Client-Side Script Analysis – Reviewing JavaScript files for hidden endpoints, credentials, or clues. Often, front-end code contains API endpoints or developer comments. By enumerating all .js files (through crawling or guesswork) and inspecting them, testers can find references to admin functions or undocumented API calls. For example, a JavaScript file might contain an AJAX call to /api/getUserList – which you can then try to access directly. This form of enumeration bridges into code review and often reveals functionality not visible in the UI.
• Query Parameter Discovery – Using wordlists to fuzz query parameters on known scripts. If a site has a page search.php, one might fuzz common parameter names like ?file=, ?id=, ?user= to see if any are accepted and change behavior. This is a way to enumerate how the server-side script might be working. For instance, fuzzing might reveal that page.php?lang=EN is a parameter, hinting the site might be including language files (which could lead to LFI if misused).
• CMS Default Pages – Checking for default installation pages (like wp-admin/install.php for WordPress or setup.php for phpMyAdmin). Enumerating these known default paths can indicate if an installation is incomplete or misconfigured. For example, finding a /phpmyadmin/ login page suggests the MySQL admin interface is present (which might have a default password or be accessible). Always probe common admin interfaces: /administrator/ (Joomla), /admin.php, /login, etc., and note their behavior.

Effective web enumeration often leads to critical findings. For instance, directory brute-forcing has uncovered hidden admin portals on real pentests, and subtle differences in web responses have allowed attackers to enumerate user accounts. By methodically mapping the web application, a tester maximizes the chances of finding weak points that can be exploited later.

Windows Host & Service Enumeration

Windows targets require enumeration both over the network (unauthenticated, prior to any access) and on the host itself (once you’ve gained a foothold). Windows systems often expose services like SMB, RPC, and WinRM that can leak information even before login. Once on a Windows host, enumerating system info and configuration is crucial for privilege escalation. This category covers Windows enumeration in two phases: remote service enumeration and local enumeration after access.

Windows Network Service Enumeration (SMB/RPC/WinRM)

• SMB Share Enumeration – Scanning for open SMB shares and their contents. Using tools like Nmap or smbclient to list shares can reveal information. Example: smbclient -N -L //10.10.10.5/ (with no password) attempts a null session to list available shares. Similarly, enum4linux -a 10.10.10.5 will try multiple techniques (NetBIOS, SMB, RPC) to enumerate users, shares, and policies. Unprotected shares might allow read access – for example, a share “Profiles$” could let you download user data, or a share “IPC$” (with a null session) might allow certain queries. In many OSCP-like exercises, enumerating SMB shares yields important files (like configuration files containing credentials or scripts).
• SMB Null Session & User Enumeration – Exploiting the historical “null session” access on IPC$ to gather information. A null session is an anonymous connection with no credentials. Using rpcclient (rpcclient -U "" -N 10.10.10.5) one can run commands like enumdomusers or queryaliasmem to list users and group memberships on the target (especially if it’s a Domain Controller). In older Windows or misconfigured systems, null sessions can retrieve a list of all usernames on the system, which is extremely valuable for password attacks. Even on newer systems, using RID cycling (iterating through user RID numbers) with tools like lookupsid.py (Impacket) or Metasploit modules can enumerate users one RID at a time. Real-world: Attackers have often used SMB null sessions to obtain user lists and then brute-force accounts – one reason modern Windows tightened this by default.
• NetBIOS Name Service Enumeration – Querying NetBIOS over UDP (port 137) for host information. Running nbtscan 10.10.10.0/24 or nmblookup -A 10.10.10.5 can return the hostname, logged-in username, and workgroup/Domain of a Windows host. For example, the result might show a logged in user name like <machine> <00> UNIQUE and the domain. This is useful in internal networks to map out hostnames and identify interesting systems (e.g., seeing a host with a name DC01 indicates a domain controller).
• SMB Vulnerability Scanning – Leveraging Nmap NSE scripts or tools to find known SMB vulns. For example, nmap --script smb-vuln* -p 445 10.10.10.5 checks for vulnerabilities like MS17-010 (EternalBlue) or SMB signing not required. While this crosses into vulnerability scanning, it’s part of enumeration to flag potential exploits. Additionally, enum4linux outputs password policy info (max password age, complexity requirements) which can guide password attacks. Enumerating SMB thoroughly ensures you don’t miss a critical misconfig (like SMB signing disabled, allowing relay attacks, or anonymous share access).
• WinRM and RPC Enumeration – Checking if WinRM (Windows Remote Management, default port 5985/5986) is enabled. While WinRM itself won’t give info without credentials, knowing it’s open means if creds are obtained you can use a tool like Evil-WinRM to get a shell. For RPC (TCP 135 and high ports), using rpcclient or PowerShell (if on a Windows system) with Get-WmiObject can enumerate services or users remotely if permissions allow. For instance, rpcclient can use a null or guest session to enumerate srvinfo (server info) or enumprinters (list print server info) which sometimes discloses drivers or user info. These techniques often require at least guest access, but they round out Windows remote enumeration by touching non-SMB avenues.
• WMI and SMB2/3 Protocol Details – (Advanced) If you have credentials or are on a domain, using WMI queries remotely to enumerate installed software or patches (wmic /node:target process list etc.) is possible. Additionally, enumerating supported SMB dialects or security settings (like SMB signing, NTLMSSP details) with tools or packet captures can hint at possible downgrade attacks or relay potential. For example, Responder in analysis mode (responder -I eth0 -A) will listen and report if SMB signing is off on the network. This kind of network-level Windows enum is more situational but important in internal tests (to prepare for SMB relay or capture attacks).

Windows Local Enumeration (Post-Exploitation)

Once you have a foothold on a Windows machine (e.g., a low-privilege shell or RDP access), you should enumerate the system thoroughly to find paths to privilege escalation or sensitive data. Key local enumeration techniques include:

• System Info & OS Version – Gather detailed OS info with built-in commands. systeminfo will list OS name, version, patch level, hotfixes, and system architecture. The output can be compared against known exploit databases (e.g., searchsploit) for kernel exploits or missing patches. For instance, if systeminfo shows Windows 7 SP1 with no recent patches, you might try exploits like MS17-010 (EternalBlue) or Hot Potato for privilege escalation. Additionally, ver and wmic os get version can provide OS build info. This enumeration tells you what exploits or misconfigurations to look for (older OS often means more known vulnerabilities).
• User and Group Enumeration (Local) – Identify who you are and what privileges you have. The whoami /all command shows your current user and security groups, along with any special privileges (like SeImpersonatePrivilege). For example, if whoami /all reveals you are in the “Distributed COM Users” group or have SeImpersonatePrivilege, that hints at specific escalation techniques (e.g., JuicyPotato exploit for SeImpersonate). Also, net user (or net user <username>) lists local users and group membership, which might show an unprivileged account that is actually a member of the Administrators group due to misconfigurations. Enumerating users/groups helps target which accounts or privileges to abuse.
• Running Processes and Services – Listing running processes (tasklist or powershell Get-Process) and services (sc query state= all > services.txt) to find potential escalation points. For example, a service running as SYSTEM that’s misconfigured (unquoted path or insecure file permissions) could be exploited. You might spot a process like OpenVPN.exe or an antivirus agent – knowing these can guide you (maybe the OpenVPN service has an easy privilege escalation). Unquoted Service Paths in Windows services are a classic find: using wmic service get name,displayname,pathname,startmode and looking for paths with spaces and no quotes can identify a service where you could place an executable. If you see something like C:\Program Files\Some Folder\Service.exe unquoted, and you have write access to C:\Program Files\Some.exe, you could escalate by inserting a malicious Some.exe.
• Scheduled Tasks and Autoruns – Enumerating scheduled tasks (schtasks /query /fo LIST /v) can reveal tasks running with high privileges. If a scheduled task runs a script or binary in a writable path, that’s an escalation vector. Also, check Startup folders and autorun registry keys for programs that launch at boot. Tools like autoruns (Sysinternals) or manual registry checks (reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run) show what executables run at startup. If any of those are writable by the current user, you can replace them and wait for a privileged execution (or reboot trigger if possible).
• Registry Enumeration – Searching the Windows Registry for sensitive info. Common checks: look at HKLM\SAM and HKLM\Security (if you can access, usually not without SYSTEM), and HKLM\SOFTWARE for product keys or credentials. A famous example is checking HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon for values DefaultUsername/Password which sometimes store autologon creds in plaintext. Also, in domain environments, Group Policy Preferences might store passwords in registry or files (if the SYSVOL share is accessible, checking for Groups.xml). Enumerating registry ACLs can also show if any interesting keys are writable (though less common for privesc).
• Stored Credentials & Password Hunting – Searching the system for passwords. Use commands like findstr /SI "password" *.txt in common directories (Users folders, Program Files) to find files containing “password”. Many times, administrators leave config files or scripts with hardcoded creds. Also, check PowerShell history (%userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt) and command history for any credentials left behind. Another key check: cmdkey /list – this shows saved Windows credentials (stored using Credential Manager). If any saved creds are listed (e.g., for remote systems or drives), you might reuse them to elevate or move laterally. In OSCP labs, it’s common to find a password in a file like “notes.txt” or an old installation config on the desktop – local enumeration should find those.
• Privileges and Impersonation – If your account has special privileges, enumerate their potential use. For instance, if you see SeImpersonatePrivilege (which many service accounts have), you can attempt token impersonation attacks (like RottenPotato or JuicyPotato exploits) to get SYSTEM. If you have SeBackupPrivilege or SeRestorePrivilege, you could abuse those to read/write any file (there are tools to exploit backup privilege to dump SAM database). Thus, enumerating whoami /priv is crucial – it might reveal a seemingly low-privilege account actually has a powerful privilege available.
• Check for Weak Folder Permissions – Enumerate ACLs on important directories. Using commands like icacls "C:\Program Files\SomeFolder" to see if standard users have modify rights where they shouldn’t. A common misstep is giving “Everyone:F” (full control to everyone) on a service directory or even at C:\. If you find a program directory or Windows service directory writable by you, you can potentially replace executables or DLLs to escalate. Tools like AccessChk (Sysinternals) can automate searching for weak permissions. For example, accesschk.exe -uwdqs Users * lists objects where “Users” group has write access – this could quickly spot a misconfigured folder or service.
• Kernel and Driver Enumeration – Checking the kernel version and installed drivers for known vulnerabilities. systeminfo provides the OS build which can correlate to a particular Windows build number; some kernel exploits are version-specific (like build 7600 vs 7601 for Windows 7). Tools such as Windows Exploit Suggester (or the newer Sherlock/Watson PowerShell scripts) can take patch lists from systeminfo and suggest known privilege escalations. Additionally, listing drivers (driverquery) might show vulnerable drivers (e.g., an old VulnerableDriver.sys known for privilege escalation). While this gets into automated tool territory, it’s part of enumeration to know your attack options.
• AV and Security Tools – Enumerate which antivirus or EDR (Endpoint Detection & Response) agents are running (from processes, services, or system tray). Knowing the security software is important – some older or misconfigured AV might be disabled or have known bypasses. Also, some AVs can be turned off by users (bad practice but happens), which is useful to know. While this doesn’t directly give a privilege escalation, it affects your strategy. For example, if you see Windows Defender only, you might try known techniques to live off the land; if you see a third-party AV, you might consider migrating to another process or using a different exploit technique that avoids detection.
• Local Networking and Pivot Points – Enumerate network info on the Windows host: ipconfig /all to get IPs, route print to see routing table, and netstat -ano to list current network connections and listening ports. This can reveal other internal networks the host is connected to (multi-homed systems) and trust relationships. For instance, a host might have a second NIC on a 172.16.0.0/16 network – that’s a new network to pivot into. Also, net use can show any network drives mounted (maybe connecting to an SMB share on another machine, indicating likely credentials or an interesting server). Enumerating these aspects sets you up for lateral movement after elevating privileges.

In Windows environments, thorough enumeration is often rewarded. It’s common in OSCP labs to find, for example, an unquoted service path vulnerability or a plaintext password in a config file that gives Administrator access. By systematically checking the above, a penetration tester increases the chance of finding that one misconfiguration that turns a limited shell into a system compromise.

Linux & Unix Enumeration

Like Windows, Linux/Unix systems require both remote service enumeration and local post-exploitation enumeration. Many OSCP targets run Linux services that reveal info to unauthenticated users (NFS shares, Finger service, etc.), and once on a Linux box, numerous techniques can enumerate system details for privilege escalation. Here we cover both aspects:

Remote Enumeration of Linux/Unix Services

• NFS Share Listing – As mentioned earlier, use showmount -e <host> to enumerate exported NFS shares from a Unix server. For example, showmount -e 10.10.10.8 might reveal shares like /home or /var/nfs * (accessible to all hosts). NFS shares could allow anonymous mounting – meaning you can mount the share locally (mount -t nfs 10.10.10.8:/home /mnt/nfs_home) and read/write files. This is a common find in CTFs/OSCP labs: a world-writable NFS share that allows dropping an SSH key in /home/user/.ssh/authorized_keys to log in as that user. Enumerating NFS can directly lead to shell access if misconfigured.
• Finger Service Enumeration – The Finger protocol (TCP port 79) allows querying a remote system for information about users currently logged in or user details. Using a finger client or telnet: telnet 10.10.10.8 79 and then typing a username (or just pressing enter to list all logged in users on some implementations) can output usernames, idle times, etc. Attackers use this to enumerate valid system users on old Unix systems. For example, a finger query might respond with a list of user accounts or details like “jdoe console Dec 10 10:00” indicating that user. This was more prevalent in legacy systems, but if encountered, it quickly gives a list of usernames to try for SSH or other services.
• RPC and NIS (YP) Enumeration – Unix RPC services like NIS (Network Information Service) can leak user and password data. If NIS is in use and accessible, an attacker could query the NIS server for the password map (which historically could give password hashes). Tools like ypcat can retrieve NIS maps if misconfigured. Also, rpcinfo -p listing an NIS service (ypserv) is a clue to attempt NIS enumeration. While rare today, OSCP labs sometimes emulate older setups. Enumerating RPC programs might reveal print services, database services, etc., that have their own enumeration vectors (for instance, an RPC-based database could allow queries without auth).
• SNMP on Network Devices – Many network devices (switches, routers) run Linux-like OSes internally and expose SNMP. If targeting network infrastructure, using SNMP as described earlier can enumerate configuration. For example, SNMP on a Cisco router might reveal the running configuration (with the SNMP community “private”), which could include plaintext router passwords. This is more infrastructure than host, but a reminder that SNMP isn’t just Windows – it’s a common Unix-based network device vector.
• SSH Banner Grabbing and Key Fingerprints – When SSH (port 22) is open, grabbing its banner (ssh -v user@10.10.10.8 or using Nmap script) shows the SSH version and sometimes the OS (e.g., “OpenSSH_8.2p1 Ubuntu”). That reveals the distro or at least the fact it’s likely Linux. Additionally, one can enumerate the SSH host key fingerprint; while not often useful, in some cases comparing host key fingerprints can tell if two hosts are actually the same machine or cloned VMs (which might matter in complex scenarios). Also, enumerating allowed authentication methods by observing SSH handshake (ssh -v) can show if password auth is enabled or only key auth (if only keys, you’ll need to find a key, not waste time brute-forcing passwords).

Local Enumeration on Linux/Unix (Post-Exploitation)

After obtaining a low-privilege shell on a Linux system, enumerate extensively to find privilege escalation paths. This usually involves checking system configuration, file permissions, and sensitive data:

• Operating System Info – Run uname -a to get the kernel version, architecture, and OS release. For example, Linux victim 4.4.0-116-generic #140-Ubuntu SMP ... x86_64 GNU/Linux tells you it’s Ubuntu with a specific kernel. Note the kernel version – certain kernel versions have known exploits (e.g., Ubuntu 4.4.0-116 generic is vulnerable to an overlayfs privilege escalation, for instance). Also check /etc/issue or /etc/os-release for distribution version (e.g., Ubuntu 16.04). Older distros or kernels often have public exploits, so this guides your search (you might use searchsploit linux kernel 4.4.0 to find an exploit).
• User Accounts and Environment – View the /etc/passwd file to list all users on the system (even without root, it’s world-readable). This can show which users exist and might be targets for switching (for instance, noticing a user “oracle” might indicate Oracle is installed, and you could look for files owned by oracle). Also, check current user privileges: run id to see your groups. If you’re in an unusual group (like docker or lxd), that can be an instant privesc vector (Docker group can often escalate to root by controlling containers). The environment variables (env or printenv) can reveal interesting info too – like if PATH is misconfigured (including . or writable directories) which could be abused, or if there are credentials in environment variables (not common, but sometimes web apps put creds in env).
• SUID/SGID File Enumeration – Search for files with the SUID/SGID bit set, as they run with elevated privileges. Use find / -perm -4000 -type f -ls 2>/dev/null to list SUID files. Look for unusual SUID files, especially ones owned by root. For example, if you find /usr/local/bin/customapp has SUID, that binary might be exploitable to gain root. Even standard binaries can be abused if configured strangely (e.g., an older version of find with SUID can be exploited via environment variables). Common privesc via SUID include misconfigured sudo (if sudo itself is SUID with a custom config) or well-known vulnerable SUID programs (like the infamous dirtycow exploit created a SUID executable as part of exploitation). Also, find SGID (-2000) files to see if any give group privileges that might be sensitive (less common).
• Scheduled Jobs (Cron) – Enumerate cron jobs for all users. Check /etc/crontab, /etc/cron.d/, and user cron with crontab -l for each user if possible. If you find a cron job running a script or binary, check its permissions. For instance, a root cronjob executing /usr/local/bin/backup.sh every minute – if you can edit that script (writable by your user), you can insert malicious commands to run as root. Another thing: sometimes cron jobs use wildcards insecurely (e.g., a cronjob like tar -czf /backup/backup.tgz /home/* can be exploited by creating a malicious filename in /home/ since * will expand to it). Thus enumerating cron jobs can uncover logic or file permission issues to abuse.
• Configuration Files – Search for world-readable config files that may contain secrets. Web application configs (e.g., /var/www/html/config.php) often have database credentials. Likewise, configs for services (Apache, MySQL, Docker) might be misconfigured or have cred info. Use find / -type f \( -name "*.conf" -o -name "*config*" \) -perm -004 2>/dev/null to find globally readable configs. Pay attention to files in /etc/ (like /etc/mysql/my.cnf might contain credentials for the DB admin). Also, if any user home directories are world-accessible (ls -ld /home/* to check permissions), browse those for interesting files (SSH keys, notes, .bash_history, etc.).
• Credentials in History Files – Check shell history files for passwords or keys. For example, .bash_history in the home directory of users might show commands that include passwords (maybe someone ran mysql -u root -psecret123). Similarly, if the user used an editor, sometimes backup files like .bash_history.swp or other artifacts might exist. If multiple users’ home directories are accessible, check all their histories. In CTF scenarios, it’s common to find an admin’s history revealing a password used with su or a database connection string.
• Exposed Private Keys – Sometimes users leave SSH private keys without proper permissions. Look for files named id_rsa in home directories. If you find another user’s private key and it’s not protected by a strong passphrase (or any passphrase), you could use it to login as that user (either on this machine or others, depending on key usage). Also, check for key files in unusual places (e.g., backups or copied to /tmp). One OSCP-like trick is finding a backup of a user’s home directory that contains .ssh/id_rsa.
• Kernel Exploits and Privilege Escalation Scripts – After manual checks, running automated scripts like LinPEAS or LinEnum can enumerate a ton of info quickly. They highlight obvious misconfigurations (like world-writable cron, SUID, etc.) and check for known issues. For example, LinPEAS will flag if /etc/passwd is writable (which means you can add a new root user easily) or if Docker can be exploited. While the exam might not want copy-pasting the script output as your answer, using these tools in practice is common to ensure you didn’t miss anything. They are essentially doing the above enumerations plus more, quickly. For instance, LinPEAS checks the system against a database of known privilege escalation CVEs and suggests possible exploits (similar to what a seasoned pen-tester would recall).
• Processes and Open Ports (Internal) – Use ps aux to see running processes and note any unusual ones owned by root. If you see something like a custom binary or a screen/tmux session left by admin, that might be leveraged. Also, netstat -plant (or ss -tulpn) to see listening ports can reveal internal services not visible from outside. Perhaps an internal MySQL or Redis is running and only bound to localhost – if you can interact with it (now that you’re on the box), that could be a way to escalate or pivot. For example, a Redis running as root and no auth – you could use it to write a cron job or authorized_key (classic Redis exploit). Local port enumeration effectively reveals any “hidden” services and their owners, which might be privilege escalation targets.
• Docker and Container Enumeration – If the target is using Docker or LXC containers, enumerate those. Check if your user is in the docker group (id output) – if yes, that’s usually an instant root: members of docker group can run commands in containers as root on the host. Even if not, you might find Docker containers running (e.g., via docker ps if you have rights, or by seeing docker processes). If you can break out of a container or access its filesystem, you might access the host. So enumerating container config is advanced but important on modern assessments. In OSCP labs, one machine might simulate a Docker breakout scenario. For example, if you see /var/www actually mounted from a container, you’d adjust your enumeration to look for container escape avenues.

By performing these Linux enumeration steps, you gather all the puzzle pieces needed for privilege escalation. In practice, this might reveal a misconfigured sudo (maybe the user can run sudo vim which leads to root), a sensitive file (like a script with root password), or a vulnerable service. A classic real-world case was “dirty cow” (CVE-2016-5195): enumerating the kernel version showed it was vulnerable, and a quick compile of the exploit gave root. On OSCP-like challenges, common finds include world-writable cron jobs or SSH keys in backups – emphasizing that exhaustive enumeration makes the difference in discovering these.

Active Directory Enumeration

Active Directory (AD) environments introduce an entirely new layer of enumeration. AD is essentially the identity and access management database for Windows domains, so enumerating it yields user accounts, groups, computers, domain trusts, policies, and more. Many penetration tests (and newer OSCP scenarios) involve AD, where the goal is often to pivot from a single compromised machine to full domain admin. Proper enumeration of AD can reveal misconfigurations that allow privilege escalation within the domain. It’s been observed that testers who ignore AD are “leaving a massive attack surface on the table” – indeed, focusing on AD often leads to critical findings even if other services seem secure. Below are key AD enumeration techniques (assuming we’re starting with limited or no domain access and then moving to having some credentials):

• LDAP and Domain Controller Probing – Even without credentials, you can enumerate some AD information. For example, an Nmap scan might show LDAP (389/tcp) and Global Catalog (3268/tcp) open on a DC. You can attempt an anonymous LDAP bind: ldapsearch -x -H ldap://dc1.target.local -s base namingcontexts to get the base DN of the domain. In some cases, a DC may allow anonymous queries of certain objects (not common in hardened setups, but possible in misconfigs). Additionally, simply seeing the domain name (e.g., via SMB banner or DNS) is enumeration – e.g., knowing the AD domain is TARGET.LOCAL guides all further attacks.
• Kerberos Domain User Enumeration – Using the Kerberos service (88/tcp) to verify valid usernames. Tools like kerbrute can perform user enumeration by attempting to request TGTs for user accounts without passwords. If the username is valid, the KDC responds differently (error about pre-authentication) than if the username is wrong (principal not found). For example: kerbrute userenum -d TARGET.LOCAL --dc 10.10.10.5 usernames.txt will identify which usernames in the list exist in the domain (the tool watches for “kinit: Pre-authentication failed” vs “Principal unknown”). This is a stealthy way to build a list of valid accounts in the domain. Once you have a list of users, you can try password spraying (trying a common password like “Summer2023” across all accounts) or use it for other attacks.
• SMB Domain Enumeration (Null/Guest) – Similar to standalone Windows, but targeting a domain controller with SMB. A null session to a DC (rpcclient -U "" -N DC1) may allow certain queries like enumdomusers to list domain user accounts or enumdomgroups for groups. Even if null doesn’t work, a guest account (if enabled) or any low-priv account can be used. Another approach: use smbmap or CrackMapExec on the DC. For example, crackmapexec smb 10.10.10.5 -u '' -p '' --users attempts an anonymous bind to list users. If successful, you get a dump of all domain usernames. Domain controllers often disallow anonymous enumeration nowadays, but misconfigurations or legacy settings could still permit it.
• Enumerating Domain Groups and Membership – Once you have a foothold (some valid user credentials or a low-priv shell on a domain machine), enumerate AD users, groups, and computers in detail. On a Windows host in the domain, using the PowerShell ActiveDirectory module (Import-Module ActiveDirectory) provides cmdlets like Get-ADUser, Get-ADComputer, Get-ADGroupMember, etc. For example, Get-ADUser -Filter * | select Name will list all usernames (by default any authenticated domain user can read AD directory information). You can query specific groups: Get-ADGroupMember "Domain Admins" to see who the domain admins are. If using command line tools on Kali, ldapsearch or windapsearch or BloodHound (see below) can pull similar info via LDAP. Enumerating group membership might reveal, say, that your low-priv user is actually in some privileged group by mistake, or identify users who are in the “Remote Desktop Users” group on servers, etc., which shapes attack paths.
• Password Policy and SPRaying Info – Determine the domain password policy (to plan brute force or spraying attacks). This can often be done with a simple command if you have domain credentials: net user /domain (which returns password policy info and a user list truncated) or via CrackMapExec: crackmapexec smb <DC IP> -u <user> -p <pass> --pass-pol will output the domain’s password requirements (min length, complexity). Knowing the policy lets you do password spraying intelligently (e.g., if account lockout threshold is 5, you spray at 4 attempts per account). It also may reveal if password history is enforced, etc. Enumerating this is purely informational but critical for planning attacks.
• SPN Service Account Enumeration (Kerberoasting) – In AD, service accounts with Service Principal Names (SPNs) set can have their Kerberos service tickets requested by any user. Using tools like GetUserSPNs.py (Impacket) or PowerShell’s Invoke-Kerberoast, you can enumerate accounts that are kerberoastable. For example: GetUserSPNs.py TARGET.LOCAL/user:password -request will find any user with an SPN (usually service accounts) and return a Kerberos ticket hash that can be cracked offline. Even before cracking, the fact an SPN exists and which account it’s tied to is useful enumeration – it tells you “these accounts likely belong to services, possibly with elevated rights.” So, enumerating SPNs is both an attack (Kerberoasting) and an enumeration of the domain’s service accounts. If you find an account like MSSQLSvc/SQL01 associated with user sqlservice, you’ve learned the domain has a SQL server and a service account; you might then target that account’s hash.
• AS-REP Roasting (Accounts without Pre-auth) – Enumerate user accounts that have the property “Do not require Kerberos preauthentication” (dNSHostName attribute for computers or userAccountControl flag for users). GetNPUsers.py (Impacket) can be used: GetNPUsers.py -dc-ip 10.10.10.5 TARGET.LOCAL/username:password -usersfile users.txt -format john will attempt to get TGT data for accounts with preauth disabled. If successful, it means those accounts can have their Kerberos AS-REP ticket obtained without credentials (and then crackable). Enumerating which accounts have this setting (commonly older or service accounts) is valuable – it’s a sign of weak config. And if you pulled an AS-REP hash, you’ve essentially enumerated a crackable piece of info that might lead to login.
• BloodHound Enumeration – BloodHound is a graphical tool that maps AD trust relationships by ingesting data about users, groups, permissions, sessions, etc. Using BloodHound requires some level of access (at least one valid domain user credentials). The collection can be done via the Windows ingestor (SharpHound.exe) or the Python version (bloodhound-python). For example, bloodhound-python -d TARGET.LOCAL -u username -p password -c All -ns 10.10.10.5 collects all AD data it can and uploads to a neo4j database for analysis. BloodHound isn’t used on the OSCP exam itself (OffSec expects more manual enumeration), but in real-world and post-OSCP practice it’s common. It enumerates things like: which users have local admin on which machines, path from a given user to domain admin (via group memberships or ACLs), etc. Running BloodHound in a lab can quickly highlight, say, that the “IT Support” group has RDP access to a server where a Domain Admin is logged in – a path for credential theft. So BloodHound is an enumeration (not exploitation) tool that reveals the “attack paths” within AD.
• Group Policy Enumeration – Group Policy Objects (GPOs) can contain interesting settings. A classic example is Group Policy Preferences (GPP) which historically stored credentials in SYSVOL (accessible to any domain user) with weak encryption. Although patched (the cpassword is now well-known), old GPP passwords can still be found. Enumerate the SYSVOL share on the DC (via \\DC\SYSVOL\Domain\Policies\...) to find any XML files with <cpassword> fields. Tools like gpp-decrypt can decrypt those to plaintext. Even beyond GPP, enumerating GPOs can show if local admin passwords are being set via policy (there was an old exploit via GPP). Another angle: enumerate if there’s a policy that restricts or allows certain things (for instance, a policy that adds Domain Users into Local Administrators on all PCs – which means any domain user can admin any workstation). Such info is retrievable via AD queries (PowerView has functions to get GPO details).
• Trusts and Domain Enumeration – If the environment has multiple domains or a forest, enumerate trust relationships. Using nltest /domain_trusts /all_trusts on a domain-joined machine (or PowerView’s Get-NetDomainTrust) will list trusts like DomainA -> DomainB. This is important because a low-priv user in one domain might have rights in a trusted domain (or there might be some misconfiguration in trust allowing relay attacks). Also enumerate domain controllers and other critical servers: nltest /dclist:target.local gives all DCs; nltest /dnsgetdc:target.local provides DC and AD site info. Knowing all DCs is necessary (e.g., for DCsync attacks later). Essentially, map out the AD structure: how many domains, what are their names, and how they trust each other – this all comes from enumeration commands.
• DNS in AD – AD-integrated DNS can leak internal host info. If you have read access in AD (any user does), you can enumerate DNS records via LDAP. The DNS zone data is stored in the MicrosoftDNS container in the AD LDAP. Tools like adidnsdump can extract all DNS records if the user has rights (by default, Authenticated Users can read DNS records in AD unless restricted). This can provide a full list of hostnames and IPs in the domain, similar to a zone transfer. For example, it could reveal interesting hosts like backup-server.target.local or legacy-app.target.local that you might not have known about. Thus AD enumeration might include querying DNS records from the DC (beyond the basic forward lookup).
• Service Principal Enumeration – Identify any unconstrained or constrained delegation settings in AD. This is more advanced: using tools like PowerView’s Get-DomainUser -TrustedToAuth or Get-DomainComputer -TrustedToAuth to see if any accounts have delegation rights. If, for example, a computer or user is set with “Trusted To Auth For Delegation” (unconstrained delegation), capturing their credential (or impersonating them) could escalate to impersonating any user (even domain admin) when connecting to that service. Enumerating delegation settings is crucial in a thorough AD pentest, though it’s an edge case in OSCP-level exercises. It’s more of a “beyond OSCP” enumeration item that real-world red teamers check.

Active Directory enumeration is often the step where testers accumulate small weaknesses that add up to compromise. A real-world scenario might be: enumerating users finds an account “backupAdmin”; a password spraying attack (using the user list) finds that BackupAdmin has the password “Winter2023”. With those creds, enumerating AD further shows BackupAdmin is a member of “Backup Operators” on a DC, allowing login. Logging in, you then enumerate that you can DCSync (replicate directory) or extract password hashes. This chain underscores that each piece – user list, spraying, group membership, etc. – came from thorough enumeration. In summary, AD offers many avenues for information gathering, and each enumeration technique can reveal a critical piece of the puzzle for achieving domain takeover.

Database and Application Enumeration

Many penetration tests involve databases or other applications that require their own enumeration methods. After discovering a database service (e.g., MySQL, MSSQL, Oracle) during port scanning, enumerating its configuration and contents can lead to sensitive data or system access. Often this occurs once you have some level of credentials, but even without creds, default setups can be leveraged. Here we list enumeration techniques for common databases and related services:

• MySQL/MariaDB Enumeration – If a MySQL database is accessible (default port 3306) and you have credentials (or the root account has no password, which sometimes happens in CTFs), enumerate the databases and users. For example, after connecting with the MySQL client: SHOW DATABASES; will list databases, and SELECT user, host, password FROM mysql.user; (for MySQL <5.7) shows user accounts and password hashes. Even without login, the MySQL protocol handshake reveals the version (e.g., 5.5.60-0ubuntu0.14.04.1) which might have known vulns (like old MySQL had a username enumeration via timing). If no creds, try default creds: root with blank password, root:root, or test:test – not likely in hardened setups but seen in practice. Enumerating data from MySQL could reveal application credentials or data worth exfiltrating. On OSCP, one path was finding a MySQL with no root password, allowing reading local files via LOAD_FILE() or executing commands via SELECT sys_exec(...) in MariaDB – a reminder that database enumeration can pivot to full compromise.
• MSSQL (SQL Server) Enumeration – Microsoft SQL Server (port 1433) often appears in Windows environments. If we find SA credentials or another user, we can enumerate the instance. Using sqsh or impacket’s mssqlclient.py to connect: once in, run SELECT @@version; to get the SQL Server version (which might indicate if xp_cmdshell is enabled by default). Check the login user’s privileges: SELECT SYSTEM_USER; SELECT IS_SRVROLEMEMBER('sysadmin'); – if the user is sysadmin, you can enable xp_cmdshell and execute system commands. Even without that, you can enumerate databases with EXEC sp_helpdb;, list users with SELECT name FROM master.sys.sql_logins;. If no creds are known, try common ones (SA: blank, SA:Password1, etc.). There’s also a technique to brute force or use a dictionary with Nmap’s ms-sql-brute script. Also, the MSSQL protocol can sometimes be enumerated using nmap --script ms-sql-info to get server details. A real-world misconfiguration: enabling the “xp_cmdshell” stored procedure for low-priv users – enumerating that capability is key because it means a direct system shell is possible from SQL.
• Oracle Database Enumeration – Oracle listens typically on port 1521 (TNS Listener). Initial enumeration includes grabbing the listener banner (which gives Oracle version). Using tnscmd10g status (from Oracle toolkit) can sometimes get the listener status and known services. If you have credentials for an Oracle DB (or a default like scott/tiger), you can enumerate users with SELECT username FROM all_users; and perhaps password hashes from SELECT * FROM dba_users; (if you have high privileges). Also, Oracle’s data dictionary views (ALL_TABLES, ALL_TAB_COLUMNS) allow mapping the database schema. There are default accounts in Oracle (scott/tiger, system/<password>, etc.) which can be tried. Oracle even without creds could be vulnerable to TNS poisoning, but that’s an exploitation. Another enumeration trick: If the listener has no password, you might be able to abuse TNS to get information or even create an entry to route connections. However, for OSCP-level, enumerating Oracle likely focuses on default creds and version info.
• PostgreSQL Enumeration – Postgres (usually port 5432) if accessible can sometimes allow connections with default credentials (the “postgres” superuser with no password is a classic misconfig). If you can connect (psql -h 10.10.10.5 -U postgres), check current user with SELECT current_user; and list databases with \l (in psql client) or SELECT datname FROM pg_database;. Once in a database, list tables with \dt and users/roles with \du. Postgres has a feature: if you have superuser rights, you can execute shell commands via COPY ... TO PROGRAM. Enumerating whether your user is superuser (SELECT rolsuper FROM pg_roles WHERE rolname=current_user;) is critical – if true, you can essentially get a shell on the OS as the postgres system user. In one OSCP-like instance, a postgres service had a weak password; enumerating it gave access to the database, and the ability to write to a file and get a reverse shell as the database user.
• NoSQL and Unauthenticated DBs – Services like MongoDB, Redis, or ElasticSearch often have had issues with default open access. Enumerating these is straightforward: e.g., for MongoDB (27017), connecting with mongo --host 10.10.10.5 with no auth could allow show dbs and dump data. For Redis (6379), using the redis-cli: INFO command gives server info, KEYS * lists all keys if no auth. Attackers famously find open Redis and do CONFIG SET dir /tmp and CONFIG SET dbfilename "shell.php" and save a webshell. Enumerating an open Redis service means you have essentially an open door – listing all keys might show cached credentials or session tokens. ElasticSearch (9200) if left open can show cluster info and stored data via REST queries (like curl https://10.10.10.5:9200/_cat/indices?v). The key is recognizing these less-common DB services and checking if they require authentication or not. On an engagement, finding an open ElasticSearch might allow reading all indexed documents (which could include sensitive info). So enumeration here is simply using the API to retrieve as much data as possible (since no creds needed).
• Interacting with Database via Web Apps – Sometimes you won’t connect directly to a DB, but you can enumerate it through a web application (SQL injection, etc.). For instance, if an app is vulnerable to SQL injection, you might enumerate the DB user, version, and schema via injection payloads (UNION SELECT user(), @@version, database(), etc. in MySQL). This is more on the exploitation side, but it’s enumeration of the database structure through a vulnerability. In an OSCP context, if you exploit SQLi, one of the first steps is to enumerate the database – find table names, column names, and extract data like user hashes. Keeping in scope, direct DB service enumeration (previous points) is separate, but it’s worth noting that exploitation often yields an enumeration phase (dumping data) as well.
• Default Credentials and Common Ports – Always consider default creds for things like PHPMyAdmin (a web app, but used for DB admin) – if discovered during web enumeration, try admin:admin or other common logins. Similarly for appliances (some run Postgres with known default creds, or an MQ service like ActiveMQ with default console password). Enumerating these applications often comes down to knowing default login/password combos and testing them. A comprehensive list of default creds (for Tomcat Manager, WebLogic console, etc.) is handy – many OSCP students maintain a cheatsheet. If you enumerate that a Tomcat service is present (from web fingerprint), you might try the default tomcat:tomcat or admin:admin. If a MySQL is present, try root with no password. Enumerating isn’t just listing, but also testing these well-known defaults safely.

Enumerating databases and related services can directly lead to sensitive information or new access. For example, once an OSCP student found that an MS SQL server had a weak SA password, which allowed enabling xp_cmdshell and getting a system shell – essentially turning a database enumeration into full server compromise. In real cases, databases often hold the crown jewels (PII, credit cards, etc.), so enumerating their content (table names, user data) is critical for assessment reporting. Always ensure any found credentials or information in databases are used to pivot further (e.g., a password found in a DB might be reused for a server admin account).

Other Advanced Enumeration Techniques

Beyond the typical network, web, and host-based enumeration, a well-rounded pentester should also utilize external reconnaissance and specialized enumeration techniques when appropriate. These can include open-source intelligence gathering (OSINT), cloud environment enumeration, wireless network scanning, and even physical or social engineering reconnaissance. While these may be beyond the strict scope of OSCP exam criteria, they are very relevant in broader offensive security engagements. We’ll outline a few of these advanced enumeration areas:

OSINT and External Reconnaissance

• Public Footprint (Whois & DNS) – Enumerate public information about the target via OSINT. This includes performing a Whois lookup on domain names to find registration details (which might give contact names or addresses that could be used in social engineering). Also, use passive DNS services or search engines to find subdomains (for example, using Google with site:target.com -www to find less obvious subdomains indexed, or using Certificate Transparency logs to find *.target.com certificates which often list subdomains). This external enumeration can reveal development or staging sites that aren’t obvious.
• Employee and Email Gathering – Collect employee names, email addresses, and patterns. LinkedIn is a goldmine: an attacker can enumerate employees of Company X and get full names and job titles. From that, derive email addresses (e.g., first.last@target.com). There are tools like theHarvester which automate searching for emails and names across LinkedIn, Google, etc. The result might be a list of 50 company emails – useful for phishing or for password spraying on OWA/VPN if those are in scope. Even in an OSCP-like lab, if you identify a domain name, you might guess usernames from patterns (e.g., “John Smith” -> jsmith) and use that in SMTP VRFY or Kerberos, as discussed earlier.
• Pastebin and Breach Data – Search paste sites and breach databases for mentions of the target. Sometimes sensitive info (API keys, passwords, config) is accidentally leaked on Pastebin, GitHub Gists, or in public breach dumps. Using Google dorks like "password" "target.com" or searching on sites like HaveIBeenPwned (for company email domains) can enumerate if any user accounts were in known breaches. If an employee’s email shows up with a hashed password in a breach, cracking that hash could give you a valid credential (users often reuse passwords). This is definitely an advanced technique and more OSINT-driven, but it can pay off big. Real example: attackers have found cloud service API keys in public GitHub repos which allowed complete compromise of cloud infrastructure. Enumerating a target’s public GitHub projects or those of their developers might yield such secrets.
• Infrastructure Exposure (Shodan/Censys) – Use internet-wide scanners like Shodan or Censys to see what the target organization exposes. By searching the company name, domain, or IP ranges, you might enumerate external-facing systems and services that you wouldn’t find from a single vantage point. For instance, Shodan might show that mail.target.com has port 3389 (RDP) open, which might not have been obvious. Or that certain IoT devices or VPN portals are accessible. This kind of enumeration often reveals old systems forgotten by the org. It’s not uncommon to find a development server or an old site via Shodan that isn’t linked anywhere on the main site.
• Social Media and Website Clues – Review the target’s official website and social media for hints. Job postings can enumerate technologies used (e.g., “looking for an Azure DevOps engineer” – clue that they use Azure, or “Experience with Oracle DB required” – likely an Oracle database in environment). Press releases or IT blogs might mention recent system upgrades or partnerships (e.g., a partnership with Salesforce – maybe there’s a Salesforce integration to enumerate). Employees’ social media might inadvertently reveal system info (a selfie in the server room showing equipment brands, or a tweet complaining “VPN is down again”). While subtle, these can guide your technical enumeration (knowing they use a particular VPN technology might lead you to enumerate that VPN’s endpoints and default creds).

Cloud Environment Enumeration

• AWS Metadata Service & Role Enumeration – If you compromise a server in the cloud (AWS, Azure, GCP), check if it’s an instance with roles/permissions. On AWS, every EC2 instance has the metadata service at https://169.254.169.254/. Curling that URL from the instance can enumerate a lot: for example, curl https://169.254.169.254/latest/meta-data/iam/info tells if an IAM role is attached. If yes, curl https://169.254.169.254/latest/meta-data/iam/security-credentials/<RoleName> gives temporary AWS credentials for that role. This is an enumeration technique that often immediately yields new credentials. Once you have AWS keys, you enumerate the cloud environment: use AWS CLI or tools like enumerate-iam to list what that role can do (e.g., aws sts get-caller-identity to see who you are, aws s3 ls to list S3 buckets accessible, aws ec2 describe-instances to see other instances). In many cloud breaches, compromising one app server led to enumerating its IAM role, which had overly broad permissions (like access to all S3 buckets, some containing sensitive data).
• S3 Bucket Enumeration – Enumerate cloud storage buckets for sensitive data. Even without compromising an instance, attackers often brute-force bucket names or use OSINT to find them (public S3 buckets often have names like company-backups, company-media, etc.). Tools like AWSBucketDump or s3scanner try common bucket name patterns. If a bucket is found and misconfigured as public, listing its content (aws s3 ls s3://target-bucket-name) could reveal sensitive files. Even if not public, if you have some AWS credentials (maybe from the above metadata method or a leaked key), you enumerate which buckets those creds can access. This was the case in the famous Tesla AWS breach – Kubernetes admin console was open, yielding AWS creds, which when enumerated gave access to an S3 bucket with sensitive telemetry.
• Azure AD and Office 365 Enumeration – If targeting Azure or O365, there are specific enum tricks. For example, you can enumerate valid O365 users via the O365 login portal (similar to web user enum): differing responses for valid vs invalid usernames. Tools like MailSniper automate this by attempting logins to O365 with a list of usernames and a bad password, capturing which user accounts exist (this is a form of account enumeration via response code). In Azure AD (if you have some foothold), using the Azure CLI with az ad user list or az ad group list can enumerate cloud-only accounts. Azure also has a metadata service (169.254.169.254 as well for VM info). The point is, each cloud platform has unique enumeration points – whether it’s listing all VMs in a subscription if you get a token, or enumerating lambda functions, etc. Cloud pentesting involves a lot of asking “what can this credential see or do?” and expanding outward.
• CI/CD and DevOps Enumeration – Many organizations integrate code repos and continuous integration pipelines (Jenkins, GitLab CI, etc.). If you encounter credentials or access to such systems, enumerate them. For example, if you get into a Jenkins server (perhaps via default admin creds), enumerate the configured jobs and credentials stored. Jenkins often has credentials saved for code repositories or deployment – these can be extracted (Jenkins has scripting consoles to dump creds). Similarly, if you find an API token for something like GitHub or GitLab, use it to enumerate projects, code, and secrets. Developers sometimes leave sensitive info in code repositories; enumerating a company’s public or leaked code can expose API keys or passwords. This category borders on exploitation but fundamentally it’s gathering info from DevOps tools that can lead to further compromise (commonly, finding a password in code that gives domain admin on the network – it has happened!).

Wireless and IoT Enumeration

• Wi-Fi Network Scanning – If the engagement includes a wireless component, enumerating Wi-Fi networks (SSID, encryption, signal strength) is the first step. Using tools like airodump-ng with a wireless adapter in monitor mode, you can list all nearby Wi-Fi networks and associated client devices. This enumeration gives network names which might identify targets (e.g., an SSID “CorpGuest” vs “CorpInternal” – one might allow easier attack). It also reveals security (WPA2, Enterprise, etc.). If it’s WEP or WPA/WPA2 with a weak passphrase, capturing handshakes for cracking is next. But even with WPA2-Enterprise, enumerating the EAP type (PEAP, EAP-TLS, etc.) and any leaked info in beacons (some networks broadcast the AP’s hostname or other metadata) is useful for planning. Wireless enumeration might also involve using tools like Kismet to map out AP locations and channels.
• Bluetooth and IoT Device Scanning – Using tools to scan for Bluetooth devices or other IoT signals can enumerate vulnerable devices. For example, with a Bluetooth adapter, running hcitool scan or Bleah can list discoverable BT devices, including perhaps a company’s door access systems, printers, or headsets. Knowing what Bluetooth devices are present can lead to attempts to connect (some older Bluetooth Classic devices had default PINs like “0000” or “1234”). IoT devices like smart thermostats or cameras might show up on Wi-Fi or via their own beacons – enumerating these (with specialized spectrum scanners or simply observing open Wi-Fi networks they create for setup) can reveal an entry (maybe the IoT device has a default admin password accessible via a mobile app or web interface).
• RFID and Physical Badge Enumeration – If doing physical engagements, enumerating badge IDs or frequencies with an RFID reader could be considered. For example, using a Proxmark device to scan employee badges might enumerate the facility code and badge numbers, which could be later cloned. This is quite far from OSCP content, but in broader security tests, gathering this info is analogous to network enumeration but in the physical realm.
• Physical Recon – Simply observing and noting physical details: company office locations, building layout, where the server room might be (sometimes you can see through windows), security guard routines, etc., is a form of enumeration. Tailoring an attack might involve noticing that a particular side door is often ajar (potential for a drop-in attack) or that employees wear ID badges with a certain format (which you could duplicate visually). While not technical, mentioning these recognizance techniques shows awareness of the full spectrum of offensive security.

Each of these advanced areas could be deep on its own, but the key is that enumeration isn’t limited to port scanning. A skilled penetration tester uses every available avenue to gather information. For instance, before even sending a packet to the target network, an OSINT sweep might reveal the organization’s VPN portal and a leaked password – effectively compromising security without “exploiting” in the traditional sense. Similarly, cloud enumeration might turn a single compromised webserver into global administrator access if misconfigured roles are found. By expanding enumeration to these domains, you greatly increase the chances of finding that one weakness that leads to a big score. In summary, enumeration is an exhaustive process – from on-prem networks to cloud, from web apps to Wi-Fi, from user accounts to hardware – and the more thorough the enumeration, the more successful the overall penetration test is likely to be.