Ngày 14/07/2026, đội Threat Research của ReliaQuest công bố hai bộ công cụ phishing mới: Jalisco (device code phishing, sinh mã OAuth theo thời gian thực) và OmegaLord (credential harvester thu thêm số điện thoại để cướp MFA). Điểm chung: cả hai đều được thiết kế để đánh bại MFA, chứ không chỉ để lấy mật khẩu. Bài này tóm tắt báo cáo, và tự đặt Jalisco cạnh Muraena  để so sánh (chủ ý cá nhân)— bộ AiTM reverse proxy kinh điển — để thấy rõ hướng tiến hóa của phishing hiện đại.

1. Bối cảnh: 2026 là năm phishing “đổi hệ quy chiếu”

Trong nhiều năm, mô hình phòng thủ chống phishing của chúng ta dựa trên ba giả định:

1. Kẻ tấn công cần mật khẩu của nạn nhân.
2. MFA sẽ chặn được kẻ tấn công dù có mật khẩu.
3. Reset mật khẩu sẽ đuổi được kẻ tấn công ra khỏi tài khoản.

Cả ba giả định này đều đã bị phá vỡ. ReliaQuest ghi nhận hoạt động phishing tăng 1.380% trong giai đoạn cuối 2025 đến đầu 2026, phần lớn nhờ hệ sinh thái PhaaS (Phishing-as-a-Service) có tích hợp AI, cho phép bất kỳ ai — kể cả người không biết code — dựng chiến dịch giả mạo thương hiệu chỉ từ một URL.

Điểm cần nhấn mạnh cho anh em làm bảo mật: trọng tâm tấn công đã dịch từ “đánh cắp thông tin đăng nhập” sang “đánh cắp quá trình xác thực”. Kẻ tấn công không cần biết mật khẩu của bạn — họ chỉ cần bạn tự bấm “Approve”.

2. Jalisco: device code phishing thế hệ mới

2.1. Device code phishing hoạt động thế nào?

Luồng OAuth Device Authorization Grant sinh ra cho các thiết bị không có bàn phím tiện lợi (smart TV, thiết bị IoT, CLI). Thiết bị hiển thị một mã ngắn, người dùng vào microsoft.com/devicelogin trên máy khác, nhập mã, đăng nhập — và thiết bị kia được cấp token.

Kẻ tấn công lợi dụng đúng luồng hợp lệ này:

• Chúng khởi tạo yêu cầu device code với Microsoft, nhận về một mã.
• Chúng dụ nạn nhân nhập mã đó vào trang đăng nhập thật của Microsoft.
• Nạn nhân đăng nhập bình thường, hoàn tất MFA hoàn toàn hợp lệ.
• Ở phía sau, công cụ của kẻ tấn công âm thầm nhận access token + refresh token từ token endpoint của Microsoft.

Kết quả: kẻ tấn công có quyền truy cập bền vững vào tài khoản mà chưa bao giờ chạm vào mật khẩu. Đây chính là lý do các biện pháp truyền thống — reset mật khẩu, giám sát credential leak — trở nên vô nghĩa: không có credential nào bị lộ để mà giám sát.

Về mặt trải nghiệm, trang phishing thường hiển thị một cái “mồi” (ví dụ file PDF giả), kèm mã device code, và mở cửa sổ pop-up là trang đăng nhập Microsoft 365 chính chủ. Người dùng thấy đúng domain, đúng chứng chỉ TLS, đúng giao diện — vì nó là trang thật.

2.2. Cái mới của Jalisco: “lure-generation” đánh bại TTL

Đây là phần đáng chú ý nhất của báo cáo. Các bộ kit device code phishing chia làm hai thế hệ:

Phòng thủ lâu nay ngầm dựa vào TTL 15 phút của device code như một cơ chế giới hạn thiệt hại tự nhiên: email gửi lúc 9h, nạn nhân đọc lúc 9h30 → mã chết. Lure-generation xóa sổ giả định đó. ReliaQuest đánh giá kỹ thuật này rất nhiều khả năng sẽ trở thành tính năng tiêu chuẩn của các phishing kit khác trong 6–12 tháng tới.

2.3. Duy trì truy cập: đăng ký thiết bị vào Entra ID

Sau khi có token, kẻ tấn công đăng ký thiết bị của chính mình vào tenant Entra ID của nạn nhân. Thiết bị đã đăng ký sẽ nhận Primary Refresh Token (PRT) — loại token tự động gia hạn chừng nào thiết bị còn hoạt động.

Hệ quả cho đội IR:

• Reset mật khẩu: không đủ.
• Revoke session: không đủ.
• Phải xóa từng thiết bị kẻ tấn công đã đăng ký, nếu không chúng quay lại ngay.

