Một chiến dịch password spray tự động quy mô lớn đang tích cực lạm dụng Microsoft Azure Command-Line Interface (CLI) và các luồng OAuth cũ để xâm phạm tài khoản Entra ID, bất chấp việc các tổ chức đã triển khai xác thực đa yếu tố (MFA).
Tấn công Password Spray trên Azure CLI và OAuth
Huntress đang theo dõi một chiến dịch password spray và token kéo dài nhắm vào các đăng nhập Microsoft 365 và Azure CLI. Hoạt động này đã tăng đột biến trong khoảng thời gian từ ngày 12 đến ngày 26 tháng 6 năm 2026.
Trong 14 ngày này, kẻ tấn công đã thực hiện hơn 81 triệu lần đăng nhập vào các tenant của khách hàng Huntress và chiếm quyền điều khiển thành công ít nhất 78 tài khoản Microsoft trên 64 tổ chức. Số lượng tài khoản bị xâm phạm hàng ngày ban đầu ở mức thấp, thường là hai đến bốn tài khoản mỗi ngày, trước khi tăng vọt lên 30 danh tính người dùng trên 23 doanh nghiệp vào ngày 22 tháng 6, đánh dấu một sự kiện leo thang rõ ràng trong chiến dịch.
Hoạt động này là một phần của xu hướng rộng lớn hơn: Huntress báo cáo rằng khối lượng password spray trên cơ sở khách hàng của họ đã tăng hơn 155 lần trong sáu tháng qua, với mức trung bình hiện tại khoảng 1.964 cuộc tấn công thất bại mỗi tenant mỗi tháng và trung vị là 804.
Lựa chọn Mục tiêu
Việc lựa chọn mục tiêu dường như được thúc đẩy bởi sự phổ biến của mật khẩu trong các danh sách kết hợp (combo lists) hiện có, thay vì theo ngành hoặc lĩnh vực. Điều này cho thấy sự lạm dụng cơ hội đối với các thông tin xác thực đã bị xâm phạm trước đó và chưa được xoay vòng.
Nguồn Gốc Lưu Lượng Tấn Công
Phần lớn lưu lượng tấn công quan sát được bắt nguồn từ dải địa chỉ IPv6 2a0a:d683::/32, được công bố dưới hệ thống tự trị AS32167 và được quy cho nhà cung cấp hạ tầng Internet LSHIY LLC. LSHIY vận hành ít nhất hai ASN — AS32167, đăng ký vào tháng 6 năm 2021 và AS955, đăng ký vào tháng 6 năm 2022 — với dữ liệu đo lường từ bên thứ ba thường xuyên liên kết các tiền tố IPv6 của họ với nguồn gốc Trung Quốc.
Hồ sơ đăng ký doanh nghiệp liên kết LSHIY với các địa chỉ nhà máy ở Hồng Kông và Vũ Hán, cũng như một không gian văn phòng chung tại 42 Broadway, New York. Cấu trúc này làm mờ đi quyền sở hữu hoạt động thực tế. Huntress đã gửi báo cáo lạm dụng tới LSHIY liên quan đến hoạt động quan sát được nhưng chưa nhận được phản hồi.
Cơ chế Tấn công: Lạm dụng Luồng ROPC
Kẻ tấn công đang phát lại các cặp tên người dùng-mật khẩu cũ đã bị lộ trong các vụ xâm phạm trước đó nhưng chưa bao giờ được xoay vòng. Họ xác thực các cặp thông tin này thông qua luồng OAuth Resource Owner Password Credentials (ROPC) được sử dụng bởi Azure CLI.
ROPC, một luồng đã bị loại bỏ trong OAuth 2.1, trao đổi tên người dùng và mật khẩu thô trực tiếp tại điểm cuối token và cấp phát các token truy cập được ủy quyền bởi người dùng mà không có bước ủy quyền tương tác. Do các Chính sách Truy cập Có Điều kiện (Conditional Access Policies – CAP) thường thực thi MFA tại điểm cuối ủy quyền, ROPC có thể bỏ qua các chính sách được cấu hình kém. Điều này dẫn đến việc cấp phát token thành công mà không có yêu cầu MFA.
Lỗ hổng trong Cấu hình Conditional Access Policies (CAP)
Huntress phát hiện ra rằng nhiều tenant bị ảnh hưởng đã triển khai MFA và CAP nhưng có những lỗ hổng cấu hình nghiêm trọng. Các trường hợp thất bại phổ biến bao gồm việc giới hạn phạm vi áp dụng MFA cho các ứng dụng đám mây cụ thể thay vì “Tất cả Ứng dụng Đám mây”, chỉ thực thi MFA cho các nhóm đặc quyền như quản trị viên, giới hạn MFA cho các vị trí không đáng tin cậy, và để các chính sách ở chế độ chỉ báo cáo (report-only).
Trong một số trường hợp, sự không nhất quán về định vị địa lý đã gán sai các địa chỉ IP tấn công là địa chỉ Hoa Kỳ, cho phép chúng lọt qua logic “vị trí đáng tin cậy” ngay cả khi các dữ liệu đo lường khác đặt chúng ở Trung Quốc.
Các Biện pháp Phòng ngừa và Khuyến nghị
Huntress và các nhà nghiên cứu khác khuyến nghị các tổ chức coi Azure CLI và ROPC là các bề mặt rủi ro cao và điều chỉnh cấu hình CAP tương ứng. Việc này giúp giảm thiểu nguy cơ bảo mật tiềm ẩn.
Cấu hình CAP Mạnh mẽ
Quản trị viên nên yêu cầu MFA hoặc chặn hoàn toàn quyền truy cập cho tất cả người dùng, tất cả ứng dụng đám mây và tất cả các loại ứng dụng khách. Đồng thời, cần thực thi xác thực mạnh mẽ ở cấp độ ứng dụng khách (ví dụ: sử dụng cài đặt userStrongAuthClientAuthNRequired) để ngăn chặn việc cấp token dựa trên ROPC.
Nếu có thể, Azure CLI nên được giới hạn cho người dùng không phải quản trị viên thực sự cần nó, hoặc bị chặn rõ ràng thông qua các quy tắc CAP chuyên dụng. Đây là một phần quan trọng của chiến lược an ninh mạng.
Tăng cường các Chính sách Bảo mật khác
Ngoài ROPC, các tổ chức nên vô hiệu hóa các luồng cấp phép cũ và các giao thức xác thực lỗi thời. Việc siết chặt các vị trí được đặt tên và liên tục kiểm tra hành vi của CAP bằng các công cụ như trình mô phỏng “What If” của Microsoft để xác định các chính sách ở chế độ chỉ báo cáo hoặc bị loại trừ là rất cần thiết.
Việc cập nhật bản vá và rà soát cấu hình định kỳ là chìa khóa để duy trì an toàn thông tin trước các mối đe dọa mới.
Nguồn tham khảo chi tiết hơn về chiến dịch này có thể tìm thấy tại Huntress Blog.
