Không Fake Login, Không Đánh Cắp Password: Phishing 2026 Đang Hoạt Động Theo Cách Hoàn Toàn Mới

Tóm tắt chiến dịch

Vừa qua một chiến dịch lừa đảo qua OAuth Device Code Flow (được tự động hóa bằng công cụ EvilTokens) được ghi nhận và nhắm mục tiêu vào hơn 340 tổ chức sử dụng Microsoft 365, cho phép kẻ tấn công vượt qua hoàn toàn các cơ chế MFA truyền thống. Thay vì đánh cắp thông tin đăng nhập (credential), phương thức này đánh lừa người dùng tự tay cấp quyền truy cập (consent) cho một ứng dụng độc hại mạo danh ứng dụng nội bộ hợp lệ.

Rủi ro lớn nhất là kẻ tấn công thu thập được Refresh Token có thời hạn dài, duy trì quyền truy cập vào hộp thư (Exchange Online), tệp tin (SharePoint/OneDrive) và dữ liệu nhạy cảm mà không cần tương tác thêm với nạn nhân. Các tổ chức phụ thuộc hoàn toàn vào SMS OTP hoặc Authenticator App mà thiếu kiểm soát ứng dụng OAuth (Enterprise Applications) có nguy cơ bị xâm nhập cao nhất. Hành động khẩn cấp nhất lúc này là rà soát toàn bộ các ứng dụng bên thứ ba đã được cấp quyền trong Azure AD và cấu hình Conditional Access để chặn luồng Device Code nếu không thực sự cần thiết.

Timeline sự kiện

Thời điểm	Sự kiện
Tháng 02/2026	Nền tảng Phishing-as-a-Service (PhaaS) mang tên "EvilTokens" bắt đầu xuất hiện trên thị trường ngầm, tự động hóa hoàn toàn luồng lạm dụng OAuth Device Code.
Tháng 03/2026	Số lượng trang lừa đảo sử dụng Device Code Flow tăng trưởng đột biến (đạt mức tăng 37.5 lần vào đầu tháng 4/2026).
25/03/2026	Cloud Security Alliance (CSA) công bố báo cáo đầu tiên cảnh báo chiến dịch này đã xâm nhập thành công hơn 340 tổ chức Microsoft 365 trên toàn cầu.
20/05/2026	CSA cập nhật báo cáo chi tiết về EvilTokens, cảnh báo tính năng mới sử dụng mô hình ngôn ngữ lớn (LLM) để tự động hóa phân loại email và triển khai tấn công BEC ở quy mô lớn.

Quy trình tấn công

Quy trình tấn công lạm dụng OAuth Device Code Flow thông qua bộ công cụ EvilTokens được thực hiện qua các bước phối hợp nhịp nhàng giữa kỹ thuật giao thức và social engineering

Giai đoạn đầu tiên là khởi tạo yêu cầu (Device Code Request): Tại đây kẻ tấn công sử dụng công cụ EvilTokens gửi yêu cầu xác thực thiết bị đến Microsoft Identity Platform dưới danh nghĩa một ứng dụng hợp lệ (ví dụ: Microsoft Office). Microsoft phản hồi bằng một mã code ngắn hiển thị (user_code) và một mã định danh phiên (device_code).

Sau khi đã tạo được yêu cầu thì kẻ tấn công sẽ tìm cách dẫn dụ nạn nhân bằng việc gửi email lừa đảo mạo danh thông báo hệ thống IT (như yêu cầu xác minh thiết bị, nâng cấp bảo mật định kỳ). Email cung cấp đường link chính thức của Microsoft (https://microsoft.com/devicelogin) kèm theo user_code đã tạo ở trên.

Tại đây công cụ EvilTokens tự động thiết lập một tác vụ polling liên tục gửi yêu cầu đến endpoint lấy token của Microsoft sau mỗi khoảng thời gian định sẵn (thường là 5 giây), sử dụng device_code để kiểm tra trạng thái xác thực của nạn nhân.

Sau đó nạn nhân click vào đường link thật của Microsoft, nhập user_code, đăng nhập bằng tài khoản và tự hoàn tất bước xác thực hai yếu tố (MFA). Vì trang web hoàn toàn thuộc tên miền của Microsoft, không có cảnh báo bảo mật nào từ trình duyệt hay hệ thống phòng thủ. Tiếp đó, nạn nhân click "Accept" để phê duyệt các quyền được yêu cầu.

Ngay khi nạn nhân click đồng ý, yêu cầu polling tiếp theo từ máy chủ EvilTokens của kẻ tấn công sẽ được Microsoft phản hồi bằng một cặp mã thông báo hợp lệ: access_token (ngắn hạn) và refresh_token (dài hạn).

Kẻ tấn công sử dụng refresh_token để duy trì quyền truy cập lâu dài mà không cần mật khẩu hay MFA của người dùng. EvilTokens tích hợp các mô hình ngôn ngữ lớn (LLM) để quét nhanh hộp thư của nạn nhân, tìm các chuỗi email nhạy cảm về tài chính (invoices, thanh toán) và tự động tạo/gửi email lừa đảo thoả hiệp email doanh nghiệp (BEC) với độ chính xác cao.

Phân tích kỹ thuật chi tiết

Bản chất của kỹ thuật này là sự lạm dụng có chủ đích giao thức OAuth 2.0 Device Authorization Grant (RFC 8628). Giao thức này vốn được thiết kế để hỗ trợ các thiết bị hạn chế về khả năng nhập liệu hoặc không có trình duyệt (như Smart TV, máy in, thiết bị IoT) có thể đăng nhập vào tài khoản doanh nghiệp.

Giao thức RFC 8628

Khi khởi tạo luồng tấn công, EvilTokens gửi một truy vấn POST đến endpoint xác thực thiết bị của Microsoft:

Trong đó:

client_id: Kẻ tấn công sử dụng App ID hợp lệ của Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c) để che giấu nguồn gốc ứng dụng, khiến nạn nhân tin rằng đây là thông báo đăng nhập dịch vụ văn phòng tiêu chuẩn.
scope: Các quyền yêu cầu bao gồm đọc email (Mail.Read), truy cập tài liệu (Files.ReadWrite.All) và đặc biệt là quyền duy trì ngoại tuyến (offline_access) để lấy được refresh_token.