ReliaQuest ghi nhận nhóm tấn công đăng ký hơn 5 thiết bị trên một tài khoản bị chiếm (trước đây thường chỉ 1–2), đặt tên kiểu microsoft-*, WINDOWS-* để lẫn vào danh sách thiết bị hợp lệ. Thời gian exfiltrate dữ liệu có thể chỉ 6 phút — nhanh hơn cả thời gian một analyst mở ticket.

2.4. Hạ tầng: lạm dụng nền tảng cloud hợp pháp

Các kit này host trang phishing trên workers[.]dev (Cloudflare Workers) và edgeone[.]app — dịch vụ hợp pháp dành cho developer. Domain có chứng chỉ hợp lệ, reputation sạch, thường nằm trong allowlist. Subdomain được đặt kiểu sharepoint-upload-xxxx[.]<user>[.]workers[.]dev để tăng độ tin cậy. Với secure email gateway dựa trên chữ ký và danh tiếng domain, đây gần như là điểm mù.

2.5. Hệ sinh thái PhaaS có AI

Jalisco không đơn độc. Báo cáo liệt kê EvilTokens, Kali365, Tycoon2FA, Venom, Darcula. Điểm chung của thế hệ mới: chỉ cần đưa một URL mục tiêu, AI sẽ tự nhân bản logo, hình ảnh, bố cục của thương hiệu đó lên trang phishing. Việc “làm trang giả giống trang thật” — trước đây tốn cả ngày công của người có kỹ năng frontend — nay còn vài giây.

3. OmegaLord: phishing truyền thống cũng đang được “gia cố” quanh MFA

OmegaLord là credential harvester viết bằng JavaScript, giả dạng trình đọc PDF yêu cầu đăng nhập. Ngoài email và mật khẩu, nó còn hỏi số điện thoại — điều bất thường với một credential harvester thông thường.

Lý do rất rõ: có số điện thoại, kẻ tấn công có thể thực hiện MFA fatigue, vishing giả danh helpdesk, hoặc SIM swap để chiếm mã OTP. Thông điệp cho các đội bảo mật: MFA qua SMS/cuộc gọi không còn là biện pháp bảo vệ đáng tin cậy nữa.

4. So sánh: Jalisco (device code) vs Muraena (AiTM reverse proxy)

Nếu bạn từng theo dõi mảng phishing vượt MFA, chắc chắn bạn biết Muraena — bộ công cụ do Michele Orrù (antisnatchor) và Giuseppe Trotta công bố tại Hack In The Box Amsterdam 2019. Muraena là một almost-transparent reverse proxy viết bằng Go, đi kèm NecroBrowser (container Chromium headless) để tự động hóa giai đoạn hậu khai thác: dùng session cookie vừa cướp được để đổi mật khẩu, tắt thông báo bảo mật của Google Workspace, dump email, thay SSH key trên GitHub, tải toàn bộ repository…

Muraena thuộc họ AiTM (Adversary-in-the-Middle), cùng gia đình với Modlishka và Evilginx2. Đặt nó cạnh Jalisco sẽ thấy hai triết lý tấn công hoàn toàn khác nhau:

Vì sao sự dịch chuyển này quan trọng?

Thứ nhất — rào cản kỹ thuật sụp đổ. Muraena mạnh, nhưng nó khó. Tài liệu chính thức của dự án nói thẳng rằng với các origin phức tạp, bạn phải phân tích thủ công và tinh chỉnh file cấu hình JSON tự sinh; “đừng mong nó chạy ngay lập tức”. Ngược lại, Jalisco đóng gói mọi thứ thành API + web portal. Người vận hành chiến dịch không cần hiểu CSP, SRI hay TLS fingerprinting.

Thứ hai — không còn indicator quen thuộc. Với AiTM, chúng ta vẫn còn một thứ để bám: domain giả. Threat intel feed, DNS monitoring, cert transparency log, brand protection — tất cả đều xoay quanh việc phát hiện domain typosquat. Với device code phishing, nạn nhân nhập mã trên login.microsoftonline.com thật. Trang phishing chỉ đóng vai trò hiển thị cái mồi và con số. Toàn bộ hệ thống phát hiện dựa trên domain gần như mù.

Thứ ba — bài toán eviction khác hẳn. Sau một sự cố AiTM, revoke session + reset password thường là đủ. Sau một sự cố device code, nếu bạn không rà và xóa hết thiết bị đã đăng ký trong Entra ID, kẻ tấn công vẫn ở trong nhà.

