BlueKit PhaaS: Browser-in-the-Middle bằng rrweb — khi trang đăng nhập bạn nhìn thấy chạy trên máy kẻ tấn công

Tóm tắt

BlueKit là một nền tảng Phishing-as-a-Service (PhaaS) được Varonis ghi nhận lần đầu vào tháng 4/2026, và đến cuối tháng 6/2026 đã được Netcraft xác nhận hoạt động ở quy mô thực tế với khoảng 70 hostname mới xuất hiện chỉ trong một tuần. Điểm khiến BlueKit đáng chú ý không phải số lượng template, mà là bước chuyển kỹ thuật: từ Adversary-in-the-Middle (AitM) kiểu reverse-proxy sang Browser-in-the-Middle (BitM) dựng trên thư viện session-replay hợp pháp rrweb.

Rủi ro kinh doanh cốt lõi: với BitM, trang đăng nhập mà nạn nhân tương tác thực chất chạy trong một trình duyệt do kẻ tấn công điều khiển. Nạn nhân nhập username, password và cả mã MFA vào một phiên mà attacker đã sở hữu — khi xác thực hoàn tất, token phiên hợp lệ nằm sẵn trên máy kẻ tấn công. Hệ quả quan trọng nhất cần nắm: Device Bound Session Credentials (DBSC) — một trong những kỳ vọng lớn để chặn đánh cắp phiên — không bảo vệ được trước BitM, dù nó có tác dụng với AitM. Hành động ưu tiên: đẩy nhanh triển khai MFA kháng phishing (FIDO2 / passkey), vì đây là lớp phòng thủ hiếm hoi vẫn đứng vững trước cả AitM lẫn BitM.

BlueKit là gì — một PhaaS "all-in-one"

BlueKit được đóng gói như một dịch vụ trọn gói, hạ thấp gần như toàn bộ rào cản kỹ thuật để dựng một chiến dịch phishing. Theo phân tích của Varonis, nền tảng cung cấp:

• Hơn 40 template mạo danh các dịch vụ phổ biến: Outlook, Hotmail, Gmail, Yahoo, ProtonMail, iCloud, Apple ID, GitHub, Twitter/X, Zoho, Ledger, Zara...

• Tích hợp mua và đăng ký domain ngay trong nền tảng, dựng trang phishing và quản lý chiến dịch từ một bảng điều khiển.

• Exfil qua Telegram private channel — credential và session lấy được đẩy thẳng về kênh riêng của operator.

• Giám sát phiên nạn nhân theo thời gian thực, với chu kỳ cập nhật khoảng 5 giây: cookie, localStorage, trạng thái phiên trực tiếp và cả hoạt động sau khi đăng nhập.

• Bộ lọc anti-analysis chi tiết: chặn VPN/proxy, chặn user-agent headless, lọc theo fingerprint để loại bỏ môi trường phân tích. Mô hình dịch vụ này nghĩa là người vận hành một chiến dịch BlueKit không cần biết BitM hoạt động ra sao — họ chỉ chọn template, gắn domain, và nhận credential về Telegram.

AI Assistant — cybercrime bắt đầu nhúng LLM

Một thành phần mới trong BlueKit là AI Assistant panel hỗ trợ soạn nội dung email phishing, với khả năng chọn giữa nhiều mô hình: Llama, GPT-4.1, Claude, Gemini và DeepSeek. Cần đặt đúng mức độ: Varonis đánh giá tính năng này còn ở giai đoạn sơ khai — đầu ra nhiều nội dung placeholder và mới dừng ở mức phác khung chiến dịch, chưa tạo ra một luồng phishing hoàn chỉnh chạy được ngay.

Dù còn thô, sự hiện diện của nó phản ánh một xu hướng rõ: LLM đang được nhúng trực tiếp vào công cụ tội phạm mạng như một tính năng bán kèm, không còn là thứ operator phải tự xoay xở bên ngoài. Với đội phòng thủ, điều này báo hiệu chất lượng ngôn ngữ của email phishing sẽ đồng đều hơn, khó lọc bằng dấu hiệu "văn vụng" như trước.

Cơ chế BitM bằng rrweb — phần lõi

