Trang phishing không tồn tại ở đâu cả — ngoài trình duyệt của nạn nhân

Tóm tắt

Barracuda mô tả một chiến dịch phishing mà trang đăng nhập giả không nằm trên bất kỳ máy chủ nào. Nạn nhân nhận email giả DocuSign kèm lời mời lịch (.ics), bấm vào đường dẫn trỏ tới endpoint OAuth hợp lệ của Microsoft, bị chuyển qua Microsoft Teams, rồi trình duyệt tự dựng trang phishing từ một blob URL chỉ tồn tại trong bộ nhớ của chính máy đó.

Hệ quả thực tế: URL scanner, sandbox và blocklist không có gì để quét hay chặn. Mỗi bước trong chuỗi đều đi qua domain uy tín, còn trang độc hại xuất hiện ở bước cuối, cục bộ, và biến mất khi đóng tab.

Hành động ưu tiên:

• Đánh giá lại mức độ phụ thuộc vào lọc URL trong phòng thủ email. Với kỹ thuật này, lớp đó gần như không có tác dụng.

• Đẩy nhanh FIDO2/passkey cho tài khoản Microsoft 365 đặc quyền. Đây là biện pháp duy nhất trong danh sách không phụ thuộc vào việc phát hiện được trang giả.

Điều gì khiến chiến dịch này khác biệt

Theo Barracuda, điểm khác biệt nằm ở năm yếu tố gộp lại:

1. Không có trang phishing trên máy chủ. Nội dung được sinh ra bên trong trình duyệt nạn nhân qua blob URL.

2. Chuỗi chuyển hướng toàn domain tin cậy. Microsoft login, Microsoft Teams, rồi một CDN của dịch vụ SaaS.

3. Mồi nhử kép. Email DocuSign và lời mời lịch .ics trông vô hại.

4. Kiến trúc có backend điều khiển. Trang dùng service worker, sandboxed iframe và kênh messaging với backend, cho phép kẻ tấn công điều phối nhiều nạn nhân theo thời gian thực.

5. Cấu hình C2 được giấu. Barracuda không công bố chi tiết, nhưng cho biết cấu hình này không lộ ra trong mã trang tĩnh.

Chuỗi tấn công

1. Email mồi DocuSign. Nạn nhân nhận email yêu cầu xem hoặc ký tài liệu.

   

2. Lời mời lịch .ics. File đính kèm không chứa mã độc, chỉ chứa đường dẫn trỏ tới endpoint OAuth hợp lệ của Microsoft. Công cụ kiểm tra tệp đính kèm thấy file sạch.

   

3. Chuyển hướng qua Microsoft. Đường dẫn được dựng để Microsoft trả về lỗi và chuyển tiếp nạn nhân đi tiếp (cơ chế ở mục dưới).

4. Đi qua Microsoft Teams. Nạn nhân được đưa tới Teams, thêm một domain Microsoft vào chuỗi.

   

5. Tải tài nguyên từ cdn.bloom[.]io. Trang tải nội dung từ CDN của một dịch vụ bên thứ ba.

6. Sinh blob URL. JavaScript tạo đối tượng Blob chứa HTML trang đăng nhập giả và mở nó dưới dạng blob:https://<domain>/<uuid>.

7. Hiển thị trang đăng nhập giả. Trang chỉ tồn tại trong bộ nhớ trình duyệt đó.

   

8. Thu thập và điều phối. Service worker, sandboxed iframe và kênh messaging gửi thông tin đăng nhập về backend, nhận chỉ thị tiếp theo từ cấu hình C2 được giấu.

Ghi chú nguồn: SecurityWeek mô tả file .ics như điểm khởi đầu của chuyển hướng theo cách hơi khác với báo cáo gốc. Bài này theo mô tả của Barracuda.

Cơ chế OAuth error redirect

