Người dùng Microsoft 365 đang đối mặt với một kỹ thuật tấn công phishing mới, khai thác sự thay đổi nhỏ trong trình gửi email. Kẻ tấn công bỏ trống trường SMTP envelope sender.
Khai thác Lỗ hổng Bảo mật trong Microsoft 365
Việc bỏ trống trường người gửi này cho phép một thông điệp chưa được xác thực vượt qua cơ chế bảo vệ Direct Send. Đồng thời, người dùng vẫn nhìn thấy một địa chỉ email trông có vẻ thuộc về tổ chức của họ.
Kỹ thuật này không phải là lỗi phần mềm của Microsoft và không yêu cầu tài khoản bị đánh cắp. Nó lợi dụng cách cơ chế RejectDirectSend của Exchange Online kiểm tra tên miền trong envelope sender, thay vì địa chỉ hiển thị trong trường From.
Sự khác biệt này tạo điều kiện cho tội phạm mạng thực hiện các hành vi giả mạo danh tính. Nó loại bỏ một rào cản được thiết kế để ngăn chặn một hình thức thư lừa đảo đặc biệt rủi ro.
Phát hiện Kỹ thuật Tấn công mới
Các nhà nghiên cứu tại ReliaQuest đã xác định được phương thức này trong các trường hợp phishing đang hoạt động và tái hiện thành công trong một môi trường Microsoft 365 được kiểm soát. Theo báo cáo của ReliaQuest, kỹ thuật này đã xuất hiện lặp đi lặp lại tại nhiều tổ chức không liên quan trong suốt một năm qua.
Một thông điệp giả mạo nội bộ có thể chứa thông báo tài liệu, yêu cầu thanh toán hoặc lời mời xem thư thoại. Ngay cả khi các bộ lọc email phát hiện một số nỗ lực, bất kỳ thông điệp nào đến được người nhận đều tạo cơ hội cho việc đánh cắp thông tin đăng nhập, phân phối mã độc, chuyển tiền gian lận và chiếm quyền kiểm soát hệ thống rộng hơn.
Direct Send cho phép các thiết bị và ứng dụng gửi email trong cùng một tenant Microsoft 365 mà không cần xác thực. Các báo cáo trước đây về việc Microsoft 365 Direct Send bị khai thác đã ghi nhận kẻ tấn công giả mạo người dùng nội bộ mà không cần chiếm quyền tài khoản.
Cơ chế RejectDirectSend và Cách Bị Vượt Qua
Cơ chế RejectDirectSend được thiết kế để từ chối các thư Direct Send chưa được xác thực nhưng lại khai báo đến từ tên miền được chấp nhận của tổ chức. ReliaQuest đã gửi hai thông điệp đến máy chủ thư của một tenant.
Thông điệp sử dụng tên miền của tenant trong envelope sender đã bị từ chối. Tuy nhiên, một thông điệp khác sử dụng lệnh SMTP MAIL FROM: đã được chấp nhận và đưa vào hàng đợi.
Người nhận vẫn thấy cùng một địa chỉ hỗ trợ IT nội bộ trong trường From hiển thị. Do envelope sender bị trống và không chứa tên miền, cơ chế RejectDirectSend không có gì để so sánh với các tên miền được chấp nhận của tenant.
Do đó, điều kiện từ chối của cơ chế này không được áp dụng, mặc dù thông điệp đến từ một nguồn bên ngoài chưa được xác thực. Việc chấp nhận không có nghĩa là thông điệp sẽ đến hộp thư đến (inbox). Microsoft 365 đã đánh dấu thông điệp thử nghiệm là ẩn danh, gán điểm Spam Confidence Level là 9 và gửi vào thư mục Junk Email sau khi SPF và DKIM không trả về kết quả và DMARC thất bại.
Tuy nhiên, kết quả lọc có thể khác nhau tùy thuộc vào nội dung, cơ sở hạ tầng, cấu hình và các ngoại lệ cho người gửi tin cậy. Trong một trường hợp, một thông điệp thất bại mọi kiểm tra xác thực người gửi đã được phân loại là phishing có độ tin cậy cao nhưng vẫn đến được hộp thư đến vì người bị giả mạo (giám đốc điều hành) là một người gửi được phép.
Các tổ chức tuân theo hướng dẫn cấu hình xác thực email cũng nên xem xét các ngoại lệ có thể ghi đè các kiểm tra này.
Phạm vi và Tác động của Tấn công
ReliaQuest đã xem xét các ví dụ từ tháng 9 năm 2025 đến tháng 8 năm 2026 nhắm vào các giám đốc điều hành, quản lý, nhân viên tài chính, đội mua sắm và các vai trò tiếp xúc với khách hàng. Những cá nhân này thường xuyên xử lý hóa đơn, báo giá, tệp chia sẻ và hướng dẫn thanh toán, làm cho ngôn ngữ kinh doanh trở nên thuyết phục.
Các thông báo chia sẻ tệp là phổ biến nhất, tiếp theo là yêu cầu thanh toán và chuyển tiền, lời mời mua sắm, đề nghị vay hoặc đầu tư và lời mời họp. Một số thông điệp sử dụng tệp đính kèm SVG được ngụy trang dưới dạng bản ghi âm thanh.
Phương thức này tương tự như các báo cáo về các tệp phishing sử dụng SVG làm vũ khí, có thể kích hoạt chuyển hướng trình duyệt thay vì hoạt động như hình ảnh. Các nhóm bảo mật nên giữ lại cơ chế RejectDirectSend nhưng không coi đó là một biện pháp phòng thủ hoàn chỉnh.
Các Biện pháp Bảo vệ và Khuyến nghị
Một cổng kết nối inbound giới hạn theo địa chỉ IP cho phép Direct Send chưa được xác thực chỉ từ các thiết bị và ứng dụng đã phê duyệt. Cơ chế này đã chặn mọi nỗ lực Direct Send, bao gồm cả những nỗ lực có envelope sender trống.
Quản trị viên nên xác định các hệ thống thực sự cần Direct Send và giới hạn chặt chẽ các địa chỉ IP nguồn được phê duyệt. Loại bỏ các ngoại lệ lọc không cần thiết, bao gồm người gửi được phép, tên miền được phép, mục người gửi an toàn và các quy tắc thay đổi điểm spam.
Các trường hợp giả mạo email nội bộ trước đây cho thấy lý do tại sao các tuyến đường tin cậy và các quy tắc linh hoạt cần được xem xét kỹ lưỡng. Cuối cùng, các nhà phòng thủ nên tìm kiếm các trường hợp envelope sender trống kết hợp với địa chỉ From hiển thị trong một tên miền nội bộ được chấp nhận, khác biệt với thư trả lại (bounce mail).
Ưu tiên các cảnh báo mà SPF, DKIM hoặc DMARC cũng thất bại nhưng thông điệp vẫn được gửi thành công thông qua một quy tắc ghi đè. Nhân viên nên xác minh các yêu cầu thanh toán, tài liệu hoặc truy cập bất ngờ thông qua một kênh đã biết trước khi hành động. Việc kiểm tra này nên được thực hiện trước khi phản hồi hoặc mở tệp đính kèm.
