hoodoer/js-tapJavaScript beacons and C2 to be used for XSS payload or post exploitation implants on webapp servers or desktop software to monitor users and maintain persistence. Browser extension, electron app, and node/bun app implants are included.
Major changes are documented in the project Announcements:
https://github.com/hoodoer/JS-Tap/discussions/categories/announcements
You can read the original blog post about JS-Tap here:
https://trustedsec.com/blog/js-tap-weaponizing-javascript-for-red-teams
Short demo from ShmooCon of JS-Tap version 1:
https://youtu.be/IDLMMiqV6ss?si=XunvnVarqSIjx_x0&t=19814
Demo of JS-Tap version 2 at HackSpaceCon, including C2 and how to use it as a post exploitation implant:
https://youtu.be/aWvNLJnqObQ?t=11719
Demo of the automatic payload generator, uses intercepted form posts and JavaScript network traffic as a blueprint for generating custom C2 payloads:
https://www.youtube.com/watch?v=cU915mxLfTo
Demo at CactusCon of v2 including mimic feature:
https://youtu.be/O7-zxAmP13o?si=gchYwOJksutCCUPH
Demo of v3 Beacons, beta code:
https://youtu.be/-esrfSHqZeo
I do not plan on creating migration scripts for the database, and version number bumps often involve database schema changes (check the changelogs). You should probably delete your jsTap.db database on version bumps. If you have custom payloads in your JS-Tap server, make sure you export them before you delete the database files.
JS-Tap is a JavaScript-based offensive toolkit for red teamers. It started as a generic JavaScript payload for attacking webapps via XSS or post-exploitation implant, and has grown to include browser extensions and Electron desktop app implants — all reporting to a single C2 server.
The payload does not require the targeted user running the payload to be authenticated to the application being attacked, and it does not require any prior knowledge of the application beyond finding a way to get the JavaScript into the application.
Instead of attacking the application server itself, the JS-Tap payload focuses on the client-side of the application and heavily instruments the client-side code. A C2 system allows custom JavaScript payloads to be added and run as tasks on JS-Tap clients, providing a means to attack the application server directly. To facilitate faster transition to attacking the server, JS-Tap now includes a "mimic" feature to automatically generate custom payloads and hand them off to the C2 system.
The example DOM Beacon payload is contained in the telemlib.js file in the payloads directory, however any file in this directory is served unauthenticated so you can serve multiple payloads with different configurations targeting different applications at the same time.
Copy the telemlib.js file to whatever filename you wish and modify the configuration as needed. This file has not been obfuscated. Prior to using in an engagement strongly consider changing the naming of endpoints, stripping comments, and highly obfuscating the payload. By default the application uses rather obvious API endpoints (e.g. /loot/screenshot), in App Settings you can turn on traffic obfuscation.
Make sure you review the configuration section below carefully before using on a publicly exposed server.
JS-Tap has five beacon/agent types that connect to the same server:
| Beacon Type | What It Is | How It Gets There |
|---|---|---|
| DOM Beacon (telemlib.js) | A JavaScript payload injected into a web page. Instruments the DOM, captures user activity, screenshots, network calls. | XSS vulnerability, or directly added to the target app's JavaScript files (post-exploitation). |
| BEX Beacon | A browser extension (Chrome MV3 / Firefox MV2). Monitors all browsing activity, captures cookies (including httpOnly), localStorage, sessionStorage, and request headers. Can inject DOM Beacons into specific domains on command. | Installed in the target's browser (social engineering, physical access, policy push, etc.). |
| Sidecar | A native Go binary that runs on the target's OS. Provides file system browsing, file reading, and command execution. | Installed alongside the BEX Beacon via native messaging. Requires the BEX Beacon to relay commands. |
| Atom Beacon | A dual-layer implant for Electron desktop applications. Injects a main-process agent (Node.js runtime) + renderer payloads into all app windows. Combines browser-level data collection with host-level OS access — no separate binary needed. Supports browser proxy mode. | Patched into the target Electron app's ASAR archive (or unpacked app directory) using atomize.py. |
| V8 Beacon | A JavaScript agent for Node.js and Bun CLI applications (Gemini CLI, Claude Code, etc.). Intercepts all HTTP/Fetch network calls, captures keystrokes, and provides file system and shell access. Supports browser proxy mode. Zero dependencies. | Injected via environment variable: NODE_OPTIONS="--require" (Node.js) or BUN_OPTIONS="--preload" (Bun). No app patching needed. |
All five report back to the same JS-Tap server portal, where loot is viewed and C2 commands are issued.
The portal also includes two session-cloning tools:
| Tool | What It Does |
|---|---|
| Browser Proxy | A MITM proxy on the JS-Tap server that routes the operator's HTTP/HTTPS traffic through the victim's browser (or Node.js process) via WebSocket. Requests are fetched from the victim's network context, so the target site sees the victim's IP and TLS fingerprint. Combine with a Session Ticket for authenticated browsing through the victim's network. Supported by BEX, Atom, and V8 Beacons. See Browser Proxy below. |
| JS-Tap Conductor | A standalone Firefox extension that imports session data captured by the BEX Beacon (as a "JS-Tap Ticket") and replays it locally — setting cookies, injecting headers, populating storage, and spoofing the User-Agent — so the operator can browse as the victim. See JS-Tap Tickets & JS-Tap Conductor below. |
Standalone DOM Beacon: The DOM Beacon payload (telemlib.js) works independently. Inject it via XSS or implant it in the target's JS files. It calls home to the JS-Tap server on its own.
BEX Beacon as a dropper: The BEX Beacon monitors browsing and collects passive intelligence (cookies, localStorage, sessionStorage, request headers, navigation). From the JS-Tap portal, you can command the beacon to inject a DOM Beacon into a specific domain. The DOM Beacon spawned by a BEX Beacon gets high-quality screenshots via the extension's captureVisibleTab API (the "BEX-Assist" mode).
Sidecar for OS access: When installed, the Sidecar binary gives the BEX Beacon access to the underlying operating system. Commands are sent from the JS-Tap portal, relayed through the beacon's encrypted channel to the native binary, and results are sent back. This turns a browser extension into a foothold for file system access and command execution.
Browser Proxy for live browsing: The operator configures their browser to use the JS-Tap proxy and all HTTP/HTTPS traffic is routed through the victim's browser in real time. The proxy performs MITM TLS termination (with an auto-generated CA) so the operator can browse HTTPS sites. The proxy is a "dumb pipe" — it forwards exactly what the operator's browser sends. For authenticated browsing, combine with a Session Ticket: the JS-Tap Conductor injects the victim's cookies, headers, and User-Agent into the operator's browser, the MITM proxy forwards those to the beacon, and the beacon fetches from the victim's network. This gives the operator an authenticated session from the victim's IP address. BEX, Atom, and V8 Beacons all support proxy mode.