Điểm khác biệt kỹ thuật thật sự nằm ở cách BlueKit giao trang đăng nhập. Thay vì reverse-proxy lưu lượng như Evilginx, BlueKit chạy trang login thật trong một trình duyệt do kẻ tấn công điều khiển, rồi phát lại giao diện đó cho nạn nhân bằng rrweb — một thư viện session-replay mã nguồn mở vốn dùng hợp pháp để ghi và tái dựng phiên người dùng phục vụ debug/analytics.

rrweb là công cụ hợp pháp — bản thân việc một trang có nhúng rrweb không phải bằng chứng độc hại. Điều nguy hiểm là kỹ thuật này bị tái mục đích để trung chuyển một phiên đăng nhập thật.

Quá trình chia làm hai pha:

Pha 1 — Anti-analysis & sàng lọc nạn nhân

Trước khi giao payload BitM, BlueKit chạy một lớp sàng lọc để loại bỏ môi trường của nhà nghiên cứu và hệ thống tự động:

• Thao túng CSS filter ngẫu nhiên trên trang, làm sai lệch pixel-hash để né các hệ thống so khớp ảnh trang phishing.

• JavaScript obfuscate kích thước lớn (>1MB), xoay vòng liên tục để cản phân tích tĩnh và signature.

• Custom CAPTCHA mạo danh chính brand bị giả hoặc Cloudflare, với HTML sinh ngẫu nhiên mỗi lần load nhằm chống fingerprint theo cấu trúc trang.

• Fingerprint trình duyệt/thiết bị: RAM, số nhân CPU, ngôn ngữ, độ phân giải, phát hiện headless, và các extension chống-fingerprint.

• Phát hiện WebRTC IP mismatch — so IP công khai với IP lộ qua WebRTC để phát hiện analyst đang ẩn sau proxy/VPN. Chỉ những truy cập "qualified" (giống nạn nhân thật) mới được đẩy sang pha hai.

Pha 2 — Giao payload BitM

• Hạ tầng attacker mở trang đăng nhập hợp pháp trong một trình duyệt mà chúng kiểm soát.

• rrweb serialize toàn bộ DOM của trang đó và stream qua WebSocket về phía nạn nhân.

• Trình duyệt nạn nhân render native (không phải ảnh chụp hay video) — nên giao diện trông y hệt trang thật, tương tác mượt.

• Các asset (ảnh, script, style) được lấy qua một proxy API thay vì tải trực tiếp từ nhà cung cấp thật.

• Khi nạn nhân nhập thông tin và mã MFA, dữ liệu được relay ngược về trình duyệt của attacker; quá trình xác thực hoàn tất ngay trên máy attacker, để lại một session token hợp lệ.

• Operator theo dõi toàn bộ qua admin panel thời gian thực và tiếp tục quan sát hoạt động sau đăng nhập. Vì người dùng thật hoàn tất luồng đăng nhập trên chính hạ tầng của attacker, kẻ tấn công thu được session đã xác thực đầy đủ — vượt qua MFA mà không cần crack yếu tố thứ hai.

BitM khác Evilginx (reverse-proxy AitM) ở đâu

Tiêu chí	AitM / reverse-proxy (Evilginx)	BitM (BlueKit + rrweb)
Ngữ cảnh thực thi trang login	Chạy trên máy nạn nhân, lưu lượng đi qua proxy trung gian	Chạy trên trình duyệt của attacker, phát lại giao diện cho nạn nhân
Cách chiếm phiên	Bắt cookie/token khi chuyển tiếp giữa nạn nhân và dịch vụ	Session hoàn tất sẵn trên máy attacker → token nằm sẵn ở đó
Fingerprint phía dịch vụ	Có nguy cơ mismatch (IP/thiết bị của proxy khác nạn nhân) → tín hiệu phát hiện	Nhất quán hơn: phiên thật diễn ra trong một browser attacker duy nhất
DBSC (Device Bound Session Credentials)	Có thể giảm thiểu (ràng token vào thiết bị)	Không bảo vệ được — session sinh ra ngay trên thiết bị attacker
Chi phí hạ tầng	Nhẹ hơn (chỉ proxy lưu lượng)	Nặng hơn (phải chạy browser thật + stream DOM)