Microsoft Identity Platform trả về cấu trúc JSON:

EvilTokens lưu lại device_code để thực hiện polling và trích xuất user_code (OTJRY5WQD) để nhúng vào email phishing gửi cho nạn nhân.

Quá trình Polling và Đánh cắp Token

Kẻ tấn công chạy script gửi yêu cầu liên tục đến endpoint /token sau mỗi 5 giây (theo tham số interval trả về):

Trong khi nạn nhân chưa nhập mã, Microsoft sẽ phản hồi bằng mã lỗi 400 Bad Request kèm nội dung authorization_pending.

Ngay sau khi nạn nhân nhập mã OTJRY5WQD tại microsoft.com/devicelogin và hoàn tất MFA, Microsoft xác thực phiên làm việc đó liên kết với device_code. Ở lần polling tiếp theo của EvilTokens, Microsoft phản hồi trạng thái 200 OK kèm theo Access Token và Refresh Token đầy đủ quyền lực.

Điểm mù của hệ thống phòng thủ truyền thống

Phương thức lấn át bảo mật này sở hữu những ưu thế kỹ thuật vượt trội so với các hình thức phishing truyền thống:

Không thể chặn bằng URL Filtering/Secure Email Gateway: Email lừa đảo dẫn dụ nạn nhân truy cập vào chính xác tên miền hợp lệ của Microsoft (microsoft.com). Các bộ lọc email hay giải pháp Web Proxy không thể chặn hoặc phân loại URL này là độc hại.

Vượt qua hoàn toàn MFA: Vì nạn nhân trực tiếp thực hiện đăng nhập và phê duyệt MFA trên trình duyệt của chính họ, các giải pháp MFA mạnh mẽ nhất (như Authenticator App, SMS OTP hay thậm chí khóa bảo mật FIDO2) đều không phát hiện được sự bất thường do luồng xác thực diễn ra hoàn toàn hợp lệ.

Bypass Password Reset: Điểm mấu chốt của sự nguy hiểm là cơ chế hoạt động của Refresh Token trong Azure AD. Khi người dùng đổi mật khẩu, Azure AD sẽ thu hồi các session cookies của trình duyệt, nhưng các Refresh Token đã cấp cho ứng dụng OAuth bên thứ ba vẫn giữ nguyên hiệu lực. Kẻ tấn công có thể tiếp tục sinh Access Token mới để truy cập dữ liệu mà không cần biết mật khẩu mới của nạn nhân.

IOC

Việc phát hiện chiến dịch này yêu cầu phân tích kỹ Azure AD (Microsoft Entra ID) Audit Logs và Sign-in Logs.

Azure AD Audit Logs

Tìm kiếm các sự kiện người dùng cấp quyền cho ứng dụng lạ hoặc có các scope quyền bất thường (offline_access, Mail.ReadWrite, Files.ReadWrite.All):

Activity: Consent to application hoặc Add app role assignment to service principal
Application ID abused: Rà soát các ứng dụng sử dụng First-party Client ID của Microsoft như:
- Microsoft Office: d3590ed6-52b3-4102-aeff-aad2292ab01c
- Microsoft Teams: 1fec8e78-bce4-4aaf-ab1b-5451cc3e7264

Lọc các đăng nhập sử dụng giao thức Device Code Flow:

Authentication Protocol: Device Code
Original Transfer Method: deviceCodeFlow
Anomalous Location: Kiểm tra sự bất hợp lý về mặt địa lý. Điển hình là khi địa chỉ IP thực hiện yêu cầu khởi tạo mã (IP của server EvilTokens) nằm ở một quốc gia khác hoàn toàn so với địa chỉ IP của nạn nhân khi họ thực hiện nhập mã và xác thực MFA. Do EvilTokens sử dụng các hosting provider giá rẻ để chạy PhaaS, cần rà soát các kết nối xác thực từ dải IP của các nhà cung cấp dịch vụ cloud (DigitalOcean, Linode, AWS, OVH) thay vì dải IP của các nhà mạng viễn thông dân dụng thông thường.

