TD;DR
- Một chiến dịch phishing lùa nạn nhân nhập mã trực tiếp trên trang đăng nhập thật của Microsoft, vượt qua cả MFA, rồi âm thầm chiếm quyền hộp thư, OneDrive và Teams -> nếu chỉ check mỗi URL là dính đòn.
- Cụ thể,kẻ tấn công lạm dụng luồng đăng nhập hợp lệ dành cho thiết bị của Microsoft để lấy một mã OTP thật, rồi lừa nạn nhân tự approve mã đó. -> abuse api trên thiết bị
- Các thiết bị như smart TV, máy in hay thiết bị IoT không có bàn phím đầy đủ hoặc trình duyệt thực thụ, nên việc gõ mật khẩu trực tiếp rất bất tiện. Device Authorization Grant cho phép người dùng dùng một điện thoại hoặc máy tính ở gần để phê duyệt cho thiết bị kia. Chính điểm thuận tiện đó lại trở thành bề mặt tấn công
- Nạn nhân nhập mã trên microsoft.com/devicelogin, tức trang chính chủ, sau đó hoàn tất luôn cả bước xác thực đa yếu tố. Kiểm tra URL và MFA đều không có tác dụng phát hiện đây là phishing.
- Sau khi approve, kẻ tấn công thu được access_token, refresh_token và id_token. refresh_token cho phép duy trì quyền truy cập âm thầm trong thời gian dài.
- Chuỗi tấn công đi qua nhiều domain tin cậy như Microsoft và Cacoo.com nên các bộ lọc dựa trên độ uy tín tên miền không chặn được.
- Biện pháp phòng ngừa mạnh nhất là chặn Device Code Flow bằng Conditional Access nếu tổ chức không dùng đến.
- Phân tích kỹ thuật dựa trên nghiên cứu của Kaspersky Securelist
- Kỹ thuật: Device Code Phishing
Ok a/e đã đi qua phần tóm tắt, nếu chưa hiểu lắm thì đọc tiếp nhé.
I. Bối cảnh
Lời khuyên chống phishing kinh điển là kiểm tra tên miền trước khi nhập thông tin, thế nhưng với chiến dịch này nó lại vô dụng, vì tên miền mà nạn nhân nhập thông tin lại hoàn toàn là của Microsoft. Trong hầu hết các vụ phishing truyền thống, một người được đào tạo nhận thức đầy đủ (về security) sẽ dễ dàng nhận ra tên miền giả lệch vài ký tự so với địa chỉ thật.
Tuy nhiên, với chiến dịch Device Code Phishing không chơi theo cách đó. Thay vì dựng một trang đăng nhập fake, kẻ tấn công dẫn nạn nhân tới đúng nền tảng Identity & Access Management (IAM) của Microsoft là Microsoft Identity Platform, nơi vận hành một phần mở rộng của chuẩn OAuth 2.0 là Device Authorization Grant.
Cơ chế này sinh ra để giải quyết một bài toán rất basic: Các thiết bị như smart TV, máy in hay thiết bị IoT không có bàn phím đầy đủ hoặc trình duyệt thực thụ, nên việc gõ mật khẩu trực tiếp rất bất tiện. Device Authorization Grant cho phép người dùng dùng một điện thoại hoặc máy tính ở gần để phê duyệt cho thiết bị kia. Chính điểm thuận tiện đó lại trở thành bề mặt tấn công.
II. Phân tích kỹ thuật
Device Authorization Grant vận hành thế nào trong quy trình bình thường ?
Trước khi đi sâu vào cách kẻ tấn công lợi dụng cơ chế này, ta hãy đi vào tìm hiểu quy trình gốc như nào. Đây là sequence diagram mô tả các tương tác giữa thiết bị đầu cuối và máy chủ danh tính của Microsoft:
| Bước 1: Yêu cầu mã ủy quyền | Ứng dụng trên thiết bị gửi một yêu cầu POST tới /oauth2/v2.0/devicecode kèm theo client_id của ứng dụng và scope quyền cần xin. |
| Bước 2: Máy chủ trả về bộ mã | Microsoft phản hồi bằng device_code dùng nội bộ, user_code ngắn để hiển thị, verification_uri là địa chỉ đăng nhập, cùng thời hạn sống của mã. |
| Bước 3: Hiển thị mã cho người dùng | Thiết bị hiện user_code và địa chỉ, thường kèm mã QR, để người dùng mở trên điện thoại. |
| Bước 4: Nhập mã và xác nhận | Người dùng vào verification_uri, ví dụ microsoft.com/devicelogin, nhập user_code rồi đăng nhập kèm MFA. |
| Bước 5: Thiết bị hỏi liên tục | Thiết bị gửi POST tới endpoint /token với grant_type=urn:ietf:params:oauth:grant-type:device_code để hỏi máy chủ đã được phê duyệt hay chưa. |
| Bước 6: Cấp token và tự gia hạn | Khi người dùng phê duyệt, máy chủ cấp bộ token. access_token thường sống một tiếng, còn refresh_token cho phép tự làm mới quyền mà không cần người dùng thao tác lại. |
Trong kịch bản hợp lệ, chính thiết bị của người dùng là bên khởi tạo yêu cầu ở bước 1. Toàn bộ vấn đề của chiến dịch tấn công nằm ở chỗ: attacker mới thực sự là bên khởi tạo.
Chuỗi tấn công thực tế
Kaspersky ghi nhận chiến dịch chạy từ đầu tháng 4 tới giữa tháng 5 năm 2026, điểm đáng sợ nhất đây không phải là một cuộc tấn công phishing bình thường, mà là cách kẻ tấn công xâu chuỗi những thành phần hoàn toàn hợp lệ để thành một cuộc tấn công phishing tinh vi.
Hình 2: Chuỗi tấn công
Chuỗi liên tục đan xen giữa hạ tầng của kẻ tấn công và hạ tầng thật, khiến cả người dùng lẫn hệ thống lọc tự động khó tìm ra điểm bám để cảnh báo.
Ở mắt xích số 5, mã mà nạn nhân được yêu cầu sao chép không phải mã ngẫu nhiên. Đó là user_code mà ứng dụng phía máy chủ của kẻ tấn công đã truy vấn sẵn từ endpoint /devicecode thật của Microsoft. Nói cách khác, kẻ tấn công đã âm thầm chạy bước 1 của luồng hợp lệ.
Ở mắt xích số 6, khi nạn nhân bấm vào mã vừa sao chép nó vào clipboard vừa chuyển hướng nạn nhân sang verification_uri thật của Microsoft. Nạn nhân dán mã, đăng nhập bằng chính tài khoản của mình, và hoàn tất xác thực đa yếu tố ngay trên trang chính chủ. Với nạn nhân, không có nghi ngờ nào cả. Với kẻ tấn công, phiên đăng nhập mà chúng khởi tạo vừa được phê duyệt bởi nạn nhân 😀
MFA xác minh rằng đúng người đang đăng nhập. Nó không xác minh rằng người đó hiểu mình đang phê duyệt phiên cho ai. Nạn nhân xác thực MFA thành công -> trao token cho kẻ tấn công.
Hậu quả
Ngay khi xác thực thành công, kẻ tấn công thu được cả bộ token của phiên. Mỗi loại mở ra một khả năng khác nhau, và loại nguy hiểm nhất về lâu dài lại là loại ít được chú ý.
access_token hết hạn nhanh nên nếu đây là thứ duy nhất bị mất thì thiệt hại còn giới hạn. Nhưng refresh_token mất thì khác, nó sẽ trở thành điểm mà hacker có thể quay lại, vì nó tự sinh access_token mới mà không cần nạn nhân đăng nhập lại.
Với bộ token trong tay, kẻ tấn công đọc và gửi thư từ hộp thư của nạn nhân, lấy cắp file trên OneDrive, và truy cập hội thoại trên Teams. refresh_token đặc biệt nguy hiểm vì nó cho phép duy trì quyền truy cập trong thời gian dài mà không phát sinh thêm lần đăng nhập nào để đội phòng thủ có thể để ý.
Kỹ thuật được tái sử dụng, nhắm vào Brazil
Chiến dịch gốc kết thúc sau hơn một tháng, nhưng nhóm tấn công không dừng lại. Kaspersky ghi nhận một biến thể điều chỉnh theo khu vực, chuyển hướng sang người dùng tại Brazil, với hai thay đổi đáng chú ý về hạ tầng.
Thứ nhất, biến thể Brazil bỏ hẳn tệp PDF độc hại đính kèm. Thay vào đó, email nhúng một liên kết trỏ tới cacoo.com, một nền tảng vẽ sơ đồ trực tuyến thuộc Nulab. Cũng giống cách Microsoft bị mượn ở chiến dịch gốc, domain tin cậy này đóng vai một open redirect để đẩy nạn nhân về hạ tầng phishing.
Thứ hai, mồi nhử đổi từ thông báo pháp lý sang thông báo xác nhận đơn hàng, viết bằng tiếng Bồ Đào Nha, đề nghị người dùng đăng nhập vào chính tài khoản đã nhận thư để xác thực tài liệu. Phần còn lại của chuỗi vẫn y hệt, vẫn dẫn về trang hiển thị mã dùng một lần rồi sang cổng Microsoft thật để hoàn tất Device Authorization Grant.
Chiến dịch diễn ra khi nào ?
III. Phòng ngừa
Vì mọi thao tác nhạy cảm đều diễn ra trên hạ tầng thật, phòng thủ không thể chỉ dựa vào việc nhận diện tên miền xấu. Cần kết hợp kiểm soát cấu hình, giám sát hành vi và nâng nhận thức người dùng.
a. Cho đội quản trị và bảo mật
| Biện pháp | Tác dụng | Ưu tiên |
|---|---|---|
| Chặn Device Code Flow bằng Conditional Access | Nếu tổ chức không thực sự cần luồng này, hãy tắt trên toàn miền trong Microsoft Entra ID -> đây là cách chặn triệt để nhất | Cao nhất |
| Giám sát sự kiện DeviceCodeSignIn | Thiết lập cảnh báo riêng cho các lần đăng nhập theo Device Authorization Grant để phát hiện phê duyệt bất thường. | Cao |
| Bắt buộc trạng thái tuân thủ thiết bị | Chỉ cho phép cấp quyền cho thiết bị đạt chuẩn quản lý, giảm cơ hội cho phiên do kẻ tấn công khởi tạo. | Trung bình |
| Cảnh báo đăng nhập từ vị trí lạ | Phát hiện việc token được dùng từ địa điểm bất thường so với hành vi quen thuộc của người dùng. | Trung bình |
| Triển khai giải pháp bảo mật email | Chặn từ sớm các mồi nhử dạng PDF có mật khẩu hoặc liên kết open redirect trước khi tới hộp thư. | Nền tảng |
b. Cho người dùng cuối
Nguyên tắc gốc rất đơn giản. Nếu ta không tự mình khởi tạo một yêu cầu đăng nhập thiết bị, thì đừng phê duyệt bất kỳ mã nào, kể cả khi liên kết dẫn tới đúng domain Microsoft. Không nhập mã ủy quyền nhận được từ email hay tin nhắn bất ngờ.
Trước khi bấm bất cứ liên kết nào, hãy rê chuột để xem cả tên miền chính lẫn các tham số chuyển hướng như redirect_uri, return_url hay next nằm sau dấu hỏi. Sau khi trang tải xong, kiểm tra lại địa chỉ cuối cùng có đúng là tài nguyên bạn mong đợi hay không. Đó là mức tối thiểu trước khi nhập bất kỳ thông tin đăng nhập nào.
Kết luận
Điều khiến chiến dịch này đáng nhớ không phải độ tinh vi của mã độc, vì gần như không có mã độc nào. Nó đáng nhớ vì cho thấy kẻ tấn công có thể vũ khí hóa những công cụ hoàn toàn hợp pháp. Chúng không cần đánh cắp mật khẩu hay cài phần mềm gián điệp. Chúng chỉ cần thuyết phục nạn nhân bấm một cái vào đúng nơi.
Với người dùng, thông điệp là hãy cảnh giác cả khi đang ở trên những nền tảng chính thống như Microsoft hay Cacoo.com. Với tổ chức, thông điệp là hãy đánh giá xem có thực sự cần Device Code Flow không, và nếu không thì tắt nó đi trước khi hacker tắt hộ thì khổ hơn nhiều!
Ref: securelist.com.
Nhat Truong Blog 