Client-Side Browser Exploitation Lab

Overview

What this lab demonstrated

The Windows VM visited a Kali-hosted page, retrieved a test payload, and opened a reverse session to the lab handler.

Testing used isolated, self-managed course VMs. The archived browser ran with its sandbox disabled; the result does not demonstrate a bypass of a current browser sandbox.

Troubleshooting & Validation

What made the lab work

• Matching the browser build and architecture to the exploit target was essential.
• Using --no-sandbox reduced browser isolation for the controlled demonstration.
• Separating the exploit web server, payload server, and reverse handler made it possible to validate each stage independently.
• Server logs and session output were more reliable proof of success than the browser screen alone.

Defender Takeaways

What defenders could observe

• A browser unexpectedly launching a child process is suspicious endpoint behavior.
• An executable download from an unusual internal host is useful network and endpoint evidence.
• Unexpected outbound connections from a browser process can indicate compromise or post-exploitation activity.
• Browser patching, sandboxing, least privilege, and endpoint monitoring reduce risk and improve detection.