MITRE ATT&CK Mapping

T1528 - Steal Application Access Token: Kẻ tấn công thu thập Access/Refresh Token sau khi nạn nhân xác thực.

T1524 - Trust Discovery / Consent Grant: Lợi dụng sự tin tưởng của người dùng để xin cấp quyền ứng dụng (Illicit Consent Grant).

T1556 - Modify Authentication Process: Vượt qua luồng xác thực đa yếu tố bằng cách chuyển hướng thao tác MFA sang phía nạn nhân.

Yara Rule

rule phishing_eviltokens_phishing_page {
    meta:
        malware = "EvilTokens"
        description = "Find EvilTokens device code phishing pages based on characteristic strings"
        source = "Sekoia.io"
        creation_date = "2026-03-05"
        modification_date = "2026-03-05"
        classification = "TLP:CLEAR"
        reference = "https://blog.sekoia.io/new-widespread-eviltokens-kit-device-code-phishing-as-a-service-part-1/"


    strings:
        $html = "<!DOCTYPE html>" ascii

        $str01 = "<div id=\"r\">" ascii
        $str02 = "function f(s){" ascii
        $str03 = "return Uint8Array.from(atob(s),x=>x.charCodeAt(0))" ascii
        $str04 = "var k=await crypto.subtle.importKey(" ascii
        $str05 = "var p=await crypto.subtle.decrypt(" ascii
        $str06 = "name:\"AES-GCM\",iv:f(b)" ascii
        $str07 = "document.write(new TextDecoder().decode(" ascii
        $str08 = "document.body.innerHTML=\"Loading failed\"" ascii
        $str09 = "document.close()}catch(e)" ascii

    condition:
        $html at 0 and
        6 of them and filesize < 50KB
}

Nhận định chuyên gia

Sự bùng nổ của chiến dịch OAuth Device Code cho thấy một sự dịch chuyển rõ rệt về kỹ thuật của các nhóm tấn công: khi các tổ chức tại Việt Nam và trên thế giới đã phổ cập MFA, việc đánh cắp thông tin đăng nhập (credential phishing) không còn mang lại nhiều giá trị. Thay vào đó, "Token is the new credential".

MFA truyền thống đang tạo ra một cảm giác an toàn giả tạo. Thực tế trong các đợt ứng cứu sự cố (Incident Response) gần đây, SOC ghi nhận người dùng cuối thường nhấp "Accept" một cách vô thức khi thấy giao diện đăng nhập quen thuộc của Microsoft, bất chấp việc ứng dụng đang yêu cầu quyền truy cập toàn bộ hộp thư. Việc phòng thủ không thể chỉ dựa vào endpoint hay mạng, mà phải dịch chuyển sang identity, cụ thể là kiểm soát chặt chẽ bề mặt tấn công của các Enterprise Applications.

Khuyến nghị

Immediate (0-24h)

Vô hiệu hóa luồng Device Code Flow nếu tổ chức không sử dụng các thiết bị IoT/Smart TV cần xác thực M365. Cấu hình điều này thông qua Azure AD Conditional Access policy bằng cách block condition "Device code flow".
Truy vấn Unified Audit Log để tìm các sự kiện Consent to application trong 30 ngày qua và thu hồi (revoke) quyền của bất kỳ ứng dụng nào không được IT phê duyệt.

Short-term (1-7 ngày)

Thay đổi cấu hình Azure AD "User consent settings" thành Do not allow user consent. Bắt buộc mọi yêu cầu cấp quyền ứng dụng bên thứ ba phải qua quy trình Admin Consent workflow.
Chạy script PowerShell Get-AzureADPSPermissions.ps1 để audit toàn bộ các quyền OAuth (Delegated và Application permissions) đang tồn tại trong tenant.

Long-term

Triển khai Continuous Access Evaluation (CAE) để hệ thống có thể thu hồi (revoke) token gần như ngay lập tức nếu phát hiện sự thay đổi bất thường (như đổi địa chỉ IP hoặc thiết bị).
Đào tạo nhận thức bảo mật cho nhân viên: Cảnh báo cụ thể về hình thức lừa đảo nhập mã (code) tại microsoft.com/devicelogin.

Tham khảo

EvilTokens: an AI-augmented phishing kit for automating BEC fraud

EvilTokens Emerges as New Phishing-as-a-Service Platform for Microsoft Account Takeover

The New Phishing Click: How OAuth Consent Bypasses MFA

Không Fake Login, Không Đánh Cắp Password: Phishing 2026 Đang Hoạt Động Theo Cách Hoàn Toàn Mới

Tóm tắt chiến dịch

Timeline sự kiện

Quy trình tấn công