Điểm mấu chốt để đội phòng thủ ghi nhớ: nhiều cơ chế chống AitM dựa trên việc phát hiện sự bất nhất giữa phiên proxy và nạn nhân. BitM làm mờ chính tín hiệu đó, vì phiên đăng nhập thật sự diễn ra trong một trình duyệt attacker mạch lạc — và DBSC, vốn được kỳ vọng chặn đánh cắp phiên, không áp dụng được cho mô hình này.

Nhận định

BlueKit là ví dụ điển hình cho hai xu hướng đang hội tụ. Thứ nhất, PhaaS hạ rào cản kỹ thuật đến mức một kẻ tấn công không cần hiểu BitM vẫn triển khai được kỹ thuật này ở quy mô lớn — Netcraft quan sát khoảng 70 hostname mới trong một tuần cho thấy tốc độ nhân bản hạ tầng rất cao. Thứ hai, BitM vô hiệu hóa MFA truyền thống (OTP, push, SMS) theo cách mà ngay cả các biện pháp chống đánh cắp phiên thế hệ mới như DBSC cũng không đỡ được.

Với môi trường doanh nghiệp Việt Nam, hệ quả trực tiếp là các tổ chức dùng Microsoft 365 / Google Workspace không thể coi "đã bật MFA" là đủ. Đường phòng thủ thực chất còn đứng vững trước BitM là MFA kháng phishing dựa trên FIDO2 / passkey, nơi việc xác thực ràng buộc mật mã với origin thật khiến trang phát lại của attacker không thể hoàn tất challenge. Ngoài ra, các thương hiệu nội địa giá trị cao — ngân hàng, ví điện tử, sàn TMĐT — hoàn toàn có thể bị thêm vào bộ template của một PhaaS như BlueKit, nên việc giám sát đăng ký domain giả mạo thương hiệu cần được coi là quy trình thường trực, không phải phản ứng sau sự cố.

Dấu hiệu phát hiện

Ba nguồn tham chiếu không công bố hash/IP cứng — do bản chất PhaaS, hạ tầng xoay vòng liên tục. Thay vào đó, đây là các tín hiệu quan sát (investigative signals) giúp nhận diện một trang BitM kiểu BlueKit, tổng hợp từ Netcraft:

- WebSocket truyền dữ liệu binary/mã hóa ngay trên trang login (kênh stream DOM của rrweb)
- Endpoint dạng proxy-API dùng để nạp asset (ảnh/script/style) thay vì tải trực tiếp từ nhà cung cấp thật
- Tham chiếu rrweb xuất hiện ngoài ngữ cảnh analytics/session-replay hợp pháp
- Custom CAPTCHA non-native mạo danh brand hoặc Cloudflare, HTML thay đổi mỗi lần load
- Thao túng CSS filter ngẫu nhiên (nhằm phá pixel-hash matching)
- JavaScript obfuscate kích thước lớn (>1MB), nội dung xoay vòng liên tục
- Phát hiện WebRTC IP mismatch được thực thi phía client trên landing page
- Độ trễ (latency) bất thường khi tương tác trang login — red flag cho end-user

Lưu ý: rrweb là dự án hợp pháp; sự hiện diện của nó không tự thân là IOC. Các tín hiệu trên có giá trị khi kết hợp nhiều dấu hiệu, không phải khi đứng riêng lẻ.

Khuyến nghị

• Ưu tiên MFA kháng phishing (FIDO2 / passkey) cho tài khoản đặc quyền và ứng dụng quan trọng — lớp phòng thủ hiếm hoi vẫn đứng vững trước cả AitM lẫn BitM.

• Đừng trông cậy DBSC để chặn BitM: DBSC giảm thiểu AitM nhưng không áp dụng cho mô hình session sinh ra trên máy attacker.

• Giám sát đăng ký domain mạo danh thương hiệu (nội bộ và đối tác) như quy trình thường trực; theo dõi các hostname mới xuất hiện hàng loạt.

• Đào tạo người dùng nhận biết latency bất thường và custom CAPTCHA lạ trên trang đăng nhập; báo cáo ngay thay vì nhập tiếp.

---

Tài liệu tham khảo

• Netcraft — Bluekit Phishing-as-a-Service: Browser-in-the-Middle (BitM) Analysis

• BleepingComputer — Bluekit phishing kit adopts browser-in-the-middle for login theft

• BleepingComputer — New Bluekit phishing service includes an AI assistant, 40+ templates