HTTP and HTTPS Enumeration for Pentesting (80, 443)
Introduction
In Part 1 of this series, we covered FTP (port 21) and SSH (port 22) enumeration: banner grabbing, anonymous login checks, supported commands (HELP/FEAT for FTP), SSH version and auth-method detection, and the workflow of discover → identify → version → safe probes → document. In this part we continue with HTTP (port 80) and HTTPS (port 443).
Typically, web applications on those ports are prime targets: they expose version strings, frameworks, and misconfigurations through headers and default pages. Enumeration here involves: you send normal requests and interpret responses. This blog covers banners, headers, directory discovery, and basic SSL/TLS checks, enough to steer your next steps without noisy scanning.
Understanding how HTTP and HTTPS differ at the protocol layer is essential for our effective web enumeration, below table shows how they compare for most part:
Feature / Property | HTTP | HTTPS |
|---|---|---|
URL Scheme | http:// | https:// |
Default Port | 80 | 443 |
Transport Security | Unencrypted (Plaintext) | Encrypted via TLS/SSL |
Protocol Layering | Application Layer directly over TCP | Application Layer over TLS/SSL over TCP |
Connection Handshake | Standard 3-way TCP handshake | TCP handshake + TLS/SSL negotiation handshake |
Server Authentication | None (Vulnerable to spoofing/MITM) | Validated via X.509 Digital Certificates |
Data Integrity | None (Traffic can be tampered with in transit) | Guaranteed using cryptographic hashing/MACs |
HTTP Enumeration (Port 80)
HTTP Banner Grabbing and Server Version
Grab the raw response to see the Server header and status:
curl -sI http://192.168.1.10/
Or with netcat (no TLS, so you see the first line and headers):
printf "GET / HTTP/1.0\r\nHost: 192.168.1.10\r\n\r\n" | nc -nv 192.168.1.10 80
Look for:
Server: e.g. Apache/2.4.41, nginx/1.18.0: note product and version for CVE checks.
X-Powered-By: often reveals PHP, ASP.NET, or other runtimes.
Status: 200, 301, 403, etc., and any redirect location.
Nmap can do version detection and run safe HTTP scripts:
nmap -p 80 -sV --script http-server-header,http-headers 192.168.1.10
HTTP Headers to Record for Pentesting
Header | Why it matters |
|---|---|
Server | Product and version for vulnerability research |
X-Powered-By | Runtime/framework (PHP, .NET, etc.) |
X-AspNet-Version | .NET version |
Strict-Transport-Security | HSTS present or missing (HTTPS) |
Set-Cookie | Session/security cookie names and flags |
Save a full header dump for the report:
curl -sI -L http://192.168.1.10/ -o headers_80.txt
For more details on HTTP headers please check out our detailed HTTP headers blog.
Web Directory and Path Discovery
Use a wordlist and only read responses, try to avoid destructive requests. Use a small wordlist first to avoid rate limits or lockouts. Adjust the wordlist path for your environment (for e.g. Kali: /usr/share/wordlists/dirb/common.txt). Examples:
# Gobuster (dir mode, 40 threads, common wordlist)
gobuster dir -u http://192.168.1.10/ -w /usr/share/wordlists/dirb/common.txt -t 40
# Feroxbuster (recursive, auto-calibration)
feroxbuster -u http://192.168.1.10/ -w /usr/share/wordlists/dirb/common.txt
Interpret status codes: 200 (OK), 301/302 (redirect; note Location), 403 (forbidden but path exists; often a finding: "admin path present but restricted"), 404 (not found). Then document interesting paths (admin, backup, config, api, .git, env) for manual inspection and the report.
Note: most default distributions will not have these tools present by default, as such you might need to set them up via appropriate package managers.
Web Technology Fingerprinting
Default pages: /server-status, /phpinfo.php, /wp-admin (WordPress) reveal stack and sometimes versions.
Headers: X-Powered-By, Server, and framework-specific headers (e.g. X-Drupal-Cache) narrow the stack.
Cookies: Session or framework cookies (e.g. PHPSESSID, wp-settings) confirm technologies.
One request can give a lot:
curl -sI http://192.168.1.10/
curl -s http://192.168.1.10/ | head -50
Check the HTML for meta generator tags, comments, or script paths that reveal CMS or framework.
HTTP Findings: Misconfiguration vs Version Risk
Web enumeration findings split the same way FTP and SSH do.
Version risk is a Server or X-Powered-By header that maps to a CVE for a specific Apache, nginx, PHP, or framework release. Note the exact version string so the client can check it against their own patch records, since header values can lag behind the actual installed version on hardened hosts.
Misconfiguration risk covers things like directory listing left enabled, a /server-status or /phpinfo.php page reachable without authentication, verbose error pages that leak stack traces or file paths, and missing security headers such as Strict-Transport-Security or Content-Security-Policy.
A fully patched web server can still leak its entire technology stack through a forgotten debug endpoint.
Report the two separately: cite the CVE reference for version-based findings, and describe the exact exposed path or missing header for configuration findings so the fix is unambiguous.
What to Document for HTTP Findings
For each host, keep a record of the full response headers (not just Server), the HTTP status code and any redirect target, the directory-discovery wordlist and tool settings you used (so results are reproducible), and every interesting path you found with its status code and content length.
A 403 on /admin is not the same finding as a 200 on /admin/config.php.bak; document them as distinct rows in your findings table rather than a single vague "some paths found" note. Save raw header dumps and full HTML pages you reference in the report to your evidence folder, and quote only the relevant snippet in the report body. If a page reveals a CMS or framework version, capture the exact string (meta generator tag, changelog file, or footer credit) rather than paraphrasing it.
Safe vs Unsafe HTTP Probes
curl, header inspection, and directory discovery with a small, standard wordlist are safe: they are ordinary GET requests that any web server handles thousands of times a day, and a well-tuned scan with a moderate thread count rarely causes more than a blip in access logs. Where HTTP enumeration becomes risky is aggressive brute-forcing of large wordlists against small or rate-limited applications, which can trigger a web application firewall, exhaust connection pools, or in the worst case take down a fragile staging server.
Always start with a small wordlist and a conservative thread count, watch for increasing response times or connection errors, and back off if you see them. Avoid submitting forms or hitting endpoints that clearly perform a write action (account creation, password reset, checkout) during enumeration; those belong in a later, explicitly scoped testing phase, not the initial recon pass.
HTTPS Enumeration (Port 443)
HTTPS adds TLS and often a different virtual host. Enumerate both the TLS stack and the HTTP layer (same ideas as port 80, but over SSL).
HTTPS and SSL/TLS Version and Cipher Enumeration
Quick certificate check with OpenSSL (subject, issuer, validity):
openssl s_client -connect 192.168.1.10:443 -servername 192.168.1.10 </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
For cipher and protocol enumeration, use Nmap:
nmap -p 443 --script ssl-enum-ciphers,ssl-cert 192.168.1.10
Record:
Certificate: subject, issuer, validity (expiry), SANs (hostnames).
Protocols: TLS 1.0/1.1 (weak) vs 1.2/1.3.
Ciphers: weak ciphers (e.g. NULL, export, RC4) are often compliance findings.
HTTP over HTTPS (Application Layer Enumeration)
Once you know 443 is HTTPS, treat it like HTTP enumeration with the correct URL:
curl -sI https://192.168.1.10/
curl -sI -k https://192.168.1.10/ # -k if you ignore cert errors for internal testing
Use the same header and directory-discovery approach as port 80; just change the scheme and (if needed) Host for virtual hosting:
gobuster dir -u https://192.168.1.10/ -w /usr/share/wordlists/dirb/common.txt -k -t 40
Virtual Host Enumeration
If the target is name-based, try the real hostname and any known subdomains:
curl -sI -H "Host: admin.target.local" https://192.168.1.10/
Document which Host headers return different content or status codes; that is useful for scope and follow-up. Also try the IP as Host, plus common names (e.g. www, admin, dev, staging, mail) if you have a known base hostname.
HTTPS Findings: Misconfiguration vs Version Risk
TLS findings follow the same pattern as the rest of this series.
Version risk is an outdated TLS library or web server build tied to a known vulnerability; note the exact software version from the certificate or Server header alongside the protocol versions Nmap reported.
Misconfiguration risk covers certificate and protocol issues that exist independent of software version: an expired or self-signed certificate on a production host, TLS 1.0 or 1.1 still enabled alongside 1.2/1.3, weak or export-grade ciphers still negotiated, or a certificate whose Subject Alternative Names do not match the hostnames actually served. A brand-new TLS stack can still be misconfigured to accept a weak cipher suite for backward compatibility.
Report certificate expiry and weak protocol support as configuration findings with a clear remediation, for example disabling TLS 1.0/1.1 in the server's SSL configuration, separate from any CVE tied to the underlying TLS library version.
What to Document for HTTPS and TLS Findings
Capture the certificate subject, issuer, validity window, and full SAN list from openssl x509 (or other as applicable), plus the protocol and cipher list from ssl-enum-ciphers. Flag any protocol below TLS 1.2 explicitly by name in your notes, since "weak TLS" alone is not actionable for a client's infrastructure team. However, remember that a lower TLS version supported by itself is not a bug. if there is valid business justification to implement and support the said protocol, in the "right way", the same needs to be allowed.
For virtual host testing, record each Host header you tried and the resulting status code or content length side by side in a small table; this makes it easy to spot which hostnames route to different applications on the same IP. If a certificate is expired or mismatched, note the exact expiry date and the hostname it was issued for, since that is usually enough evidence for the finding without needing a screenshot of a browser warning page.
Safe vs Unsafe HTTPS Probes
Certificate inspection with openssl s_client, ssl-enum-ciphers, and switching the Host header for virtual host discovery are all safe, passive checks; they read configuration and certificate metadata without submitting any application data, and they will not trip account lockouts or write any state.
Where HTTPS testing becomes riskier is combining virtual host discovery with aggressive directory brute-forcing across many candidate hostnames at once, which multiplies your request volume and can look like a distributed scan to a monitoring team.
If you must test many virtual hosts, throttle the discovery pass per hostname and confirm with the client whether internal hostnames outside the agreed scope, for example an admin hostname you guessed rather than one they provided, are fair game before you probe them; enumerating a hostname is usually fine, but treat anything you find behind it as out of scope until confirmed.
HTTP and HTTPS Enumeration Quick Reference
Goal | Tool / method |
|---|---|
Server banner | curl -sI http(s)://<ip>/ or nmap -p 80,443 -sV |
Full headers | curl -sI -L and Nmap http-headers script |
Directories | gobuster dir or feroxbuster with a safe wordlist |
TLS/cert | openssl s_client and nmap --script ssl-enum-ciphers,ssl-cert |
Tech fingerprint | Headers + default paths + HTML meta/comments |
Summary: HTTP and HTTPS Enumeration for Pentesting
HTTP (port 80) and HTTPS (port 443) enumeration gives you web server and framework versions, directory layout, and TLS posture. Always record Server, X-Powered-By, and certificate details; then use directory discovery and headers to map the application. Part 3 covers SMTP (port 25), POP3 (110), IMAP (143), and SNMP (161): mail server and network-management enumeration you can run with the same methodology.
References
Register for instructor-led online courses today! https://www.darkrelay.com/courses
Check out our self-paced learning paths! https://www.darkrelay.com/learning-paths
Explore our bundled Pricing & Plans for cost-effective options! Buy a course subscription to learn more—hands-on labs and expert-led training included. https://www.darkrelay.com/plans-pricing
Contact us for custom pentesting needs at: info@darkrelay.com or WhatsApp.
Comments