🛡️ Methodology Checklist

  • Server banner: curl -I http://[TARGET] — check Server header
  • CMS detection: whatweb, Wappalyzer, curl for cms-specific paths
  • WordPress: /wp-login.php, /wp-admin/, wp-content/
  • Joomla: /administrator/, components/com_
  • Drupal: sites/default/, /CHANGELOG.txt
  • OS fingerprint via Server header parenthetical: (Ubuntu), (Win32)
  • Check TLS cert for domain/org info
  • Note all tech stack components for CVE research

🎯 Operational Context

Use when: Before selecting any exploit — identify web server type, version, CMS platform, framework, and technology stack to narrow CVE and tool selection. Think Dumber First: Run whatweb first (2 seconds). Then check response headers manually with curl -I. Version info in Server:, X-Powered-By:, and Set-Cookie: headers eliminates hours of guessing. Skip when: Target is well-known (confirmed WordPress/Joomla from scope doc) — skip fingerprinting and go directly to CMS-specific tools.


⚡ Tactical Cheatsheet

CommandTactical Outcome
curl -I http://[TARGET_IP]Banner grab — check Server, X-Powered-By, X-Redirect-By headers
curl -I http://[DOMAIN]Same — use domain if VHost mapping needed
wafw00f [DOMAIN]Detect WAF presence and type
nikto -h [TARGET_IP] -Tuning bSoftware identification (fast, low noise)
nikto -h [TARGET_IP]Full Nikto scan — default files, outdated versions, misconfigs

🔬 Deep Dive & Workflow

Initial Enumeration

  • Add domain to /etc/hosts if VHost in use
  • curl -I http://[DOMAIN] — extract:
    • Server: header → web server software + OS (e.g., Apache/2.4.41 (Ubuntu))
    • X-Powered-By: → scripting language / framework (PHP, ASP.NET)
    • X-Redirect-By: → CMS (e.g., WordPress)
    • Location: path → confirms specific software (e.g., /wp-login.php)
  • wafw00f [DOMAIN] — check for Cloudflare, Wordfence, Defiant WAF
  • nikto -h [TARGET_IP] -Tuning b — check /license.txt, /robots.txt, login paths

Attacks

Technology Fingerprinting Cheat Sheet

TechniqueClues
Banner GrabbingServer: Apache, Server: Nginx, Server: IIS
CMS Pathswp-content (WordPress), components/com_ (Joomla), sites/default (Drupal)
OS FingerprintingText inside parentheses: (Ubuntu), (Debian), (CentOS), (Win32)
Passive ToolsWappalyzer (browser ext), BuiltWith (online) — no packets sent

CPTS Exam Quick Answers

  • Apache version?curl -I → look at Server: line value
  • CMS type?curl -IX-Redirect-By: or Nikto login paths
  • OS? → Text in parentheses of Server: header

VHost trap: if scanning IP and getting generic results, add domain to /etc/hosts and scan by domain name.


🛠️ Troubleshooting & Edge Cases

ProblemCauseFix
whatweb returns no versionServer headers strippedCheck 404 error page — error pages often leak stack info (X-AspNet-Version, stack traces)
Server header shows nginx but app behaves like ApacheReverse proxy in frontCheck for X-Forwarded-For, Via headers; test with OPTIONS method
Wappalyzer browser extension conflicts with VPNExtension unreliableUse wappalyzer-cli or webanalyze from CLI instead
wafw00f detects no WAF but requests get blockedWAF with no bannerTest manually: add ' OR 1=1 to parameter — if blocked with 403, WAF present
Technology stack changes per endpointMixed architectureMap per-endpoint: API might be Node.js while frontend is PHP — fingerprint each path

📝 Reporting Trigger

Finding Title: Web Server Version Disclosure Enables Targeted Exploitation Impact: Exposed server version information (Server: Apache/2.4.49) allows attackers to immediately identify applicable CVEs (e.g., CVE-2021-41773 path traversal) without additional reconnaissance. Root Cause: Default web server configuration exposes version strings in HTTP response headers. No header sanitization applied. Recommendation: Configure web server to suppress version disclosure (ServerTokens Prod for Apache, server_tokens off for Nginx). Remove X-Powered-By headers. Implement WAF to normalize response headers.