This module covers attacks against web server platforms including IIS, Apache, and nginx. Attackers exploit misconfigurations, directory traversal vulnerabilities, default credentials, unnecessary modules, and HTTP method abuses to gain unauthorized access to web server systems.
The CEHStudy app carries 8 flashcards for Module 13 across 2 sections — drill the security-header list until each maps to the attack it closes: HSTS blocks downgrades, CSP limits injection blast radius, X-Frame-Options stops clickjacking, nosniff stops MIME sniffing.
Key Topics Covered
IIS vulnerabilities: IIS 6.0/7.0 path parsing, ASP.NET attacks
IIS (Internet Information Services): Microsoft's web server for Windows. Vulnerabilities include path parsing in IIS 6.0 (.asp; extension), ASP.NET view state exploitation, and default configuration weaknesses.
Apache Exploits: Includes .htaccess manipulation to execute PHP, mod_ssl heartbleed-like vulnerabilities, directory listing enabled by default, and misconfigured virtual hosts exposing sensitive files.
Directory Traversal: Using ../ sequences (or URL-encoded variants like %2e%2e%2f) to access files outside the web root. Can expose /etc/passwd, configuration files, and source code.
HTTP TRACE Method: Echoes back the request content — used in Cross-Site Tracing (XST) attacks to steal cookies or credentials. Should be disabled on production servers.
Nginx Misconfigurations: Includes improper fastcgi configuration, directory listing, default virtual host settings, and worker process privilege issues.
How to Study This Module
Know common vulnerabilities for IIS, Apache, and nginx specifically
Understand directory traversal techniques and URL encoding bypasses
Memorize which HTTP methods should be enabled/disabled on production servers
Frequently Asked Questions
What are common web server vulnerabilities? Misconfigurations (directory listing, default pages), outdated software versions, unnecessary modules, weak file permissions, enabled dangerous HTTP methods, and default credentials.
How do you secure IIS and Apache? Apply security patches, disable unnecessary modules/methods, configure proper file permissions, disable directory listing, remove default pages, and implement web server hardening guidelines.
Web Server Hacking covers attacks against the web server platforms themselves — IIS, Apache HTTP Server, and nginx — not the applications running on them. Unlike Module 14, which targets application-level flaws (XSS, SQLi), this module targets the server's own misconfigurations, parsing bugs, and protocol weaknesses. Web servers front most internet-facing systems, so compromising one is a high-priority objective. Module 13 topics account for approximately 10% of CEH v13 exam questions.
Key Concepts in Hacking Web Servers
IIS Path Parsing Vulnerability (.asp;.txt): IIS 6.0 parses extensions left to right, so a file named "evil.asp;.jpg" executes as ASP code even when uploaded as an image — bypassing filters that only block .asp/.aspx. IIS 7.0 switched to right-to-left parsing and closed this vector. Path-parsing bugs are version-specific: know which IIS version uses which order. Never trust extension filtering as your only defense against script execution.
Directory Traversal & URL Encoding Bypasses: "../" sequences navigate outside the document root to read arbitrary files — /page?file=../../../etc/passwd. When literal "../" is blocked, encodings get through: %2e%2e%2f (URL-encoded), ..%c0%af (UTF-8 overlong), ..%252e%252f (double encoding), backslash variants (..\..\). Know which variant defeats which filter. Defense: decode and normalize the path server-side before file access — pattern-matching raw input is not enough.
HTTP TRACE Method & XST Attacks: TRACE echoes the client's request back, including headers. In a Cross-Site Tracing (XST) attack, attacker-hosted JavaScript sends a cross-origin TRACE to the victim's authenticated session; without SameSite cookie protection or CORS restrictions, the page reads the Set-Cookie header from the echoed response and exfiltrates the session ID. Disable TRACE on production servers ( in IIS, Limit in Apache). OWASP lists XST as a lesser-known but valid cookie theft vector.
Web Server Hardening & Attack Surface Reduction: (1) Remove unnecessary modules and handlers — every loaded module is attack surface, (2) disable dangerous HTTP methods (TRACE, PUT, DELETE, OPTIONS), (3) remove default pages and test files (default.php, server-status), (4) lock down file permissions so the server user can't read system files, (5) disable directory listing (Options -Indexes in Apache, Directory Browsing in IIS), (6) add a Web Application Firewall (WAF) for defense-in-depth, (7) keep the OS and web platform patched. Hardening is ongoing — new vulnerabilities surface even in maintained platforms like Apache 2.4.x.
Common Exam Mistakes in Module 13
Confusing server-level with application-level targets: this module covers the platform itself — misconfigurations, outdated versions, exposed default pages, permissive HTTP methods, CGI and server-side include bugs. Script-level XSS or database payloads belong to Modules 14–15. Exam stems name the software layer; the answer key follows it.
Skipping header reconnaissance: curl -I, WhatWeb, and Nmap read Server and X-Powered-By headers to target known CVEs, spot weak TLS, and map the stack. First-step-against-an-unknown-server stems want banner and version discovery — not a payload.
Answering hardening questions with patching alone: the full control set is procedural — remove default and test pages, disable directory listing, restrict HTTP methods (deny TRACE, PUT, DELETE), enforce modern TLS with HSTS, add security headers, put a WAF in front. Update-only answers miss the configuration half.
Tools Used in Web Server Hacking
Tools the CEH v13 exam references for web server testing:
Nmap + NSE scripts: vuln scripts such as http-put, http-trace, http-methods, and http-apache-negotiation-check probe for exposed methods and module misconfigurations
WhatWeb: fingerprints web stacks at scale from response details — engine, version, and configuration traits
curl -I: the quick header check; Server and X-Powered-By reveal versions for targeted CVE lookups
Nikto: scans for known weak configurations and exposed test or default content across web servers
DirBuster / Gobuster: brute-force hidden directories, backup files, and admin interfaces (/admin/, *.bak) that never appear in navigation
crt.sh: certificate-transparency lookups enumerating the virtual hosts on one IP before host-header probing
Worked Example: From Default Page to Denied Method
A fresh staging box serves vendor default pages with directory listing on — versions, sample files, and paths for free. curl -I surfaces the server version; Nikto confirms exposed test scripts. After hardening removes the defaults and listing, testing moves to method abuse: TRACE is still accepted (the XST reflection path), and PUT writes a file into the web root.
The twist: the final gate is headers. X-Frame-Options: DENY blocks clickjacking iframes, HSTS closes the SSL-stripping window, nosniff blocks content-type tricks, and CSP limits the blast radius of injected code. The exam treats these as the server-hardening checklist — each header-to-attack pairing should be instant.
How to Study Web Server Hacking for the CEH v13 Exam
To study Module 13 for the CEH v13 exam:
Build a comparison table: Web Server (IIS/Apache/nginx) | Common Vulnerability | CVE Example | Attack Vector | Defense. Exam stems match a vulnerability to its platform and exploit mechanism — e.g., "Which web server is vulnerable to the .asp;.txt path parsing bug?" (Answer: IIS 6.0)
Hands-on: set up a vulnerable web server VM (Metasploitable or OWASP WebGoat). Use DirBuster to find hidden directories, Burp Suite Repeater to test TRACE/PUT, and attempt directory traversal on parameterized URLs. Document which attacks succeed on default configs and which changes block them — this maps directly to hardening questions
Memorize the traversal encodings: %2e%2e%2f (URL-encoded), ..%c0%af (UTF-8 overlong null), ..%252e%252f (double encoding), backslash (..\) variants. Exam stems show an attack string and ask which filter it defeats
Frequently Asked Questions About Web Server Hacking
How do you determine which web server a target is running?
(1) Server header — often shows platform and version ("Server: Microsoft-IIS/7.5", "Server: Apache/2.4.41 (Ubuntu)", "Server: nginx/1.18.0") unless suppressed by hardening; (2) error pages — server-specific pages leak versions (IIS blue screen, Apache error page, nginx 50x page); (3) file extensions — .asp/.aspx indicate IIS with ASP.NET, .php suggests Apache or nginx with PHP-FPM, .do/.action suggest Java application servers; (4) default paths — /iissamples/ for IIS, /server-status for Apache, /nginx_status for nginx; (5) Nmap -sV and web-server fingerprinting NSE scripts. Header analysis is fastest but unreliable on hardened servers — error-page analysis is the fallback.
Why are unnecessary web server modules a security risk?
Each loaded module adds attack surface. mod_php loads PHP inside Apache (vs PHP-FPM, which runs separately) — a PHP memory corruption bug can crash or compromise Apache itself. mod_negotiation acts on client Accept headers — misconfigured, it allows directory listing and file access via partial filename matching. IIS's ASP.NET handlers process .aspx requests — with an insecure ViewState configuration, an attacker can forge server authentication state. Principle: if the app doesn't use a module, disable it. OWASP Top 10 "Security Misconfiguration" (A05) includes unnecessary modules enabled. Keep a documented baseline of required modules and audit the running config against it.