Attack Path: Client-Side Browser Exploitation Chain

[samugit83]

Description

Implement a dedicated classified attack path for client-side browser exploitation — targeting the victim's browser via malicious pages, browser_autopwn2, and JavaScript-based payloads.

Why the unclassified fallback isn't enough

Client-side attacks have a fundamentally different topology from server-side exploits — the target connects to YOU, not the other way around:

1. Reversed connection model: in CVE exploitation, the agent connects to the vulnerable server. In client-side exploitation, the agent hosts a malicious server and the victim visits it. This inverted model requires setting up auxiliary/server/browser_autopwn2 or crafting a custom page, getting the URL, and delivering it — a multi-phase workflow the unclassified path doesn't guide.
2. Browser fingerprinting determines the payload: browser_autopwn2 automatically selects exploits based on the victim's User-Agent (IE vs Chrome vs Firefox, OS, Java/Flash version). The agent needs to understand that it cannot pre-select the exploit — the module does it dynamically. Without workflow prompts, the agent tries to manually configure individual browser exploit modules instead of using autopwn's automatic selection.
3. Delivery requires social engineering integration: the malicious URL must reach the victim. This means the client-side chain must integrate with the phishing workflow (email the link, embed in a document, use DNS spoofing to redirect). Without classified routing, the agent doesn't connect these two paths.
4. JavaScript payload knowledge: modern client-side attacks use BeEF (Browser Exploitation Framework) hooks, XSS-to-session-hijacking chains, and JavaScript keyloggers. These aren't Metasploit modules — they require execute_code to craft custom JS payloads and execute_curl to inject them via stored XSS. The agent needs explicit guidance on when to use Metasploit browser modules vs custom JS.
5. Session type differs: browser exploits often yield a browser-context session (limited sandbox), not a full Meterpreter. The agent must know to escalate from browser sandbox → OS-level access, which is a different post-exploitation path than standard Meterpreter.

What already exists

• Metasploit browser exploit modules (Category 9 in README.ATTACK_PATHS.md)
• browser_autopwn2 auxiliary module
• Phishing/social engineering classified path (for delivery)
• Handler setup workflow (shared with phishing path)
• Tunnel support (ngrok/chisel) for reachable URLs

What needs to be built

• New attack path classification: client_side_browser_exploitation
• Workflow prompts for the server-setup → delivery → session pipeline
• browser_autopwn2 integration with automatic exploit selection guidance
• Custom JavaScript payload crafting guidance (BeEF hooks, XSS chains, keyloggers)
• Cross-reference with phishing path for URL delivery
• Browser sandbox escape / post-exploitation escalation guidance
• URL generation and tunnel integration for victim-reachable endpoints