36. More Essential Kali Tools

36.3 WhatWeb Command: Detect Website Technology (and Wappalyzer)

By Ravindra Bagale · Last updated: 27 October 2026

Short answer: Install WhatWeb on Kali, point it at a lab URL you own, read the server/CMS hints, then cross-check with headers or Wappalyzer. Never scan strangers.

sudo apt install -y whatweb
whatweb http://192.168.56.20
whatweb -a 3 -v http://192.168.56.20/dvwa/

Why technology fingerprinting matters

Attackers want to know your stack. If they see old PHP or WordPress, they search for a matching bug. Defenders use the same idea to inventory what they run.

What: Fingerprinting guesses web server, language, CMS and libraries from public signals.

How: Tools read HTTP headers, cookies, HTML comments, script paths and known plugin patterns.

What you need (lab only)

1. A Kali Linux VM (or any Debian/Ubuntu box).
2. A target you own, such as DVWA on http://192.168.56.20.
3. Written permission if the target is not yours.

How to run the WhatWeb command

Why: One command gives a first map of the site.

What: WhatWeb is a CLI fingerprinting tool that ships with Kali.

How: follow these steps.

1. Install if needed:

   sudo apt update
   sudo apt install -y whatweb
   whatweb --version
   

   Sample output:

   WhatWeb version 0.5.5
   

   Meaning: the tool is ready.

2. Run a calm scan on your lab home page:

   whatweb http://192.168.56.20
   

   Sample output:

   http://192.168.56.20 [200 OK] Apache[2.4.41], Country[RESERVED][ZZ], HTML5,
   HTTPServer[Ubuntu Linux][Apache/2.4.41 (Ubuntu)], IP[192.168.56.20],
   PHP[7.4.3], Title[DVWA], X-Powered-By[PHP/7.4.3]
   

   Meaning: Apache on Ubuntu, PHP 7.4, page title DVWA. Versions are hints only.

3. Raise aggression only in the lab (more plugins, more requests):

   whatweb -a 3 http://192.168.56.20/dvwa/
   

   Meaning: level 1 is passive; 3 probes harder. Do not use high aggression on production you do not own.

4. Add verbose mode when you teach or write a report:

   whatweb -v http://192.168.56.20
   

   Meaning: longer detail per plugin match.

5. Save output for your notes:

   whatweb -a 3 http://192.168.56.20/dvwa/ | tee ~/lab-whatweb.txt
   

   Meaning: you keep evidence for the worksheet.

Example: Priya fingerprints her Pune lab

Priya runs DVWA on a VirtualBox host in Pune. She runs whatweb http://192.168.56.20/dvwa/. She sees X-Powered-By[PHP/7.4.3]. She does not download an exploit. She opens the Apache/Nginx config, removes the version header, reloads, and scans again. The header is gone. That is the defender path.

Example: James cross-checks with curl in London

1. Fetch headers only:

   curl -sI http://192.168.56.20/dvwa/ | sed -n '1,20p'
   

   Sample output:

   HTTP/1.1 200 OK
   Server: Apache/2.4.41 (Ubuntu)
   X-Powered-By: PHP/7.4.3
   Set-Cookie: PHPSESSID=...
   

   Meaning: curl confirms WhatWeb. Always cross-check.

2. Compare with the free Phishing Link Checker only for suspicious URLs; for stack checks stay with WhatWeb + curl.

Wappalyzer in the browser

Why: Managers and analysts often prefer a visual stack list.

What: Wappalyzer (browser extension) shows technologies while you browse.

How:

1. Install the official extension from the Chrome or Firefox store.
2. Open your lab site only.
3. Read the sidebar: CMS, frameworks, analytics, CDNs.
4. Write "stack observed" in your lab report. Do not treat it as a CVE list.

How to harden against fingerprinting

1. Hide nginx version: see guide Secure nginx: hide server version headers (draft) and live lesson on nginx hardening when deployed.
2. Remove X-Powered-By in PHP-FPM / Apache.
3. Use generic error pages (no stack traces).
4. Patch on a schedule. Hiding versions without patching is theatre.
5. Check headers with curl security headers guide (draft) and the Website Security Checklist.

Common mistakes

• Scanning random public sites. That can be illegal.
• Trusting one version string and running an exploit. False positives happen.
• Leaving Server and X-Powered-By on production "for debugging".
• Using aggression level 4 against a shared staging host without asking.

Extended teaching notes

Why this lesson matters

A SOC turns logs into action. Good juniors triage with playbooks: what fired, which asset, how bad, contain or escalate, write the timeline.

1. Prepare: asset list, contacts, runbooks.
2. Detect: SIEM/EDR alerts with context.
3. Contain: disable account, isolate host, block IOC.
4. Eradicate & recover: patch, rebuild, restore.
5. Lessons: one improvement ticket per incident.

Indian company (sample)

A 24×7 SOC at a large Indian IT services firm handles phishing and malware for many clients. Tier-1 analysts follow a script; they do not freestyle on production.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

1. Write the lesson title, date and the exact lab target you are allowed to use.
2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
3. Run one safe check from the lesson on a lab system only. Paste the command and output.
4. Write a two-sentence fix you would give a teammate.
5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

• Control: a safeguard (patch, config, process, detection).
• Finding: a weakness backed by evidence.
• Remediation: the fix plus how you verified it.
• Scope: systems you have written permission to touch.
• Least privilege: only the access the task needs.
• Defence in depth: several layers so one failure does not end the story.

Common mistakes

• Skipping written permission "just for a quick scan".
• Practising on hostel, office or public targets without authorisation.
• Collecting tool output without writing the fix.
• Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
• Publishing screenshots that contain secrets, cookies or internal hostnames.