红蓝攻防
点击放大


**A modern, standalone browser-hooking framework for red teams, security
researchers, and educators — a clean-room successor to BeEF and the blind-XSS
callback tools we live in.**
> FOR AUTHORIZED SECURITY TESTING, RESEARCH & EDUCATION ONLY. WRAITH is an
> offensi tool for demonstrating and testing phishing /
> man-in-the-browser / blind-XSS tradecraft. Only use it against systems and
> people you have explicit authorization to test. You are responsible for how
> you use it.
!WRAITH operator console
---
Over the course of our work at Arcanum, we kept reaching for two different
kinds of tooling and wishing they were one thing.
On one side was BeEF — the Browser Exploitation Framework — for the classic
*hook a browser, then work from inside its session* workflow: keylog a fake login,
recon the local network, push a module at a li. It's the tool we used to
make man-in-the-browser real to people. But it's showing its age, big chunks of it
are unreliable in today's browsers, and the social-engineering o look like
logins from a decade ago.
On the other side were our fa blind-XSS callback frameworks (XSS Hunter,
ezXSS): drop a payload into a field, and the instant it fires somewhere you can't
see, it calls home with the loot — origin, cookies, DOM, a screenshot.
What we increasingly needed — especially as more of our targets became **AI
application ecosystems**, where untrusted text flows through agents, tool outputs,
admin review queues, and support consoles, and *fires Ja in places nobody
is watching* — was a single framework that did both: the interactive,
persistent post-exploitation control of a BeEF hook, and the fire-and-forget
blind-XSS callback loot, in one payload that's reliable in current browsers and
looks like today's real login screens.
So we built WRAITH.
We're releasing WRAITH early, and on purpose. We'd rather get it into the
hands of the people who'll actually use it — and hear what breaks — than sit on it
until it's "done."
That means: expect rough edges and bugs. Some modules are more battle-tested
than others, browser behavior shifts under us constantly (see the network-scan
notes below), and APIs may change between . If you hit something, please
open an issue — repro steps,
browser + , and what you expected are gold. PRs welcome under the project's
contribution terms.
---
The fastest path. You need Docker + Docker Compose.
setup.sh walks you through e:
1. Detects your public IP (or lets you enter a domain / custom host) so every
hook and payload URL is minted with *your* address.
2. Has you set an operator username + password for the console login.
3. Generates the session-signing secret, writes a gitignored .env (chmod 600),
and builds + starts the container.
4. Prints your live URLs and a drop-in XSS payload at the end:
Manage it with standard compose commands:
Captured sessions persist in ./data/ on the host — never baked into the
image, never committed (.env and data/ are gitignored).
The operator console is login-gated whenever an operator password is set, with
a username + password sign-in:
!Operator login
Then open the operator console at and the demo
page at (in a second browser/profile). On
localhost, login is disabled by default for con — the server refuses
to bind to a public interface without an operator password, so you can't
accidentally expose an open panel.
---
/hook.js is a small payload. Drop it in any page you control
(<script src="/hook.js"></script>) or deliver it via an XSS in your target. The
browser that loads it opens a WebSocket back to the operator, fingerprints itself
(browser, OS, IP, page, UA), auto-reconnects, and survi. Every
hooked browser shows up live in the console, where you pick one and drive it — the
full dashboard is the hero shot at the top of this README: hooked-browser roster,
target detail, deploy controls, li feed, and captured credentials.
Modernized fake-login o, rendered in an isolated shadow DOM so they
look pixel-correct on any host page and frost-blur the page behind them like a
real re-auth modal. Ships with LinkedIn, Facebook, and **Microsoft /
Office 365** (authentic two-step email → password).
!LinkedIn re-auth o over a host page
Every character the target types into an o streams to the console in real
time, and the submitted credentials land in Captured Credentials — all
persisted so nothing is lost on refresh or restart.
!Li and captured credential
The instant a browser hooks, WRAITH auto-fires Page Capture: exactly what a
blind-XSS framework grabs when your payload fires somewhere you can't see —
where it fired (origin + URL + referrer), the 's cookies
(non-HttpOnly), the full DOM, and a screenshot. Failures are reported
honestly, because they *are* the lesson: HttpOnly cookies ne, and CSP or
cross-origin can can block the screenshot.
!Page Capture blind-XSS loot
This is where WRAITH goes further than the tools it replaces. When you land a
blind XSS or a hook in a page, most frameworks stop at a **screenshot and a dump
of raw HTML** — you can see *where* your payload fired, but you can't actually *do*
anything with it.
WRAITH's Page Mirror turns that dead-end loot into a **li view of
the application**. Open the hooked page as a real, rendered browser view inside the
operator console — then click links and mo the app , just
like the would.
!Page Mirror — a li view of the hooked page
The key: every na is fetched *through the hooked browser*, so it rides
the 's session and same-origin trust. Any page, endpoint, or feature the
's session can reach, you can reach too — including pages gated behind an
authenticated session cookie you never see (and, being HttpOnly, could ne
outright).
In the example below, we start on a support-agent's ticket queue and click
straight through to an internal Credential Vault — a page that only resolves
inside an authenticated agent session. No credentials phished, no cookie stolen:
we simply rode the 's session to it.
!Page Mirror reaching a session-gated vault through the
> Cross-origin reads still fail by design (the Same-Origin Policy holds) — the
> mirror's reach is exactly the 's reach, no more, no less. That boundary is
> itself part of the lesson.
An XSS-Hunter-style catalog of ready-to-fire injection strings for every context
(HTML, attribute breakout, tag-close, event handlers, JS context, ja:
URIs, jQuery), each auto-filled with your hook URL and one-click copyable.
!Blind-XSS payload catalog
Uses the hooked browser as a proxy to fingerprint the 's local services.
It's a timing side-channel, rebuilt for current browsers — the reliable default
is a *calibrated* 127.0.0.1 scan using two independent primitives (fetch- and
WebSocket-timing, the literal eBay check.js method). LAN modes are included but
honestly labeled, because Chrome 142+ Local Network Access now gates them (see
below).
A deliberately "support desk" at /lab with a stored-XSS sink, so you
can demo the whole chain end to end, same-origin: submit a malicious ticket → an
"agent" reviews the queue and the payload fires (the blind-XSS moment) → Page
Mirror the hooked agent and pull the session-gated vault. Intentionally insecure by
design, with planted flags.
!The built-in practice lab
---
The hook fires the moment it loads, exactly like a blind-XSS payload dropped into a
stored field that later renders in some admin/support/log/agent context you can't
see. Lessons surfaced right in the data:
For an offline lab, self-host html2canvas — see public//README.md.
Ja cannot read cross-origin responses, but it can start a request and watch
how it fails and how fast, which leaks port state. The module was rebuilt around
what works in current browsers (2025–2026), because the old BeEF-era LAN sweep
is now dead.
The modern reality: Chrome 142+ (Oct 2025) shipped **Local Network Access
(LNA), which gates requests to private ranges (10.x / 172.16.x / 192.168.x**)
behind a permission prompt. A blind LAN sweep no longer reaches the wire. But
loopback (127.0.0.1) is still reachable, and scanning it is the real-world
attack — eBay, Best Buy, and others were caught port-scanning ' localhost
to fingerprint local services and remote-access tools.
So the module has three modes:
127.0.0.1 scan that probes each port with fetch-timing and WebSocket-timing,| BeEF | WRAITH |
|---|---|
| hook.js + XHR polling | public/hook.js + WebSocket (li) |
| Ruby server + RESTful API | server.js (Node + ws) |
| Online/offline browsers panel | Operator console "Hooked Browsers" |
| Pretty Theft module | o modules/*.js (modern LinkedIn/Facebook/Microsoft) |
| Network discovery / port scanner | modules/portscan.js (calibrated, current-browser) |
| Command results | Li + Captured Credentials + Scan Results |
| *(no equi)* | Page Capture (blind-XSS loot) + Page Mirror (na the app) |
These tools live at different stages of the attack and abuse **different trust
contexts**. They're complementary, and they chain together.
| | WRAITH / BeEF | Blind-XSS frameworks (XSS Hunter, ezXSS) | AiTM proxies (E, E, Modlishka) |
|---|---|---|---|
| What it is | Man-in-the-browser post-exploitation C2 (+ blind-XSS loot) | XSS detection + proof with one-shot recon | Ad reverse proxy |
| Prerequisite | You already have JS running in the page | Same: your payload executes somewhere you can't see | clicks a link and logs in on your lookalike domain |
| Origin it abuses | The 's real session / real origin | The app's origin | A separate attacker domain proxying the real site |
| What you capture | Creds + keystrokes + recon + blind-XSS loot + na the app via Page Mirror | "It fired, and here": DOM, cookies, screenshot, origin | Real creds and the post-MFA session token |
| Beats MFA? | No — you phished a static credential | Only if it rides a li session in-page | Yes — stealing the post-auth session cookie is the point |
The honest distinction to teach: our o phish harvests **what the user
types — it does not** capture a real session or beat MFA. That's exactly why
it's a great contrast, and why the industry moved to **phishing-resistant,
origin-bound auth (FIDO2 / WebAuthn / passkeys)**. A realistic kill chain uses all
three: blind XSS finds and delivers code execution, a WRAITH hook gi
in-session control (and, via Page Mirror, reaches app functionality directly), and
a redirect can funnel the into an E flow for a real MFA-passed
session.
E is en; the same build runs anywhere because hook.js derives
its call-back URL from wherever it was served. setup.sh writes these into .env.
| Env var | Default | Purpose |
|---|---|---|
| WRAITH_HOST | 127.0.0.1 | bind interface (0.0.0.0 to expose; forced in Docker) |
| WRAITH_PORT | 3000 | HTTP + WebSocket port (setup.sh defaults to 8090) |
| WRAITH_PUBLIC_URL | *(derived)* | your IP/domain, used to print correct hook URLs |
| WRAITH_OP_USER | *(empty)* | operator login username (optional; setup.sh sets one) |
| WRAITH_OP_PASSWORD | *(empty)* | operator login password; required to bind publicly |
| WRAITH_SECRET | *(random/boot)* | signs session cookies; set it to keep logins across restarts |
| WRAITH_SESSION_HOURS | 12 | operator session lifetime |
| WRAITH_AUTOCAPTURE | 1 | auto-fire Page Capture on hook (0 = manual, BeEF-style) |
A signed HttpOnly session cookie covers both the panel and the li. The
hook payload, demo page, and /ws/hook channel stay public so can reach
them. As a fail-safe, the server refuses to bind to a public interface unless a
password is set.
For a bare-metal / systemd deployment instead of Docker, see
deploy/DEPLOY.md.
WRAITH is © 2026 Arcanum Information Security, released under the
Apache License 2.0.
You're free to use, modify, and redistribute it — including in your own training —
but you must keep the attribution: retain the LICENSE and NOTICE files and
the Arcanum copyright notice in anything you distribute or fork, and state any
changes you made (Apache-2.0 §4). See NOTICE. The license does not grant
use of the Arcanum name or marks beyond describing where the code came from.
Built with ❤️ by Arcanum — <
开发语言:JavaScript
Star 数:154
该项目属于红蓝攻防方向的开源资源,代码结构清晰,适合安全研究人员学习参考。项目围绕WRAITH — a modern browser-hooking framework (BeEF + blind-XSS successor) for red teams, researchers, and educators. For authorized security testing, research & education only.展开,提供了可运行的实现,对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。
从技术实现角度看,此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论,梳理项目的初始化流程、核心模块职责与数据流转,逐步掌握其中的技术细节与设计思路。
1. 下载源码压缩包,解压到本地环境。
2. 根据项目类型准备对应的运行环境与依赖。
3. 按照 README 中的步骤完成配置与部署。
4. 在隔离的测试环境中运行验证,避免影响生产系统。
本资源来源于开源社区,仅供安全研究、技术学习与合法授权范围内的攻防演练使用,请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。
| 资源标题 | wraith - WRAITH — a modern browser-hooking framework (BeEF |
| 所属分类 | 红蓝攻防 |
| 发布作者 | admin |
| 发布时间 | 2026-10-06 00:49:08 |
| 下载权限 | 免费下载 |
| 附件数量 | 2 个下载链接 |
| 浏览次数 | 191 |
| 讨论数量 | 0 |
| 主题状态 | 正常讨论中 |