Thứ tư — passkey vẫn là câu trả lời, nhưng không phải cho mọi thứ. Đây là chi tiết tinh tế mà nhiều người bỏ qua. FIDO2/passkey vô hiệu hóa AiTM kiểu Muraena một cách triệt để, vì xác thực được gắn với origin — proxy ở domain khác thì assertion không hợp lệ. Nhưng với device code phishing, nạn nhân xác thực trên đúng origin thật, nên passkey vẫn “pass” bình thường. Passkey không cứu bạn ở đây; chỉ có chặn luồng device code mới cứu được.

5. Hành động cụ thể

Ưu tiên 1 — Chặn device code flow

• Microsoft Entra ID: tạo Conditional Access policy tại Conditions > Authentication Flows, chặn Device code flow, áp dụng cho All users và All cloud apps. Chỉ loại trừ một nhóm nhỏ tài khoản/service account có nhu cầu nghiệp vụ được ghi nhận chính thức, và scope exception theo application registration cụ thể, không theo nhóm người dùng rộng.
• Okta: hạn chế grant OAuth Device Authorization ở cấp authorization server policy, yêu cầu phê duyệt chính thức trước khi bật cho bất kỳ ứng dụng nào.

Thực tế: rất ít tổ chức có nhu cầu hợp pháp với luồng này ở quy mô người dùng phổ thông. Chặn mặc định là lựa chọn đúng.

Ưu tiên 2 — Rà soát application registration

Nhiều tổ chức tích tụ hàng chục app registration qua nhiều năm mà không ai rà lại grant. Coi mọi registration còn bật device authorization grant là điểm xâm nhập tiềm năng cho đến khi chứng minh được nhu cầu nghiệp vụ.

Ưu tiên 3 — Siết đăng ký thiết bị

Mặc định Entra ID cho phép mỗi người dùng đăng ký tới 50 thiết bị cá nhân. Hạ xuống 1–2. Trong Device Settings, đổi “Users may register devices” từ All sang một nhóm được kiểm soát (ví dụ IT-Approved-Device-Registrars).

Ưu tiên 4 — Detection & response

Những gì nên đưa vào SIEM/XDR:

• Cấp token qua device code flow (Entra sign-in log, authenticationProtocol = deviceCode).
• Đăng ký thiết bị mới, đặc biệt nhiều thiết bị trên cùng một tài khoản trong thời gian ngắn, hoặc tên thiết bị dạng microsoft-*, WINDOWS-*.
• Truy cập SharePoint/OneDrive bất thường ngay sau một sự kiện cấp token mới.
• Traffic tới các subdomain *.workers[.]dev, *.edgeone[.]app phát sinh từ link trong email.

Playbook eviction cho device code phishing phải theo đúng thứ tự: revoke session → xóa thiết bị đã đăng ký → disable tài khoản nếu cần. Bỏ bước giữa là tái nhiễm.

Ưu tiên 5 — Chuyển khỏi MFA qua SMS

OmegaLord thu số điện thoại là lời nhắc rõ ràng. Ưu tiên passkey/FIDO2 hoặc authenticator app có number matching thay cho SMS OTP.

6. IOC (theo ReliaQuest)

Lưu ý: một số chỉ dấu là dịch vụ hợp pháp hoặc site bên thứ ba bị lạm dụng mà chủ sở hữu không hay biết. Cân nhắc trước khi block cứng.

7. Kết luận

Từ Muraena (2019) đến Jalisco (2026), hướng đi rất nhất quán: kẻ tấn công ngày càng lùi ra xa khỏi mật khẩu và tiến gần hơn tới bản thân quá trình xác thực.

Muraena dạy chúng ta rằng MFA không phải viên đạn bạc, vì session cookie có thể bị cướp. Jalisco đi xa hơn một bậc: nó không cần cướp gì cả — nó chỉ cần nạn nhân tự nguyện hoàn tất xác thực hộ mình, trên chính trang đăng nhập thật.

ReliaQuest đánh giá với độ tin cậy cao rằng device code phishing sẽ thay thế credential harvesting làm kỹ thuật phishing chủ đạo trong phần còn lại của năm 2026. Với các tổ chức đang dùng Microsoft 365, có một việc nên làm ngay trong tuần này, và nó chỉ mất vài phút: kiểm tra xem device code flow đã bị chặn bằng Conditional Access hay chưa.

Bài viết tổng hợp và phân tích từ báo cáo của ReliaQuest Threat Research Team (John Dilgen, Jalen Vaughn), 14/07/2026. Nội dung nhằm mục đích phòng thủ và nâng cao nhận thức; không cung cấp hướng dẫn vận hành công cụ tấn công.

What’s Your Reaction?

0In Love0Happy0Not Sure0OMG0Angry0Sad0LOL0Cry0Silly0Crazy