Nguồn: Barracuda chỉ nói chuỗi tấn công "lạm dụng chuyển hướng của Microsoft", không công bố tham số URL. Phần dưới đây tổng hợp từ nghiên cứu của Microsoft Threat Intelligence (02/03/2026) và các hãng như LevelBlue SpiderLabs, Guardz về kỹ thuật cùng loại. Chưa có xác nhận đây đúng là biến thể dùng trong chiến dịch Barracuda theo dõi.

Kẻ tấn công đăng ký một ứng dụng multi-tenant trong tenant của chúng, khai báo redirect URI là domain chúng kiểm soát. Sau đó dựng đường dẫn dạng:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
  ?client_id=<app_id>
  &response_type=code
  &scope=<invalid_scope>
  &prompt=none
  &state=<value>

Với prompt=none và scope không hợp lệ, Entra ID không thể hoàn tất xác thực im lặng nên trả lỗi (ví dụ 65001 hoặc interaction_required) và chuyển trình duyệt về redirect URI đã đăng ký, tức là về hạ tầng của kẻ tấn công.

Ba điểm cần hiểu đúng:

• Không có token nào bị đánh cắp ở bước này. Mục tiêu là mượn độ tin cậy của login.microsoftonline.com để vượt qua bộ lọc email và cảnh giác của người dùng.

• Gateway email tin domain Microsoft. Guardz nhận định phần lớn secure email gateway không đánh giá sâu đường dẫn trỏ tới endpoint đăng nhập của Microsoft, vì chặn chúng sẽ gây lỗi hàng loạt.

• Tác dụng phụ: xác nhận tài khoản tồn tại. Phản hồi lỗi khác nhau tùy tài khoản có thật hay không, giúp kẻ tấn công lọc danh sách mục tiêu.

Blob URL: cũ về kỹ thuật, mới về kiến trúc

Blob phishing không phải kỹ thuật mới. Cofense ghi nhận từ giữa năm 2022, và chính Barracuda (cùng tác giả Ashitosh Deshnur) đã viết về nó vào 10/2024 với chiến dịch giả mạo Capital One. Blob URL cũng có nhiều ứng dụng hợp lệ, ví dụ YouTube dùng để phát video.

Điều mới ở chiến dịch 2026 là phần kiến trúc quanh blob:

• Service worker chặn và xử lý request trong trình duyệt, cho phép trang hoạt động như một ứng dụng hoàn chỉnh thay vì một form tĩnh.

• Sandboxed iframe cô lập các thành phần, gây khó cho việc phân tích DOM.

• Browser messaging với backend giúp kẻ tấn công quản lý nhiều nạn nhân cùng lúc, phù hợp với mô hình phishing platform có người điều khiển.

• Cấu hình C2 ẩn không nằm trong mã trang tĩnh. Nói cách khác, phiên bản 2022–2024 là "form giả không có URL", còn phiên bản này là một nền tảng phishing chạy trong trình duyệt.

Vì sao phát hiện theo URL mất tác dụng ở đây

Lớp phòng thủ	Nó thấy gì	Kết quả
URL scanner trong email	Link tới login.microsoftonline.com	Sạch
Sandbox mở link	Chuyển hướng qua Microsoft, Teams, CDN	Không thấy trang độc hại nếu không chạy hết chuỗi với đúng điều kiện
Blocklist domain	Microsoft, Teams, CDN SaaS	Không thể chặn
TI feed URL	Blob URL duy nhất cho từng phiên, cục bộ	Không có gì để chia sẻ
Kiểm tra tệp đính kèm	File .ics chỉ chứa lời mời và link	Sạch

Nhận định

Không còn "trang" để chặn. Mô hình phòng thủ dựa trên danh tiếng URL và domain đã bị vô hiệu hóa ở cả hai đầu: đầu vào là domain tin cậy, đầu ra không có URL công khai. Trọng tâm phát hiện phải chuyển sang hành vi trong trình duyệt và tín hiệu định danh.

Passkey là điểm sáng rõ nhất. FIDO2/passkey gắn với origin. Một trang chạy dưới blob: hoặc bất kỳ origin nào không phải origin thật của Microsoft sẽ không nhận được chữ ký hợp lệ, dù trang giả trông hoàn hảo đến đâu. Đây là lý do biện pháp này đứng đầu khuyến nghị.

Báo cáo Barracuda còn mỏng. Không có tham số URL, không có domain backend, không có mẫu. Giá trị của báo cáo nằm ở việc cảnh báo về mô hình tấn công, không phải cung cấp dữ liệu để chặn. Đội SOC nên dùng nó để điều chỉnh mô hình phát hiện thay vì cập nhật blocklist.

cdn.bloom[.]io nhiều khả năng là SaaS hợp lệ bị lạm dụng. Barracuda không nói domain này thuộc kẻ tấn công. Chặn thẳng có thể gây false positive nếu tổ chức dùng dịch vụ đó. Nên theo dõi thay vì chặn mặc định.

Liên hệ Việt Nam

• Microsoft 365 và Teams phổ biến trong khối doanh nghiệp, ngân hàng và cơ quan tại Việt Nam, nên chuỗi chuyển hướng qua hạ tầng Microsoft trông hoàn toàn bình thường với người dùng.

• MFA qua SMS, OTP hay push vẫn là chủ đạo. Các hình thức này không gắn với origin, nên người dùng nhập mã vào trang giả vẫn bị lộ phiên.

• Hóa đơn điện tử và hợp đồng điện tử đã khiến yêu cầu "xem và ký tài liệu" trở nên quen thuộc. Mồi DocuSign hay tương tự dễ lọt qua sự cảnh giác.

• Tổ chức chỉ dựa vào lọc URL ở email gateway sẽ không có lớp phòng thủ nào khác trước chuỗi này.

Khuyến nghị

• Triển khai FIDO2/passkey cho tài khoản quản trị và tài khoản có quyền truy cập dữ liệu nhạy cảm trong Microsoft 365, sau đó mở rộng dần.

• Giám sát luồng OAuth bất thường: request /authorize có prompt=none kèm scope lạ, và các đợt tăng đột biến lỗi Entra 65001 hoặc interaction_required từ cùng một client_id lạ.

• Hạn chế user consent cho ứng dụng bên ngoài và định kỳ rà soát các ứng dụng multi-tenant xuất hiện trong tenant.

• Giám sát hành vi trình duyệt qua EDR hoặc giải pháp bảo mật trình duyệt: trang đăng nhập hiển thị dưới blob:, service worker đăng ký từ nội dung bên ngoài ngay sau chuỗi chuyển hướng.

• Phân tích toàn bộ click-path trong email thay vì chỉ URL đầu tiên, và xử lý link tới endpoint OAuth của Microsoft như một trường hợp cần đánh giá riêng, không mặc định tin tưởng.

• Đào tạo nhận thức: hạ tầng Microsoft không đồng nghĩa với an toàn; yêu cầu ký tài liệu bất ngờ cần được xác minh qua kênh khác.

Tài liệu tham khảo

• Barracuda — Browser-resident phishing (09/09/2026): https://blog.barracuda.com/

• SecurityWeek — New Phishing Attack Creates Malicious Pages Inside the Victim's Browser: https://www.securityweek.com/new-phishing-attack-creates-malicious-pages-inside-the-victims-browser/

• Microsoft Threat Intelligence — nghiên cứu về lạm dụng OAuth redirect (02/03/2026)

• LevelBlue SpiderLabs — phân tích OAuth redirect abuse

• Guardz — phân tích việc email gateway tin tưởng endpoint Microsoft

• Cofense — blob URL phishing (2022)

• Barracuda — blob URL phishing giả mạo Capital One (10/2024)

• Barracuda — Browser-in-the-Browser (08/09/2026)

• Barracuda — phishing qua lời mời lịch .ics (08/2026)